Hi Deborah,
thanks for your comments, please see inline (##P):
On 10/06/2020 23:57, Deborah Brungard via Datatracker wrote:
Deborah Brungard has entered the following ballot position for
draft-ietf-ospf-te-link-attr-reuse-14: Discuss
When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)
Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.
The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-ospf-te-link-attr-reuse/
----------------------------------------------------------------------
DISCUSS:
----------------------------------------------------------------------
This should be simple to resolve - the use of the SR-TE term is
out-of-alignment with other drafts, spring and idr. Suggest: Segment Routing
Traffic Engineering/s/Segment Routing Policy and SRTE/s/SR Policy.
----------------------------------------------------------------------
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.
But I don't think this is really the intention of the draft - even section 4.1
says duplication would be only in "rare cases". The specific problem (to me) is
the ability to support advertisement of application specific values?
##PP
that is the second problem that the draft is addressing.
And, to
say, new applications MUST NOT make use of RSVP-TE LSA advertisements which is
causing confusion for (some) implementations. It would help to make this more
clearer and not muddy with implementation woes.
##PP
I don't know how to make it any more clear. There is an existing text in
the draft:
In recent years new applications have been introduced which have use
cases for many of the link attributes historically used by RSVP-TE.
Such applications include Segment Routing Traffic Engineering (SRTE)
[I-D.ietf-spring-segment-routing-policy] and Loop Free Alternates
(LFA) [RFC5286]. This has introduced ambiguity in that if a
deployment includes a mix of RSVP-TE support and SRTE support (for
example) it is not possible to unambiguously indicate which
advertisements are to be used by RSVP-TE and which advertisements are
to be used by SRTE. If the topologies are fully congruent this may
not be an issue, but any incongruence leads to ambiguity.
An example where this ambiguity causes a problem is a network in
which RSVP-TE is enabled only on a subset of its links. A link
attribute is advertised for the purpose of another 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 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.
An additional issue arises in cases where both applications are
supported on a link but the link attribute values associated with
each application differ. Current advertisements do not support
advertising application specific values for the same attribute on a
specific link.
This document defines extensions which address these issues.
If above is not sufficient, please suggest a text that would make it clear.
I don't see any discussion on the dark bandwidth problem or the security
problems identified in RFC8426? It would be helpful if the draft pointed to the
RFC8426 solution.
##PP
how is RFC8426 relevant in the context of this draft?
thanks,
Peter
_______________________________________________
Lsr mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/lsr
