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

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

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

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.


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.)

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