Re: [pim] [bess] [Idr] draft-hb-idr-sr-p2mp-policy (3/10 to 3/24/2022) - Adoption call

Gyan Mishra <hayabusagsm@gmail.com> Thu, 28 April 2022 04:19 UTC

Return-Path: <hayabusagsm@gmail.com>
X-Original-To: pim@ietfa.amsl.com
Delivered-To: pim@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 30E41C157B5C; Wed, 27 Apr 2022 21:19:36 -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=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 ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IQGOAFc8pxNQ; Wed, 27 Apr 2022 21:19:31 -0700 (PDT)
Received: from mail-pl1-x635.google.com (mail-pl1-x635.google.com [IPv6:2607:f8b0:4864:20::635]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E0A55C157B58; Wed, 27 Apr 2022 21:19:31 -0700 (PDT)
Received: by mail-pl1-x635.google.com with SMTP id s14so3282098plk.8; Wed, 27 Apr 2022 21:19:31 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=6C+43LlogV6e5WkjrcPFopmzxDxkHvUhXIqD3vz//NQ=; b=QBIdh4A00pYfbIHw+qlmtdg7fXTR7PEhEo463OVW0aEUvCsGddPoaR9Bwn3lMakFcx 0QfII3FeeaUYtbMNgu5DvbXlcWGb2dUdIl8OhYvrJsqIQpbFRjQKBchG37olmmduanmb 4ywqShvQlHYt0Rm6FCNmgwZUQRayI0Ha+66GXcmlf+C1oHareIfWM0wShj0keB9rt266 V11B9TkhIGqj8179F075FvTjzrUxg+36X26m7OCZu6NC2TErien4iYt/fxcIMLDIFmjv VnNRJJOfNMzk6Akeh5ctCWxbQRV0gfClT9ystP5Dvoio8Z1gfrAk0lLtyITZbcqHnHNj ucCg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=6C+43LlogV6e5WkjrcPFopmzxDxkHvUhXIqD3vz//NQ=; b=45HmMUmpzORjrWLi8Po2AqK5vwB9i2E9w/V6lkN93wymU5V/z6G5vHUVTmdpANg0Ug u/JMrVDwV36ZctMAfknxHUhjYu1IQw2dtuMRp8RNZgycQoWxul9UzGrc3uxgYD8QRLnO G5APfODsvFx8de2L7+DG0bKwHj2dalhSch6ZZQ4N3OlGBB0ZVxYkQ9a99sNs863XuI97 sf170UtqJf2oBSduQdC5nTiC+MOz9m6fcgJ8tDKsDB/dXMed6LHVGu4mLOj8PFQJsflx YpUHvQJwIJq0oiI7voRrBM1mBLfVXo/OGCY6JrB2GjwocImU0Gv8w3pF+UZ6gvx8u/B8 8lcw==
X-Gm-Message-State: AOAM533EFAKd4DYYf80hyhCH35Z/P0PELt8IjxBgOm7UAPVFMJHQy38a KzurM1ncsnpnXD05OGHf2HxvB30MeedJxx/gnnKvib3q
X-Google-Smtp-Source: ABdhPJyed1Dm2Tb48egw2OR5cZWNqAViBfVzBQmoCsClViplfVGvetiZwSc8ho91Yt7bsrD1xY7gY5wrP51GAXlMyuE=
X-Received: by 2002:a17:90a:4fe5:b0:1d0:e5e1:5bbc with SMTP id q92-20020a17090a4fe500b001d0e5e15bbcmr46897765pjh.235.1651119570900; Wed, 27 Apr 2022 21:19:30 -0700 (PDT)
MIME-Version: 1.0
References: <011e01d83493$6175b310$24611930$@ndzh.com> <BL0PR05MB56524EE412C4938C8083E3BED41A9@BL0PR05MB5652.namprd05.prod.outlook.com> <BL0PR05MB56523E436FBC1353208E9A77D41A9@BL0PR05MB5652.namprd05.prod.outlook.com> <PH0PR08MB6581D4F1DE991EA916BAC91B911A9@PH0PR08MB6581.namprd08.prod.outlook.com> <BL0PR05MB5652FFCF1DAC42EC14831C50D41D9@BL0PR05MB5652.namprd05.prod.outlook.com> <CABNhwV1w7dDxFGchJtT9qb6xcjBBygOkvg42GE3ZAtSp9qg55g@mail.gmail.com> <BL0PR05MB5652ADAFC6E35C0669E321D4D4E49@BL0PR05MB5652.namprd05.prod.outlook.com> <CABNhwV3hT2-tuKm2p6zeaayHEh4nX3GzdUv8ksoggaLLuhZiCQ@mail.gmail.com> <BL0PR05MB565251B4F7D0BBA8BC8FF74FD4ED9@BL0PR05MB5652.namprd05.prod.outlook.com>
In-Reply-To: <BL0PR05MB565251B4F7D0BBA8BC8FF74FD4ED9@BL0PR05MB5652.namprd05.prod.outlook.com>
From: Gyan Mishra <hayabusagsm@gmail.com>
Date: Thu, 28 Apr 2022 00:19:18 -0400
Message-ID: <CABNhwV1UB4ys31rtLKucNPcwZu5a5d_LOpmKhEMKnkb6h2OJcg@mail.gmail.com>
To: "Jeffrey (Zhaohui) Zhang" <zzhang@juniper.net>
Cc: BESS <bess@ietf.org>, "Bidgoli, Hooman (Nokia - CA/Ottawa)" <hooman.bidgoli@nokia.com>, Susan Hares <shares@ndzh.com>, "idr@ietf.org" <idr@ietf.org>, "pim@ietf.org" <pim@ietf.org>
Content-Type: multipart/related; boundary="00000000000082443c05ddaf3bee"
Archived-At: <https://mailarchive.ietf.org/arch/msg/pim/zquaW1iK6e-TSxKED35YPEkpw1U>
Subject: Re: [pim] [bess] [Idr] draft-hb-idr-sr-p2mp-policy (3/10 to 3/24/2022) - Adoption call
X-BeenThere: pim@ietf.org
X-Mailman-Version: 2.1.34
Precedence: list
List-Id: Protocol Independent Multicast <pim.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/pim>, <mailto:pim-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/pim/>
List-Post: <mailto:pim@ietf.org>
List-Help: <mailto:pim-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/pim>, <mailto:pim-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 28 Apr 2022 04:19:36 -0000

Hi Jeffrey

Please see Gyan2>

On Tue, Apr 12, 2022 at 11:02 AM Jeffrey (Zhaohui) Zhang <zzhang@juniper.net>
wrote:

> Hi Gyan,
>
>
>
> Please see zzh2> below.
>
>
>
>
>
> Juniper Business Use Only
>
> *From:* Gyan Mishra <hayabusagsm@gmail.com>
> *Sent:* Friday, April 8, 2022 8:48 PM
> *To:* Jeffrey (Zhaohui) Zhang <zzhang@juniper.net>
> *Cc:* BESS <bess@ietf.org>; Bidgoli, Hooman (Nokia - CA/Ottawa) <
> hooman.bidgoli@nokia.com>; Susan Hares <shares@ndzh.com>; idr@ietf.org;
> pim@ietf.org
> *Subject:* Re: [bess] [Idr] draft-hb-idr-sr-p2mp-policy (3/10 to
> 3/24/2022) - Adoption call
>
>
>
> *[External Email. Be cautious of content]*
>
>
>
>
>
> Hi Jeffrey
>
>
>
> Please see Gyan>
>
>
>
>
>
> On Tue, Apr 5, 2022 at 7:38 PM Jeffrey (Zhaohui) Zhang <zzhang@juniper.net>
> wrote:
>
> Hi Gyan,
>
>
>
> Please see zzh> below for my view.
>
>
>
>
>
> Juniper Business Use Only
>
> *From:* Gyan Mishra <hayabusagsm@gmail.com>
> *Sent:* Tuesday, March 29, 2022 10:31 AM
> *To:* Jeffrey (Zhaohui) Zhang <zzhang@juniper.net>
> *Cc:* BESS <bess@ietf.org>; Bidgoli, Hooman (Nokia - CA/Ottawa) <
> hooman.bidgoli@nokia.com>; Susan Hares <shares@ndzh.com>; idr@ietf.org;
> pim@ietf.org
> *Subject:* Re: [bess] [Idr] draft-hb-idr-sr-p2mp-policy (3/10 to
> 3/24/2022) - Adoption call
>
>
>
> *[External Email. Be cautious of content]*
>
>
>
>
>
> Dear authors
>
>
>
> Can you describe in more detail the relationship and interaction between
> the two SR P2MP variants below:
>
>
>
> Defines new SAFI for SR P2MP variant
>
> https://datatracker.ietf.org/doc/html/draft-hb-idr-sr-p2mp-policy-04
> <https://urldefense.com/v3/__https:/datatracker.ietf.org/doc/html/draft-hb-idr-sr-p2mp-policy-04__;!!NEt6yMaO-gk!RNg1gSHc7bgU2dou9enCSiVF-PXIWQ2Wk4mTxBBHjYxjFPb_mdHB9D5C3jKh83Sr$>
>
>
>
> zzh> draft-ietf-bess-bgp-multicast-controller (referred to as draft-bess)
> defines a SAFI and different route types of that SAFI to setup replication
> state on IP/mLDP/SR-P2MP tree nodes. One of the route types is for SR-P2MP
> purposes.
>
> Zzh2> Correction – the MCAST-TREE SAFI is defined in
> draft-ietf-bess-bgp-multicast.
>
>
>
>    Gyan> Ack
>
> Zzh> draft-hb-idr-sr-p2mp-policy (draft in this adoption call, referred to
> as draft-hb) defines a different SAFI and route types for the same SR-P2MP
> purposes.
>
>  Gyan> The adoption call draft is aligned with SR-TE policy as P2MP
> extension for simplicity for operators which I agree makes sense.
>
> Does this draft utilize all the drafts below Tree sid / Replication sid
> and SR P2MP MVPN procedures for auto discovery etc.
>
>
>
> Zzh> Both drafts are for realizing the two tree-sid drafts mentioned
> below; both can be used for draft-ietf-bess-mvpn-evpn-sr-p2mp.
>
>  Gyan> Ack
>
> Zzh> As I mentioned before, both draft-bess and draft-hb have its own
> considerations. The biggest difference is how the replication information
> is encoded in the Tunnel Encapsulation Attribute (TEA).
>
>
>
> Gyan> Ack
>
> Zzh> I can understand that the IDR/PIM/BESS WGs may decide to accept both
> ways of encoding replication information in the TEA, but I believe we
> should share SAFI and route types between the two drafts – only the TEA
> would be different.
>
>
>
> Gyan> Both the BESS and IDR adoption draft are vastly different solutions
> that have very different goals I don’t see any reason or need to have
> similarities as far as TEA or SAFI encodings or usage.  The BGP controller
> draft has a very wide scope, but also is more of an alternative approach as
> it introduces new extensibility idea of utilizing TEA and wide communities
> encoding to make the solution RFC 6513 and 6514 MVPN signaling
> independent.  That is a drastic change for scalability for operations
> traditional use of multicast X-PMSI P-Tree  leveraging the separation of
> control plane from forwarding plane with RR using traditional MVPN
> procedures.  As the ideas from the BESS draft as it builds on the BGP
> Multicast draft is to eliminate soft state tree building protocols and with
> the move towards hard state, thus the signaling paradigm change from
> traditional MVPM procedures to alternate TEA and wide community encoding.
> Am I reading that correctly as the goals of the BESS draft?
>
>
>
> Zzh2> Not really 😊
>
>  Gyan> Ok
>
> The BESS document also mentions that the solution can be used for underlay
> and overlay trees as replacement for MVPN signaling.  For underlay trees
> are you referring to GTM?  I have many more questions about the BESS draft
> and will ask in a new thread.
>
>
>
> Zzh2> draft-ietf-bess-bgp-multicast-controller was initially intended to
> build traditional IP multicast trees (w/o any VPN specifics) and mLDP
> tunnels (started in September 2017) with calculation on and signaling from
> controllers. SR-P2MP was added in -03 (July 2020) because the generic
> mechanism for IP/mLDP trees can be used for SR-P2MP as well. These can all
> be considered as underlay.
>
    Gyan> Ack

> Zzh2> Overlay support – as an MVPN replacement – was added in -06
> (February 2021), but the concept is **not different** from underlay at
> all – we’re just setting up (s, g) IP multicast state in VRFs, with
> downstream nodes including remote VRFs connected by some sort of tunnels.
> That is not different from setting up state in global table at all.
>

     Gyan2> Ack

   Gyan2> What is the advantage of using TEA encoding as opposed to
existing PTA RFC 6513 & RFC 6514 MVPN signaling?

> Zzh2> Thanks.
>
> Zzh2> Jeffrey
>
> Zzh> Jeffrey
>
>
>
> Defines Tree SID stitching of replication SID SR policy P2MP variant
>
> https://datatracker.ietf.org/doc/html/draft-voyer-pim-sr-p2mp-policy-00
> <https://urldefense.com/v3/__https:/datatracker.ietf.org/doc/html/draft-voyer-pim-sr-p2mp-policy-00__;!!NEt6yMaO-gk!RNg1gSHc7bgU2dou9enCSiVF-PXIWQ2Wk4mTxBBHjYxjFPb_mdHB9D5C3gdi0hAB$>
>
>
>
> Replication SID
>
>
> https://datatracker.ietf.org/doc/html/draft-ietf-spring-sr-replication-segment
> <https://urldefense.com/v3/__https:/datatracker.ietf.org/doc/html/draft-ietf-spring-sr-replication-segment__;!!NEt6yMaO-gk!RNg1gSHc7bgU2dou9enCSiVF-PXIWQ2Wk4mTxBBHjYxjFPb_mdHB9D5C3smIMNzh$>
>
>
>
> Defines new SR P2MP PTA using MVPN procedures
>
> https://datatracker.ietf.org/doc/html/draft-ietf-bess-mvpn-evpn-sr-p2mp
> <https://urldefense.com/v3/__https:/datatracker.ietf.org/doc/html/draft-ietf-bess-mvpn-evpn-sr-p2mp__;!!NEt6yMaO-gk!RNg1gSHc7bgU2dou9enCSiVF-PXIWQ2Wk4mTxBBHjYxjFPb_mdHB9D5C3g-W3jH0$>
>
>
>
>
>
> Kind Regards
>
>
>
> Gyan
>
>
>
>
>
> On Mon, Mar 28, 2022 at 3:39 PM Jeffrey (Zhaohui) Zhang <zzhang=
> 40juniper.net@dmarc.ietf.org> wrote:
>
> Hi,
>
>
>
> When it comes to SR-P2MP state downloading, there are three aspects
> involved here:
>
>
>
>    1. NLRI to encode policy information
>    2. NLRI to encode <tree/path/instance, node> identification
>    3. Tunnel Encapsulation Attribute (TEA) that encodes actual
>    replication branches
>
>
>
> The major difference between the two ways is on #3. Indeed, we could not
> reach consensus – there are two ways of encoding the TEA and each has its
> own considerations. The draft-ietf-bess way (even when used for SR-P2MP) is
> aligned with other non-SR multicast trees (IP/mLDP) for a unified approach,
> while draft-hb is aligned to unicast BGP SR policy.
>
>
>
> I want to initiate a discussion and I can understand that WGs may
> eventually choose to allow both ways for #3. Even so, I think we should
> strive for consistent approach at least for #1 and #2 (and for that I am
> not saying that draft-ietf-bess way must be used). For example, use the
> same SAFI and route types for both ways, but use different TEA encoding
> methods.
>
>
>
> Thanks.
>
>
>
> Jeffrey
>
>
>
>
>
> Juniper Business Use Only
>
> *From:* Bidgoli, Hooman (Nokia - CA/Ottawa) <hooman.bidgoli@nokia.com>
> *Sent:* Friday, March 25, 2022 11:34 AM
> *To:* Jeffrey (Zhaohui) Zhang <zzhang@juniper.net>; Susan Hares <
> shares@ndzh.com>; idr@ietf.org
> *Cc:* 'pim@ietf.org' <pim@ietf.org>; 'BESS' <bess@ietf.org>
> *Subject:* RE: [Idr] draft-hb-idr-sr-p2mp-policy (3/10 to 3/24/2022) -
> Adoption call
>
>
>
> *[External Email. Be cautious of content]*
>
>
>
> Hi All
>
>
>
> Zzh> I do think BGP signaling for SR P2MP is appropriate. We just need to
> discuss the two ways and figure out how to proceed. The authors have
> discussed before though we have not reached consensus.
>
>
>
> HB> yes there was discussion and there was no consensus to merge the 2
> drafts as their approach is widely different. The authors of this draft
> have kept the implementation very close to unicast BGP SR Policy for the
> segment list, which simplifies the implementation and deployment of the
> technology. As you said there seems to be two way to download this policy
> and the segment list and we can work on both.
>
> Given the solid support I don’t see why the adoption of this draft should
> be delayed because of these arguments.
>
>
>
> Thanks
>
> Hooman
>
>
>
> *From:* pim <pim-bounces@ietf.org> *On Behalf Of *Jeffrey (Zhaohui) Zhang
> *Sent:* Friday, March 25, 2022 10:47 AM
> *To:* Susan Hares <shares@ndzh.com>; idr@ietf.org
> *Cc:* 'pim@ietf.org' <pim@ietf.org>; 'BESS' <bess@ietf.org>
> *Subject:* Re: [pim] [Idr] draft-hb-idr-sr-p2mp-policy (3/10 to
> 3/24/2022) - Adoption call
>
>
>
> [+ BESS, PIM]
>
>
>
> Hi,
>
>
>
> I realized that in a hurry I did not respond to the specific questions
> below. Please see zzh> next to the questions.
>
>
>
> Looks like that there are some comments on BESS/PIM list and I will go
> through those to see if I have any addition/follow-up on those.
>
>
>
>
>
> Juniper Business Use Only
>
> *From:* Idr <idr-bounces@ietf.org> *On Behalf Of *Jeffrey (Zhaohui) Zhang
> *Sent:* Friday, March 25, 2022 6:30 AM
> *To:* Susan Hares <shares@ndzh.com>; idr@ietf.org
> *Subject:* Re: [Idr] draft-hb-idr-sr-p2mp-policy (3/10 to 3/24/2022) -
> Adoption call
>
>
>
> *[External Email. Be cautious of content]*
>
>
>
> I am sorry for responding late. I somehow missed this.
>
>
>
> I think we should discuss the relationship with
> daft-ietf-bess-bgp-multicast-controller further before adopting this.
>
>
>
> Thanks.
> Jeffrey
>
>
>
>
>
> Juniper Business Use Only
>
> *From:* Idr <idr-bounces@ietf.org> *On Behalf Of *Susan Hares
> *Sent:* Thursday, March 10, 2022 10:28 AM
> *To:* idr@ietf.org
> *Subject:* Re: [Idr] draft-hb-idr-sr-p2mp-policy (3/10 to 3/24/2022) -
> Adoption call
>
>
>
> *[External Email. Be cautious of content]*
>
>
>
> IDR WG:
>
>
>
> If you just wish to respond to the IDR list,
>
> you may respond to this email on the adoption call.
>
>
>
> Cheers, Sue
>
>
>
> *From:* Idr [mailto:idr-bounces@ietf.org <idr-bounces@ietf.org>] *On
> Behalf Of *Susan Hares
> *Sent:* Thursday, March 10, 2022 9:55 AM
> *To:* idr@ietf.org; pim@ietf.org; bess@ietf.org
> *Subject:* [Idr] draft-hb-idr-sr-p2mp-policy (3/10 to 3/24/2022)
>
>
>
> This begins a 2 week WG adoption call for:
>
> draft-hb-idr-sr-p2mp-policy from (3/10 to 3/24/2022)
>
>
>
> You can obtain the draft at:
>
> https://datatracker.ietf.org/doc/draft-hb-idr-sr-p2mp-policy/
> <https://urldefense.com/v3/__https:/datatracker.ietf.org/doc/draft-hb-idr-sr-p2mp-policy/__;!!NEt6yMaO-gk!TfiPI1NfecN3db3pj6WZ8paxUr4s6OvmVZ91mapddPFeCkFZJodxFk8aTGCpYg34$>
>
>
>
> In your comments for this call please consider:
>
>
>
> Zzh> I want to point out that
> https://datatracker.ietf.org/doc/draft-ietf-bess-bgp-multicast-controller/
> <https://urldefense.com/v3/__https:/datatracker.ietf.org/doc/draft-ietf-bess-bgp-multicast-controller/__;!!NEt6yMaO-gk!S33KKHGKJVywLaE5hTpBZvb2Og_8GrdduTTT-6xmknLUl8Yylk7RNo3lGazDpUZk$>
> is another way to do the same. I also explained in
> https://mailarchive.ietf.org/arch/msg/idr/KObeSgKPu3HRbd0ZN7L7fWq_Eto/
> <https://urldefense.com/v3/__https:/mailarchive.ietf.org/arch/msg/idr/KObeSgKPu3HRbd0ZN7L7fWq_Eto/__;!!NEt6yMaO-gk!S33KKHGKJVywLaE5hTpBZvb2Og_8GrdduTTT-6xmknLUl8Yylk7RNo3lGW1pXg_c$>
> why it was in the bess WG.
>
> Zzh> In addition, the bess draft supports **other** multicast trees (IP,
> mLDP besides SR-P2MP) using a consistent way.
>
>
>
> 1)  Does this technology support the SR P2MP features
>
> that distributes candidate paths which connect
>
> a multicast distribution tree (tree to leaves).
>
>
>
> Zzh> It is one way to use BGP to support that. The bess draft specifies
> another way.
>
>
>
> 2) Is the technology correctly specified for the
>
> NLRI (AFI/SAFI) and the tunnel encapsulation attribute
>
> additions (sections 2 and 3)?
>
>
>
> Zzh> The specified SAFI and tunnel encapsulation attribute additions are
> one way for the BGP signaling for SR-P2MP. The bess draft specifies another
> way.
>
>
>
> 3) Does the P2MP policy operation (section 4)
>
> provide enough information for those implementing this
>
> technology and those deploying the technology?
>
>
>
> 4) Do you think this multicast technology is a good
>
> Place to start for P2MP policy advertisement via BGP?
>
>
>
> Zzh> Both ways are good place to start. We just need to figure out how to
> proceed with the two proposals.
>
>
>
> 5) Do you think this SR P2MP policies should not be advertised
>
> via BGP?
>
>
>
> Zzh> I do think BGP signaling for SR P2MP is appropriate. We just need to
> discuss the two ways and figure out how to proceed. The authors have
> discussed before though we have not reached consensus.
>
> Zzh> Thanks!
>
> Zzh> Jeffrey
>
>
>
> Cheers, Susan Hares
>
> _______________________________________________
> BESS mailing list
> BESS@ietf.org
> https://www.ietf.org/mailman/listinfo/bess
> <https://urldefense.com/v3/__https:/www.ietf.org/mailman/listinfo/bess__;!!NEt6yMaO-gk!RNg1gSHc7bgU2dou9enCSiVF-PXIWQ2Wk4mTxBBHjYxjFPb_mdHB9D5C3t2xHmG0$>
>
> --
>
> [image: Image removed by sender.]
> <https://urldefense.com/v3/__http:/www.verizon.com/__;!!NEt6yMaO-gk!RNg1gSHc7bgU2dou9enCSiVF-PXIWQ2Wk4mTxBBHjYxjFPb_mdHB9D5C3l4bzk3s$>
>
> *Gyan Mishra*
>
> *Network Solutions Architect *
>
> *Email **gyan.s.mishra@verizon.com* <gyan.s.mishra@verizon.com>
>
> *M 301 502-1347*
>
>
>
> --
>
> [image: Image removed by sender.]
> <https://urldefense.com/v3/__http:/www.verizon.com/__;!!NEt6yMaO-gk!RiHtqGntIPhoemdxe2yBGpMBQILKyyj3TMv6dkbc_ucJ3OqtTJdthtFCYzd2wPtC$>
>
> *Gyan Mishra*
>
> *Network Solutions Architect *
>
> *Email gyan.s.mishra@verizon.com <gyan.s.mishra@verizon.com>*
>
> *M 301 502-1347*
>
>
>
-- 

<http://www.verizon.com/>

*Gyan Mishra*

*Network Solutions A**rchitect *

*Email gyan.s.mishra@verizon.com <gyan.s.mishra@verizon.com>*



*M 301 502-1347*