[mpls] Request for clarification on RFC 6720

Ramakrishna Rao Desetti <ramakrishnadtv@gmail.com> Fri, 28 December 2018 06:30 UTC

MIME-Version: 1.0
From: Ramakrishna Rao Desetti <ramakrishnadtv@gmail.com>
Date: Fri, 28 Dec 2018 11:59:52 +0530
Message-ID: <CAEh1p15Jqrw8p_fE1kLssphcUxF9n1qnPVcT0oXER3qZw5qPOA@mail.gmail.com>
To: mpls@ietf.org
Content-Type: text/plain; charset="UTF-8"
Archived-At: <https://mailarchive.ietf.org/arch/msg/mpls/OYRjxKbSgaeT615ecKN5b4XaV84>
Subject: [mpls] Request for clarification on RFC 6720
Precedence: list

Hi,

I request a clarification on a specific point in RFC 6720 (The Generalized TTL
Security Mechanism (GTSM) for the Label Distribution Protocol (LDP)).

RFC 6720 talks about GTSM support when both basic and extended discovery are
used. In this regard, consider the following excerpt from Section 3:

"3.  LDP Peering Scenarios and GTSM Considerations

   This section discusses GTSM considerations arising from the LDP
   peering scenarios used, including single-hop versus multi-hop LDP
   neighbors, as well as the use of LDP Basic Discovery versus Extended
   Discovery.

   The reason that the GTSM capability negotiation is enabled for Basic
   Discovery by default (i.e., G=1) but not for Extended Discovery is
   that the usage of Basic Discovery typically relates to a single-hop
   LDP peering session, whereas the usage of Extended Discovery
   typically relates to a multi-hop LDP peering session.  GTSM
   protection for multi-hop LDP sessions is outside the scope of this
   specification (see Section 1.2).  However, it is worth clarifying the
   following exceptions that may occur with Basic or Extended Discovery
   usage:

   ...

   c.  Two adjacent LSRs (i.e., back-to-back PE routers) forming a
       single-hop LDP peering session after doing both Basic and
       Extended Discovery

   ...  In the third case (c), GTSM is
   enabled by default for Basic Discovery and enforced on the subsequent
   LDP peering, and is not for Extended Discovery.  However, if each LSR
   uses the same IPv4 transport address object value in both Basic and
   Extended Discoveries, then it would result in a single LDP peering
   session that would be enabled with GTSM.  Otherwise, GTSM would not
   be enforced on the second LDP peering session corresponding to the
   Extended Discovery."

End-of-excerpt.

Please consider case (c) above. The text seems to imply that a second LDP
peering session would be established for extended discovery if it uses a IPv4
transport address different from that of basic discovery.

But from what I understand about RFC 5036, the second peering session would not
be established for this case.

This is based on RFC 5036.
Section 2.5.2 of RFC 5036 seems to imply that even if there are two
adjacencies from basic
and extended discoveries, only one LDP session would be established.

Section 2.5.2 says:

"If LSR1 does not already have an LDP session for the exchange
 of label spaces LSR1:a and LSR2:b, it attempts to open a TCP
 connection for a new LDP session with LSR2."

Section 2.5.2 also says:

"An LSR MUST advertise the same transport address in all Hellos that
 advertise the same label space."

Based on this, it appears the possibility of second LDP peering session for
extended discovery does not arise.

Could you please let me know your comments?

Thanks and regards,
Ramakrishna DTV.

[mpls] Request for clarification on RFC 6720 Ramakrishna Rao Desetti