Hi Balaji, I guess you have NOT been following the OSPF mailing list… The whole point of the draft is to NOT require OSPF TE LSAs when RSVP traffic engineering in not active – fewer LSAs to correlate is better.
Please review the archives. https://datatracker.ietf.org/wg/ospf/archives/ Hope this helps, Acee From: Balaji venkat Venkataswami <balajivenkat...@gmail.com> Date: Wednesday, January 31, 2018 at 11:11 AM To: OSPF WG List <ospf@ietf.org>, "Peter Psenak (ppsenak)" <ppse...@cisco.com>, Acee Lindem <a...@cisco.com> Subject: Fwd: I-D Action: draft-ietf-ospf-te-link-attr-reuse-03.txt Hi Peter, Acee, In section 2 in your proposal, you have specified as follows. 1. Remote Interface IP address [RFC3630] - OSPFv2 currently cannot distinguish between parallel links between two OSPFv2 routers. As a result, the two-way connectivity check performed during SPF may succeed when the two routers disagree on which of the links to use for data traffic. Though your intention was to say that Remote Interface IP address is a Link-attribute that would be useful to non-MPLS-TE and non-GMPLS applications, it comes across in this para that the parallel-links identification problem still exists in OSPFv2 inspite of RFC 3630 specs for this TLV. Its just a cosmetic issue but for a newbie looking at the draft, it takes the conclusion too seriously. RFC 3630 appropriate extract. 2.5.4<https://tools.ietf.org/html/rfc3630#section-2.5.4>. Remote Interface IP Address The Remote Interface IP Address sub-TLV specifies the IP address(es) of the neighbor's interface corresponding to this link. This and the local address are used to discern multiple parallel links between systems. If the Link Type of the link is Multi-access, the Remote Interface IP Address is set to 0.0.0.0; alternatively, an implementation MAY choose not to send this sub-TLV. The Remote Interface IP Address sub-TLV is TLV type 4, and is 4N octets in length, where N is the number of neighbor addresses. Just a small correction needed. That RFC 3630 got rid of the problem and that it still doesnt persist. thanks and regards, balaji venkat ---------- Forwarded message ---------- From: <internet-dra...@ietf.org<mailto:internet-dra...@ietf.org>> Date: Tue, Jan 30, 2018 at 6:41 PM Subject: I-D Action: draft-ietf-ospf-te-link-attr-reuse-03.txt To: i-d-annou...@ietf.org<mailto:i-d-annou...@ietf.org> Cc: ospf@ietf.org<mailto:ospf@ietf.org> A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Open Shortest Path First IGP WG of the IETF. Title : OSPFv2 Link Traffic Engineering (TE) Attribute Reuse Authors : Peter Psenak Acee Lindem Les Ginsberg Wim Henderickx Jeff Tantsura Hannes Gredler John Drake Filename : draft-ietf-ospf-te-link-attr-reuse-03.txt Pages : 16 Date : 2018-01-30 Abstract: Various link attributes have been defined in OSPFv2 in the context of the MPLS Traffic Engineering (TE) and GMPLS. Many of these link attributes can be used for purposes other than MPLS Traffic Engineering or GMPLS. This documents defines how to distribute such attributes in OSPFv2 for applications other than MPLS Traffic Engineering or GMPLS purposes.
_______________________________________________ OSPF mailing list OSPF@ietf.org https://www.ietf.org/mailman/listinfo/ospf
