Re: [Idr] AD Review of draft-ietf-idr-tunnel-encaps-15

Gyan Mishra <hayabusagsm@gmail.com> Fri, 08 May 2020 14:20 UTC

Return-Path: <hayabusagsm@gmail.com>
X-Original-To: idr@ietfa.amsl.com
Delivered-To: idr@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DA77F3A0B0E; Fri, 8 May 2020 07:20:26 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.096
X-Spam-Level:
X-Spam-Status: No, score=-2.096 tagged_above=-999 required=5 tests=[AC_DIV_BONANZA=0.001, BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, 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=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 QPmGR05DjQe8; Fri, 8 May 2020 07:20:24 -0700 (PDT)
Received: from mail-il1-x131.google.com (mail-il1-x131.google.com [IPv6:2607:f8b0:4864:20::131]) (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 ED2503A0B04; Fri, 8 May 2020 07:20:23 -0700 (PDT)
Received: by mail-il1-x131.google.com with SMTP id w6so1559991ilg.1; Fri, 08 May 2020 07:20:23 -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=7/AC+26twMr/zJuq2rDTXbLv2JueNJsYoQTddxqZLDs=; b=KiEzK/cm/1V9l1VIOQTAoz+rtJH3N59f1mKNveNV2+ltFNhkxfSdA2mN5XZrqEAA85 nsxs9iHSHttnFP6fDuWPu337/oteIPtFAoMzYyB5WA3HyBe5GrD8ro+edBilg5ds+Xif GlADsTP2N60BAJPoH6z+AoFFkS84xitXt+3qMN0dMZRPl/S4cSL0F5kccdKuPiMvaGkC j4L4NM2kPdtotBX5Mh8EqWyF2QTC+uhp0/E7zE9Z5tzp2RV7z2KpzXddUR5ab8u2mkyr qfijZdGqi10PUJskC/TjctKJGRkyKRUqjRTQjaXV971O6nx3gNwOwvo1LSNzSBuvU/L0 XsNA==
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=7/AC+26twMr/zJuq2rDTXbLv2JueNJsYoQTddxqZLDs=; b=FaONP1vhFpwxgiyCVpc6NAMtXT9NpS4zSngxqfgFnZLZbzes7gCFE3YqHhHfNuVX0z mVQI9a248AIMhCDqG5dmFOO/SV1Xx6/F7rctYWfyKhCYZPmuHjb/5zF38nLTB4oKXtuG eSHML+40fC6nGNkTp0ViXhvCWvQhOKuK4vxiX+gSkjgQoLdq6pQflaXXL9zP7T7Ny5Wb XAOzjlAg2B1gkwt6d+9XqIsDAxKP5Xtf7+HmcaUwQ2yW0NJygLeu1YBfiI+6pAgo5qH7 CaIsFr6YzdF5ZaK4rlewahGfiJ6O9uBJBHCKZ1XfegHEFrtZRvG1SYftFA7UI+JMJnFa sQNg==
X-Gm-Message-State: AGi0PuZREW7PLu9wfC1v4hEkimcbuDUd0RoxC0JgRelS54arvOqoQsLi Ry4hivh5Cga3sDipGIM9fRFZrWEeN3w5bv4fGKE=
X-Google-Smtp-Source: APiQypLa8w+As6X9lznEx5HVyb7QlXW+07705YpHkD+cRlsS/wC+3z1nM5ukpkQ0RiIYwesZ4V2jEqswSCrkn9kh5F8=
X-Received: by 2002:a92:3c55:: with SMTP id j82mr3162224ila.258.1588947623090; Fri, 08 May 2020 07:20:23 -0700 (PDT)
MIME-Version: 1.0
References: <CAMMESsw09LGWWhqyJ_0=jRimUN+_UuCjaXHCdqF9zkpaxSQgVQ@mail.gmail.com> <D6F74C0F-3332-491B-B730-05613356B1BA@juniper.net> <CABNhwV3cO3T41=u9UGzvEMfL-GmX0VF8ZK2GDEp5muad1G4ZSg@mail.gmail.com> <79BDFAF7-1CBF-4BAE-A880-DE1608DE683D@nokia.com>
In-Reply-To: <79BDFAF7-1CBF-4BAE-A880-DE1608DE683D@nokia.com>
From: Gyan Mishra <hayabusagsm@gmail.com>
Date: Fri, 8 May 2020 10:20:12 -0400
Message-ID: <CABNhwV3L8rYkgJT7+sJf71Yo0qniQfuC2yjOiJuXkuKuuDtGkg@mail.gmail.com>
To: "Rabadan, Jorge (Nokia - US/Mountain View)" <jorge.rabadan@nokia.com>
Cc: John Scudder <jgs=40juniper.net@dmarc.ietf.org>, Keyur Patel <keyur@arrcus.com>, "draft-ietf-idr-tunnel-encaps@ietf.org" <draft-ietf-idr-tunnel-encaps@ietf.org>, "idr-chairs@ietf.org" <idr-chairs@ietf.org>, "idr@ietf. org" <idr@ietf.org>
Content-Type: multipart/alternative; boundary="000000000000a41dc505a523b2d7"
Archived-At: <https://mailarchive.ietf.org/arch/msg/idr/b7tcQridDnqe4mo4QHFDvbN7YmU>
Subject: Re: [Idr] AD Review of draft-ietf-idr-tunnel-encaps-15
X-BeenThere: idr@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Inter-Domain Routing <idr.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/idr>, <mailto:idr-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/idr/>
List-Post: <mailto:idr@ietf.org>
List-Help: <mailto:idr-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/idr>, <mailto:idr-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 08 May 2020 14:20:27 -0000

Thanks Jorge.  John confirmed that it does not update RFC 8365 or any of
the other encapsulation RFCs.

Thanks

Gyan

On Fri, May 8, 2020 at 4:14 AM Rabadan, Jorge (Nokia - US/Mountain View) <
jorge.rabadan@nokia.com> wrote:

> Gyan,
>
>
>
> The authors can confirm, but my reading of draft-ietf-idr-tunnel-encaps is
> that it is perfectly backwards compatible with the encapsulation extended
> community used in RFC8365.
>
> So RFC8365 implementations don’t need to change at all. That’s my reading
> of the encapsulation extended community section.
>
>
>
> Only in case of requiring the tunnel encapsulation attribute for any other
> reason, then an implementor should look at the rules included in this draft.
>
>
>
> My two cents.
>
>
>
> Thanks.
>
> Jorge
>
>
>
> *From: *Idr <idr-bounces@ietf.org> on behalf of Gyan Mishra <
> hayabusagsm@gmail.com>
> *Date: *Friday, May 8, 2020 at 9:48 AM
> *To: *John Scudder <jgs=40juniper.net@dmarc.ietf.org>rg>, Keyur Patel <
> keyur@arrcus.com>
> *Cc: *"idr-chairs@ietf.org" <idr-chairs@ietf.org>rg>, "idr@ietf. org" <
> idr@ietf.org>gt;, "draft-ietf-idr-tunnel-encaps@ietf.org" <
> draft-ietf-idr-tunnel-encaps@ietf.org>
> *Subject: *Re: [Idr] AD Review of draft-ietf-idr-tunnel-encaps-15
>
>
>
>
>
> Hi Keyur and other others of this draft.
>
>
>
> For vxlan evpn NVO3 RFC 8365 describes the vxlan BGP EVPN overlay
> architecture and the various encapsulation types below that exist today and
> have been implemented now by most vendors.
>
>
>
> https://tools.ietf.org/html/rfc8365
>
>
>
> Value    Name
>
>    -----    ------------------------
>
>    8        VXLAN Encapsulation
>
>    9        NVGRE Encapsulation
>
>    10       MPLS Encapsulation
>
>    11       MPLS in GRE Encapsulation
>
>    12       VXLAN GPE Encapsulation
>
>
>
> So RFC 8365  has been implemented and it works without this drafts tunnel
> encapsulation attribute new SAFI defined.
>
>
>
> So would this draft once it gets WG adoption update RFC 8365 and any other
> encapsulation types that work today without this encapsulation attribute.
> Would that require vendor to update their code to now support this SAFI.
>
>
>
> Since RFC 8365 NVO3 vxlan evpn works well today without this tunnel
> attributes, please specify what is gained by having vendors update their
> code to support this new tunnel attribute.
>
>
>
> Please help shed some light on this topic.
>
>
>
> Kind regards
>
>
>
> Gyan
>
> Verizon
>
>
>
> On Thu, May 7, 2020 at 2:51 PM John Scudder <jgs=
> 40juniper.net@dmarc.ietf.org> wrote:
>
> Hi Alvaro,
>
>
>
> On Feb 21, 2020, at 7:47 AM, Alvaro Retana <aretana.ietf@gmail.com> wrote:
>
>
>
> [minor] "topmost" and "bottommost" are not mentioned in rfc3032.
> Please be consistent with the terminology.  It is ok to introduce new
> terminology, if needed, but please explain that as well.
>
>
>
> RFC 3032 is careful in defining what “top” and “bottom” mean for labels of
> course. Don’t you think the meanings of “topmost” and “bottommost” are
> obvious in that context?
>
>
>
> —John
>
> _______________________________________________
> Idr mailing list
> Idr@ietf.org
> https://www.ietf.org/mailman/listinfo/idr
>
> --
>
> Gyan  Mishra
>
> Network Engineering & Technology
>
> Verizon
>
> Silver Spring, MD 20904
>
> Phone: 301 502-1347
>
> Email: gyan.s.mishra@verizon.com
>
>
>
>
>
-- 

Gyan  Mishra

Network Engineering & Technology

Verizon

Silver Spring, MD 20904

Phone: 301 502-1347

Email: gyan.s.mishra@verizon.com