Peter, Thank you very much for adding the extra text to explain. But SR is supposed to be transparent to all intermediate nodes. Does your draft require a node to be specifically configured for each link to support or not support SR or RSVP-TE? In addition, there is no new attributes described in the document. So if a node is advertising TE related attributes for a specific link, such as bandwidth, delay, what kind problems this node will encounter if a remote node utilize those TE specific attributes? Linda Dunbar -----Original Message----- From: Peter Psenak <ppsenak@xxxxxxxxx> Sent: Monday, June 1, 2020 11:01 AM To: Linda Dunbar <linda.dunbar@xxxxxxxxxxxxx>; gen-art@xxxxxxxx Cc: last-call@xxxxxxxx; lsr@xxxxxxxx; draft-ietf-ospf-te-link-attr-reuse.all@xxxxxxxx Subject: Re: Genart last call review of draft-ietf-ospf-te-link-attr-reuse-12 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 <ppsenak@xxxxxxxxx> > Sent: Friday, May 29, 2020 10:00 AM > To: Linda Dunbar <linda.dunbar@xxxxxxxxxxxxx>; gen-art@xxxxxxxx > Cc: last-call@xxxxxxxx; lsr@xxxxxxxx; > draft-ietf-ospf-te-link-attr-reuse.all@xxxxxxxx > 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 <ppsenak@xxxxxxxxx <mailto:ppsenak@xxxxxxxxx>> >> Sent: Friday, May 29, 2020 5:51 AM >> To: Linda Dunbar <linda.dunbar@xxxxxxxxxxxxx >> <mailto:linda.dunbar@xxxxxxxxxxxxx>>; > gen-art@xxxxxxxx <mailto:gen-art@xxxxxxxx> >> Cc: last-call@xxxxxxxx <mailto:last-call@xxxxxxxx>; lsr@xxxxxxxx > <mailto:lsr@xxxxxxxx>; >> draft-ietf-ospf-te-link-attr-reuse.all@xxxxxxxx > <mailto:draft-ietf-ospf-te-link-attr-reuse.all@xxxxxxxx> >> 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%7C1bd0e81d5279453d853808d8064500a2%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637266240741960001&sdata=faz4UopBwiK3D0CXWu%2BiebFOje9qfJt1wL6J4QqcjlY%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-call@xxxxxxxx https://www.ietf.org/mailman/listinfo/last-call
