Re: [OSPF] I-D Action: draft-ietf-ospf-te-link-attr-reuse-03.txt

["Acee Lindem (acee)" <[e-mail]>]

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 <[e-mail]>
Date: Wednesday, January 31, 2018 at 11:11 AM
To: OSPF WG List <[e-mail]>, "Peter Psenak (ppsenak)" <[e-mail]>, Acee Lindem <[e-mail]>
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: <[e-mail]<mailto:[e-mail]>>
Date: Tue, Jan 30, 2018 at 6:41 PM
Subject: I-D Action: draft-ietf-ospf-te-link-attr-reuse-03.txt
To: [e-mail]<mailto:[e-mail]>
Cc: [e-mail]<mailto:[e-mail]>



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.