Hi Paul,

please see inline:

On 4/7/16 22:09 , Paul Mattes (AZURE) wrote:
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.

ok, will change.


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.

well, it's not just SR-based traffic engineering. LFA is another example, which is not related to SR TE.


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.


section 3.1 talks about the other approach, which is to only use TE Opaque LSA for advertising any link attributes. In such case the link attribute is only advertise once.

Section 3.2., which talks about the preferred option of using Extended Link LSA explicitly says "the same link attribute is advertised in both the TE Opaque and Extended Link Attribute LSAs".

thanks,
Peter

/pdm/



_______________________________________________
OSPF mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/ospf


_______________________________________________
OSPF mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/ospf

Reply via email to