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

Robert Raszuk <rraszuk@gmail.com> Thu, 27 June 2019 11:52 UTC

Return-Path: <rraszuk@gmail.com>
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 901281201CF; Thu, 27 Jun 2019 04:52:33 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.997
X-Spam-Level:
X-Spam-Status: No, score=-1.997 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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=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 ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HcK0u2U0DtAU; Thu, 27 Jun 2019 04:52:30 -0700 (PDT)
Received: from mail-pl1-x630.google.com (mail-pl1-x630.google.com [IPv6:2607:f8b0:4864:20::630]) (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 57EC6120170; Thu, 27 Jun 2019 04:52:30 -0700 (PDT)
Received: by mail-pl1-x630.google.com with SMTP id a93so1179393pla.7; Thu, 27 Jun 2019 04:52:30 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=Mn3IxVBT2wEtmR0ubydFwtyOjY8pVmcFhy64Zbha5XE=; b=imSe1RiO3pOMKfMamhp1ximW/M0yGZfFxLGabt+nUvG05bUtt1xaWqYij/zOol6oDb QR//WntdRe7jGLi4HZ795dJQr3lxPTvmmpjQkz/rVoZDDyQhbK1ukGslSIwGpAPzBBCc v3YdkOE3D9y9wxGpHx07eQS5QKqK/HZd2BGi7/uqn5zw9AVB9FcxdghP6CRI7yFoDnV0 sDimFiOqa4+ON/+G01q6q9ksh4y+NDuaQ2JO9HOod7WL/xRe3PyUYFl9Mjj7N+VqeZ1z m4LECAl5+0QlUN3bsWfP/4CdZY4HguOa84maTAPYB5tGGIexsYJyRpfOH9J0QiEiq5t3 40eQ==
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=Mn3IxVBT2wEtmR0ubydFwtyOjY8pVmcFhy64Zbha5XE=; b=jWrNuPy4mI9QmqW734WrcNKz/YXDqkiiez5P97S3DkX0xfAG62epPHGxT4boQbGhM6 mJ3AozAsy5BtEbrmfP95G4CkHTWuiffHEnoL8MBDAN+dUYYJKntlUq+208pXEfG9sP8I NEJXqabFdhMgZV32YyOQIdUBnuoARrG+26SrfYObr/lUwLWnDq65dwt6Mhr/Qlu3C/j3 91JtZYxDaBsdLMJFT4+ER4SxedNg+s22c1skUVCWUv16iF0eDyq2Wzg6OMY9DMgr7ttl 1zjCEloIe0CF/GVs0NNrdQaT+wUxdc0lvU14GP1MFI5TExeb2qb0SjBZR5uPEuXgpZU3 Bulw==
X-Gm-Message-State: APjAAAU1zb6MWhcn7RJ0KNk/CVBS0Re5QF0pFhdzVmri6kIH7xI4AWFz Puzbq+BRUbLlKN9/KRaagtY9Bp0o2JmPSq7Tp38=
X-Google-Smtp-Source: APXvYqwT7jRmedkqTI0MnkxRhmL+Zw+UZrIHEuxqJNIm1eJyPguxPG4VEPi2ENtpEt4ub6dlKIryYlQBBE2Du9vuNyA=
X-Received: by 2002:a17:902:61:: with SMTP id 88mr4065756pla.50.1561636349346; Thu, 27 Jun 2019 04:52:29 -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> <9670cbbf-9b35-7ac4-b809-529ab59f18a9@nokia.com> <19AB2A007F56DB4E8257F949A2FB9858E5BE4DA2@NKGEML515-MBS.china.huawei.com>
In-Reply-To: <19AB2A007F56DB4E8257F949A2FB9858E5BE4DA2@NKGEML515-MBS.china.huawei.com>
From: Robert Raszuk <rraszuk@gmail.com>
Date: Thu, 27 Jun 2019 13:52:18 +0200
Message-ID: <CA+b+ER=5oZy7TsY+UNp7x+obCu4P+XCrnpgCLXh=Cn9Pr_uW0g@mail.gmail.com>
To: Zhuangshunwan <zhuangshunwan@huawei.com>
Cc: "Vigoureux, Martin (Nokia - FR/Paris-Saclay)" <martin.vigoureux@nokia.com>, Xiejingrong <xiejingrong@huawei.com>, Alexander Okonnikov <alexander.okonnikov@gmail.com>, "bess@ietf.org" <bess@ietf.org>, "softwires@ietf.org" <softwires@ietf.org>, "idr@ietf.org" <idr@ietf.org>
Content-Type: multipart/alternative; boundary="000000000000df0928058c4ccb94"
Archived-At: <https://mailarchive.ietf.org/arch/msg/softwires/ovk4_mlbZ01jbgRu3iY1nbDN1EA>
Subject: Re: [Softwires] [bess] [Idr] 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 11:52:34 -0000

My vote - Reject.

Justification:

Irrespective if we would reject or accept the erratum implementations must
be able to handle 10 years old RFC so must be able to properly recognize
the next hop to be either of length 16 or 24. (I am putting aside the 32/48
invention).

So that means that next hop length should be used to recognize format of
the next hop. That with the fact that stuffing next hop address with
useless 64 zeros in the front leads me to believe that if we are to produce
any erratums it should be the other way around ... we should replace all
documents which call for having next hops full of zeros in the front to
normalize it to consist of just real IPv4 or IPv6 single address.

Thx,
R.

On Thu, Jun 27, 2019 at 1:39 PM Zhuangshunwan <zhuangshunwan@huawei.com>
wrote:

> Hi all,
>
> Can the WG reach a conclusion on how to treat that erratum related to
> RFC5549:
>
> https://www.rfc-editor.org/errata/eid5253
>
> Thanks,
> Shunwan
>
> -----Original Message-----
> From: Softwires [mailto:softwires-bounces@ietf.org] On Behalf Of
> Vigoureux, Martin (Nokia - FR/Paris-Saclay)
> Sent: Thursday, June 27, 2019 6:37 PM
> To: Xiejingrong <xiejingrong@huawei.com>om>; Alexander Okonnikov <
> alexander.okonnikov@gmail.com>gt;; Robert Raszuk <robert@raszuk.net>et>;
> bess@ietf.org
> Cc: softwires@ietf.org; idr@ietf.org
> Subject: Re: [Softwires] [Idr] [bess] Regarding the Next Hop Network
> Address coding for IPv4 VPN over IPv6 Core in RFC5549
>
> since we are discussing that topic,
>
> maybe the WG would like to reach a conclusion on how to treat that erratum:
> http://www.rfc-editor.org/errata/eid5738
>
> Thanks
> -m
>
> Le 2019-06-27 à 11:15, Xiejingrong a écrit :
> > 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!
> >
> >
> >
> >
> >
> > _______________________________________________
> > Idr mailing list
> > Idr@ietf.org
> > https://www.ietf.org/mailman/listinfo/idr
> >
> _______________________________________________
> Softwires mailing list
> Softwires@ietf.org
> https://www.ietf.org/mailman/listinfo/softwires
> _______________________________________________
> BESS mailing list
> BESS@ietf.org
> https://www.ietf.org/mailman/listinfo/bess
>