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

[Mark Stapp <[e-mail]>]

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***
>