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

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

 



Hi, Scott,

Based on the current MIF charter proposal, it consider only host.
http://www.ietf.org/mail-archive/web/mif/current/msg00367.html
I am wondering whether RG is a kind of host?

Anyhow, this discussion benefit MIF for the future consideration how
to identify the source.

Many thanks

-Hui

2009/4/11 Scott Brim <swb@xxxxxxxxxxxxx>:
> Excerpts from Ralph Droms on Fri, Apr 10, 2009 03:25:49PM -0400:
>> Scott raises an interesting point about identifying the source of
>> options when delivered to clients.
>>
>> BTW, Scott - what is "DHS"?
>
> Sorry, DHCP server
>
>> 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
>
> Well put.  It all comes down to where information is going to be
> merged.  The case where a single RG client connected to multiple SP
> servers is essentially already covered by MIF/6man, they just need to
> document it.  If the information is merged at the RG server, then the
> RG server should somehow know which interface which DHCP information
> came from.  If all of the information is transparently passed to the
> consumer device, then it needs the tags as well.
>
> I don't know how the information could be usefully tagged -- the SP
> server's IP address doesn't sound like a good idea.  The WG should
> decide if tagging should be included in the container syntax or added
> later (but documented now as needing study).
>
> I'm CCing MIF in case people there aren't on the ietf list.
>
> Thanks ... Scott
>
>>
>> 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]