[mpls] Request for clarification on RFC 7552

Ramakrishna Rao Desetti <ramakrishnadtv@gmail.com> Thu, 03 January 2019 07:33 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 CB471131105 for <mpls@ietfa.amsl.com>; Wed, 2 Jan 2019 23:33:42 -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 XUVVT4-6wO87 for <mpls@ietfa.amsl.com>; Wed, 2 Jan 2019 23:33:41 -0800 (PST)
Received: from mail-oi1-x236.google.com (mail-oi1-x236.google.com [IPv6:2607:f8b0:4864:20::236]) (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 094FC130E51 for <mpls@ietf.org>; Wed, 2 Jan 2019 23:33:40 -0800 (PST)
Received: by mail-oi1-x236.google.com with SMTP id y23so27022016oia.4 for <mpls@ietf.org>; Wed, 02 Jan 2019 23:33:40 -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=dYALOY4x6EuK/v794GLCPngcXBzd/9NsUT3fNVxxs1c=; b=Pjxm5HLE/jnmyG+kOnNlPH6SoFdDmPKlHS4etJuU21bbkUzGob2RrJJr//7P0cN1Eb Dmyl0q4y7UHdJhdT9f3fLOnjbDp5Ctgd+p8MhFuRddKtMTgSYfl6eQw4N5ODmEjyWNl1 p553nuCiveZeAtJW2NeIL4qW3B4Fsd2S/Mm0imIuMupa/3O4ETrcX1nYBPROeBHRZPqx 1sHtvK5DKNsZQ1kHm/qhdRaKdkC6I0BePZURrhls8tfwPuA6LlN/84uG3cG9Tb5DNrOJ a5Ym2T2/gOa+Ea7CiuHfpx0qUxVD6i5T7Jumaoz/NxA/5x11uqLfwkg9F0JpaRVuO7TN k37g==
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=dYALOY4x6EuK/v794GLCPngcXBzd/9NsUT3fNVxxs1c=; b=AlMjaU82nlHrp4Ko+xwMGISvUeTf7B8/0uCXi2b+CK7xhMWY0rHsZRCHb0DJcLBINE waPf5gbQR0IBccV0hrYLEIcl5Ael35IbzNlDOxoLYnVQq4tBHGDCJPbL1vKwAKEmxosI xv3E7QKfRJvZjDIWNRPtyrJk6A8re3oHlqf70QtgQRAEXQskKpdHlUeAWcjEBocYvpZE GWaoAsqyeQ4QRDSoo3a3H7wr9lhjUyxfEGdcYKqmaeP0lvEY/ZfB+sTrGaeyT1+a5Yk+ kJC74q9ItkYG5pEFEk+m2keBSKN4rJX4P82ASIYYDSacl+iLwbPrLNLYQXedHdefuXyg yRwQ==
X-Gm-Message-State: AA+aEWZM7Xq7e/VMwbALlGu4+uM+g962PCYmkWm6Du9Er6BJ3w1VFC3+ ICm/PyVypv3JDOXyL+YrS9Nbs3QujMl4Chh6to4nfW6K
X-Google-Smtp-Source: AFSGD/X1Eb/J6eDYgKpy6+x+CgtO0uaSsCzZYCmgHNs02d5agYy5EsLIRzD+whomq/5jmHW3nnsPBjdme5UcJjQUh+g=
X-Received: by 2002:aca:4cc8:: with SMTP id z191mr32469827oia.54.1546500820010; Wed, 02 Jan 2019 23:33:40 -0800 (PST)
MIME-Version: 1.0
From: Ramakrishna Rao Desetti <ramakrishnadtv@gmail.com>
Date: Thu, 3 Jan 2019 13:03:27 +0530
Message-ID: <CAEh1p15dEO-Qok==u8A_-LT4jUso3iGao4jH8KOKMtt9UBDR7g@mail.gmail.com>
To: mpls@ietf.org
Content-Type: text/plain; charset="UTF-8"
Archived-At: <https://mailarchive.ietf.org/arch/msg/mpls/k6DxLs-YSGzrgp29obuQlb0X67I>
X-Mailman-Approved-At: Thu, 03 Jan 2019 02:39:55 -0800
Subject: [mpls] Request for clarification on RFC 7552
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: Thu, 03 Jan 2019 07:33:43 -0000


I request a clarification with regard to RFC 7552 (Updates to LDP for IPv6).

This is regarding how to determine active/passive roles in some scenarios.

Consider the following scenario (reproduced from RFC 7552):


         Figure 2: LSRs Connected via Two Single-Stack Interfaces

In this case, R1 and R2 are dual-stack LSRs. Hence they intend to exchange
both IPv4 and IPv6 FEC label mappings.

Note that in the above setup, R1 and R2 are connected via two single-stack
interfaces. The transport-connection-preference is set to ipv4.

The IPv6 link is UP and R1 and R2 formed adjacency. The Dual-Stack capability
is set as IPv4. For some reason, the IPv4 adjacency is not getting established.

In this scenario, what do R1 and R2 do? Do they establish IPv6 based TCP
session? The reason I am asking is if they intend to do that how do they
determine which LSR will become active.

The RFC says:

"2. If the Dual-Stack capability TLV is present and the remote
      preference matches the local preference, then:

      a) If TR=0100 (LDPoIPv4), then determine the active/passive roles
         for the TCP connection using an IPv4 transport address as
         defined in Section 2.5.2 of RFC 5036.

      b) If TR=0110 (LDPoIPv6), then determine the active/passive roles
         for the TCP connection by using an IPv6 transport address as
         defined in Section 2.5.2 of RFC 5036."

Based on this criteria, it is not possible to determine active/passive because
IPv4 adjacency was not formed.

How do R1 and R2 proceed further? It appears the standard is not providing
guidance, although the intention seems to be to establish an IPv6
based TCP session.

Could you please let me know your comments?

Thanks and regards,
Ramakrishna DTV.