Hi Lou, Thanks a lot for your prompt response.
I see that label may be used for some technologies, so I will update the draft following your guidance: keep the previous text and update the IANA allocation rules for type value 5-31. Thanks. Best regards, Jie > -----Original Message----- > From: Lou Berger [mailto:[email protected]] > Sent: Thursday, February 26, 2015 11:40 AM > To: Dongjie (Jimmy); Elwyn Davies; General area reviewing team > Cc: [email protected] > Subject: Re: Gen-art LC review of draft-ietf-teas-rsvp-te-li-lb-03 > > Jie, > see below. > > On 02/25/2015 10:00 PM, Dongjie (Jimmy) wrote: > > Hi Elwyn, > > > > Thanks for your prompt response. Attached is a new revision which reflects > your comments and suggestions, please let me know if this revision is OK to > progress, thanks. > > > > Hi Lou, > > > > Thanks for your suggestion. > > > > In this new revision the text about valid ERO subobject types is revised a > > bit, as > I noticed the type value of "label" (3) is also less than 32, while it may > not be > used to identify a loopback target. > > > Why not? This is a technology specific issue. For example, one could loop a > specific lambda in certain optical switches by identifying a specific lambda > via a > label. > > > Currently the IANA allocation rules for 5-31 is not changed by this > > revision. If > you think this change is needed, I can update the draft before submission. > Thanks. > > > > I think the previous text should be used. > > Thanks, > Lou > > > Cheers, > > Jie > > > >> -----Original Message----- > >> From: Elwyn Davies [mailto:[email protected]] > >> Sent: Thursday, February 26, 2015 2:14 AM > >> To: Dongjie (Jimmy); General area reviewing team > >> Cc: [email protected] > >> Subject: Re: Gen-art LC review of draft-ietf-teas-rsvp-te-li-lb-03 > >> > >> Hi, Jie. > >> > >> I think we are almost done. > >> > >> There is a proposal for the specific types at the end. > >> > >> Cheers, > >> Elwyn > >> > >> > >> > >> On 25/02/2015 06:10, Dongjie (Jimmy) wrote: > >>> Hi Elwyn, > >>> > >>> Thanks a lot for your response. Please see my replies inline: > >>> > >>> Best regards, > >>> Jie > >>> > >>>>>> s3.2, para 2: > >>>>>> OLD: > >>>>>> The ingress MUST ensure that the desired loopback mode is > >>>>>> strictly identified in the ERO. > >>>>>> > >>>>>> Am I right that "mode" is a typo? Should it be "node" rather > >>>>>> than "mode? I couldn't see anything about "loopback modes" in RFC > >>>>>> 5860 or RFC 6371. After much head scratching I came to the > >>>>>> conclusion that > >> "node" > >>>>>> was the right answer... If not then please explain where modes > >>>>>> are > >> defined. > >>>>> I guess we may not call it a typo. The above sentence was added > >>>>> during the > >>>> WG review, the intention was to strictly identify the entity at > >>>> which the loopback is desired, which can be either a node or an > >>>> interface of a > >> node. > >>>>> If we replace "mode" with "entity", do you think it can be clearer? > >>>>> > >>>>>> Continuing on the basis that the word s/b "node"... I think this > >>>>>> would > >>>>>> be clearer as follows: > >>>>>> NEW > >>>>>> The ingress node MUST ensure that the node where loopback is > >>>>>> intended to occur is marked as a strict hop (i.e., not a loose > >>>>>> hop) in the > >> ERO. > >>>>> If you agree with the above change, in your suggestion we can also > >>>>> substitute > >>>> "node" with "entity". > >>>> That would help. How about: > >>>> NEW (mk 2): > >>>> > >>>> The ingress node MUST ensure that the entity (node or interface), > >>>> at which loopback is intended to occur, is marked as a strict hop > >>>> (i.e., not a loose hop) in the ERO type subobject. > >>> Agree with this description. Will update in the new revision. > >> Fine. > >>> > >>>>> The prior subobject of "ERO Hop Attributes subobject" would also > >>>>> be ERO > >>>> subobject which identifies the target entity of loopback. As > >>>> specified in the sentence below, the type value of the prior > >>>> subobject ensures the prior subobject would be an IP prefix or an > >>>> interface ID, which can identify the node or interface at which > >>>> loopback is desired. Note that the current description requires > >>>> both the "ERO Hop Attributes subobject" and the prior subobject > >>>> have the L bit set to 0 to ensure that the two subobjects together > >>>> strictly specify a > >> loopback request on an specific entity (node or interface). > >>>>> We can rephrase to make it clearer. > >>>> I have looked into this issue a bit more deeply, and realize that > >>>> my problem is not really with this draft but, at least partly, with > >>>> draft-ietf-teas-lsp-attribute-ro-01. Having gone back to RFC3209, > >>>> I understand that the subobjects in an ERO as defined there are all > >>>> specifiers for type of 'entity' that could be waypoints on the > >>>> explicit route. There is no allowance for other types of subobject > >>>> (such as the attribute subobjects being introduced by > >>>> draft-ietf-teas-lsp-attribute-ro-01). As introduced in RFC 3209, > >>>> both EROs and RROs contained only entity type subobjects, but RFC > >>>> 5420 changed this for *RROs only* by introducing RRO Attributes > >>>> subobjects which could be inserted between the type subobjects. > >>>> Thus as standardized currently, EROs aren't allowed any other sort > >>>> of subobject > >> and there is no equivalent to the "Presence Rules" defined for RROs > >> in RFC 5420 section 7.3.1. > >>>> > >>>> draft-ietf-teas-lsp-attribute-ro-01 updates the presence rules for > >>>> RROs to allow for the RRO Hop Attributes subobjects but the > >>>> necessary presence rules that would control where the ERO HOP > >>>> Attributes could be inserted are not properly defined in > >>>> draft-ietf-teas-lsp-attribute-ro-01. Para 1 of s2.3 of > >>>> draft-ietf-teas-lsp-attribute-ro-01 seems to indicate that the HOP > >>>> Attributes would be placed after all the type subobjects which > >>>> doesn't seem right. I would have thought that the hop attributes > >>>> needed to be interleaved between the type subobjects - and I think > >>>> that is what the existing text in the lock draft is trying to say. > >>>> > >>>> So I think the draft-ietf-teas-lsp-attribute-ro-01 needs to be > >>>> clarified > >>>> - a specific section on Presence Rules as in RFC 5420 would help. > >>>> > >>>> The text about checking that the L bit in the lock draft is > >>>> confusing, because the L bit is *required* by > >>>> draft-ietf-teas-lsp-attribute-ro-01 > >>>> to be 0 in *all* Hop Attributes subobjects whether they are > >>>> associated with loose or strict hops and need not be mentioned. > >>>> The L bit is only set in the type subobject if it is a loose hop so > >>>> the check should > >> be > >>>> that the type subobject has its L bit clear. It should also be made > >>>> clearer in the lock draft that there can be multiple Hop Attribute > >>>> subobjects after the type subobject. > >>>> > >>>> I hope this helps. > >>> You are correct, the L bit in the ERO hop attributes subobject must > >>> be 0, thus > >> we would only specify that the L bit in the prior ERO subobject MUST > >> be set to 0 in the new revision. > >> OK. > >>> > >>> As for the rules about multiple Hop Attribute subobjects in ERO, IMO > >>> maybe it > >> is more suitable to be specified in draft-ietf-teas-lsp-attribute-ro, > >> but we can also add such descriptions if you think they belongs to this > >> draft. > >> I will negotiate with the authors of draft-ietf-teas-lsp-attribute-ro > >> to see if we can agree a revision. > >>> > >>>>>> s3.2, para 3: > >>>>>>> Currently, the type value MUST be verified to be > >>>>>>> less than 32, and for type values 1 and 2 the prefix length MUST > be > >>>>>>> 32 and 128 respectively. > >>>>>> It would be better to use the names of the types (1 = IPv4, 2 = > >>>>>> IPv6) that would make it clearer why the lengths are as they are > specified. > >>>>>> Is it possible to explain why the type has to be less than this > >>>>>> apparently arbitrary limit of 32? And hence what allocation > >>>>>> constraints ought to be applied in the future - this might need a > >>>>>> change in the IANA allocation rules that should be specified in > >>>>>> this > >> document. > >>>>> The limit of 32 was to ensure the subobject type can identify a > >>>>> specific node > >>>> or interface. Maybe we can specify the required types (node, > >>>> interface) explicitly to make it clear. > >>>> That would help. > >>>> It has just occurred to me why you want to say that the prefix > >>>> lengths are > >>>> 32/128 bits - so that the IP address refers to exactly one node. > >>>> However this is possibly confusing because RFC 3209 *requires* the > >>>> values to be 32/128 respectively and the subobjects do carry just a > >>>> host address and not a domain prefix as might be implied by lower values. > >>> As specified in 4.3.3 of RFC 3209, for the ERO subobjects, the > >>> prefix lengths > >> are not required to be just 32/128. While as specified in 4.4.1 of > >> RFC 3209, for the RRO subobjects, the prefix lengths are required to be > 32/128. > >> You are right: I missed that RRO and ERO were different. So > >> specifying the prefix lengths is indeed needed as you say. > >>> > >>>> I noted having looked again at the registry [1], and it appears > >>>> that nobody has yet defined an ERO type for 4 octet AS numbers > >>>> which have now > >>>> (finally) been standardized. This might mean that 32 was not the > >>>> right boundary. Perhaps this means that you need to define an > >>>> update to the allocation rules for the registry so that values > >>>> below (say) > >>>> 32 are required to identify exactly one physical node and not an > >>>> abstract node with potentially many physical nodes. > >>> Thanks for your suggestion. Since this draft just want to restrict > >>> the type of > >> ERO subobjects that can appear prior to the ERO hop attributes > >> subobject, making such update to IANA was not our original intention, > >> also requires discussion with ADs and TEAS chairs. > >>> > >>> What about we specify the allowed ERO subobject types explicitly, > >>> similar to > >> 6.1.1 of RFC 4990? The specification could be something like: > >>> > >>> The prior subobject MUST be able to identify a specific node or > >>> interface, > >> specifically it MUST be one of the following: type "IPv4 prefix" with > >> prefix length 32, type "IPv6 prefix" with prefix length 128, or type > >> "Unnumbered Interface ID". > >> That would certainly cover the situation as it is at the moment. I > >> can't immediately think of any new types that might be added and > >> would be relevant as loopback points, but you might have some ideas on > this. > >> I was trying to think of an easy way to factor this into the IANA > >> registration process but I can't see anything very simple. I think a > >> few 'weasel words' will do for an unlikely event. How about: > >> NEW mk 3: > >> The prior subobject MUST be able to identify a specific node or > >> interface, specifically, at the time of writing, it can be one of the > >> following: > >> - Type "IPv4 prefix" with prefix length 32, > >> - Type "IPv6 prefix" with prefix length 128, or > >> - Type "Unnumbered Interface ID". > >> If any new subobject types are defined in future and they identify a > >> specific node or interface, the specification of the new type can extend > >> this > list. > >> > >> > >>>> [1] > >>>> http://www.iana.org/assignments/rsvp-parameters/rsvp-parameters.xml > >>>> #r > >>>> svp- > >>>> parameters-25 > > _______________________________________________ Gen-art mailing list [email protected] https://www.ietf.org/mailman/listinfo/gen-art
