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

[Peter Psenak <[e-mail]>]

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