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 <ppsenak@xxxxxxxxx>
Sent: Monday, June 1, 2020 11:01 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 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%7C1bd0e81d5279453d853808d8064500a2%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637266240741960001&sdata=faz4UopBwiK3D0CXWu%2BiebFOje9qfJt1wL6J4QqcjlY%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
