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

Robert Raszuk <robert@raszuk.net> Fri, 28 June 2019 09:11 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 94CF112026E for <softwires@ietfa.amsl.com>; Fri, 28 Jun 2019 02:11:35 -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 w4QRNaNrD0yQ for <softwires@ietfa.amsl.com>; Fri, 28 Jun 2019 02:11:32 -0700 (PDT)
Received: from mail-qt1-x832.google.com (mail-qt1-x832.google.com [IPv6:2607:f8b0:4864:20::832]) (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 D88AF120169 for <softwires@ietf.org>; Fri, 28 Jun 2019 02:11:29 -0700 (PDT)
Received: by mail-qt1-x832.google.com with SMTP id a15so5481190qtn.7 for <softwires@ietf.org>; Fri, 28 Jun 2019 02:11:29 -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=2bvLSzvaNjelt/ttGAZEOFXfT5WWyLHvy5mcrqogHgk=; b=X9jE4+ynKKi6E7QPgu75S+eqky+lKbYENQag66w48ypP5bUn1OPH3nTu4pOuMCcoFS Lhs3buJdvIBpcga6BHfSXVgSMdtLN9cpaDGG9NVLnKyn7ojKo0iUyFHli77YUiW9iZVS 8CAEAKRFsEavTp6DHVNEDkWgg8U2z3vcd7YCqBoAMcOPUIQeLytXpucXY9fh74RYGhU4 U5w4/ipXddQ1CFg6im+r1j4uoSUW24S5w27oGu75MV/2NzsDsASjQX1xhdGCfwGXiclu pcGUM1tumviJ3rgPoqBW97VbM8g42xqMDwPUqiGduY7cWuxKWVIE8fRRk7PqB2+bJxQD EApA==
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=2bvLSzvaNjelt/ttGAZEOFXfT5WWyLHvy5mcrqogHgk=; b=Zhkn2oj020mX5Z/rj2AieqbM9VNB1P6BdxX6PIQb6NiukvziA9lP2IJWpa52EGZCSU San6jctNpZG8GMaEh0TjaBKVtI8E+tg1TnSLZkIvNAclJOQWObTbUJx9edIQIpmwSwjG iBPWH2QXVwIClYIfkWqlrVJCvIq4qE7Zd6bqa9Ry/s42R6PZb9VYAjgzmuognmsnrafo cAWXlxknqfhuNvTHH0vCSF4WPk7f7pylOc5k21PhgniuGFzPsXzqckM1fT4WREGe+Akt ToUsV4EiZyJIU/NdK1u8YNM94vySiy8uQAQSKJZRJ2OPq2zNm9HulY/i+RkbQ2aKA3OA IVPQ==
X-Gm-Message-State: APjAAAVQwERhAKmDbXtQkFmwoqM7Fk4EU0kpa+St93x3QufRlaboVdHs UylvTP0Yq1XwMIthi8IUNY1k29l2fULd679ilOXlFkyU
X-Google-Smtp-Source: APXvYqxdwGE3Mafm/jgzlDr/+VuEc5hUTMbB3zcco4cjed/MQhw8rQ1xM52wjjIgdj/kiCQO33U3+PacVtMi4/jxG1k=
X-Received: by 2002:ac8:224d:: with SMTP id p13mr7076566qtp.154.1561713088894; Fri, 28 Jun 2019 02:11:28 -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> <CAOj+MMGQ36AUbk45L6=N-ATwc+sXfyb3a7esu8-NxZgrj7y0GA@mail.gmail.com> <29017_1561708101_5D15C645_29017_93_1_9E32478DFA9976438E7A22F69B08FF924C25B910@OPEXCAUBMA3.corporate.adroot.infra.ftgroup>
In-Reply-To: <29017_1561708101_5D15C645_29017_93_1_9E32478DFA9976438E7A22F69B08FF924C25B910@OPEXCAUBMA3.corporate.adroot.infra.ftgroup>
From: Robert Raszuk <robert@raszuk.net>
Date: Fri, 28 Jun 2019 11:11:18 +0200
Message-ID: <CAOj+MMEwrzgYw74sQJ8gqC5Utc+0uu5Rir7U5SmR5cgw5mNb_Q@mail.gmail.com>
To: stephane.litkowski@orange.com
Cc: Xiejingrong <xiejingrong@huawei.com>, "softwires@ietf.org" <softwires@ietf.org>, "draft-dawra-bess-srv6-services@ietf.org" <draft-dawra-bess-srv6-services@ietf.org>, "bess@ietf.org" <bess@ietf.org>, "idr@ietf.org" <idr@ietf.org>
Content-Type: multipart/alternative; boundary="000000000000e7add6058c5ea944"
Archived-At: <https://mailarchive.ietf.org/arch/msg/softwires/gvUsNML_mvIFHPyZCJ3bBTqNpNw>
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: Fri, 28 Jun 2019 09:11:41 -0000

Stephane,

Sure you can send two NHs next to each other. But my main question is what
should the receiver of such "thing" do ? Which next hop is more important
to be actually used in forwarding ? Based on what elements such decision is
made ...

If you know some history and can share it here iI think it may be useful
for others.

Btw which implementation sends two :) ? Should not be a big secret I
suppose.

Thx,
R.

On Fri, Jun 28, 2019 at 9:48 AM <stephane.litkowski@orange.com> wrote:

> Hi Robert,
>
>
>
> There are implementations which set two NHs, here is a capture:
>
>
>
> Update Message (2), length: 150
>
>           Multi-Protocol Reach NLRI (14), length: 100, Flags [O]:
>
>             AFI: IPv6 (2), SAFI: labeled VPN Unicast (128)
>
>             nexthop: RD: 0:0 (= 0.0.0.0), 2000::162RD: 0:0 (= 0.0.0.0),
> fe80::2a94:fff:fefa:3cc0, nh-length: 48, no SNPA
>
>               RD: 10283:803700200 (= 47.231.125.232), 2000:bebe:37::/56,
> label:1313 (bottom)
>
>               RD: 10283:803700200 (= 47.231.125.232), 2000:bebe:37::1/128,
> label:1314 (bottom)
>
>           Origin (1), length: 1, Flags [T]: IGP
>
>           AS Path (2), length: 6, Flags [T]: 11111
>
>           Extended Community (16), length: 8, Flags [OT]:
>
>             target (0x0002), Flags [none]: 11111:999900200 (= 59.153.68.40)
>
>
>
> Note that this behavior caused some interop issues with another vendor who
> partially supported RFC4659.
>
>
>
> Brgds,
>
>
>
>
>
>
>
> *From:* Idr [mailto:idr-bounces@ietf.org] *On Behalf Of *Robert Raszuk
> *Sent:* Thursday, June 27, 2019 12:50
> *To:* Xiejingrong
> *Cc:* softwires@ietf.org; draft-dawra-bess-srv6-services@ietf.org;
> bess@ietf.org; idr@ietf.org
> *Subject:* Re: [Idr] [bess] [Softwires] Regarding the Next Hop Network
> Address coding for IPv4 VPN over IPv6 Core in RFC5549
>
>
>
> > 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
> <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!
>
>
>
>
>
> _________________________________________________________________________________________________________________________
>
> Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc
> pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler
> a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,
> Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.
>
> This message and its attachments may contain confidential or privileged information that may be protected by law;
> they should not be distributed, used or copied without authorisation.
> If you have received this email in error, please notify the sender and delete this message and its attachments.
> As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.
> Thank you.
>
>