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>
Sent: Friday, May 29, 2020 5:51 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 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%7C008faccf0edd4290149908d803be29ea%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637263462571035839&sdata=gkOw4rUUjCqIpp%2B3opurl5M44kb3cQzOYlIC%2FOLAoD0%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
--
last-call mailing list
last-call@xxxxxxxx
https://www.ietf.org/mailman/listinfo/last-call
