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

From: Linda Dunbar via Datatracker <[email-masked]>
Date: Thu, 28 May 2020 10:02:59 -0700

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://trac.ietf.org/trac/gen/wiki/GenArtfaq>.

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?

Minor issues:

Nits/editorial comments:

Best regards,

Linda Dunbar

---

From: Peter Psenak <[email-masked]>
Date: Fri, 29 May 2020 12:50:48 +0200

Hi Linda,

> SID and the SIDs of adjacent nodes. Can't they be encoded (or extended) in

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

---

From: Linda Dunbar <[email-masked]>
Date: Fri, 29 May 2020 14:52:13 +0000

Peter,

You said:

      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?  If no new attributes are to be added, then why need a new ASLA sub-TLV?

Linda

-----Original Message-----
From: Peter Psenak <[email-masked]>
Sent: Friday, May 29, 2020 5:51 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 28/05/2020 19:02, Linda Dunbar via Datatracker wrote:
> 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.
>
> <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%7C008faccf0edd4290149908d803be29ea%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637263462571035839&amp;sdata=gkOw4rUUjCqIpp%2B3opurl5M44kb3cQzOYlIC%2FOLAoD0%3D&amp;reserved=0>.
>
> 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

---

From: Peter Psenak <[email-masked]>
Date: Fri, 29 May 2020 16:59:33 +0200

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

> Cc: [email-masked]; [email-masked]; 
> [email-masked]