[mpls] Request for clarification on RFC 6720

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

Return-Path: <ramakrishnadtv@gmail.com>
X-Original-To: mpls@ietfa.amsl.com
Delivered-To: mpls@ietfa.amsl.com
Received: from localhost (localhost []) by ietfa.amsl.com (Postfix) with ESMTP id 6FF92128CE4 for <mpls@ietfa.amsl.com>; Thu, 27 Dec 2018 22:30:08 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id 1ldbjsa_2Z5Z for <mpls@ietfa.amsl.com>; Thu, 27 Dec 2018 22:30:07 -0800 (PST)
Received: from mail-oi1-x230.google.com (mail-oi1-x230.google.com [IPv6:2607:f8b0:4864:20::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F0AF41288BD for <mpls@ietf.org>; Thu, 27 Dec 2018 22:30:06 -0800 (PST)
Received: by mail-oi1-x230.google.com with SMTP id x23so16715191oix.3 for <mpls@ietf.org>; Thu, 27 Dec 2018 22:30:06 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to; bh=OU57OHoktS1gIXWcNNtNM/V6PLpfEJYSA7ppsIW62AY=; b=nZo/xHBwDswxXSLVunEKBntTAdfrMloJVZhVvFYJlxutWSNrrkGQzJI7nzjO7rXVPx sepw1+M4PHIJsNAmMUxhyHIgll096M4+AMOp2xHEQFjdwnA5CWZPU5SNp2U0/smHvcMl JbsSVMIyf0IWRluMRVTVIuvbLUIiw8iZVEnKXDVYnTYcrdVUylGHtTEB658KAxiWaQ2c g/iYCLE4q7aenOXjW8tdYFaDKqjelOIcJGmF+UEhxV5KgZHUcO3ThOr3QreivmFpb7U4 LXP7TRuF2VVb32bqGNJunsL/XQQ38Wlpjh5niRqUDOjKKq1jSRGr9OA1QtxPs7Pq7L6G xRzw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=OU57OHoktS1gIXWcNNtNM/V6PLpfEJYSA7ppsIW62AY=; b=lxExqivpX9i992FJn95RDQsNSzp/MceIIUldZojXEPm6TEz5jjR2+MTtNiDP8n/5l7 o4Do2b79eTZieAY2wHdLquTchCHa0y7QZLOtPs73B/cEFJWiNiG2GkD1qHwXkdSdK5i6 Lp8HNLo2tEjf32VX4Qyptqbhb/gc5uY+EHPY/h53SPRpMx4QOiZ41gDlrDxAJGmQAJx9 0oV53Cyfp8Jlgwc3saCj4RRZLcLFOmm32rG1vqv4UkUq+3bg1a66jLK66Jf37x9hJj73 hGx1U0PcF5D0AsmjP+ZuaMGZd/Ddryyp8b5PBuHSObFKCN+cDbbWhL0L1j4DiTvnvorK r/Lw==
X-Gm-Message-State: AA+aEWaDjOBLgOew3AhhHS9iiJKPv4QWZH3HYgYd5RcIAtntzRhyPfw9 bVsQlfkReTVus6YLEv2M+MCX+EHxD4f+a+krIFNAhfYK
X-Google-Smtp-Source: AFSGD/VShc5J51CJxNXX8K1cG3ms2gOc8yTdgQa7qqm3v08dLcw0gjqWYPfcIjt+V33m/S7BCuJoSwfE6ctGiIBQ6M4=
X-Received: by 2002:aca:f288:: with SMTP id q130mr16212612oih.228.1545978605882; Thu, 27 Dec 2018 22:30:05 -0800 (PST)
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>
X-Mailman-Approved-At: Fri, 28 Dec 2018 02:20:06 -0800
Subject: [mpls] Request for clarification on RFC 6720
X-BeenThere: mpls@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Multi-Protocol Label Switching WG <mpls.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/mpls>, <mailto:mpls-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/mpls/>
List-Post: <mailto:mpls@ietf.org>
List-Help: <mailto:mpls-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/mpls>, <mailto:mpls-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 28 Dec 2018 10:19:15 -0000


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

   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


   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."


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.