I would like to amplify some of the comments made about this draft at today's
OSPF WG meeting.
The draft refers generically to TE when it really means RSVP TE. The draft
should use the more-specific term "RSVP TE" or "RSVP-based TE" in most (but not
all) of the places where "TE" is used. The most unhelpful place this occurs in
section 1:
Many of these link attributes are useful outside of the traditional MLPLS
(sic) Traffic Engineering or GMPLS.
This should read:
Many of these link attributes are useful outside of the traditional
RSVP-based Traffic Engineering, or GMPLS.
Perhaps it would be helpful if SR-based Traffic Engineering were mentioned as a
typical consumer of this new information, which would distinguish it from
RSVP-TE as the primary consumer of the existing TLVs.
In Section 3.1, I also have issue with this statement:
Additionally, link attributes are only advertised once when both OSPF TE
and other applications are deployed on the same link. This is not expected to
be a common deployment scenario.
I don't think that this is a desired result, and I believe this is what Chris
Bowers was trying to emphasize with his earlier comments. If a router currently
advertises the existing TE TLVs, it should continue to advertise them after it
implements this draft. Turning off advertisement of the existing TE TLVs (if
somehow they were being advertised without enabling RSVP-TE on the link) should
not be the default behavior, though perhaps it could be made an option. I know
this default would be less efficient, but I don't think it is worth breaking
backwards compatibility to have.
pdm
_______________________________________________
OSPF mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/ospf
