RE: [dhcwg] Gen-ART review of draft-ietf-dhc-container-00

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



While this is certainly an interesting point, I don't really see that it
is specific to the container option or that the container option adds
any new or different issues?

I don't see why this would hold up this draft (perhaps it is not holding
it up)? Perhaps at most some statement(s) about the issue should be
added to the draft.

If there was no container option, the RG would have to extract those
options it received that it thought where of interest to the client and
pass them on when the client requested them.

So, whether there is a container option or not does not change anything
(it just makes it easier to deliver information the RG for its clients
and to potentially deliver different information to the RG's clients
from what is given the RG itself).


The issue of how a multi-homed device decides to use sources of
information is certainly an interesting one, but no different than what
has existed for years with multi-homed clients.

I guess one choice for those developing multi-interface RGs is to
provide configuration for which interface(s) options are to be
'preferred' over others. In the simple case, this could be just a
preference value that applies to any information from that interface. In
more complex cases, one might envision policy that would indicate a
preference on an option-by-option basis, with even the ability to merge
data from multiple interfaces (in perference order). Though, this
doesn't account for mobile RGs which might be connecting to vastly
different services over the same interface(s) depending on where they
are located (with the preferences for the interface changing based on
the provider).

- Bernie 

-----Original Message-----
From: dhcwg-bounces@xxxxxxxx [mailto:dhcwg-bounces@xxxxxxxx] On Behalf
Of Ralph Droms (rdroms)
Sent: Friday, April 10, 2009 3:26 PM
To: Scott Brim
Cc: dhc WG; gen-art@xxxxxxxx; Black_David@xxxxxxx; ietf@xxxxxxxx
Subject: Re: [dhcwg] Gen-ART review of draft-ietf-dhc-container-00

Scott raises an interesting point about identifying the source of  
options when delivered to clients.

BTW, Scott - what is "DHS"?

The usual case - almost the only case today - is that there is a  
single upstream service provider and a single source of DHCP options  
to be passed along to the client.  In this scenario, there's no need  
to pass along any information identifying the source of the options.

To allow for a multihomed subscriber network, I can imagine adding a  
tag that would be passed along with the options so the subscriber  
client can identify the source of each option.  But, what would the  
client do with that information?  How would the client interpret it?   
What is the syntax and semantics of the tagging?

Taken a step farther, sourcing information might be required even if  
there is no intermediate RG and the contained option is not in use.   
How does a device with multiple interfaces make policy decisions about  
information received on those multiple interfaces (which is pretty  
much the question Scott asks about the container option)?

- Ralph

On Apr 7, 2009, at 2:25 PM 4/7/09, Scott Brim wrote:

> I have been selected as the General Area Review Team (Gen-ART)
> reviewer for this draft (for background on Gen-ART, please see
> http://www.alvestrand.no/ietf/gen/art/gen-art-FAQ.html).
>
> Please wait for direction from your document shepherd
> or AD before posting a new version of the draft.
>
> Document: draft-ietf-dhc-container-00
> Reviewer: Scott Brim
> Review Date:         7 April 2009
> IESG Telechat date: 14 April 2009
>
> Summary:
>
> This draft is on the right track but has open issues.
>
> Comments:
>
> More significant:
>
>   I am concerned about multiple interface scenarios as are being
>   discussed in MIF and 6MAN, where either the RG is multiply connected
>   or the end device is.  For a discussion of the sort of problems that
>   lead to this concern, see (for example) notes from the MIF BOF at
>   IETF74.
>
>   - There must be a way to associate options with a particular
>     upstream DHS they were obtained from, when the container is passed
>     to the RG server and perhaps to the end device.  This source
>     information may or may not be in the container itself -- that's up
>     to the WG to decide.  If it is decided that the source information
>     will not be part of the container syntax, at least the fact that
>     it is necessary should be documented for people who ultimately do
>     specify how container options are passed.
>
>   - The SP server may have its ideas of how a consumer device should
>     be configured, but it is not appropriate to say that the "SP
>     server MUST be able to control which DHCP options are transmitted
>     to the consumer device".  The RG server may need to make decisions
>     about information from multiple DHCP servers.  Perhaps you could
>     say that the SP server MUST be able to "provide information" to
>     the RG server.
>
> Less significant:
>
>   5.1 and 5.2
>
>     Alignment between the v4 and v6 descriptions would be better. The
>     v4 description has "code" in the diagram and says that "code" is
>     OPTION_CONTAINER_V4.  The v6 description has "OPTION_CONTAINER_V6"
>     in the diagram and says that "option-code" is OPTION_CONTAINER_V6.

_______________________________________________
dhcwg mailing list
dhcwg@xxxxxxxx
https://www.ietf.org/mailman/listinfo/dhcwg
_______________________________________________

Ietf@xxxxxxxx
https://www.ietf.org/mailman/listinfo/ietf

[Index of Archives]     [IETF Annoucements]     [IETF]     [IP Storage]     [Yosemite News]     [Linux SCTP]     [Linux Newbies]     [Fedora Users]