Subject: Re: [Last-Call] Genart last call review of draft-ietf-ospf-te-link-attr-reuse-12

From: Linda Dunbar <[email-masked]>
Date: Mon, 1 Jun 2020 15:30:30 +0000

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?

Linda Dunbar

-----Original Message-----
From: Peter Psenak <[email-masked]>
Sent: Friday, May 29, 2020 10:00 AM
To: Linda Dunbar <[email-masked]>; [email-masked]
Cc: [email-masked]; [email-masked]; [email-masked]
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 <[email-masked]<mailto:[email-masked]>>
> Sent: Friday, May 29, 2020 5:51 AM
> To: Linda Dunbar <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>
> Cc: [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>;
> [email-masked]<mailto:[email-masked]>
> 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&amp;data=02%7C01%7Clinda.dunbar%40futurewei.com%7C34b141b11fe6484fc65208d803e0e851%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637263611798933480&amp;sdata=hXIX5xyAiXcFdymKVyg%2BVuQZAznQKJV5Il7U9OOdVv0%3D&amp;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
>>
>>
>>
>>

---

From: Peter Psenak <[email-masked]>
Date: Mon, 1 Jun 2020 18:01:05 +0200

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.//”/

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

> Cc: [email-masked]; [email-masked]; 
> [email-masked]
> the problem with existing advertisement is that RSVP-TE will use it, 
> even if it was not intended to be used by RSVP-TE.
>> From: Peter Psenak <[email-masked] <mailto:[email-masked]>>
>> To: Linda Dunbar <[email-masked] <mailto:[email-masked]>>; 
> [email-masked] <mailto:[email-masked]>
>> Cc: [email-masked] <mailto:[email-masked]>; [email-masked] 
> <mailto:[email-masked]>;
>> [email-masked] 
> <mailto:[email-masked]>

---

From: "Scott O. Bradner" <[email-masked]>
Date: Mon, 1 Jun 2020 13:04:23 -0400

that works for me - thanks

Scott

> On Jun 1, 2020, at 12:01 PM, Peter Psenak <ppsenak=[email-masked]> wrote:
> 
> Hi Linda,
> 
> 
>> /“//the problem with existing advertisement is that RSVP-TE will use it, even if it was not intended to be used by RSVP-TE.//”/
> "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."
> 
>>> /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?
>>>> 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.
>>>> 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 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
> [email-masked]
> https://www.ietf.org/mailman/listinfo/last-call

---

From: Linda Dunbar <[email-masked]>
Date: Tue, 9 Jun 2020 00:37:05 +0000

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 <[email-masked]> 
Sent: Monday, June 1, 2020 11:01 AM
To: Linda Dunbar <[email-masked]>; [email-masked]
Cc: [email-masked]; [email-masked]; [email-masked]
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?

thanks,
Peter

>> /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?
>>> <https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Ftrac.ietf.org%2Ftrac%2Fgen%2Fwiki%2FGenArtfaq&amp;data=02%7C01%7Clinda.dunbar%40futurewei.com%7C1bd0e81d5279453d853808d8064500a2%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637266240741960001&amp;sdata=faz4UopBwiK3D0CXWu%2BiebFOje9qfJt1wL6J4QqcjlY%3D&amp;reserved=0>.
>>> 
>>> the NEW Link attributes needed by Segment Routing. Page 7 (section 
>>> 5) has a really good description on all the link properties added to 
>>> 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?

---

From: Peter Psenak <[email-masked]>
Date: Tue, 9 Jun 2020 10:51:50 +0200

Linda,

> 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.

> 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 wil…

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

---

From: "Acee Lindem (acee)" <[email-masked]>
Date: Tue, 9 Jun 2020 11:25:07 +0000

Hi Linda,
One more point... 

On 6/9/20, 4:52 AM, "Peter Psenak" <[email-masked]> wrote:

    Linda,

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

    thanks,
    Peter

---

From: Linda Dunbar <[email-masked]>
Date: Tue, 9 Jun 2020 14:18:51 +0000

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? 

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?). 

 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? 

Thank you. 

Linda

