agree with what Ray says. that gives a path forward for 4rd without requiring us to settle the interface-id structure question.
cheers, Ole On Jan 31, 2013, at 11:26 , Ray Hunter <v6...@globis.net> wrote: >> GangChen <mailto:phdg...@gmail.com> >> 31 January 2013 08:53 >> 2013/1/30, Ray Hunter <v6...@globis.net>: >>> inline. >>> >>> Ole Troan wrote: >>>> Brian, >>>> >>>>>>>> - If agreed on the principle, and if no one else volunteers, I can be >>>>>>>> available to propose a draft to this effect. >>>>>>> Seems reasonable. >>>>>>> >>>>>>> >>>>>>>> (e) With the 16-bit 4rd IID prefix, only 1/2^14 of the unused set of >>>>>>>> IIDs having u=1 is reserved. This leaves plenty of space for future >>>>>>>> uses of IIDs having u= as explicitly expected in RFC 4291. >>>>>>> That goes to the argument of (d), that it isn't harmful to assign >>>>>>> some space to 4rd. >>>>>> I still think we need to answer the question Brian raised. >>>>>> should the interface-id have any encoded meaning? >>>>> That will not be done overnight. I've been thinking about it and >>>>> have some ideas about how to write a discussion draft, but it is >>>>> unfortuante to make the 4rd work queue behind us. Is there any risk >>>>> in doing as Rémi suggested? >>>> it depends on what the expected meaning of a reservation is. >>>> should all implementations treat the reserved part of the interface-id as >>>> martian, >>>> and prohibit a user from configuring it for another purpose than 4rd? >>>> >>>> or is it just a 'suggestion' for interface-id's that the 4rd mechanism can >>>> use, and the operator >>>> deploying it will make sure there are no conflicts? >>> my 2 cents. >>> >>> If 4rd is truly experimental then indeed I think it's up to the >>> operators deploying it to ensure they choose a unique IID range within >>> the scope of where they are operating 4rd (between tunnel endpoints and >>> the tunnel gateway). My initial concerns were that this could cause harm >>> even in experimental form, but I've convinced myself that it shouldn't. >>> In this case I see no need for a hard global IID reservation, because at >>> the moment, u=1 g=1 isn't used for creating IID's for use with SLAAC. >> >> Just some comments from operational views. I guess it's true operators >> could avoid confliction with u=1 g=1 in near future. However, I >> believe that is relative short-term guarantee with the condition of a >> particular operational domain. The term of "experimental" is not >> really mean "experimental" to a commercial network. It would be safe >> for operations if there is legitimate registry to ensure there is no >> need to renumbering. Therefore I prefer Remi's proposal (e) to grant >> 4rd 0x0300. >> >> Best Regards >> >> Gang >> > > I disagree. > > See http://www.ietf.org/iesg/informational-vs-experimental.html > > IMVHO "Experimental" means everything could change: including a need for > mass renumbering or equipment replacement. > > Publication is "Subject only to editorial considerations and to > verification that there has been adequate coordination with the > standards process." No guarantees. The test I am currently applying when > reviewing this ID is whether the experiment is likely to cause harm. > > I see no compelling reason at this time to define a global reservation > or an explicit IID structure in order for the experiment to be able to > proceed and succeed. On the other hand, adding a reservation and > structure to the IID at this time would likely impact other > implementations (e.g. packet classifiers) and existing documents and IDs > (e.g. address selection). > > If you want 4rd to be "informational" or "standards track" I also think > that's worth discussing, but then I also think there's a lot more to > specify and discuss beyond the current ID. > >>> On the other hand, If 4rd is not truly experimental, or it's expected to >>> work universally across AS boundaries, I suspect the WG will have to >>> wait for an answer to Brian's question on whether structure within the >>> IID is desirable. I don't think there's any clear consensus so far on >>> that point (indeed there are some counter posts saying structure within >>> the IID is undesirable). >>> >>> My own particular concern here is that there is a danger of creating a >>> precedent of a completely new class of IPv6 addressing by the back door >>> without this being fully and properly debated i.e. address ranges that >>> don't perform DAD, and that are associated directly with a certain >>> tunnel or transport protocol, and yet which are assigned within the >>> generic GUA space, but perhaps which overlap with other IPv6 prefix >>> spaces too. >>> >>> e.g. 1 What in draft-ietf-softwire-4rd-04 prevents tunnel space used by >>> 6to4 (2002::/16) being associated with 4rd IIDs? >>> >>> e.g. 2 How would this new class of IID encoded ranges/tunnel/transport >>> protocols interact with RFC6724 and draft-ietf-6man-addr-select-opt-08 >>> (both of which assume that bit-contiguous left-anchored IPv6 prefixes >>> map to transport protocols, not individual IID bits)? >>> >>> These questions probably have little relevance to 4rd being deployed in >>> an experimental situation, and I think we should perhaps try to keep >>> them decoupled as far as possible. >>> >>>> one of my concerns is that continuing to add the interface-id bits, is the >>>> opposite direction of where >>>> I want us to go. >>>> >>>> I wouldn't object to non-normative language in 4rd suggesting a >>>> interface-id to use, without >>>> creating any expectation that new or existing IPv6 implementations have to >>>> change. >>>> >>>> that said, 4rd will work perfectly well _without_ this reservation, so I >>>> don't buy the argument that >>>> we're holding up the 4rd work. >>>> >>>> cheers, >>>> Ole >>>> >>>> >>> -------------------------------------------------------------------- >>> IETF IPv6 working group mailing list >>> ipv6@ietf.org >>> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 >>> -------------------------------------------------------------------- >>> >> Ray Hunter <mailto:v6...@globis.net> >> 30 January 2013 16:59 >> inline. >> >> Ole Troan wrote: >>> Brian, >>> >>>>>>> - If agreed on the principle, and if no one else volunteers, I can be >>>>>>> available to propose a draft to this effect. >>>>>> Seems reasonable. >>>>>> >>>>>> >>>>>>> (e) With the 16-bit 4rd IID prefix, only 1/2^14 of the unused set of >>>>>>> IIDs having u=1 is reserved. This leaves plenty of space for future >>>>>>> uses of IIDs having u= as explicitly expected in RFC 4291. >>>>>> That goes to the argument of (d), that it isn't harmful to assign >>>>>> some space to 4rd. >>>>> I still think we need to answer the question Brian raised. >>>>> should the interface-id have any encoded meaning? >>>> That will not be done overnight. I've been thinking about it and >>>> have some ideas about how to write a discussion draft, but it is >>>> unfortuante to make the 4rd work queue behind us. Is there any risk >>>> in doing as Rémi suggested? >>> it depends on what the expected meaning of a reservation is. >>> should all implementations treat the reserved part of the interface-id as >>> martian, >>> and prohibit a user from configuring it for another purpose than 4rd? >>> >>> or is it just a 'suggestion' for interface-id's that the 4rd mechanism can >>> use, and the operator >>> deploying it will make sure there are no conflicts? >> my 2 cents. >> >> If 4rd is truly experimental then indeed I think it's up to the >> operators deploying it to ensure they choose a unique IID range within >> the scope of where they are operating 4rd (between tunnel endpoints and >> the tunnel gateway). My initial concerns were that this could cause harm >> even in experimental form, but I've convinced myself that it shouldn't. >> In this case I see no need for a hard global IID reservation, because at >> the moment, u=1 g=1 isn't used for creating IID's for use with SLAAC. >> >> On the other hand, If 4rd is not truly experimental, or it's expected to >> work universally across AS boundaries, I suspect the WG will have to >> wait for an answer to Brian's question on whether structure within the >> IID is desirable. I don't think there's any clear consensus so far on >> that point (indeed there are some counter posts saying structure within >> the IID is undesirable). >> >> My own particular concern here is that there is a danger of creating a >> precedent of a completely new class of IPv6 addressing by the back door >> without this being fully and properly debated i.e. address ranges that >> don't perform DAD, and that are associated directly with a certain >> tunnel or transport protocol, and yet which are assigned within the >> generic GUA space, but perhaps which overlap with other IPv6 prefix >> spaces too. >> >> e.g. 1 What in draft-ietf-softwire-4rd-04 prevents tunnel space used by >> 6to4 (2002::/16) being associated with 4rd IIDs? >> >> e.g. 2 How would this new class of IID encoded ranges/tunnel/transport >> protocols interact with RFC6724 and draft-ietf-6man-addr-select-opt-08 >> (both of which assume that bit-contiguous left-anchored IPv6 prefixes >> map to transport protocols, not individual IID bits)? >> >> These questions probably have little relevance to 4rd being deployed in >> an experimental situation, and I think we should perhaps try to keep >> them decoupled as far as possible. >> >>> one of my concerns is that continuing to add the interface-id bits, is the >>> opposite direction of where >>> I want us to go. >>> >>> I wouldn't object to non-normative language in 4rd suggesting a >>> interface-id to use, without >>> creating any expectation that new or existing IPv6 implementations have to >>> change. >>> >>> that said, 4rd will work perfectly well _without_ this reservation, so I >>> don't buy the argument that >>> we're holding up the 4rd work. >>> >>> cheers, >>> Ole >>> >>> >> >> ------------------------------------------------------------------------ -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
