Re: [dhcwg] I-D Action: draft-ietf-dhc-relay-id-suboption-08.txt

["Bernie Volz (volz)" <[e-mail]>]

I do think that we've discussed this to bits and it really is up to you
how you want to proceed.

- Bernie

-----Original Message-----
From: Bharat Joshi [mailto:[e-mail]] 
Sent: Tuesday, June 14, 2011 12:46 PM
To: Bernie Volz (volz); Mark Stapp (mjs)
Cc: [e-mail]
Subject: RE: [dhcwg] I-D Action:
draft-ietf-dhc-relay-id-suboption-08.txt

Bernie,

>so the question is: can a DUID-based relay identifier be administered?
> if so, 
> >then we can return that suggestion to the draft. if not, we'll stick
> with 
> >'opaque'. in either case, we'll add text to make it clear that the
> identifier 
> >needs to be administratively-unique.
> 
> Regarding the DUID, that is a complex issue and question. For a device
> with storage, if you moved the storage to another device, it would
> retain the DUID. So, the DUID is not really something that is
hardwired
> in this case. Of course, this really only applies to DUID-LLT as that
is
> the only type that needs to be stored. (The other types are generated
> from 'hardwired' data and thus need no storage.)
> 
> 
> I really don't see why you don't do both?

Actually we end up removing DUID from the draft because we could not
find a use-case for DUID as relay-id.

The two use-cases in this draft needs an administratively configured
relay-id.

Can you think of any scenario where a DUID relay-id could be useful?

> The default identifier that can be used by any device 'out of the box'
> is the DUID type. Nothing has to be configured for the device to use
> this.
> 
> If the administrator optionally configures an alternative 'opaque'
> identifier, then the device uses that instead - with the understanding
> that it is up to the administrator to assure that this identifier is
> unique.
> 
> Hence, leave the type byte and have the two forms. You get both
> capabilities - an identifier that can be used without any
configuration
> and an identifier that can be used in a case where a stable identifier
> across multiple potential "replacement" devices works.

The 'type' field came from previous revisions. I think we had
unfortunately assumed that DHCP server may parse/interpret the relay-id
and so this type field was kept here to indicate what kind of relay-id
this sub-option is carrying.

After looking at the use cases again, we think we can remove it as DHCP
server would never need to parse/interpret it and relay-agent will
always know what it has used in relay-id sub-option.

Let me know what you think?

> 
> It is an interesting question as to whether we might want to think
about
> a DUID-OI (Opaque Identifier) at some point to accommodate "locally
> administered" identifiers. These would NOT be allowed except when
> administratively configured with the understanding that the
> administrator must assure it is unique. This would then preclude the
> need for a type byte in this suboption and also be useable by DHCPv6
> relay agents. One could even envision that part of the identifier
might
> include a randomly generated value along the idea of the IPv6 Unique
> Local Addresses (ULA) [probably just use the ULA?] as that could avoid
> some issues when two administrative domains are collapsed into one.
> Perhaps a draft I should think about writing? (If this has merit,
> perhaps then your draft is simplified as all it needs to state is
using
> the DUID.)

Yes. I agree. This might be useful. Some time back I think Mark and I
were discussing whether we need an administratively configured DUID
which can be reused.

Thanks,
Bharat

> The DUID-OI data format could be 6+<n> octets:
> - 6 octets of the 48-bit ULA value (see RFC 4193 - this includes 7-bit
> prefix (FC00::/7), L bit, and 40 bit Global ID.)
> - <n> octets that follow which are the unique identifier.
> 
> - Bernie
> 
__
-----Original Message-----
From: Mark Stapp (mjs)
Sent: Monday, June 13, 2011 9:39 AM
To: Bernie Volz (volz)
Cc: Bharat Joshi; [e-mail]
Subject: Re: [dhcwg] I-D Action:
draft-ietf-dhc-relay-id-suboption-08.txt

Hi Bernie,

yes, I'd also prefer to use a single suboption for this purpose.

on the issue of the use of DUID, there's a disagreement. I understood
Ted to say
that he objected very strongly to any text that proposed 'moving' a DUID
from
one device to another, or administratively managing DUIDs. I'll let Ted
speak
for himself, of course, but that's a fundamental issue for this draft.

the brief history is:

- initial draft just describes opaque identifier, offers two suggestions
for
assigning id: ascii string and DUID-generating algorithm
- someone in WG discussion (David Hankins, maybe?) asked that there be a

type-byte. type byte was added.
- Ted realized that the draft was proposing to assign DUID generated as
relay-id
by one device to another device, and objected
- Bharat re-issued draft sort of back at initial state, with just opaque
id, and
no implication that DUID was appropriate

so the question is: can a DUID-based relay identifier be administered?
if so,
then we can return that suggestion to the draft. if not, we'll stick
with
'opaque'. in either case, we'll add text to make it clear that the
identifier
needs to be administratively-unique.

Thanks,
Mark


