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

[Peter Psenak <[e-mail]>]

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.

> 
> 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 <[e-mail]>
> Sent: Monday, June 1, 2020 11:01 AM
> To: Linda Dunbar <[e-mail]>; [e-mail]
> Cc: [e-mail]; [e-mail]; [e-mail]
> 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 <[e-mail]>
>> Sent: Friday, May 29, 2020 10:00 AM
>> To: Linda Dunbar <[e-mail]>; [e-mail]
>> Cc: [e-mail]; [e-mail];
>> [e-mail]
>> 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 <[e-mail] <mailto:[e-mail]>>
>>> Sent: Friday, May 29, 2020 5:51 AM
>>> To: Linda Dunbar <[e-mail]
>>> <mailto:[e-mail]>>;
>> [e-mail] <mailto:[e-mail]>
>>> Cc: [e-mail] <mailto:[e-mail]>; [e-mail]
>> <mailto:[e-mail]>;
>>> [e-mail]
>> <mailto:[e-mail]>
>>> 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%7C1bd0e81d5279453d853808d8064500a2%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637266240741960001&amp;sdata=faz4UopBwiK3D0CXWu%2BiebFOje9qfJt1wL6J4QqcjlY%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
>>>>
>>>>
>>>>
>>>>
> 
> 
>