Re: [bess] [Idr] draft-ietf-bess-evpn-overlay vs. draft-ietf-idr-tunnel-encaps

<thomas.morin@orange.com> Thu, 05 May 2016 12:32 UTC

Return-Path: <thomas.morin@orange.com>
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 67F5512D51C; Thu, 5 May 2016 05:32:00 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.618
X-Spam-Level:
X-Spam-Status: No, score=-2.618 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=ham autolearn_force=no
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 p7tjUAjiZss5; Thu, 5 May 2016 05:31:57 -0700 (PDT)
Received: from relais-inet.francetelecom.com (relais-ias92.francetelecom.com [193.251.215.92]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 375C912D51F; Thu, 5 May 2016 05:31:56 -0700 (PDT)
Received: from omfedm08.si.francetelecom.fr (unknown [xx.xx.xx.4]) by omfedm14.si.francetelecom.fr (ESMTP service) with ESMTP id 753AC22C884; Thu, 5 May 2016 14:31:54 +0200 (CEST)
Received: from Exchangemail-eme2.itn.ftgroup (unknown [10.114.31.31]) by omfedm08.si.francetelecom.fr (ESMTP service) with ESMTP id 473FD238056; Thu, 5 May 2016 14:31:54 +0200 (CEST)
Received: from OPEXCLILM43.corporate.adroot.infra.ftgroup ([fe80::ec23:902:c31f:731c]) by OPEXCLILM22.corporate.adroot.infra.ftgroup ([fe80::8c90:f4e9:be28:2a1%19]) with mapi id 14.03.0294.000; Thu, 5 May 2016 14:31:53 +0200
From: thomas.morin@orange.com
To: EXT John E Drake <jdrake@juniper.net>, IDR <idr@ietf.org>, BESS <bess@ietf.org>, "draft-ietf-bess-evpn-overlay@tools.ietf.org" <draft-ietf-bess-evpn-overlay@tools.ietf.org>, "Ali Sajassi (sajassi)" <sajassi@cisco.com>, "Rabadan, Jorge (Nokia - US)" <jorge.rabadan@nokia.com>, "draft-ietf-idr-tunnel-encap@tools.ietf.org" <draft-ietf-idr-tunnel-encap@tools.ietf.org>
Thread-Topic: [Idr] draft-ietf-bess-evpn-overlay vs. draft-ietf-idr-tunnel-encaps
Thread-Index: AdGmBJMUJMtmxTFkSDagWg0yGwJv3wAA4tKAAAWwlwAAAPoxgAACvdiAAAOPgQAAADvBgAAjSzCP
Date: Thu, 05 May 2016 12:31:53 +0000
Message-ID: <1881_1462451514_572B3D3A_1881_7198_1_0vn90oitr7e881gh2sn8qm5f.1462451509961@email.android.com>
References: <5729F1C3.1030605@orange.com> <5729F7C5.6040604@orange.com> <52D35106-ED5E-4C95-9131-6EA4527370D5@alcatel-lucent.com> <BY2PR0501MB1702CD2423A817F3725CB5DFC77B0@BY2PR0501MB1702.namprd05.prod.outlook.com> <012C176C-A8D6-45AA-BA69-616C0ED7E41E@alcatel-lucent.com>, <SN1PR0501MB1709E1AF8C398791421E2123C77B0@SN1PR0501MB1709.namprd05.prod.outlook.com>, <420BA2D8D80A6727.2B2C290F-2299-40BB-B53B-CC36D2B5D826@mail.outlook.com>
In-Reply-To: <420BA2D8D80A6727.2B2C290F-2299-40BB-B53B-CC36D2B5D826@mail.outlook.com>
Accept-Language: fr-FR, en-US
Content-Language: fr-FR
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
Content-Type: multipart/alternative; boundary="_000_0vn90oitr7e881gh2sn8qm5f1462451509961emailandroidcom_"
MIME-Version: 1.0
X-PMX-Version: 6.2.1.2478543, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2016.5.5.111218
Archived-At: <http://mailarchive.ietf.org/arch/msg/bess/IuC7YqDwS2frA-5GD5MIoyv8vYQ>
Subject: Re: [bess] [Idr] draft-ietf-bess-evpn-overlay vs. draft-ietf-idr-tunnel-encaps
X-BeenThere: bess@ietf.org
X-Mailman-Version: 2.1.17
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: Thu, 05 May 2016 12:32:00 -0000

Thanks for the clarification on the intent around draft-ietf-bess-evpn-overlay. Then indeed section 9 needs some tidying up.

The issue that I think remain is that it would be much cleaner to explain how to use PMSI with overlay encaps in a spec not specific to E-VPN and in a way more consistent to what is done for unicast.

It seems if course that draft-ietf-idr-tunnel-encap should be the place, but that document currently explicitly makes PMSIs out of scope.

Shouldn't this part of draft-ietf-idr-tunnel-encap be revisited ?

-Thomas


---- Rabadan, Jorge (Nokia - US) a écrit ----

Fully agree John. That's what I meant, sorry if I didn't make myself clear. Section 9 needs clean up, yes.

Thanks,
Jorge

_____________________________
From: EXT John E Drake <jdrake@juniper.net<mailto:jdrake@juniper.net>>
Sent: Wednesday, May 4, 2016 23:34
Subject: RE: [Idr] draft-ietf-bess-evpn-overlay vs. draft-ietf-idr-tunnel-encaps
To: IDR <idr@ietf.org<mailto:idr@ietf.org>>, Ali Sajassi (sajassi) <sajassi@cisco.com<mailto:sajassi@cisco.com>>, Rabadan, Jorge (Nokia - US) <jorge.rabadan@alcatel-lucent.com<mailto:jorge.rabadan@alcatel-lucent.com>>, BESS <bess@ietf.org<mailto:bess@ietf.org>>, <draft-ietf-bess-evpn-overlay@tools.ietf.org<mailto:draft-ietf-bess-evpn-overlay@tools.ietf.org>>, EXT - thomas.morin@orange.com<mailto:thomas.morin@orange.com> <thomas.morin@orange.com<mailto:thomas.morin@orange.com>>


Jorge,

We put the VNI value in the MPLS label field of the PMSI attribute for all service types, and we put a value in the Ethernet Tag field following the rules for each service type as described in 5.1.3 (https://tools.ietf.org/html/draft-ietf-bess-evpn-overlay-02#section-5.1.3).

You're right that we need to clean up section 9.

Yours Irrespectively,

John

> -----Original Message-----
> From: Rabadan, Jorge (Nokia - US) [mailto:jorge.rabadan@nokia.com]
> Sent: Wednesday, May 04, 2016 3:53 PM
> To: John E Drake; EXT - thomas.morin@orange.com<mailto:thomas.morin@orange.com>; BESS; IDR; draft-ietf-bess-evpn-
> overlay@tools.ietf.org<mailto:overlay@tools.ietf.org>; Ali Sajassi (sajassi)
> Subject: Re: [Idr] draft-ietf-bess-evpn-overlay vs. draft-ietf-idr-tunnel-encaps
>
> Hi John,
>
> About this:
>
> [JD] For the IMET route the MPLS label field is carried in the PMSI attribute. I think we need
> to ask everyone whether they used the Ethernet Tag or the PMSI attribute to carry the VNI
>
>
> In case it helps, I’ve seen a few implementations running and they all encode the VNI in the
> MPLS label field in the PTA. And a couple of them, encode the VNI in the ethernet-tag, in
> addition to the MPLS label in the PTA. In any case, I think section 9 contradicts section 5.1.3
> and should be clarified.
>
> "5.1.3 Constructing EVPN BGP Routes
> <snip>
> the MPLS label field in the MAC Advertisement, Ethernet AD per EVI, and **Inclusive
> Multicast Ethernet Tag** routes is used to carry the VNI or VSID."
>
> Thanks.
> Jorge
>
>
>
>
>
> On 5/4/16, 8:34 PM, "EXT John E Drake" <jdrake@juniper.net<mailto:jdrake@juniper.net>> wrote:
>
> >Thomas and Jorge,
> >
> >Snipped, comments inline.
> >
> >Yours Irrespectively,
> >
> >John
> >
> >> >
> >> >draft-ietf-bess-evpn-overlay (see section 9) relies on the BGP
> >> >Encapsulation extended to encode the tunnel encap to use for BUM
> >> >traffic, but contrary to other E-VPN routes, relies on the Ethernet
> >> >Tag field of the NLRI to encode the VNI/VSID.
> >>
> >> [JORGE] This is certainly a leftover from an old version where the
> >> VNI/VSID was encoded in the ethernet tag for all the routes. The VNI
> >> should be encoded in the Label field in all the routes. This has to be corrected.
> >>
> >> In fact, section 5.1.3 says:
> >>
> >> 5.1.3 Constructing EVPN BGP Routes
> >>
> >> <snip>
> >>
> >> Accordingly, and
> >> specifically to support the option of locally assigned VNIs, the MPLS
> >> label field in the MAC Advertisement, Ethernet AD per EVI, and
> >> Inclusive Multicast Ethernet Tag routes is used to carry the VNI or
> >> VSID. For the balance of this memo, the MPLS label field will be
> >> referred to as the VNI/VSID field. The VNI/VSID field is used for
> >> both local and global VNIs/VSIDs, and for either case the entire 24-
> >> bit field is used to encode the VNI/VSID value.
> >>
> >> <snip>
> >
> >
> >[JD] For the IMET route the MPLS label field is carried in the PMSI attribute. I think we
> need to ask everyone whether they
> >used the Ethernet Tag or the PMSI attribute to carry the VNI
> >
> >
> >> >>
> >> >> There are minor things that could be improved in
> >> >> draft-ietf-bess-evpn-overlay wrt. consistency with
> >> >> draft-ietf-idr-tunnel-encaps :
> >> >>
> >> >> * since draft-ietf-idr-tunnel-encaps will deprecate RFC5512, it
> >> >> would be better that draft-ietf-bess-evpn-overlay refers to
> >> >> draft-ietf-idr-tunnel-encaps and not anymore to RFC5512.
> >>
> >> [JORGE] I agree, as long as draft-ietf-idr-tunnel-encaps keeps the
> >> encapsulation extended community. There are a few implementations
> >> using this community and it is enough when only the encapsulation type is needed.
> >
> >
> >[JD] I agree and the tunnel encaps draft does keep the EC
> >
> >
> >>
> >> >>
> >> >> * I think it would be better to avoid the explicit list of encap
> >> >> types in section 5.1.3, and rather refer to
> >> >> draft-ietf-idr-tunnel-encaps instead
> >>
> >> [JORGE] I agree.
> >
> >
> >[JD] According to IANA, it allocated the five tunnels types to the
> >overlay draft so I think we need to keep them
> >
> >
> >>
> >> >> * the following minor modification was proposed, but not yet incorporated:
> >> >>
> >> >> John Drake, 2015-11-13 (to BESS ML):
> >> >>> For the overlay draft, replace this text in section 5.1.3:
> >> >>>
> >> >>> "If the BGP Encapsulation extended community is not present,
> >> >>> then the default MPLS encapsulation or a statically configured
> >> >>> encapsulation is assumed."
> >> >>>
> >> >>> With the following:
> >> >>>
> >> >>> "Note that the MPLS encapsulation tunnel type is needed in
> >> >>> order to distinguish between an advertising node that only
> >> >>> supports non-MPLS encapsulations and one that supports MPLS and
> >> >>> non-MPLS encapsulations. An advertising node that only supports
> >> >>> MPLS encapsulation does not need to advertise any encapsulation
> >> >>> tunnel types; i.e., if the BGP Encapsulation extended community
> >> >>> is not present, then either MPLS encapsulation or a statically
> >> >>> configured encapsulation is assumed."
> >> >>
> >> >> I think this change is useful and should be incorporated, although
> >> >> skipping the last sentence would be wise if the full list of
> >> >> tunnel types is removed.
> >
> >
> >[JD] Fine with me either w/ or w/o the last sentence
> >
> >



_________________________________________________________________________________________________________________________

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.