Re: [bess] [Idr] [Softwires] Regarding the Next Hop Network Address coding for IPv4 VPN over IPv6 Core in RFC5549

Robert Raszuk <robert@raszuk.net> Wed, 26 June 2019 13:27 UTC

Return-Path: <robert@raszuk.net>
X-Original-To: bess@ietfa.amsl.com
Delivered-To: bess@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2DB69120111 for <bess@ietfa.amsl.com>; Wed, 26 Jun 2019 06:27:39 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.898
X-Spam-Level:
X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=raszuk.net
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 50pewystF3-F for <bess@ietfa.amsl.com>; Wed, 26 Jun 2019 06:27:37 -0700 (PDT)
Received: from mail-qk1-x743.google.com (mail-qk1-x743.google.com [IPv6:2607:f8b0:4864:20::743]) (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 C2F8F12008A for <bess@ietf.org>; Wed, 26 Jun 2019 06:27:32 -0700 (PDT)
Received: by mail-qk1-x743.google.com with SMTP id c11so1583708qkk.8 for <bess@ietf.org>; Wed, 26 Jun 2019 06:27:32 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=raszuk.net; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=7AUeSsaZsDAwylpKvmLyIEHgn2Z5ay/XsC8c8yTUneM=; b=K2KTHgGP52h4pJkf1dnkkX0RciZKVq4isXUw4mAwUU8lDaK99fP0HMMM+gUFl6c5Lr U6ET0Si3+jouX+u8PsRJXab7eqG9+Q4eGjckpevhfs2K+vIvm8KKtwJ6/f/q/2Ibn2qJ thZ95jzAv8f5N1wURnRauzsxqt1m4nZgWb9dRqkU7/4FaaItSHw5IKICE3dXIqExpfRa MtT+2Y7MAKWr7O5twq2e0+EX0diZYKSejhpborsmKh9298wgM8BSTSe0AxN1C4UHegOy ond9i8WaY9E1SbXEGlMOOJNTHUT5lClvK6V+e7JQs+dq5aNOszTWKM99mARfelgYfDzK iwXA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=7AUeSsaZsDAwylpKvmLyIEHgn2Z5ay/XsC8c8yTUneM=; b=VZhyZmbtr9940JRemLjvrQwPcWN1mguyq3++In1upGlriCg7aBUlChj6Le96QdcElU D1PWtTrrlLOjuI/RmHBbE0kFeLTYhHdq0TN8d9Y0JBvi898Htj9fNEFHTgpLHB9KjWc5 k/GwO9S7Y5qU9034OcS39Ec/QgKe/rhWA+M5UCiqfISB4IadsACVJqsuhgigHSbXLO+Q aHnh3Jkj3CzCtNxA1vklYUFAeDluReWKXLa3nkrEupWFaqDnU9omh8cLgtNjr5fjSTBl Cc+PYVQ3l7fAywh1X2bJQVYRs3fLIZL677NBMXZVltTD3RMb1QjzySs9EHegJt4uHxyQ 2zOQ==
X-Gm-Message-State: APjAAAWuhsDUN0i/q/OI2zHlh9vlUS3sG21pJSruG26q0ak9cCW8NcJG oJajTrVwEXKcrLLGeaI/zFdThOMxAtgInla2xe/4EA==
X-Google-Smtp-Source: APXvYqxNiUPJ9ITDICjLlZd6n4Kc8SLF3BqYY7N2KvTfDz858UHL/MEdFH1U5uchdcsqO9P3x2A/41+WOs5vCqqPaB8=
X-Received: by 2002:a05:620a:1285:: with SMTP id w5mr3630442qki.302.1561555651804; Wed, 26 Jun 2019 06:27:31 -0700 (PDT)
MIME-Version: 1.0
References: <19AB2A007F56DB4E8257F949A2FB9858E5BDBB89@NKGEML515-MBS.china.huawei.com> <9DB8FCD5-DD04-4EB1-AEA5-A33B5B6F1BC4@gmx.com> <19AB2A007F56DB4E8257F949A2FB9858E5BE201C@NKGEML515-MBS.china.huawei.com> <B577834D-4010-42DF-AF28-690A1BD2A5AC@telekom.de> <16253F7987E4F346823E305D08F9115AAB8D61CE@nkgeml514-mbx.china.huawei.com> <CAOj+MMGdoi1ROTmbuFu8eXWix6JfYwO1TCPUakyOEdTU01-1zA@mail.gmail.com> <B17A6910EEDD1F45980687268941550F4D87EC92@MISOUT7MSGUSRCD.ITServices.sbc.com> <8E1E4882-7850-4BF4-82EC-82BDFE9BF408@gmail.com>
In-Reply-To: <8E1E4882-7850-4BF4-82EC-82BDFE9BF408@gmail.com>
From: Robert Raszuk <robert@raszuk.net>
Date: Wed, 26 Jun 2019 15:27:18 +0200
Message-ID: <CAOj+MMGKN9drVzJgrE6WVkF6k43Vqe6TNwK9VpHpFbJTafKUdA@mail.gmail.com>
To: Alexander Okonnikov <alexander.okonnikov@gmail.com>
Cc: "UTTARO, JAMES" <ju1738@att.com>, Xiejingrong <xiejingrong@huawei.com>, "softwires@ietf.org" <softwires@ietf.org>, "idr@ietf.org" <idr@ietf.org>, "ian.farrer@telekom.de" <ian.farrer@telekom.de>, "bess@ietf.org" <bess@ietf.org>, "ianfarrer@gmx.com" <ianfarrer@gmx.com>
Content-Type: multipart/alternative; boundary="000000000000ec527e058c3a011f"
Archived-At: <https://mailarchive.ietf.org/arch/msg/bess/5VUrBbhAuKoU5ANN1l6PQnHlvJc>
Subject: Re: [bess] [Idr] [Softwires] Regarding the Next Hop Network Address coding for IPv4 VPN over IPv6 Core in RFC5549
X-BeenThere: bess@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: BGP-Enabled ServiceS working group discussion list <bess.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/bess>, <mailto:bess-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/bess/>
List-Post: <mailto:bess@ietf.org>
List-Help: <mailto:bess-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/bess>, <mailto:bess-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 26 Jun 2019 13:27:39 -0000

Hi Alex,

> My understanding is follow: RD is encoded in Next Hop field

That is subtle misinterpretation of the 4364 :)

