Deborah,
please see inline (##PP)
On 11/06/2020 14:00, BRUNGARD, DEBORAH A wrote:
Hi Peter,
Thanks - in-line-
Deborah
-----Original Message-----
From: Peter Psenak <[email protected]>
Sent: Thursday, June 11, 2020 7:00 AM
To: BRUNGARD, DEBORAH A <[email protected]>; The IESG <[email protected]>
Cc: [email protected]; [email protected]; [email protected]; Acee
Lindem <[email protected]>; Yingzhen Qu <[email protected]>;
[email protected]
Subject: Re: Deborah Brungard's Discuss on
draft-ietf-ospf-te-link-attr-reuse-14: (with DISCUSS and COMMENT)
Hi Deborah,
thanks for your comments, please see inline (##P):
----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------
As Warren noted, the draft is very difficult to read.
This doesn't parse:
"As soon as the router that is an RSVP-TE head-end sees the link attribute being
advertised for that link, it assumes RSVP-TE is enabled on that link,
even though it is not. If such RSVP-TE head-end router tries to
setup an RSVP-TE path via that link it will result in the path setup
failure."
It seems there is the assumption the link is congruent with the signaling
(maybe some implementations do but not per spec). Maybe this is needed by some
implementations, but the draft seems to make it a "general problem".
##PP
It is a general problem. RSVP-TE and IGP topologies do not need to be
congruent. All major vendors' implementation derive the link
participation in the RSVP-TE topology from the presence of the RSVP-TE
link attributes. So this is one of the two problems this draft solves.
##DB
That's too bad - sad. But as you say it is an implementation problem - that's my concern on having
these sentences in this document - we will be giving visibility to it as if it is a
"BCP". I think this needs to be prefaced as "Some implementations". As I said,
I find this confusing and detracts from the (hopefully) main aim of the document. I'll redo my
Discuss to add this qualifier as I do think we need to accurately say this is an implementation
problem.
##PP
it is not the implementation problem.
There is no standardized way to derive the RSVP-TE traffic engineering
topology.
For example, RFC3630 says:
"The extensions provide a way of describing the traffic engineering
topology (including bandwidth and administrative constraints) and
distributing this information within a given OSPF area. This
topology does not necessarily match the regular routed topology,"
but it does not provide any mechanism how the traffic engineering
topology is derived. So we have a problem, where implementations picked
a method to fill the void in the specification.
##PP
how is RFC8426 relevant in the context of this draft?
##DB
Advertising bandwidth per an application will not solve the "big problem" -
dark bandwidth accounting. While not part of the advertisement, as we already have an RFC
on it, it would be helpful to our user community to point to it.
##PP
we are not trying to solve the "dark bandwidth accounting", so I see no
relevance between this draft and RFC8426.
thanks,
Peter
thanks,
Peter
_______________________________________________
Lsr mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/lsr
_______________________________________________
Lsr mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/lsr