On 6/13/11 8:59 AM, Bernie Volz (volz) wrote:
> First, let me say that I'd MUCH prefer a type field over multiple
> suboptions if we feel there is likely to be a need for multiple
> identifiers. The reason is that with multiple suboptions, a relay
would
> potentially need to send more than one (in case a server didn't
support
> one of the newer suboptions) and it would be much more difficult to
> determine which to use / which was used (from the server's / relay's
> perspective).
>
> Second, a DUID is tied to a device (at least the default DUID) but
there
> is nothing that says you can't configure a replacement device to use
the
> same DUID as the previous device - though obviously you have to be
> careful to assure that the previous device no longer uses that DUID
> (either because it is discarded or because it is re-initialized and
> generates a new DUID, if DUID-LLT).
>
> Third, I think if you stick with an opaque identifier, you would need
to
> be clear to add text that says something like a relay MUST NOT
generate
> this identifier nor use it until it is ADMINISTRATIVELY configured and
> it is up to the administrator then to assure it is unique across the
> administrative domain. There is nothing in the draft that states this.
>
> Fourth, I think having a DUID based identifier is the best option for
> most cases. If you want the industrial Ethernet environment where you
> need something that is stable across devices, then add a type that
> allows this administratively configured identifier. But as a general
> relay identifier I would use the DUID.
>
> So, you might define:
>       Type = 1 - DUID (default type)
>       Type = 2 - Opaque identifier (must only be used if
> administratively configured on the device and requires administrator
to
> assure it is unique).
>
> - Bernie
>
> -----Original Message-----
> From: Bharat Joshi [mailto:[e-mail]]
> Sent: Monday, June 13, 2011 2:45 AM
> To: Bernie Volz (volz)
> Cc: Mark Stapp (mjs); [e-mail]
> Subject: RE: [dhcwg] I-D Action:
> draft-ietf-dhc-relay-id-suboption-08.txt
>
> Hi Bernie,
>
>       Thanks a lot for the quick review. Please see my response in
line.
>
> Regards,
> Bharat
>
>> Hi ... I've decided to add the DHC WG as this is a document being
> worked
>> on there.
> Yes. No issues.
>
>> Personally, I'd switch section 3.1 and 3.2 (bulk LQ is a much
stronger
>> argument for this).
> That make sense. I can surely do this in next revision.
>
>> And, I doubt the IESG will be happy with this document and leaving
the
>> actual identifier as completely opaque!  How would this identifying
> data
>> be assured to be unique if it is just defined as a 'series of
octets'?
> The draft suggest that this opaque identifier be administratively
> configured and there should be a mean to display this to the
> administrator. So we expect administrator to be able to take care of
> keeping it unique in their own administrative domain.
>
>> I also fail to see why the DUID isn't being recommended as the
> standard
>> format for this relay identifier? See RFC 5460 section 5.4,
>> OPTION_RELAY_ID.
> The previous version of this draft had suggested the use of DUID. But
we
> had to remove it because our use cases required that same relay-id be
> used even if the device is replaced.
>
>> And, thus do we really need a type field in the option? Isn't just a
>> DUID sufficient?
> That 'type' field was kept from the previous revision, for the future
> extensibility. At present, we feel that an opaque relay-id fulfils
works
> for our use-cases but in future that may be other use-cases which
might
> want to use a different type of relay-id.
>
> In fact, Ted and Pavan had a similar comments. If most of the people
> feel that we can define a new sub-option when such a requirements
comes,
> we can remove this 'type' field.
>
>> I'd also say that for "compatibility" with DHCPv6, using the DUID as
> the
>> relay identifier too would be really convenient and appropriate. This
>> also means section 6 can probably be significantly scaled back - the
>> only issue is the unicast RENEW.
> I am not sure if using DUID for the use-cases mentioned in this draft
> will be appropriate.
>
> We had to come out with this new revision because it was pointed out
> that DUID cannot be used where same id is required even when the
devices
> are replaced.
>
> Once we decide upon whether we can use DUID or not, we can discuss
other
> points which you have raised here.
> **************** CAUTION - Disclaimer *****************
> This e-mail contains PRIVILEGED AND CONFIDENTIAL INFORMATION intended
> solely
> for the use of the addressee(s). If you are not the intended
recipient,
> please
> notify the sender by e-mail and delete the original message. Further,
> you are not
> to copy, disclose, or distribute this e-mail or its contents to any
> other person and
> any such actions are unlawful. This e-mail may contain viruses.
Infosys
> has taken
> every reasonable precaution to minimize this risk, but is not liable
for
> any damage
> you may sustain as a result of any virus in this e-mail. You should
> carry out your
> own virus checks before opening the e-mail or attachment. Infosys
> reserves the
> right to monitor and review the content of all messages sent to or
from
> this e-mail
> address. Messages sent to or from this e-mail address may be stored on
> the
> Infosys e-mail system.
> ***INFOSYS******** End of Disclaimer ********INFOSYS***
>