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

Robert Raszuk <robert@raszuk.net> Thu, 27 June 2019 10:49 UTC

Return-Path: <robert@raszuk.net>
X-Original-To: softwires@ietfa.amsl.com
Delivered-To: softwires@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3A5A6120240 for <softwires@ietfa.amsl.com>; Thu, 27 Jun 2019 03:49:52 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.998
X-Spam-Level:
X-Spam-Status: No, score=-1.998 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, 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 CzCfYa5u5FzC for <softwires@ietfa.amsl.com>; Thu, 27 Jun 2019 03:49:50 -0700 (PDT)
Received: from mail-qt1-x82e.google.com (mail-qt1-x82e.google.com [IPv6:2607:f8b0:4864:20::82e]) (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 9B0C712007C for <softwires@ietf.org>; Thu, 27 Jun 2019 03:49:48 -0700 (PDT)
Received: by mail-qt1-x82e.google.com with SMTP id j19so1845669qtr.12 for <softwires@ietf.org>; Thu, 27 Jun 2019 03:49:48 -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=yAwZgAcmiNy/Ev0AhK0GJN7pttbe9aQ1LKRqc4i1akU=; b=cGpozCUL2dAGLjG+ph/0Lr8EgGfJpYQoY5USPBBJlycQl4mpZj1GWQ9AqyDQdW4pVe LHOX15mCED3XH/NC63KChdrmKn++YdKdpv8bGiNNfYJp3mGtq9TJSJRxJcD6lgWOnoLc i1EVoeql5fDbeeUT++kNbIDakFdB05TxDvFE+cn+qqoXT0i2EIl/lCHBIwplHLL00Chv 7mfEqafLxdmoOfsrhpYXL+z0X1+MXKKq7Fb9KXkzbht2HWkcr+l3P4sFM2LOqebDR1m3 to7Y3I8vW4N35Jz1xZm0WxkN3uhF8K4vhd9IACj+tyTH787MjjguvltKIb+yyWikQGqW rDJQ==
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=yAwZgAcmiNy/Ev0AhK0GJN7pttbe9aQ1LKRqc4i1akU=; b=ZNy4AaVLEBgYXQ72KVN2v2zMxuU+plm1GZSMWJi1jGuATb5DI4KzYL6bKpIv6B4EYZ taGEP0LrqJshxDo4Vw05TS7rKxSWwFAnZEZNw4iEnzndeD46/fDznzXF6Sc7V71orEzi uXOk68QcxPg0lU6EwphyMsruoKu9uMj1q750DuDP+4xpFGphZBdvikRnKmomkL0AFwbB SLI3YOtH+Xmi3n8a8hziY85NSELf9FTRkzTxK3TG+5oJvghBgsLHoGLnWmzKyoXOj+kU UbvtglVTVrUAJCKFrXHX1RVMNLGn8RQX4G5Gn1oobvqMZ6E6X4kYWxctvktna4oo/qef RlPw==
X-Gm-Message-State: APjAAAWkMgi5AWzquHGuG3quOewLVxSEC0XZR+BDwBBU5OYU5ALuJPg4 KDJ8NhUWhJxyzs/HEMukBzlq80nZR655rVS1z/z/0g==
X-Google-Smtp-Source: APXvYqyHbBIYURigOhLoVPG5idU3E05iAvsqIhBWo4pHHb18ejnPSX1k2Vm3R6xD4VQKBqtSpc8bt/ki5EQCt6awGCE=
X-Received: by 2002:aed:228d:: with SMTP id p13mr2443330qtc.208.1561632587497; Thu, 27 Jun 2019 03:49:47 -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> <CAOj+MMGKN9drVzJgrE6WVkF6k43Vqe6TNwK9VpHpFbJTafKUdA@mail.gmail.com> <880939EA-32A0-4869-A272-0E7416DED534@gmail.com> <16253F7987E4F346823E305D08F9115AAB8D7E66@nkgeml514-mbx.china.huawei.com>
In-Reply-To: <16253F7987E4F346823E305D08F9115AAB8D7E66@nkgeml514-mbx.china.huawei.com>
From: Robert Raszuk <robert@raszuk.net>
Date: Thu, 27 Jun 2019 12:49:36 +0200
Message-ID: <CAOj+MMGQ36AUbk45L6=N-ATwc+sXfyb3a7esu8-NxZgrj7y0GA@mail.gmail.com>
To: Xiejingrong <xiejingrong@huawei.com>
Cc: Alexander Okonnikov <alexander.okonnikov@gmail.com>, "softwires@ietf.org" <softwires@ietf.org>, "idr@ietf.org" <idr@ietf.org>, "bess@ietf.org" <bess@ietf.org>, "draft-dawra-bess-srv6-services@ietf.org" <draft-dawra-bess-srv6-services@ietf.org>
Content-Type: multipart/alternative; boundary="000000000000a5d6d2058c4beb37"
Archived-At: <https://mailarchive.ietf.org/arch/msg/softwires/BXuVRNLIOocz3f0nw0kbI4CWfjo>
Subject: Re: [Softwires] [Idr] [bess] Regarding the Next Hop Network Address coding for IPv4 VPN over IPv6 Core in RFC5549
X-BeenThere: softwires@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: softwires wg discussion list <softwires.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/softwires>, <mailto:softwires-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/softwires/>
List-Post: <mailto:softwires@ietf.org>
List-Help: <mailto:softwires-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/softwires>, <mailto:softwires-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 27 Jun 2019 10:49:52 -0000

> Back to my suggestion: implementation should interpret nexthop RD+IPv4
and nexthop IPv4 the same, and interpret nexthop RD+IPv6 and nexthop IPv6
the same.

When elements of BGP UPDATE message are being parsed code must know what to
expect. Note that we are dealing here with deployed SAFI 128 for nearly 20
years.

So today there are two ways to know what format of next hop is in MP_REACH:

a) Inferring it from AFI/SAFI per section 3 of RFC4760

