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 <ppsenak@xxxxxxxxx>
Sent: Friday, May 29, 2020 10:00 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
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 <mailto:ppsenak@xxxxxxxxx>>
Sent: Friday, May 29, 2020 5:51 AM
To: Linda Dunbar <linda.dunbar@xxxxxxxxxxxxx <mailto:linda.dunbar@xxxxxxxxxxxxx>>;
gen-art@xxxxxxxx <mailto:gen-art@xxxxxxxx>
Cc: last-call@xxxxxxxx <mailto:last-call@xxxxxxxx>; lsr@xxxxxxxx
<mailto:lsr@xxxxxxxx>;
draft-ietf-ospf-te-link-attr-reuse.all@xxxxxxxx
<mailto: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%7C34b141b11fe6484fc65208d803e0e851%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637263611798933480&sdata=hXIX5xyAiXcFdymKVyg%2BVuQZAznQKJV5Il7U9OOdVv0%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
