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

Balaji venkat Venkataswami <balajivenkat299@gmail.com> Wed, 31 January 2018 16:13 UTC

MIME-Version: 1.0
In-Reply-To: <151731787540.27488.14111387915689532214@ietfa.amsl.com>
References: <151731787540.27488.14111387915689532214@ietfa.amsl.com>
From: Balaji venkat Venkataswami <balajivenkat299@gmail.com>
Date: Wed, 31 Jan 2018 21:41:37 +0530
Message-ID: <CAHF4apMehNqh_sinW_+KkUpOi4g6rumDy9sEdrg-hZ=FbSY4jw@mail.gmail.com>
To: ospf@ietf.org, ppsenak@cisco.com, acee@cisco.com
Content-Type: multipart/alternative; boundary="001a11442e44e15525056414bb11"
Archived-At: <https://mailarchive.ietf.org/arch/msg/ospf/umlsytCoy5B6PdtlI8P1w476Gvg>
Subject: [OSPF] Fwd: I-D Action: draft-ietf-ospf-te-link-attr-reuse-03.txt
Precedence: list

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-drafts@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-announce@ietf.org
Cc: 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] I-D Action: draft-ietf-ospf-te-link-attr-r… internet-drafts
[OSPF] Fwd: I-D Action: draft-ietf-ospf-te-link-a… Balaji venkat Venkataswami
Re: [OSPF] I-D Action: draft-ietf-ospf-te-link-at… Acee Lindem (acee)