or (in addition to the above coarse assumption)

b) Inferring it from the discrete value of next hop length field as defined
in section 3 of RFC5549

Note that if we would be defining new SAFI we can write anything we like to
the rules of constructing the update message. But here again we are dealing
with something which is deployed so sort of operating on the plane in
flight.

If implementation can infer next hop type from length we are safe to define
all sections to have next hop length = 16 octets and be done. But if there
are some implementations which would only take AFI/SAFI to check if the
next hop is correct or even further to check if the next hop length is
correct then we have a problem.

/* Btw this notion of next hop length = 32 is bizarre ! I have never seen
any BGP implementation sending two next hops (global IPv6 address followed
by link local IPv6 address) not I am able to find any docs describing how
any BGP stack would handle it. IMHO we should move this 32 next hop length
to historic asap. */

To the msg from Martin,

> maybe the WG would like to reach a conclusion on how to treat that
erratum:
> http://www.rfc-editor.org/errata/eid5738

I would vote to reject the errata. There is no value of stuffing 8 octet of
zeros in the next hop field. If the RFC got defined in 2012 that really
means that most implementations are capable of inferring next hop format
from the length field - which is very good. Accepting the errata would be a
step backwords.

Thx,
R.

On Thu, Jun 27, 2019 at 11:15 AM Xiejingrong <xiejingrong@huawei.com> wrote:

> Thanks for the RFC historical lessons.
>
> --there was historically some assumption that next hop must be of the same
> AF as prefix.
>
> --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.
>
> --authors of RFC 4364 were trying to make it consistent with 4760.
>
> --Also, drafts of RFC 4364 and RFC 4760 were being developed practically
> at the same time period.
>
>
>
> The problem is clear, the nexthop field has been inconsistent between
> different L3VPN/MVPN scenarios and different implementations in the long
> history.
>
>
>
> <draft-dawra-bess-srv6-services-00> is the latest draft, but it has
> different nexthop in section 3.1 to 3.4, in the year 2019.
>
>
>
> Back to my suggestion: implementation should interpret nexthop RD+IPv4 and
> nexthop IPv4 the same, and interpret nexthop RD+IPv6 and nexthop IPv6 the
> same.
>
>
>
> I think it may be helpful for <draft-dawra-bess-srv6-services-00> to add
> the above text, and update RFC4364/4659/4760/5549, to eliminate the worries
> about interoperation. ----is there any worries about interoperation ?
>
>
>
> Thanks
>
> Jingrong
>
>
>
>
>
> *From:* Alexander Okonnikov [mailto:alexander.okonnikov@gmail.com]
> *Sent:* Wednesday, June 26, 2019 9:38 PM
> *To:* Robert Raszuk <robert@raszuk.net>
> *Cc:* UTTARO, JAMES <ju1738@att.com>om>; Xiejingrong <xiejingrong@huawei.com>om>;
> softwires@ietf.org; idr@ietf.org; ian.farrer@telekom.de; bess@ietf.org;
> ianfarrer@gmx.com
> *Subject:* Re: [Idr] [bess] [Softwires] Regarding the Next Hop Network
> Address coding for IPv4 VPN over IPv6 Core in RFC5549
>
>
>
> Hi Robert,
>
>
>
> Sorry, I was not so precise :-) Of course, RD part in Next Hop is not
> copied from RD of NLRI, but zeroed. I was trying to explain why Next Hop
> field in RFC 4364 and RFC 4659 has format RD:IP (VPNvX address) rather than
> just IP.
>
>
>
> Thank you!
>
>
>
>
>