The text says:

"When a PE router distributes a VPN-IPv4 route via BGP, it uses its  own
address as the "BGP next hop".  This address is encoded as a VPN-IPv4
address with an RD of 0."

That can be read as:

A) Next hop field has prepended zeros to match the NLRI format of 8 octet
RD + 4 octet IPv4 (for IPv4 case)

B) Next hop is of format RD:IPv4 where RD=0

My recollection and number of direct discussions with authors of
both2547/4364 & 4760 at that time leads me to believe we are dealing with
A. Of course anyone can see option B as valid, but at the end of the day it
is the same on the wire :)

So I am not sure what exactly the problem or the question we are trying to
answer is :)

Cheers,
R.






On Wed, Jun 26, 2019 at 3:22 PM Alexander Okonnikov <
alexander.okonnikov@gmail.com> wrote:

> Hi,
>
> My understanding is follow: RD is encoded in Next Hop field, because
> authors of RFC 4364, while referring to RFC 2858, were trying to make it
> consistent with RFC 4760 (obsoletes RFC 2858). RFC 2858 says that Next Hop
> field should match AFI. On the other hand, RFC 4760 says that Next Hop
> Field should match combination of AFI/SAFI. Also, drafts of RFC 4364 and
> RFC 4760 were being developed practically at the same time period.
>
> 26 июня 2019 г., в 16:05, UTTARO, JAMES <ju1738@att.com> написал(а):
>
> *+1*
>
> *From:* Idr <idr-bounces@ietf.org> *On Behalf Of *Robert Raszuk
> *Sent:* Wednesday, June 26, 2019 7:53 AM
> *To:* Xiejingrong <xiejingrong@huawei.com>
> *Cc:* idr@ietf.org; ian.farrer@telekom.de; ianfarrer@gmx.com;
> softwires@ietf.org; bess@ietf.org
> *Subject:* Re: [Idr] [bess] [Softwires] Regarding the Next Hop Network
> Address coding for IPv4 VPN over IPv6 Core in RFC5549
>
> All,
>
> RD is a property of the NLRI not next hop. I am not sure where in this
> thread or some spec someone came to the conclusion that next hop field
> should contain an RD. RD is not useful there and should never be part of
> any next hop field.
>
> Remember RD role is to make prefix unique - that's it - no more no less.
> Next hop uniqness is given by architecture and there is no need to make it
> unique.
>
> In some cases when we need to carry IPv4 address in IPv6 next hop field
> (there was historically some assumption that next hop must be of the same
> AF as prefix) we prepend to it numerical zeros.
>
> Thx,
> R.
>
>
>
>
>
> On Wed, Jun 26, 2019 at 1:40 PM Xiejingrong <xiejingrong@huawei.com>
> wrote:
>
> Hi folks,
>
> I guess this is an inconsistency due to past carelessness. Is there anyone
> can tell us the history of this inconsistency ?
> RFC4364(VPNv4 over IPv4 network) and RFC4659(VPNv6 over IPv4 or IPv6
> network) both require to use RD+IP(v4 or v6 respectively) as nexthop.
> RFC5549(VPNv4/IPv4 over IPv6 network) requires to use IPv6 without RD as
> nexthop.
> This same question also occur in MVPN: RFC6515, which talks about MVPN6
> over IPv4/IPv6, or MVPN over IPv6, but does imply loosely to use IPv4/IPv6
> without RD as nexthop (see below).
>    The purpose of this document is to make clear that whenever a PE
>    address occurs in an MCAST-VPN route (whether in the NLRI or in an
>    attribute), the IP address family of that address is determined by
>    the length of the address (a length of 4 octets for IPv4 addresses, a
>    length of 16 octets for IPv6 addresses), NOT by the AFI field of the
>    route.
>
> My suggestion: implementation should interpret nexthop RD+IPv4 and nexthop
> IPv4 the same, and interpret nexthop RD+IPv6 and nexthop IPv6 the same.
> The RFC5549/SRv6-VPN/RFC6515 can keep as current shape, while interoperate
> can meet between different implementations.
> Need a new draft to clarify this and to give a guide on further FooService
> over FooNetwork ?
>
> Thanks
> Jingrong
>
> *From:* Softwires [mailto:softwires-bounces@ietf.org] *On Behalf Of *
> ian.farrer@telekom.de
> *Sent:* Tuesday, June 25, 2019 11:12 PM
> *To:* Zhuangshunwan <zhuangshunwan@huawei.com>; ianfarrer@gmx.com
> *Cc:* softwires@ietf.org; bess@ietf.org
> *Subject:* Re: [Softwires] Regarding the Next Hop Network Address coding
> for IPv4 VPN over IPv6 Core in RFC5549
>
> Hi Shunwan,
>
> I’ve just re-checked RFC5539, and the referenced section 3 of RFC2545 and
> I can find nothing about using VPN-IPv6 for encoding the next-hop. Section
> 3 of RFC5539 is very clear that it’s a 16-byte GU IPv6 address or 32-bytes
> with a GU and LL address.
>
> Can you point me to the text that gives you the impression that VPN-IPv6
> is correct?
>
> Note – I see that there is reported Errata on RFC5549, (not verified)
> saying that the length should be 24 or 48 to include the RD. However, as
> mentioned above, the supporting text in multiple places in the RFC and its
> references support the use of an IPv6 address (or 2) with no RD at 16 or 32
> bytes, so this does seem to be the intention of the document as written.
> https://www.rfc-editor.org/errata_search.php?rfc=5549
> <https://urldefense.proofpoint.com/v2/url?u=https-3A__www.rfc-2Deditor.org_errata-5Fsearch.php-3Frfc-3D5549&d=DwMFaQ&c=LFYZ-o9_HUMeMTSQicvjIg&r=s7ZzB4JbPv3nYuoSx5Gy8Q&m=UIVZS5gA4_SHRLCgtb5AnrGyg_Rit-E-t_ZsSB8Z5hQ&s=333xV6xato3JrUqR7cF_lNHZ6cCgzHqaeva-aNH6ORY&e=>
>
> Thanks,
> Ian
>
> *From: *Softwires <softwires-bounces@ietf.org> on behalf of Zhuangshunwan
> <zhuangshunwan@huawei.com>
> *Date: *Tuesday, 25. June 2019 at 13:18
> *To: *"ianfarrer@gmx.com" <ianfarrer@gmx.com>
> *Cc: *"softwires@ietf.org" <softwires@ietf.org>, "bess@ietf.org" <
> bess@ietf.org>
> *Subject: *Re: [Softwires] Regarding the Next Hop Network Address coding
> for IPv4 VPN over IPv6 Core in RFC5549
>
> Hi Ian,
>
> Thanks for your response!
>
> The opinion I have collected is:
> Per RFC4634, the IPv4-VPN routes shall carry the V4 Next-hop, beginning
> with an 8-octet RD and ending with a 4-octet IPv4 address.
> Per RFC4659, the IPv6-VPN routes shall carry the V6 Next-hop, beginning
> with an 8-octet RD and ending with a 16-octet IPv6 address.
> When we start to implement the IPv4 VPN over IPv6 Core,  it is a natural
> way to encode the IPv4-VPN routes with VPN-IPv6 next-hop (i.e. beginning
> with an 8-octet RD and ending with a 16-octet IPv6 address) .
>
> I believe this is not just a minority opinion, and some of the current
> implementations are also doing this way.
>
> I hope that the WGs can give a consistent opinion on this issue and avoid
> interoperability problem in the future.
>
> Thanks,
> Shunwan
>
> *From:* ianfarrer@gmx.com [mailto:ianfarrer@gmx.com <ianfarrer@gmx.com>]
> *Sent:* Monday, June 24, 2019 8:08 PM
> *To:* Zhuangshunwan <zhuangshunwan@huawei.com>
> *Cc:* bess@ietf.org; softwires@ietf.org
> *Subject:* Re: [Softwires] Regarding the Next Hop Network Address coding
> for IPv4 VPN over IPv6 Core in RFC5549
>
> Hi,
>
> My reading of Section 3 of RFC5549 is that the v6 next-hop is encoded as
> an IPv6 address:
>
>    The BGP speaker receiving the advertisement MUST use the Length of
>    Next Hop Address field to determine which network-layer protocol the
>    next hop address belongs to.  When the Length of Next Hop Address
>    field is equal to 16 or 32, the next hop address is of type IPv6.
>
> It’s also worth noting that RFC4659 Section 2 states:
>
> A VPN-IPv6 address is a 24-octet quantity, beginning with an 8-octet
>    "Route Distinguisher" (RD) and ending with a 16-octet IPv6 address.
>
> So, not 16 or 32 bytes.
>
> Thanks,
> Ian
>
>
>
>
> On 22. Jun 2019, at 09:59, Zhuangshunwan <zhuangshunwan@huawei.com> wrote:
>
> Dear authors and WGs,
>
> RFC5549 Section 6.2 says:
>
> . 6.2.  IPv4 VPN over IPv6 Core
> .
> .    The extensions defined in this document may be used for support of
> .    IPV4 VPNs over an IPv6 backbone.  In this application, PE routers
> .    would advertise VPN-IPv4 NLRI in the MP_REACH_NLRI along with an IPv6
> .    Next Hop.
> .
> .    The MP_REACH_NLRI is encoded with:
> .
> .    o  AFI = 1
> .
> .    o  SAFI = 128
> .
> .    o  Length of Next Hop Network Address = 16 (or 32)
> .
> .    o  Network Address of Next Hop = IPv6 address of Next Hop
> .
> .    o  NLRI = IPv4-VPN routes
>
>
> Regarding IPv4-VPN routes, RFC4634 Section 4.3.2 says:
>
>
> . 4.3.2.  Route Distribution Among PEs by BGP
> [snip]
> .    When a PE router distributes a VPN-IPv4 route via BGP, it uses its
> .    own address as the "BGP next hop".  This address is encoded as a
> .    VPN-IPv4 address with an RD of 0.  ([BGP-MP] requires that the next
> .    hop address be in the same address family as the Network Layer
> .    Reachability Information (NLRI).)  It also assigns and distributes an
> .    MPLS label.  (Essentially, PE routers distribute not VPN-IPv4 routes,
> .    but Labeled VPN-IPv4 routes.  Cf. [MPLS-BGP].)  When the PE processes
> .    a received packet that has this label at the top of the stack, the PE
> .    will pop the stack, and process the packet appropriately.
> [snip]
>
>
> Question:
> RFC5549 defines "IPv4 VPN over IPv6 Core", When a PE router distributes a
> VPN-IPv4 route with an IPv6 Next-Hop via BGP, should the IPv6 Next-Hop be
> encoded as an VPN-IPv6 address with an RD of 0 ?
>
>
> Thanks,
> Shunwan
> _______________________________________________
> Softwires mailing list
> Softwires@ietf.org
> https://www.ietf.org/mailman/listinfo/softwires
> <https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_softwires&d=DwMFaQ&c=LFYZ-o9_HUMeMTSQicvjIg&r=s7ZzB4JbPv3nYuoSx5Gy8Q&m=UIVZS5gA4_SHRLCgtb5AnrGyg_Rit-E-t_ZsSB8Z5hQ&s=-VhqM-U7CXqqrJK30vJoT0RsvjQI4Kbnek9L-JvjNs8&e=>
>
>
> _______________________________________________
> BESS mailing list
> BESS@ietf.org
> https://www.ietf.org/mailman/listinfo/bess
> <https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_bess&d=DwMFaQ&c=LFYZ-o9_HUMeMTSQicvjIg&r=s7ZzB4JbPv3nYuoSx5Gy8Q&m=UIVZS5gA4_SHRLCgtb5AnrGyg_Rit-E-t_ZsSB8Z5hQ&s=JKi7zUQKOeE3U_Ii2m4n4NQcorfG6hvi8c7XZ1qywEs&e=>
>
> _______________________________________________
> Idr mailing list
> Idr@ietf.org
> https://www.ietf.org/mailman/listinfo/idr
>
>
>