Re: [Bier] What does BIERin6 propose to satisfy the requirements? //RE: draft-ietf-bier-ipv6-requirements-09

Gyan Mishra <hayabusagsm@gmail.com> Thu, 26 November 2020 07:26 UTC

Return-Path: <hayabusagsm@gmail.com>
X-Original-To: bier@ietfa.amsl.com
Delivered-To: bier@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E51263A0B4E for <bier@ietfa.amsl.com>; Wed, 25 Nov 2020 23:26:59 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.097
X-Spam-Level:
X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[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 ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5MUyMMEnzp1D for <bier@ietfa.amsl.com>; Wed, 25 Nov 2020 23:26:56 -0800 (PST)
Received: from mail-pg1-x529.google.com (mail-pg1-x529.google.com [IPv6:2607:f8b0:4864:20::529]) (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 F37383A0B45 for <bier@ietf.org>; Wed, 25 Nov 2020 23:26:55 -0800 (PST)
Received: by mail-pg1-x529.google.com with SMTP id t3so961670pgi.11 for <bier@ietf.org>; Wed, 25 Nov 2020 23:26:55 -0800 (PST)
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=zt7bS9zsK/rPvyHoNd4Y0eKzHqdqKjsEam0ynrk24t4=; b=S8EBYUl9cGxLDRSlQxNfZgxpQVKKXUUMRDv81Cy83gmJtg7W6fiRzUF9COHF7E6A5/ vGNSFGSiB+qAjwHkTXFgdHorDQtthCai+F9LmsV1HCAWNM8wiNIz0KdOZMiivde9NUvw Fm16vAX/yQ985b+zTogX0Oa8apS4lSDT4OsYATxBtTB0BP0iL7HeUZMidzILX2vytbm1 2F28icALt+H/alPj18xvHBgx6+FomTY/FZLMDlRkNLkwYYmxh6+Yha3/QwPsFRlpXqBD mXi5COGnrB6In7KhYuHmOijD+5zGrrMBQinLSv6wcWzYCakHli+mFE11prgplqoFwwqw rHnw==
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=zt7bS9zsK/rPvyHoNd4Y0eKzHqdqKjsEam0ynrk24t4=; b=JQk7a2p4Uagl33x4yzgmNGISNz62w82eTuG0NHl6wDiCQpgeY66zVCqYAcQbfIenL4 bcJ7MukC10/7TCeGbnxmC7CncA/lwgbsry9RZ/x6icnSkr1FLT4Oirr/UrEAHYg0hhRD NagDanTPzdjvt6UwAwlkDIWK3TRFiHoi+V9KS6Bg2Ov2zt8SxvU3RdjbbI4HGzY5eIi3 PJCk6+Pn9y3osrV98gysW+TPsNieeLsKetFjni0YdQYozDgM3GSHYbJZ7XFTmhn1lUI+ tAwnn6YaKtGpYykZpazlVQmefNh+iCnNxmN5rswsPCLry/LY1wOznckWOumAVedJNX80 OodQ==
X-Gm-Message-State: AOAM53144wSLq5P+I26Hmvf+1Zn+zY0vAGujobjsplAdjKvZKWon7fTP YvoXCf9dafUJDa3YDOhxg2KCk7TP4Z3QYLFvHuY=
X-Google-Smtp-Source: ABdhPJzDMyya98rJU7gday3FK6Fg3Lp8k0Yz06D3CrfXNH3uFp0fswcyDGGRr9HziQAZ419gWtGF+gg52WHo8F0gu1M=
X-Received: by 2002:a65:4241:: with SMTP id d1mr1542816pgq.18.1606375615306; Wed, 25 Nov 2020 23:26:55 -0800 (PST)
MIME-Version: 1.0
References: <d518b2ac16a2468e8aa80bf77d0bc5d9@huawei.com> <MN2PR05MB598184BEDEE585C2519A36D9D4FA0@MN2PR05MB5981.namprd05.prod.outlook.com> <CABNhwV1peU2gZGDfpeP3OV4_Cz=7K0TVBWw+OQQe2TR=-NJF=g@mail.gmail.com> <CABNhwV0A+aNgQyMWLbTnsvZeGH2EWOvtDg97a_V3=S4vtifOSg@mail.gmail.com> <MN2PR05MB59819D78CC4B6E8C1CF9FC32D4FA0@MN2PR05MB5981.namprd05.prod.outlook.com> <CABNhwV31haN=kDd+h06td1e1aMAbTH4pj3-tOJb_ocYdchvi_g@mail.gmail.com> <MN2PR05MB5981ECD9F52090A9CDD72C4ED4FA0@MN2PR05MB5981.namprd05.prod.outlook.com>
In-Reply-To: <MN2PR05MB5981ECD9F52090A9CDD72C4ED4FA0@MN2PR05MB5981.namprd05.prod.outlook.com>
From: Gyan Mishra <hayabusagsm@gmail.com>
Date: Thu, 26 Nov 2020 02:26:34 -0500
Message-ID: <CABNhwV34AaySorQS3ip2-AvtKhHEf1OPWda9ExPq=ut16CSBcg@mail.gmail.com>
To: "Jeffrey (Zhaohui) Zhang" <zzhang@juniper.net>
Cc: Alvaro Retana <aretana.ietf@gmail.com>, BIER WG <bier@ietf.org>, "Xiejingrong (Jingrong)" <xiejingrong@huawei.com>, "gjshep@gmail.com" <gjshep@gmail.com>
Content-Type: multipart/related; boundary="000000000000eda67505b4fd7740"
Archived-At: <https://mailarchive.ietf.org/arch/msg/bier/jwNZIDTixs-PYKuZpbc3yfTvH4Q>
Subject: Re: [Bier] What does BIERin6 propose to satisfy the requirements? //RE: draft-ietf-bier-ipv6-requirements-09
X-BeenThere: bier@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "\"Bit Indexed Explicit Replication discussion list\"" <bier.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/bier>, <mailto:bier-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/bier/>
List-Post: <mailto:bier@ietf.org>
List-Help: <mailto:bier-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/bier>, <mailto:bier-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 26 Nov 2020 07:27:00 -0000

Jeffrey

In-line Gyan>

On Wed, Nov 25, 2020 at 4:46 PM Jeffrey (Zhaohui) Zhang <zzhang@juniper.net>
wrote:

> As I mentioned several times, “reason for IPV6 encapsulation” has several
> aspects.
>
>
>
>    1. Between directly connected BFRs
>    2. Between BFRs that are not directly connected (for non-BFR or FRR
>    support)
>    3. From BFIR to BFER
>
>  Gyan> #1 and #2 can be done with RFC 8296 Non MPLS BIER Ethernet.  Only
> FRR might need BIERin6, however for FRR local protection to work with L2
> tunnel for PLR bypass can be done.
>

The other requirement for BIERin6 is if operators requires IPV6
encapsulation, well now the encapsulation does exist but in the payload
technically with L2, and so even then BIERIn6 “optional” solution would not
be used.

The fact that BIERin6 always has to be qualified as “optional” solution it
basically would be non existent and would not be deployed by operators.

>    So then as stated as BIERin6 is optional and as long as BFR uses
Ethernet, then all of the above can be accomplished today with “L2” RFC
8296 Non MPLS BIER.  My point is the optional BIERin6 as it is optional
**not recommended** basically would never be used.

For the last 15 years TDM had been eliminated from carrier networks and MEF
MetroE is really the only L2 medium  for carrier handoff.  So the idea that
BIERin6 would be used for non Ethernet scenario as that scenario does not
exist it would not happen as well.

> #1 is optional BIERin6. #2 is used BIERin6 for non-BFR or FRR support
> reasons.
>
> #3 was introduced in BIERv6 and it is what triggered Greg’s original
> question, and that’s the crux for adding the IPv6 encapsulation discussion
> to the requirements draft.
>
>
>
> I am sure the BFIR->BFER IPv6 encapsulation requirements will be added to
> the requirements draft. Then it comes to a solution question – how does
> that work with BIER.
>
>
>
> BIERin6 already has a solution (unspoken yet in the draft) for #3 (IPv6
> becomes BIER payload) due to its nice clean layering, and it makes SRv6
> based MVPN/EVPN much easier and more aligned with unicast. As a comparison,
> for #1 and #2, BIER header comes as IPv6 payload.
>
>  Gyan> That unspoken solution is “L2” RFC 8296 Non MPLS Bier Ethernet
> where IPv6 is the payload of BIER.   So then as you stated clearly why do
> we need a BIERin6 draft?
>
    The main point here that I have mentioned several times is that the
“optional” BIERin6 solution would never be used as it is overshadowed by
the    “existing “ solution which is hush hush unspoken “L2 one hop or
multi hop RFC 8296” solution.  What this does is also overshadow BIERv6 as
well as the playing field is not level as now RFC 8296 Non MPLS BIER
Ethernet L2 solution becomes the ubiquitous dominant solution for IPV6
environments.

The only way for IPv6 encapsulation solution both BIERin6 or BIERv6 that
Greg referred to as the “why do we need IPv6 encapsulation” is if the L3
RFC 8296 Non MPLS BIER Ethernet  next header 0xAB37 is removed from the
BIERin6 draft.

> Jeffrey
>
>
>
> *From:* Gyan Mishra <hayabusagsm@gmail.com>
> *Sent:* Wednesday, November 25, 2020 3:51 PM
> *To:* Jeffrey (Zhaohui) Zhang <zzhang@juniper.net>
> *Cc:* Alvaro Retana <aretana.ietf@gmail.com>; BIER WG <bier@ietf.org>;
> Xiejingrong (Jingrong) <xiejingrong@huawei.com>; gjshep@gmail.com
> *Subject:* Re: What does BIERin6 propose to satisfy the requirements?
> //RE: draft-ietf-bier-ipv6-requirements-09
>
>
>
> *[External Email. Be cautious of content]*
>
>
>
>
>
> Thank you Jeffrey and sorry for going in circles on this.  I believe this
> is a very important subject so I think time well spent to iron out this
> last critical point as it delves into Greg’s original question as to reason
> for IPV6 encapsulation if we already have a solution.
>
>
>
> The big question for Greg and Alvaro about the existing RFC 8296 solution
> of it should be included or not in BIERin6 draft.
>
>
>
> That has been the crux of the entire thread.
>
>
>
> Thank you
>
>
>
> Gyan
>
>
>
> On Wed, Nov 25, 2020 at 1:11 PM Jeffrey (Zhaohui) Zhang <
> zzhang@juniper.net> wrote:
>
> @Alvaro Retana <aretana.ietf@gmail.com>@gjshep@gmail.com
> <gjshep@gmail.com> – one request below for the chair and AD.
>
> @Xiejingrong (Jingrong) <xiejingrong@huawei.com> – two question/comment
> below.
>
>
>
> Hi Gyan,
>
>
>
> Please see zzh2> below.
>
>
>
> *From:* Gyan Mishra <hayabusagsm@gmail.com>
> *Sent:* Wednesday, November 25, 2020 10:40 AM
> *To:* Jeffrey (Zhaohui) Zhang <zzhang@juniper.net>
> *Cc:* BIER WG <bier@ietf.org>; Xiejingrong (Jingrong) <
> xiejingrong@huawei.com>
> *Subject:* Re: What does BIERin6 propose to satisfy the requirements?
> //RE: draft-ietf-bier-ipv6-requirements-09
>
>
>
> *[External Email. Be cautious of content]*
>
>
>
>
>
>
>
>
>
> On Wed, Nov 25, 2020 at 10:29 AM Gyan Mishra <hayabusagsm@gmail.com>
> wrote:
>
>
>
> Please see Gyan2>
>
>
>
> On Wed, Nov 25, 2020 at 8:56 AM Jeffrey (Zhaohui) Zhang <
> zzhang@juniper.net> wrote:
>
> Please see zzh> below.
>
> -----Original Message-----
> From: Xiejingrong (Jingrong) <xiejingrong@huawei.com>
> Sent: Tuesday, November 24, 2020 10:27 PM
> To: Gyan Mishra <hayabusagsm@gmail.com>; Jeffrey (Zhaohui) Zhang <
> zzhang@juniper.net>
> Cc: BIER WG <bier@ietf.org>
> Subject: What does BIERin6 propose to satisfy the requirements? //RE:
> draft-ietf-bier-ipv6-requirements-09
>
> [External Email. Be cautious of content]
>
>
> (to make clean, raise a new topic)
>
> I am confused too by the claiming a solution can do everything and it is
> an "existing" solution, while requesting allocation of IPv6 Next Header /
> IPv4 Protocol value which is non-trivial.
>
> Zzh> Comparing requesting a "next header" value for BIER, and specifying
> an IPv6 DOH to encode BIER and standardizing draft-xie-bier-ipv6-mvpn,
> which is more trivial?
>
>
>
> Gyan2> BIERv6 follows RFC 8200 specification in using DOH to encode BIER
> for hop by hop en route processing.  MPLS BIER has an RFC 8556 for MVPN
> even though it follows standard MVPN procedures RFC 6513 6514.  Non MPLS
> BIER is not any different in that respect but also requires as in IPv6
> environment uses SRv6 BGP Overlay Service.  I think BIERin6 would require a
> draft as well for the optional IPv6 encapsulation for SRv6 environment as
> well.
>
>
>
> Zzh2> For BIERin6 with SRv6 based services, all we need is an assigned
> well-known multicast locator and in case of MVPN/EVPN a new PTA type/id in
> xPMSI. As I mentioned, we’ll add a section in BIERin6, or it can be done in
> a separate draft.
>
> Zzh2> Regardless whether it is a separate draft, I was just responding to
> the “which is non-trivial” comment – it is certainly much simpler than the
> BIERv6 scheme.
>
>
> Zzh> I want to point out that w/o draft-xie-bier-ipv6-mvpn, BIERv6 is not
> complete.
>
>
>
>     Gyan2> In fact MVPN we all agreed is not a requirement as BIER can be
> used for single tenant global table multicast GTM as well.
>
>
> zzh2> The requirements draft lists “Supporting different multicast flow
> overlays” and MVPN is one of them.
>
> Zzh2> I would request @Xiejingrong (Jingrong) <xiejingrong@huawei.com> to
> comment about “MVPN … is not a requirement as BIER can be used for single
> tenant global table multicast GTM as well”.
>
>
>
>
> We need to know, what does *the* BIERin6 draft propose, and how does *the*
> BIERin6 draft satisfy the bier-ipv6-requirements.
>
> Take req-1 as an example, suppose there are PPP-over-SONET(POS, RFC2615)
> links in an IPv6 network, can the existing RFC8296 solve ? What does *the*
> BIERin6 draft propose to solve ?
>
> Zzh> How does IP work with POS? PPP header has a proto field - a new code
> point would be assigned for BIER. That is not IPv6 specific.
>
>
>
> Gyan2> Jingrong’s point is that when BFRs do not use L2 Ethernet “already
> defined solution” in RFC 8296, is when BIERin6 should be used is which
> defined IPv6 encapsulation one hop tunnels. The MAJOR problem we have with
> including an existing solution RFC 8296 L2 “Non MPLS BIER Ethernet” is that
> it is existing and thus overshadows a need for for IPv6 encapsulation and
> to use existing solution and as written in BIERin6 that IPv6 encapsulation
> is “optional”.
>
>
>
> Zzh2> We’re completely going in circles. I say it one more time – BIERin6
> is about “BIER support in IPv6 Networks”, and BIER over L2 is certainly a
> viable and for many operators a preferred solution. Given the multi-year
> saga on BIERin6/BIERv6 and the heated, long/nested email threads going on
> now, it is even more critical to explicitly point out in the BIERin6 draft
> that “BIER support in IPv6 Networks” can naturally use BIER over L2 or
> tunnels, where tunnels can be any tunnel, IPv6 or not, one-hop or multi-hop.
>
> Zzh2> Would like @Alvaro Retana <aretana.ietf@gmail.com> @gjshep@gmail.com
> <gjshep@gmail.com> to chime in, whether it is appropriate if BIERin6,
> which is about “BIER support in IPv6 Networks”, to talk about BIER over L2
> and tunnels. In fact, from BIER’s point of view, there is no difference
> between over L2 and over any kind of tunnel.
>
>
>
> Gyan2> Why should IPv6 encapsulation be optional with BIERin6?  The latter
> L2 solution has existed since Day 1.  We are defining a new solution for
> IPv6 environment with BIERin6.
>
>
>
> Zzh2> IPv6 encapsulation for directly connected BFRs is optional in
> BIERin6, because BIER over L2 w/o IPv6 encapsulation just works but we want
> to allow IPv6 encapsulation for some operators who demand IPv6
> encapsulation even between directly connected BFRs.
>
> Zzh2> BIERin6 is not just “defining a new solution for IPv6”. It is about
> specifying “how BIER can be supported for IPv6” (in one way if you want to
> be exact).
>
>
>
> Gyan2> The case and point here is that most operators in the last 15 years
> have decommissioned all TDM based with Metro Ethernet services.
>
> Zzh2> Then can you ask @Xiejingrong (Jingrong) <xiejingrong@huawei.com>
> why he asked about POS?
>
>
>
> So in essence with draft BIERin6 the way it is written IPv6 encapsulation
> single hop or multi hop tunnels would never be used by operators.
>
>
>
> Zzh2> It’s clear that you have not followed the discussion. Multi-hop
> tunneling will certainly be used, either for getting over non-BFRs or for
> FRR (which will be here for long term).
>
>
>
> So then you might as well remove IPv6 encapsulation from the draft as it’s
> an option that would never be used.  Once you do that you are left with RFC
> 8296 use case informational draft and questionable if that is even
> necessary.
>
>
>
> Zzh2> Wrong conclusion based on wrong assumption – see above.
>
>
>
> The way BIERin6 is written today it would be very difficult to advance for
> WG adoption.
>
>
>
> Please note in my question the word *the* does not include anything that
> RFC8296 can solve. Any existing RFC8296 solution is not belonging to *the*
> BIERin6 proposal. Please tell us *the* BIERin6 proposal.
>
> Zzh> *The* BIERin6 proposal is BIER over L2 and/or tunnels (IPv6 or not).
> In case of IPv6 tunnels, new code points are needed and that's why it needs
> to be on standards track, as I already explained.
>
>
>
>     Gyan> The way it’s written IPv6 encapsulation one hop tunnels would
> never be used by operators as it’s overshadowed by RFC 8296.  The way
> BIERin6 reads it as L2 RFC 8296 can be used for multi hop funnels in case
> of Non BFRs as well.  Even if the operator requires BIER to be carried in
> IPv6 it would be doubtful that would get utilized for one hop tunnels as
> it’s easier to just use RFC 8296 L2 for one hop or tunnel.  In essence the
> IPV6 encapsulation would never be used by operators with BIERin6.
>
> If you think about it BIERIn6 is by definition an oxymoron.  Reason being
> is that with RFC 8296 included as part of BIERin6, BIER header is the outer
> envelope encapsulation so it would be more accurate to say “BIERout6” as
> IPv6 is the payload of BIER in L2 RFC 8296.  The only relevant piece that
> makes sense in every way to be part of BIERin6 is “in” being the keyword
> where the outer encapsulation is IPv6 and BIER is next header thus the “in”
> in BIERin6.
>
>
> Zzh> I had also explained already, why BIERin6 needs to explicitly spell
> out using *existing* solution (concept, not code point) for IPv6 network -
> we've wasted two years on this.
>
>
>
>     Gyan> Well hopefully we don’t waste another 2 year on BIERin6 or I
> guess really should be called BIER-in-out-6.
>
>
>
>       Gyan2> Another clever way to look at is that BIER-in-out-6 is a way
> to squash IPv6 encapsulation with smoke and mirrors as if a there is in a
> pretentious way a néw solution is being developed, where in essence we are
> actually quite the contrary, as this is the trickery game  “optional”
> verbiage to provide a lead on “carrot” if you will that IPv6 encapsulation
> is in the spec but really in all truthfulness let it be told the spec is
> really BIERout6.
>
>
>
> Zzh2> The above again shows that you have not followed the discussion.
>
> Zzh2> I’ve always said that BIERin6 is an existing solution, albeit it
> needs new code points, to allow BIER header following an IPv6 header.
>
> Zzh2> Jeffrey
>
>
>
>  I am not in favor of adoption of  BIERin6 the way the draft is written
> today.  We really have to remove the references to RFC 8296 to make this
> draft even viable.
>
>
>
> Thanks
> Jingrong
>
> -----Original Message-----
> From: Gyan Mishra [mailto:hayabusagsm@gmail.com]
> Sent: Wednesday, November 25, 2020 9:34 AM
> To: Jeffrey (Zhaohui) Zhang <zzhang@juniper.net>
> Cc: Alvaro Retana <aretana.ietf@gmail.com>; BIER WG <bier@ietf.org>;
> EXT-zhang.zheng@zte.com.cn <zhang.zheng@zte.com.cn>; Tony Przygienda <
> tonysietf@gmail.com>; draft-ietf-bier-ipv6-requirements <
> draft-ietf-bier-ipv6-requirements@ietf.org>; gjshep@gmail.com
> Subject: Re: draft-ietf-bier-ipv6-requirements-09
>
> Jeffrey
>
> About the two lingering points it does shed light on something that has
> been disturbing me with the BIERin6 solution.
>
>
> I thought about this some more and I think what creates a lot of confusion
> in my mind with BIERin6 solution is the L2/tunnel component.
>
> As the main reason is that the L2/tunnel exists today with RFC 8296 “Non
> MPLS BIER Ethernet” with the special allocated next header code point to
> account for BIER next header 0xAB37.
>
> I honestly think the L2 should be removed from the BIERin6 draft so that
> the optional IPV6 encapsulation is no longer “optional” in the draft as
> that now is the draft.
>
> This also provides the “IPv6 encapsulation” commonality with BIERv6 at
> least showing clearly that their is a strive for commonality and parity
> between the two solutions.
>
> Also the “muddying” of the water is eliminated by removing L2 making the
> solution crystal clear to operators.
>
>
> Kind Regards
>
> Gyan
>
>
> Juniper Business Use Only
>
> --
>
> <https://www.google.com/maps/search/13101+Columbia+Pike+%0D%0A+Silver%0D%0A+Spring,+MD?entry=gmail&source=g>
>
> [image: Image removed by sender.]
> <https://urldefense.com/v3/__http:/www.verizon.com/__;!!NEt6yMaO-gk!XgM9nZcm8mxG0SCM8QF-Qsyg3BEjUQWT5BlBYf3Y_zmD2xCvRtDyA4zikXIQZmq-$>
>
> *Gyan Mishra*
>
> *Network Solutions Architect *
>
>
>
> *M 301 502-1347 13101 Columbia Pike
> <https://urldefense.com/v3/__https:/www.google.com/maps/search/13101*Columbia*Pike**A0D*0A*Silver*Spring,*MD?entry=gmail&source=g__;KysrJSUrKys!!NEt6yMaO-gk!SS2YlPK0PoO2UO-PtUbsIzC4Wy4-S0FXns06s8B7zNgCVbVz1OmGwrhPyMEHJjID$>
> *Silver Spring, MD
> <https://urldefense.com/v3/__https:/www.google.com/maps/search/13101*Columbia*Pike**A0D*0A*Silver*Spring,*MD?entry=gmail&source=g__;KysrJSUrKys!!NEt6yMaO-gk!SS2YlPK0PoO2UO-PtUbsIzC4Wy4-S0FXns06s8B7zNgCVbVz1OmGwrhPyMEHJjID$>
>
>
>
> --
>
> <https://www.google.com/maps/search/13101+Columbia+Pike+%0D%0A+Silver%0D%0A+Spring,+MD?entry=gmail&source=g>
>
> [image: Image removed by sender.]
> <https://urldefense.com/v3/__http:/www.verizon.com/__;!!NEt6yMaO-gk!XgM9nZcm8mxG0SCM8QF-Qsyg3BEjUQWT5BlBYf3Y_zmD2xCvRtDyA4zikXIQZmq-$>
>
> *Gyan Mishra*
>
> *Network Solutions Architect *
>
>
>
> *M 301 502-1347 13101 Columbia Pike
> <https://urldefense.com/v3/__https:/www.google.com/maps/search/13101*Columbia*Pike**A0D*0A*Silver*Spring,*MD?entry=gmail&source=g__;KysrJSUrKys!!NEt6yMaO-gk!SS2YlPK0PoO2UO-PtUbsIzC4Wy4-S0FXns06s8B7zNgCVbVz1OmGwrhPyMEHJjID$>
> *Silver Spring, MD
> <https://urldefense.com/v3/__https:/www.google.com/maps/search/13101*Columbia*Pike**A0D*0A*Silver*Spring,*MD?entry=gmail&source=g__;KysrJSUrKys!!NEt6yMaO-gk!SS2YlPK0PoO2UO-PtUbsIzC4Wy4-S0FXns06s8B7zNgCVbVz1OmGwrhPyMEHJjID$>
>
>
>
>
>
> Juniper Business Use Only
>
> --
>
> <https://www.google.com/maps/search/13101+Columbia+Pike+%0D%0A+Silver+Spring,+MD?entry=gmail&source=g>
>
> [image: Image removed by sender.]
> <https://urldefense.com/v3/__http:/www.verizon.com/__;!!NEt6yMaO-gk!SS2YlPK0PoO2UO-PtUbsIzC4Wy4-S0FXns06s8B7zNgCVbVz1OmGwrhPyEqzmhS6$>
>
> *Gyan Mishra*
>
> *Network Solutions Architect *
>
>
>
> *M 301 502-1347 13101 Columbia Pike
> <https://www.google.com/maps/search/13101+Columbia+Pike+%0D%0A+Silver%0D%0A+Spring,+MD?entry=gmail&source=g>
> *Silver Spring, MD
> <https://www.google.com/maps/search/13101+Columbia+Pike+%0D%0A+Silver+Spring,+MD?entry=gmail&source=g>
>
>
>
> Juniper Business Use Only
>
-- 

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

*Gyan Mishra*

*Network Solutions A**rchitect *



*M 301 502-134713101 Columbia Pike *Silver Spring, MD