Peter,
Thank you for the explanation.
Linda
-----Original Message-----
From: Peter Psenak <ppsenak@xxxxxxxxx>
Sent: Wednesday, June 10, 2020 3:40 AM
To: Linda Dunbar <linda.dunbar@xxxxxxxxxxxxx>; Acee Lindem (acee) <acee@xxxxxxxxx>; gen-art@xxxxxxxx
Cc: last-call@xxxxxxxx; draft-ietf-ospf-te-link-attr-reuse.all@xxxxxxxx; lsr@xxxxxxxx
Subject: Re: [Lsr] Genart last call review of draft-ietf-ospf-te-link-attr-reuse-12
Linda,
On 09/06/2020 22:20, Linda Dunbar wrote:
> Peter,
>
> Thank you for the explanation.
>
> So you are saying that a node might not support RSVP or RSVP-TE, but can advertise the TE related attributes for SR purpose. When the head node receiving the advertisement also support RSVP-TE, it might use the information to establish the RSVP path, which will be rejected by the node that don't support RSVP but advertise the TE related information? is it correct?
yes.
>
> It would be useful if you can add a statement to explain the scenario that a node only has a subset of links supporting RSVP-TE but also capable of advertising TE related attributes for links that are not enabled for RSVP-TE.
There is a text in the draft:
An example where this ambiguity causes a problem is a network in
which RSVP-TE is enabled only on a subset of its links. A link
attribute is advertised for the purpose of another 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 that link, it assumes RSVP-TE is enabled on that
link, even though it is not. If such RSVP-TE head-end router tries
to setup an RSVP-TE path via that link it will result in the path
setup failure.
thanks,
Peter
>
> Linda Dunbar
>
> -----Original Message-----
> From: Peter Psenak <ppsenak@xxxxxxxxx>
> Sent: Tuesday, June 9, 2020 10:18 AM
> To: Linda Dunbar <linda.dunbar@xxxxxxxxxxxxx>; Acee Lindem (acee)
> <acee@xxxxxxxxx>; 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 09/06/2020 16:18, Linda Dunbar wrote:
>> Acee and Peter,
>>
>> Thank you very much for the explanation.
>>
>> My fundamental question is: What problem will be encountered when a node use the TE information on links that RSVP-TE are not enabled?
>
> The problem is on a node where RSVP is enabled, when it receives the link attribute for a remote link where RSVP is not enabled.
>
> An example where this ambiguity causes a problem is a network in
> which RSVP-TE is enabled only on a subset of its links. A link
> attribute is advertised for the purpose of another 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 that link, it assumes RSVP-TE is enabled on that link,
> even though it is not. If such RSVP-TE head-end router tries to
> setup an RSVP-TE path via that link it will result in the path setup
> failure.
>
>>
>> I would think that the reason that RSVP-TE is enabled per interface is because not every interface is capable of generating the TE information, or the Node doesn't want to share the detailed TE information to remote nodes (for security reasons?).
>
> the simplest reason is that RSVP is not used on the router at all.
>
>>
>> If SR is enabled on a node, which is capable of detecting the TE information on the links to be advertised to remote nodes, what problems do we have when the OSPF-TE application on remote nodes utilizes the Link TE information?
>
> please see above.
>
> thanks,
> Peter
>>
>>
>> Thank you.
>>
>> Linda
>>
>> -----Original Message-----
>> From: Acee Lindem (acee) <acee@xxxxxxxxx>
>> Sent: Tuesday, June 9, 2020 6:25 AM
>> To: Peter Psenak (ppsenak) <ppsenak@xxxxxxxxx>; 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,
>> One more point...
>>
>> On 6/9/20, 4:52 AM, "Peter Psenak" <ppsenak@xxxxxxxxx> wrote:
>>
>> Linda,
>>
>> On 09/06/2020 02:37, Linda Dunbar wrote:
>> > 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?
>>
>> the draft does not pose any new requirements in terms of how
>> applications are enabled.
>>
>> Please note that RSVP-TE is typically enabled per interface, SRTE is
>> typically enabled on a per node basis.
>>
>> For SR, these attributes are attributes are advertised in OSPF so that any OSPF router or controller in the OSPF domain can make use of them to compute the SR path.
>>
>> Thanks,
>> Acee
>>
>>
>> >
>> > 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?
>>
>> the problem is when the link attributes advertise for the purpose of
>> application other than RSVP-TE is mistakenly used by RSVP-TE.
>>
>> thanks,
>> Peter
>>
>>
>>
>> >
>> > 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%7C15106e48f1084954b35a08d80d19ccee%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637273751753415740&sdata=0aA%2B%2F9dM%2FxhneUaVnh435vqNVe6vLttlL8U8kGbTcMw%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
>> >>>>
>> >>>>
>> >>>>
>> >>>>
>> >
>> >
>> >
>>
>>
>>
>>
>
> _______________________________________________
> Lsr mailing list
> Lsr@xxxxxxxx
> https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.
> ietf.org%2Fmailman%2Flistinfo%2Flsr&data=02%7C01%7Clinda.dunbar%40
> futurewei.com%7C15106e48f1084954b35a08d80d19ccee%7C0fee8ff2a3b240189c7
> 53a1d5591fedc%7C1%7C0%7C637273751753415740&sdata=6rcZuEZernpe88EGj
> ehGIesn7nPpAX6UdI2wPLFonZI%3D&reserved=0
>
>
--
last-call mailing list
last-call@xxxxxxxx
https://www.ietf.org/mailman/listinfo/last-call