-----Original Message-----
From: Acee Lindem (acee) <[email-masked]> 
Sent: Tuesday, June 9, 2020 6:25 AM
To: Peter Psenak (ppsenak) <[email-masked]>; Linda Dunbar <[email-masked]>; [email-masked]
Cc: [email-masked]; [email-masked]; [email-masked]
Subject: Re: Genart last call review of draft-ietf-ospf-te-link-attr-reuse-12

Hi Linda,
One more point... 

    Linda,

Thanks,
Acee

    thanks,
    Peter

    >>>> <https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Ftrac.ietf.org%2Ftrac%2Fgen%2Fwiki%2FGenArtfaq&amp;data=02%7C01%7Clinda.dunbar%40futurewei.com%7C309664b123c94394e2dd08d80c67c5a3%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637272987144517506&amp;sdata=yjT5mPs4vN32aowy2foFqlpJTvM%2BfPxE1kAnDL8M8hU%3D&amp;reserved=0>.
    >>>>

---

From: Peter Psenak <[email-masked]>
Date: Tue, 9 Jun 2020 17:18:27 +0200

Linda,

> 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 inf…

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 u…

please see above.

thanks,
Peter

---

From: Linda Dunbar <[email-masked]>
Date: Tue, 9 Jun 2020 20:20:52 +0000

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? 

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. 

Linda Dunbar

-----Original Message-----
From: Peter Psenak <[email-masked]> 
Sent: Tuesday, June 9, 2020 10:18 AM
To: Linda Dunbar <[email-masked]>; Acee Lindem (acee) <[email-masked]>; [email-masked]
Cc: [email-masked]; [email-masked]; [email-masked]
Subject: Re: Genart last call review of draft-ietf-ospf-te-link-attr-reuse-12

Linda,

> 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.

please see above.

thanks,
Peter
> To: Peter Psenak (ppsenak) <[email-masked]>; Linda Dunbar 
> <[email-masked]>; [email-masked]
>      >>>> <https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Ftrac.ietf.org%2Ftrac%2Fgen%2Fwiki%2FGenArtfaq&amp;data=02%7C01%7Clinda.dunbar%40futurewei.com%7C8a84b4e73ad4437f29d308d80c885dec%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637273127117025467&amp;sdata=9a4QhoPrY67BkbvqjEslt3SaXVa0hiAkgenAR5jpMO8%3D&amp;reserved=0>.
>      >>>>

---

From: Peter Psenak <[email-masked]>
Date: Wed, 10 Jun 2020 10:39:30 +0200

Linda,

> 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…

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…

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

> _______________________________________________
> Lsr mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/lsr
> 
>

---

From: Linda Dunbar <[email-masked]>
Date: Wed, 10 Jun 2020 18:40:23 +0000

Peter, 

Linda

-----Original Message-----
From: Peter Psenak <[email-masked]> 
Sent: Wednesday, June 10, 2020 3:40 AM
To: Linda Dunbar <[email-masked]>; Acee Lindem (acee) <[email-masked]>; [email-masked]
Cc: [email-masked]; [email-masked]; [email-masked]
Subject: Re: [Lsr] Genart last call review of draft-ietf-ospf-te-link-attr-reuse-12

Linda,

yes.

thanks,
Peter

>>       >>>> <https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Ftrac.ietf.org%2Ftrac%2Fgen%2Fwiki%2FGenArtfaq&amp;data=02%7C01%7Clinda.dunbar%40futurewei.com%7C15106e48f1084954b35a08d80d19ccee%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637273751753415740&amp;sdata=0aA%2B%2F9dM%2FxhneUaVnh435vqNVe6vLttlL8U8kGbTcMw%3D&amp;reserved=0>.
>>       >>>>
> https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.
> ietf.org%2Fmailman%2Flistinfo%2Flsr&amp;data=02%7C01%7Clinda.dunbar%40
> futurewei.com%7C15106e48f1084954b35a08d80d19ccee%7C0fee8ff2a3b240189c7
> 53a1d5591fedc%7C1%7C0%7C637273751753415740&amp;sdata=6rcZuEZernpe88EGj
> ehGIesn7nPpAX6UdI2wPLFonZI%3D&amp;reserved=0
> 
>