Hi Elwyn, Thanks, a new revision addressing the comments have been posted Name: draft-ietf-teas-lsp-attribute-ro Revision: 04 Title: LSP Attribute in ERO Document date: 2015-03-04 Group: teas Pages: 14 URL: http://www.ietf.org/internet-drafts/draft-ietf-teas-lsp-attribute-ro-04.txt Status: https://datatracker.ietf.org/doc/draft-ietf-teas-lsp-attribute-ro/ Htmlized: http://tools.ietf.org/html/draft-ietf-teas-lsp-attribute-ro-04 Diff: http://www.ietf.org/rfcdiff?url2=draft-ietf-teas-lsp-attribute-ro-04
Best Regards. On 5 March 2015 at 08:26, Elwyn Davies <[email protected]> wrote: > Hi, Cyril. > > Yes.. That looks good. Thanks! > > Dong Jie will hopefully take this on board for the loopback flag in > draft-ietf-teas-rsvp-te-li-lb. We have been discussing this earlier today. > > Regards, > Elwyn > > > On 05/03/2015 03:28, Cyril Margaria wrote: > >> Hi, >> >> Thanks for the quick feedback, >> Would the following text modification address your comments . >> the wording is a bit different, I tried to simplify the description of the >> TLV scope. >> >> As described in [RFC3209] the ERO is managed as a list of subobjects >> each identifying a specific entity, an abstract node or a link that >> defines a waypoint in the network path. Identifying subobjects of >> various types are defined in [RFC3209], [RFC3477], [RFC4873], >> [RFC4874], [RFC5520] and [RFC5553]. >> >> [RFC3473] modified the ERO list by allowing one or two Label >> subobjects to be interposed in the list after a subobject identifying >> a link. One or more ERO Hop Attributes subobjects applicable to a >> particular hop MAY be inserted directly after any of the existing >> identifying subobjects defined in[RFC3209], [RFC3477], [RFC4873], >> [RFC4874], [RFC5520] and [RFC5553]. If any Label subobjects are >> present for a hop, the ERO Hop Attributes subobject(s) MAY also be >> inserted after the Label subobjects. >> >> The attributes specified in a ERO Hop Attributes subobject apply to >> the immediately preceding subobject(s) in the ERO subobject list. >> >> A document defining a specific Hop Attribute TLV has to describe: >> >> o after which kinds of ERO subobject they are valid , >> >> o if ordering of the Hop Attributes subobject and other ERO >> subobjects associated with the same hop (e.g., Label subobjects) >> is significant, >> >> o if ordering is significant, how the attribute is interpreted in >> association with the preceding ERO subobjects, and >> >> o any TLV modification rules that might apply. >> >> For instance, subobject presence rules can be defined by describing >> rules similar to [RFC4990] Section 6.1. >> >> >> That would allow a TLV to apply to one (or more) preceding subobject, the >> type of subobject being left to the TLV. >> >> Regarding section 2.2, the following text is proposed: >> >> The presence and ordering rule of the Attribute Flags TLV in an ERO >> Hop Attributes Subobject is defined by each Flag. A document >> defining a Flag to be used in a Attribute Flags TLV carried in the >> ERO Hop Attributes Subobject has to describe: >> >> o after which kinds of ERO subobject the Flag is valid >> >> o if ordering of the Flag and other ERO subobjects associated with >> the same hop (e.g., Label subobjects) is significant, >> >> o if ordering is significant, how the Flag is interpreted in >> association with the preceding subobjects, >> >> o any Flag modification rules that might apply. >> >> >> If its Ok, I can post a new revision shortly. >> >> Best Regards >> Cyril >> >> >> >> On 4 March 2015 at 13:29, Elwyn Davies <[email protected]> wrote: >> >> >>> On 04/03/2015 06:04, Cyril Margaria wrote: >>> >>> Hi, >>>> >>>> Thanks for your review, >>>> Please not that a new revision addressing IANA , APS-DIR and Gen-ART >>>> comments on revision -02 is available. >>>> https://tools.ietf.org/html/draft-ietf-teas-lsp-attribute-ro-03 >>>> >>>> please see inline. >>>> >>>> Hi, Cyril. >>> >>> Yes: my comments and the new version crossed. >>> >>> However -03 doesn't significantly alter para 1 of s2.3. >>> >>> Firstly, I am far from expert in this area, so I have not much clue as to >>> whether it would ever be useful or meaningful to associate an attribute >>> with a Label rather than with the entity identified by the other >>> subobject >>> types. However, it has just occurred to me that with the loopback case, >>> one needs to decide that if there are two labels, does loopback apply to >>> both of them or just one? Arrrgggh! >>> >>> Perhaps something like the following, replacing the first two paras of >>> s2.3, would cover all the bases and push the decision down to the >>> document >>> that defines the TLV(s)/flags used in the Hop attribute subobjects: >>> >>> OLD: >>> As described in [RFC3209] and [RFC3473] the ERO is managed as a list >>> where each hop information starts with a subobject identifying an >>> abstract node or link. The ERO Hop Attributes subobject MAY be >>> appended after any of the existing subobjects defined in [RFC3209], >>> [RFC3473], [RFC3477], [RFC4873], [RFC4874], [RFC5520] and [RFC5553]. >>> Several ERO Hop Attributes subobject MAY be present, for each hop. >>> >>> Document defining specific Hop attribute TLV has to describe after >>> which kind of subobject they are valid and if TLV modification rules >>> applies. For instance, subobject presence rules can be defined by >>> describing rules similar to [RFC4990] Section 6.1. >>> >>> NEW: >>> As described in [RFC3209] the ERO is managed as a list of subobjects >>> each identifying a specific entity, an abstract node or a link that >>> defines >>> a waypoint in the ERO route. Identifying subobjects of various types >>> are >>> defined in [RFC3209], [RFC3477], [RFC4873], [RFC4874], [RFC5520] and >>> [RFC5553]. >>> >>> [RFC3473] modified the ERO list by allowing one or two Label >>> subobjects >>> to be interposed in the list after a subobject identifying an entity >>> by >>> its >>> IP address or interface identifier. One or more ERO Hop attributes >>> subobjects applicable to a particular hop MAY be inserted directly >>> after >>> any of the existing identifying subobjects defined in [RFC3209], >>> [RFC3477], >>> [RFC4873], [RFC4874], [RFC5520] and [RFC5553]. If any Label >>> subobjects >>> are present for a hop, the ERO Hop attributes subobject(s) MAY also >>> be >>> inserted after the Label subobjects. >>> >>> The attributes specified in a ERO Hop attributes subobject apply to >>> the >>> hop >>> that ends at the route waypoint identified by the immediately >>> preceding >>> identifying subobject in the ERO subobject list. >>> >>> A document defining a specific Hop attribute TLV has to describe >>> - after which kinds of subobject they are valid , >>> - if ordering of the Hop attributes subobject and other >>> subobjects >>> associated with the same hop (e.g., Label subobjects) is >>> significant, >>> - if ordering is significant, how the attribute is interpreted in >>> association with the preceding subobjects, and >>> - any TLV modification rules that might apply. >>> For instance, subobject presence rules can be defined by describing >>> rules >>> similar to [RFC4990] Section 6.1. >>> >>> This might require a few words added to s2.2 to specify that the ordering >>> decision for individual flags is up to the definition of the flag. In >>> turn >>> that possibly means that the loopback draft needs to think about whether >>> the loopback applies to both labels or only the one the loopback flag is >>> after as mentioned above. >>> >>> Regards, >>> Elwyn >>> >>> PS >>> There is discussion about the .all aliases going to WG lists as well as >>> relevant individuals. The long standing position was that they didn't >>> but >>> change has recently been mooted. >>> >>> /E >>> >>> >>> >>>> >>>> On 3 March 2015 at 12:58, Elwyn Davies <[email protected]> wrote: >>>> >>>> Hi. >>>> >>>>> In the process of doing the gen-art review of >>>>> draft-ietf-teas-rsvp-te-li-lb for IETF last call, I needed to look at >>>>> draft-ietf-teas-lsp-attribute-ro-02 in connection with some comments >>>>> about >>>>> ordering of subobjects in the loopback draft. >>>>> >>>>> I thought that the text in the first paragraph of s2.3: >>>>> >>>>> As described in [RFC3209 <https://tools.ietf.org/html/rfc3209>] >>>>> and >>>>> [RFC3473 <https://tools.ietf.org/html/rfc3473>] the ERO is managed as >>>>> a >>>>> list >>>>> where each hop information starts with a subobject identifying an >>>>> abstract node or link. The ERO Hop Attributes subobject MAY be >>>>> appended after any of the existing subobjects defined in [RFC3209 >>>>> < >>>>> https://tools.ietf.org/html/rfc3209>], >>>>> [RFC3473 <https://tools.ietf.org/html/rfc3473>], [RFC3477 < >>>>> https://tools.ietf.org/html/rfc3477>], [RFC4873 < >>>>> https://tools.ietf.org/html/rfc4873>], [RFC4874 < >>>>> https://tools.ietf.org/html/rfc4874>], [RFC5520 < >>>>> https://tools.ietf.org/html/rfc5520>] and [RFC5553 < >>>>> https://tools.ietf.org/html/rfc5553>]. >>>>> >>>>> Several ERO Hop Attributes subobject MAY be present, for each hop. >>>>> >>>>> was not very clear: The use of 'appended' was slightly confusing. I >>>>> felt >>>>> it needed something a bit closer to the "Presence Rules" that are given >>>>> for >>>>> RRO subobjects in RFC 5420, s7.3.1 to make it quite clear what is going >>>>> on. >>>>> >>>>> I am not totally clear what would happen in the case of (say) an IPv4 >>>>> address subobject followed by two Label subobjects. The wording seems >>>>> to >>>>> indicate that Hop attributes can be inserted anywhere in the sequence >>>>> of >>>>> three subobjects - but would they specifically apply to one or other >>>>> Label >>>>> if they were inserted after a Label or would they always apply >>>>> generically >>>>> to the hop terminated at the IPv4 address entity? >>>>> >>>>> >>>>> draft-ietf-teas-lsp-attribute-ro tries to leave that open to the >>>>> >>>> documents >>>> defining the TLVs. We are not excluding an Attribute that applies to a >>>> Label or Interface. If the subobject would be inserted after a Label >>>> Subobject, the Attribute TLVs would apply to the Labels. >>>> >>>> This is based on the following review comment:" >>>> I think *this* I-D needs to make it clear what the expectations are: >>>> >>>> 1. The sub-object is allowed at any point in the ERO >>>> 2. The document that specifies a TLV for the sub-object must make it >>>> clear where in an ERO a sub-object containing that TLV is allowed >>>> and >>>> not allowed." >>>> >>>> Do you think this is reasonable or we should exclude TLVs scoped to >>>> labels? >>>> In the latter case, I would add you suggested text. >>>> >>>> Best Regards. >>>> Cyril >>>> >>>> PS: It seems there are errors with the tools.ietf.org aliases >>>> >>>> >>>> My suggestion for rewording, based on the assumption that the hop >>>> >>>>> attributes apply to the hop rather than any of the labels, would be: >>>>> >>>>> As described in [RFC3209] the ERO is managed as a list of >>>>> subobjects >>>>> each identifying a specific entity, an abstract node or a link. >>>>> Identifying >>>>> subobjects of various types are defined in [RFC3209], [RFC3477], >>>>> [RFC4873], >>>>> [RFC4874], [RFC5520] and [RFC5553]. [RFC3473] modified the ERO >>>>> list >>>>> by >>>>> allowing one or two Label subobjects to be interposed in the list >>>>> after >>>>> a >>>>> subobject identifying an entity by its IP address or interface >>>>> identifier. One >>>>> or more ERO Hop attributes subobjects applicable to a particular >>>>> hop >>>>> MAY >>>>> be inserted after any of the existing identifying subobjects >>>>> defined >>>>> in >>>>> [RFC3209], [RFC3477], [RFC4873], [RFC4874], [RFC5520] and >>>>> [RFC5553]. >>>>> If any Label subobjects are present for a hop, the ERO Hop >>>>> attributes >>>>> subobject(s) MUST be inserted after the Label subobjects. >>>>> >>>>> The last two sentences would need to be altered if Hop attributes were >>>>> applicable to Labels rather than just to the hop as a whole. >>>>> >>>>> Regards, >>>>> Elwyn >>>>> >>>>> >>>>> >>>>> _______________________________________________ >>>>> Teas mailing list >>>>> [email protected] >>>>> https://www.ietf.org/mailman/listinfo/teas >>>>> >>>>> >>>>> >>>>> >
_______________________________________________ Gen-art mailing list [email protected] https://www.ietf.org/mailman/listinfo/gen-art
