that works for me - thanks Scott
> On Jun 1, 2020, at 12:01 PM, Peter Psenak > <ppsenak=40cisco....@dmarc.ietf.org> wrote: > > Hi Linda, > > > On 01/06/2020 17:30, Linda Dunbar wrote: >> Peter, >> You said: >> /“//the problem with existing advertisement is that RSVP-TE will use it, >> even if it was not intended to be used by RSVP-TE.//”/ >> What is the problem if RSVP-TE use the advertisement? What specific >> attributes that RSVP-TE shouldn’t use? > > Following text has been added to the draft based on comments from Scott. > > "An example where this ambiguity causes problem is a network which has > RSVP-TE enabled on one subset of links, and SRTE enabled on a different > subset. A link attribute is advertised for the purpose of some other > application (e.g. SRTE) for a link that is not enabled for RSV-TE. As soon as > the router that is an RSVP-TE head-end sees the link attribute being > advertised for such link, it assumes RSVP-TE is enabled on that link, even > though in reality, RSVP-TE is not enabled on it. If such RSVP-TE head-end > router tries to setup an RSVP-TE path via link where RSVP-TE is not enabled > it will result in the path setup failure." > > Hope it makes it clear and addresses your question. > > thanks, > Peter > > > > > >> Linda Dunbar >> -----Original Message----- >> From: Peter Psenak <ppse...@cisco.com> >> Sent: Friday, May 29, 2020 10:00 AM >> To: Linda Dunbar <linda.dun...@futurewei.com>; gen-...@ietf.org >> Cc: last-c...@ietf.org; lsr@ietf.org; >> draft-ietf-ospf-te-link-attr-reuse....@ietf.org >> Subject: Re: Genart last call review of draft-ietf-ospf-te-link-attr-reuse-12 >> Linda, >> On 29/05/2020 16:52, Linda Dunbar wrote: >>> Peter, >>> You said: >>> /we are not defining any new attributes./ /We are allowing an existing link >>> attributes to be used by other applications, including, but not limited to >>> SRTE./ What prevent a node (or an application on the node) receiving the >>> LSA from using the attributes carried by the LSA? >> the problem with existing advertisement is that RSVP-TE will use it, even if >> it was not intended to be used by RSVP-TE. >> We are providing a way to explicitly advertised apps that are allowed to use >> the advertised attributes. >>> If no new attributes are >>> to be added, then why need a new ASLA sub-TLV? >> to be able to use the existing attributes for new apps, other than RSVP-TE. >> thanks, >> Peter >>> Linda >>> -----Original Message----- >>> From: Peter Psenak <ppse...@cisco.com <mailto:ppse...@cisco.com>> >>> Sent: Friday, May 29, 2020 5:51 AM >>> To: Linda Dunbar <linda.dun...@futurewei.com >>> <mailto:linda.dun...@futurewei.com>>; >> gen-...@ietf.org <mailto:gen-...@ietf.org> >>> Cc: last-c...@ietf.org <mailto:last-c...@ietf.org>; lsr@ietf.org >> <mailto:lsr@ietf.org>; >>> draft-ietf-ospf-te-link-attr-reuse....@ietf.org >> <mailto:draft-ietf-ospf-te-link-attr-reuse....@ietf.org> >>> Subject: Re: Genart last call review of >>> draft-ietf-ospf-te-link-attr-reuse-12 >>> Hi Linda, >>> On 28/05/2020 19:02, Linda Dunbar via Datatracker wrote: >>>> Reviewer: Linda Dunbar >>>> Review result: Not Ready >>>> I am the assigned Gen-ART reviewer for this draft. The General Area Review >>>> Team (Gen-ART) reviews all IETF documents being processed by the IESG for >>>> the IETF Chair. Please treat these comments just like any other last call >>>> comments. >>>> For more information, please see the FAQ at >>>> <https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Ftrac.ietf.org%2Ftrac%2Fgen%2Fwiki%2FGenArtfaq&data=02%7C01%7Clinda.dunbar%40futurewei.com%7C34b141b11fe6484fc65208d803e0e851%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637263611798933480&sdata=hXIX5xyAiXcFdymKVyg%2BVuQZAznQKJV5Il7U9OOdVv0%3D&reserved=0>. >>>> Document: draft-ietf-ospf-te-link-attr-reuse-?? >>>> Reviewer: Linda Dunbar >>>> Review Date: 2020-05-28 >>>> IETF LC End Date: 2020-05-29 >>>> IESG Telechat date: Not scheduled for a telechat >>>> Summary: this document introduces a new link attribute advertisement in >>>> OSPFv2 and OSPFv3 to address general link properties needed for new >>>> applications, such as Segment Routing. >>>> Major issues: >>>> The document has good description on the TLV structure of the Application >>>> specific Advertisements, but fails to describe what are the NEW Link >>>> attributes needed by Segment Routing. Page 7 (section 5) has a really good >>>> description on all the link properties added to OSFP (RFC4203, RFC 7308, >>>> RFC7471, RFC3630) to achieve TE. I can see Segment Routing would need each >>>> node to advertise its own SID and the SIDs of adjacent nodes. Can't they >>>> be encoded (or extended) in OSPF's NODE ID? >>> we are not defining any new attributes. >>> We are allowing an existing link attributes to be used by other >>> applications, including, but not limited to SRTE. >>> thanks, >>> Peter >>>> Minor issues: >>>> Nits/editorial comments: >>>> Best regards, >>>> Linda Dunbar > > -- > last-call mailing list > last-c...@ietf.org > https://www.ietf.org/mailman/listinfo/last-call _______________________________________________ Lsr mailing list Lsr@ietf.org https://www.ietf.org/mailman/listinfo/lsr
