Hi Elwyn, Lou, Thanks a lot for the comments. I agree with the new texts and will use them in a new revision.
Regarding the label subobject, as Lou pointed out in a previous mail, it may be used in some technologies to identify a loopback target, thus it would be better to keep this document general about such cases. Best regards, Jie > -----Original Message----- > From: Lou Berger [mailto:lber...@labn.net] > Sent: Sunday, March 01, 2015 2:28 AM > To: Elwyn Davies; Dongjie (Jimmy); General area reviewing team > Cc: draft-ietf-teas-rsvp-te-li-lb....@tools.ietf.org > Subject: Re: Gen-art LC review of draft-ietf-teas-rsvp-te-li-lb-03 > > Elwyn, > > Thanks for the comments. I think your new text is fine. (And not materially > different than the current text.) > > Lou > > > On February 28, 2015 1:00:09 PM Elwyn Davies <elw...@dial.pipex.com> > wrote: > > > Hi, Jie. > > > > I think two conversations got a bit crossed here. > > > > I just checked the final version of -04 as submitted and saw that you > > had completely reverted the text about the types (as opposed to the > > version with the earlier email to which the comments below applied). > > > > The submitted version is pretty much OK because of the rule change, > > but I think that my original comments about identifying what type 1 > > and type > > 2 actually are is desirable, and it would be useful to say why 32 is > > the > > limit: > > > > OLD (i.e. submitted -04): > > > > 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. > > > > NEW: > > Currently, the type value MUST be verified to be > > less than 32 (i.e., able to identify a specific entity where a loopback > > can > > occur, see Section 4.3), and for type values 1 (IPv4 address) and 2 > > (IPv6 > > address), the prefix length MUST be 32 and 128 respectively. > > > > Sorry about the confusion. > > > > I am not an expert in this area, but looking at your conversation with > > Lou about label subobjects I saw from RFC 3473 that, if present, one > > or two label subobjects MUST follow an IP address subobject that > > identifies the node/interface. It doesn't seem to indicate that a > > label subobject can occur on its own as an entity identifier to which > > attributes can be attached. Lou seemed to think there were cases > > where it could, but I don't see that being allowed. This may need > clarification. > > > > This also may screw up the words about where to put ERO HOP attributes > > in the attributes draft. I'll follow that up separately. > > > > /Elwyn > > > > On 26/02/2015 13:07, Elwyn Davies wrote: > > > Hi, Jie. > > > > > > I checked through the updated draft (-04) that you sent out. That > > > all looks fine except for a couple of typos: > > > > > > s3.2, para 2: s/Explicit Route object/Explicit Route Object/ > > > > > > s5, para 2: s/to remains/to remain/, s/also applies/also apply/ > > > > > > With the added IANA consideration that you have been discussing with > > > Lou we should be all done. > > > > > > I'll continue progressing the presence rule comments with the > > > attribute-ro authors. > > > > > > Thanks for the work. > > > > > > Regards, > > > Elwyn > > > > > > On 26/02/2015 06:15, Dongjie (Jimmy) wrote: > > >> 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:lber...@labn.net] > > >>> Sent: Thursday, February 26, 2015 11:40 AM > > >>> To: Dongjie (Jimmy); Elwyn Davies; General area reviewing team > > >>> Cc: draft-ietf-teas-rsvp-te-li-lb....@tools.ietf.org > > >>> 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:elw...@dial.pipex.com] > > >>>>> Sent: Thursday, February 26, 2015 2:14 AM > > >>>>> To: Dongjie (Jimmy); General area reviewing team > > >>>>> Cc: draft-ietf-teas-rsvp-te-li-lb....@tools.ietf.org > > >>>>> 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-parameter > > >>>>>>> s.xml > > >>>>>>> #r > > >>>>>>> svp- > > >>>>>>> parameters-25 > > > > > > > > _______________________________________________ Gen-art mailing list Gen-art@ietf.org https://www.ietf.org/mailman/listinfo/gen-art
