Re: [spring] Different MSDs for different traffic types on the same headend.

Gyan Mishra <hayabusagsm@gmail.com> Wed, 18 December 2019 06:28 UTC

Return-Path: <hayabusagsm@gmail.com>
X-Original-To: spring@ietfa.amsl.com
Delivered-To: spring@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 190241208B3 for <spring@ietfa.amsl.com>; Tue, 17 Dec 2019 22:28:08 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.998
X-Spam-Level:
X-Spam-Status: No, score=-0.998 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, FREEMAIL_REPLY=1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=no 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 UpwKbIpqMldU for <spring@ietfa.amsl.com>; Tue, 17 Dec 2019 22:28:05 -0800 (PST)
Received: from mail-il1-x135.google.com (mail-il1-x135.google.com [IPv6:2607:f8b0:4864:20::135]) (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 D00201200C7 for <spring@ietf.org>; Tue, 17 Dec 2019 22:28:04 -0800 (PST)
Received: by mail-il1-x135.google.com with SMTP id v69so715312ili.10 for <spring@ietf.org>; Tue, 17 Dec 2019 22:28:04 -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=pe64ShISQo1neohJ5/NdQ6qYw6vBltjhQRWX7KP2o7Y=; b=Ls1M5hNVkIFQy9kj0gztNqpoRvVMi/nOfK9miqTa87Y826Ns19iWnRMn0z+3GztJ1f um/ivaF+8KOo1dGkykSHUTNpunNMLfZ7bvSZXXgAygynEK9TaOjIGnu8p4bAdP/j1dtl vKFsZ6NbaojdoFxuLxNwHMfD/uXmCY5/deiF5PjeZK0M74e4Uhqw5g95pxA0ZyhE83y6 6UvVcJJH4hnWqeLSS2ykXpqNNqr8W9oCwNS+kMjf/heThQ00o6zZaadgWiUbEjGiGDGF uYRSm/ub0L2Z6048oyoazkxa9NR6M+0WwLmhtHd6jp/adGKQiF8pUQ5tYdIMiY2dnTyH ++fg==
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=pe64ShISQo1neohJ5/NdQ6qYw6vBltjhQRWX7KP2o7Y=; b=t7eVyVLOELbmN1MUYAVuVJRBuu6BeKzxwuOJwECDXUR0aQOL9kB+t5vWptvuQt0XU8 WtJX3UQuNDwSwJ45SIVLf5w4nBBdCamfIY5fOoSHpzHMZSW3ApByf63OiSpJQCS8VGy7 LGEXjulIdACdRKa7WubvPziLeFlYt+jRqWpfaMknlKQqs2ptyCI8uim4+Kw+SvqZw3uG 5t42tBZtTWQRwVs8R1C6je/G6Aik6uJ7Pbc4WmULb4ixs7XuJK5JMz2Izh2paWnJ0FXs ouDLdAtBIeGIpCmdFzVgxrPYokksi+7UbLNYQl0EWuKDpqU4JtumYRXDxgXa970WhgXu l3ew==
X-Gm-Message-State: APjAAAV+9r6g5Pbo0Pexx1e1QDXz9mbxH1Rr3Nx+olX5k/KGiD2/ZduG lFoY1qhNYeIdI0AlsLMrUjmvySmuoYmKM27B5L4=
X-Google-Smtp-Source: APXvYqznCSxG/K2zn4dEdoEGK66m4TwISMOgDmybDJ5W/Bfzihcmpn9tmlZZoI4fUqd58K6EvsWf68XZ0wsHFEkadgc=
X-Received: by 2002:a92:4095:: with SMTP id d21mr422018ill.158.1576650483760; Tue, 17 Dec 2019 22:28:03 -0800 (PST)
MIME-Version: 1.0
References: <CAN3QBScGjeL=yDSW3AOXZrVTGA-czbY2qDrOMQ=gDxAd4d=nYQ@mail.gmail.com> <38b14bf5-b6d9-4d46-ad1d-d26d3376df51@Spark> <CAN3QBSf2Kpu3Pd_FYmA7BCHJ=uWu9DnEEaYdQwGDDs26NmbJQg@mail.gmail.com> <CABNhwV1-yRcK18JsJbAr3e+Hm-35WdmUFZ0mkzwLj5iBD9zWxw@mail.gmail.com> <c8967bfb-5a8e-447d-8e28-314820764f13@Spark> <CAN3QBScyJ5QgmKU8_h62pLF=FQ8y40C3sSRB1TWfKBQfdb1Mkw@mail.gmail.com> <CAN3QBSdFVCBQVPVc2Ax0i2EgMrGqzSCj7YpsUUE2m3HiM9AcyA@mail.gmail.com> <CAOj+MMFZnhYgOShZDFuBAwvhaUPGppo+JTF1k_1+MWKh08NGQg@mail.gmail.com> <CAN3QBSf8e7H7337_E9odFRbz--whH4w+D0NVozsefVSsD75nNg@mail.gmail.com> <MWHPR11MB1600FC5024F4CB780597079CC1500@MWHPR11MB1600.namprd11.prod.outlook.com> <CABNhwV2WHuGMmw-DcxWoELtt6LLp7HRyisBLr7vjN6e0tPYh=g@mail.gmail.com> <45229771-83a4-418c-89f8-f8217c72cda0@Spark>
In-Reply-To: <45229771-83a4-418c-89f8-f8217c72cda0@Spark>
From: Gyan Mishra <hayabusagsm@gmail.com>
Date: Wed, 18 Dec 2019 01:27:38 -0500
Message-ID: <CABNhwV2rpGcbqeCtUM+ht6ZqcCNEh8k9SEhWe-E41qVBiD8yMg@mail.gmail.com>
To: Jeff Tantsura <jefftant.ietf@gmail.com>
Cc: "Ketan Talaulikar (ketant)" <ketant@cisco.com>, Nat Kao <lekao@pyxisworks.org>, Robert Raszuk <robert@raszuk.net>, SPRING WG <spring@ietf.org>
Content-Type: multipart/alternative; boundary="0000000000000502e60599f48c47"
Archived-At: <https://mailarchive.ietf.org/arch/msg/spring/FVrMgbBSohKiXK8WA3IRZAwbR8I>
Subject: Re: [spring] Different MSDs for different traffic types on the same headend.
X-BeenThere: spring@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "Source Packet Routing in NetworkinG \(SPRING\)" <spring.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/spring>, <mailto:spring-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/spring/>
List-Post: <mailto:spring@ietf.org>
List-Help: <mailto:spring-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/spring>, <mailto:spring-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 18 Dec 2019 06:28:08 -0000

Thanks Jeff!!

Kind regards

I have a personal Cisco VIRL server server which I just finished building
out the SP topology with two SP SR domains.  Cisco XRv supports SRv6 in
6.6.1 so I have loaded the latest image 7.0.1 so hopefully have all
features.  Plan to get it all up and running tomorrow.

Question-  Since SR-MPLS uses an IPv4 data plane and since SRv6 uses IPv6
data plane is it possible to run SRv6 as an overlay both SR-MPLS and SRv6
together as two ships in the night.  Would save on having to go back and
forth between simulations if they can both live together  so I can test
both simultaneously.

In-line questions follow up

On Tue, Dec 17, 2019 at 8:41 PM Jeff Tantsura <jefftant.ietf@gmail.com>
wrote:

> Gyan,
>
> I wrote this presentation ~3 years ago, so the numbers are not necessarily
> current.
>
> Please see inline, hope this helps you to better understand the technology
> behind the terminology.
> Let me know if anything is unclear.
>
> Cheers,
> Jeff
> On Dec 17, 2019, 3:45 PM -0800, Gyan Mishra <hayabusagsm@gmail.com>om>,
> wrote:
>
>
> Hi Ketan
>
> Is this the artificial boundary below for SR-TE from the document provided
> by Jeff.
>
>  MSD supported by different HW/SW differs widely :
> – Linux (kernel 4.10): 2 SID’s, some improvements recently (as of 4.11) –
> Low end off the shelf (merchant) silicon, e.g. BCM Trident2: 3-5 SID’s –
> High end off the shelf (merchant) silicon, e.g BCM Jericho1 : 4-7 SID’s –
> Vendor’ silicon, e.g. Juniper’ Trio, Nokia’ FP3: 4-10+ SID’s
>
> So if you are doing MPLS-TE w/o SR-TE policies reusing they MPLS data
> plane the label stack is identical to MPLS just with different label range
> for SRGB 16000-23999 for absolute or indexed label.
>
> [jeff]SRGB is either configurable or a static label range, it doesn’t have
> to be identical with SR domain, indexing provides the abstraction (and
> there’s life outside of Cisco ;-))
>
> Label stack for SR-MPLS is identical to MPLS with single topmost label for
> label switching through the core and bottom of stack services label for L3
> vpn services.
>
> [jeff] NH in the VPN route is recursively resolved to a LSP (or policy in
> modern lingo) that could have 1 or more SID’s associated with it (). In
> MPLS case, without TE, would be the label/N-SID of the egress PE, the SID
> stack would grow any time you need to use Adj-SID’s to deviate from SPT.
> Specifically to SR, egress PE can also associate a particular path (color)
> with the route and signal to the ingress PE what path to take in order to
> reach it (NH).
>

    [gyan] So if you are running just SR-MPLS using SPF path and don’t
deviate from that then with prefix/node SID which I believe is like the
egress PE ibgp NH loopback FEC destination, that you have a SID label
binding for your LSP to build topmost reusing the MPLS data plane.  In the
case described there would be only 1 transport label.  Correct?

You would only have an Adj-SID if you are doing SR-TE.  Correct?  In that
case if you had one Adj-SID in the middle of the path like a loose explicit
route object ERO, then would still be only 1 transport label in the stack
as if you were not doing SR-TE.  Or would it be 2 labels, not sure.

So let’s say If your SR-TE path deviated from the spf along 10 hops, so
then you would have 10 Adj-SIDs and so 10 labels in the stack.  So this is
where MSD and BGP-LS IGP extensions come into play to signal back to the
head end that the maximum SID depth has exceeded resulting in an error.  At
that point the
SR-TE LSP would be broken and you would have to manually build policy with
less strict hops.

I guess If you were using PCEP centralized controller that would signal MSD
exceeded but I think you would still be in a broken LSP state.  The pcep
controller would have to be sitting next to the head end for the SR-TE
policy for the LSP to fix automatically.  Is that correct?

So for SR-TE due to the MSD issues and SID depth asic limitations even with
the latest asic, you really have to deploy a pcep controller based
architecture near the head end with SR-MPLS if using SR-TE.  If you are not
using SR-TE then I believe there is really no benefit of going to SR-MPLS.

You agree.

I guess you save on having to maintain ldp state on each node.  Thats  not
a big deal or business justification to switch to SR-MPLS as for operators
“MPLS” is their bread & butter they are use to so why change.

I think the big benefit for both SR-MPLS and SRv6 is individual coloring of
vpn flows.  Cisco calls it per-VRF TE, but it’s ugly to configure and
manage.

So SR-MPLS and SRv6 is the future solution for operators that need the per
vpn coloring.

Given the issues with SR-TE with SID depth asic limitations is it possible
to use traditional RSVP TE.

I am going to try in my virl setup as that could be a good workaround for
SR-TE hardware limitations until the hardware is up to snuff to handle very
long explicit paths.

I believe their is a draft with teas in the works for IP TE to use rsvp
bandwidth signaling path and reserve messages with both SR-MPLS and SRv6.


> For clarity on nomenclature below please comment:
>
> Transport label - This is the SID label stack insertion at the ingress PE
> head end to the SR-MPLS domain performing SR-TE.  Each hop along the way
> hop the top SID label is popped until SL==0 at which time PHP default or
> UHP explicit null “pipe mode” is performed. (Similar to topmost in MPLS
> label switch world but now its a stack of labels  instead of a single
> label)
>
> [jeff] There’s no SL field in MPLS header, there’s however BoS bit that
> should be set on the most bottom label (in this case - VPN label), PHP is
> explicitly signaled by the egress PE (P/NP-flag in Prefix-SID)
>
>
> Once you get past the transport label now you are on common ground with
> M-BGP overlay services
>
> Services label- L3 vpn service SID signaled.
> So with the service label that is signaled from ingress to egress PE for
> service.  Is this a single label like traditional L3 vpn aggregate label or
> more then one or many labels.
>
> [jeff] there’s no differences with any other VPNoverFoo, service labels
> are signaled in exactly same way independently of the transport and are
> locally significant (that’s why LxVPN’s are such a great technology)
>
>
> The services label my guess should be fixed and not have any vendor
> specific boundary constraints.
>
> [jeff] they are locally significant, in any implementation - label blocks
> are associated with particular functions and programmed in HW, so the
> service label would come out of the service range, which is significant to
> the device advertising it.
> In modern OS’s the ranges are configurable, in older ones, it is static
> and there’s usually a header file that looks like:
> #define MPLS_L3VPN_MIN_LABEL  0x40000
> #define MPLS_L3VPN_MAX_LABEL 0x85FFF
>
>
> Gyan
>
> On Tue, Dec 17, 2019 at 7:21 AM Ketan Talaulikar (ketant) <
> ketant@cisco.com> wrote:
>
>> Hi Nat,
>>
>>
>>
>> The MSD framework enables us to define more/new MSD types. If there is a
>> real use-case and requirement (as you express) and the necessary MSD
>> type(s) can be formally defined then perhaps the WG can evaluate it.
>>
>>
>>
>> Thanks,
>>
>> Ketan
>>
>>
>>
>> *From:* spring <spring-bounces@ietf.org> *On Behalf Of* Nat Kao
>> *Sent:* 17 December 2019 17:16
>> *To:* Robert Raszuk <robert@raszuk.net>
>> *Cc:* SPRING WG <spring@ietf.org>rg>; Nat Kao <lekao@pyxisworks.org>
>> *Subject:* Re: [spring] Different MSDs for different traffic types on
>> the same headend.
>>
>>
>>
>> Hello, Robert.
>>
>> Surely the current BMI-MSD definition is sufficient for platforms without
>> artificial boundaries.
>>
>> In this ideal case, maximum labels available for SR-TE policy can be
>> inferred from BMI-MSD and VPN routes.
>>
>>
>> However we have 3 different artificial boundaries across 3 different
>> platforms now.
>>
>> Hardcoding these boundaries might not scale well. (Especially different
>> OS versions may behave differently.)
>>
>> A standard mechanism to discover this boundary would greatly help
>> constructing SR-TE policy candidate paths.
>>
>>
>>
>> Regards,
>>
>> Nat.
>>
>>
>>
>>
>>
>> On Tue, Dec 17, 2019 at 5:58 PM Robert Raszuk <robert@raszuk.net> wrote:
>>
>> Hi Nat,
>>
>>
>>
>> I am having a bit of difficulty understanding reasoning and the way you
>> are separating transport from service labels.
>>
>>
>>
>> The processing label limit usually comes from data plane capabilities of
>> the platform namely LFIB or hardware below.
>>
>>
>>
>> Such layer is function agnostic and it does not matter what role the
>> label serves.
>>
>>
>>
>> Label lookup results in pointer to a adj. rewrite on the outbound side.
>> It really does not matter if the adjacent peer is your P router, segment
>> endpoint or CE.
>>
>>
>>
>> Of course there are number of processing exceptions - for example concept
>> of aggregate VPN label, additional header modifications etc ...
>>
>>
>>
>> Likely some platforms put such artificial boundary between transport and
>> service hence your request. But if so IMHO this is more of an issue with
>> specific platform or its marketing message then IETF :).
>>
>>
>>
>> Many thx,
>> R.
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>> On Tue, Dec 17, 2019 at 6:06 AM Nat Kao <lekao@pyxisworks.org> wrote:
>>
>> Hi, Jeff.
>>
>> Consider a headend that can perform 1 of the following 2 modes(but not
>> both):
>>
>> 1) Plain IPv4: 6 transport labels + 0 service label => traffic can be
>> steered into a 6-label SR-TE policy.
>>
>> 2) Any type of VPN: 3 transport labels + 1~3 service labels => traffic
>> cannot be steered into a 6-label SR-TE policy.
>>
>> a) As defined in RFC8491, the BMI-MSD is 6 for this headend. Do we have a
>> standardized way to signal the transport label depth in mode 2?
>>
>>    Maybe in a different MSD type?
>>
>> b) Since plain IPv4 and VPN routes can be steered into the same SR-TE
>> policy, do we have a standardized headend behavior in this situation?
>>
>>    (Should I open a new thread to discuss this? It seems not quite
>> MSD-relative.)
>>
>>
>>
>> Thanks...
>>
>> Nat
>>
>>
>>
>> On Tue, Dec 17, 2019 at 7:19 AM Jeff Tantsura <jefftant.ietf@gmail.com>
>> wrote:
>>
>> Gyan,
>>
>>
>>
>> MSD is only relevant for a device that either imposes the label stack
>> (head-end) or manipulates it (BSID anchor). There are some other constrains
>> when it comes to entropy labels and ERLD, please read the respective drafts.
>>
>> In general, SID stack would grow when TE is in use (any time you need to
>> use additional SID to deviate from SPT), another case is when additional
>> SID’s are used for services on the nodes, other than the tail-end.
>>
>> That’s why we've designed MSD to be very flexible to accommodate all the
>> different use cases, it is upto computational logic to decide how to deal
>> with different constrains (MSD types)
>>
>>
>>
>> Cheers,
>>
>> Jeff
>>
>>
>>
>> P.S. you might want to see the NANOG MSD presentation I did some time ago.
>>
>>
>> https://pc.nanog.org/static/published/meetings/NANOG71/1424/20171004_Tantsura_The_Critical_Role_v1.pdf
>>
>> On Dec 14, 2019, 11:59 PM -0800, Gyan Mishra <hayabusagsm@gmail.com>om>,
>> wrote:
>>
>> Jeff
>>
>>
>>
>> With SR-MPLS with SR-TR let’s say if you use cSPF snd don’t have an ERO
>> strict explicit path defined or is a loose path, then the for the cSPF
>> would the transport labels be 1.  For loose would also be 1 also.  If the
>> path were explicit defined to egress PE and was 7 hops from ingress to
>> egress then transport would be 6.  And if L3 vpn service sid was signaled
>> that would be 1 vpn label.
>>
>>
>>
>> Let me know if I have that right.
>>
>>
>>
>> In Nats scenario for IPv6 he has 3 vpnv6 labels.
>>
>>
>>
>> Why is that?
>>
>>
>>
>> With both SR-MPLS and SRv6 the L3 vpn AFI/SAFI MBGP services overlay
>> single label sits on top off SR as if does today with MPLS so why 3 vpn
>> labels.
>>
>>
>>
>> So with this draft with BGP-LS and BMI-MSD you can flood into the IGP the
>> SID depth so all the nodes along the SR-TE path don’t go over the maximum
>> which would result in an error.
>>
>>
>>
>> If you set your MTU high enough in the core like 9216, does that overcome
>> the SID depth issues with SR-TE?
>>
>>
>>
>> Warm regards,
>>
>>
>>
>> Gyan
>>
>>
>>
>> On Sat, Dec 14, 2019 at 2:43 AM Nat Kao <lekao@pyxisworks.org> wrote:
>>
>> Hi, Jeff.
>>
>>
>>
>> Thanks for the BMI-MSD reference. If I understand correctly:
>>
>>
>>
>> BMI-MSD = Transport Label Depth + Service Label Depth
>>
>> Only former can be utilized by SR-TE policies.
>>
>>
>>
>> Currently do we have any method to determine the composition of BMI?
>>
>> We need to know the transport label depth when doing service route
>> per-destination steering.
>>
>>
>>
>> This problem arises when trying to steer a plain IPv4 route and a VPN
>> service route into the same SR-TE policy that exceeds the transport label
>> depth of the service route. I'm trying to figure out the standard behavior
>> in this case since the headend we use currently produces some interesting
>> results.
>>
>>
>>
>> Regards,
>>
>> Nat.
>>
>>
>>
>> On Sat, Dec 14, 2019 at 2:42 AM Jeff Tantsura <jefftant.ietf@gmail.com
>> <jefftant..ietf@gmail.com>> wrote:
>>
>> Hi Nat,
>>
>>
>>
>> Please read https://tools.ietf.org/html/rfc8491#section-5
>>
>> Currently defined MSD types are:
>>
>> 1: BMI
>>
>> 2: ERLD
>>
>>
>>
>> Specifically to BMI:
>>
>> Base MPLS Imposition MSD (BMI-MSD) signals the total number of
>> MPLS labels that can be imposed, including all
>> service/transport/special labels.
>>
>> The answer to your question is 6
>>
>>
>>
>> Cheers,
>>
>> Jeff
>>
>> On Dec 13, 2019, 3:42 AM -0800, Nat Kao <lekao@pyxisworks.org>rg>, wrote:
>>
>> Hello, SPRING WG.
>>
>> How do we deal with an SR-TE policy headend with different MSDs for
>> different types of traffic?
>>
>> For example, a headend H can impose:
>> 6 transport labels for plain IPv4 packets;
>> 5 transport labels + 1 IPv6 ExpNull label for plain IPv6 packets;
>>
>> 3 transport labels + 3 VPN  labels for VPN packets.
>>
>>
>>
>> a) For a plain IPv4 route R4 and a VPN route Rv both steered into the
>> SR-TE policy P1 with SID list <S1, S2, S3, S4, S5>, what will H perform in
>> this situation?
>> b) What is the MSD of H? 6, 5 or 3?
>>
>>
>>
>> Thanks,
>>
>> Nat.
>>
>> _______________________________________________
>> spring mailing list
>> spring@ietf.org
>> https://www.ietf.org/mailman/listinfo/spring
>>
>> _______________________________________________
>> spring mailing list
>> spring@ietf.org
>> https://www.ietf.org/mailman/listinfo/spring
>>
>> --
>>
>> Gyan S. Mishra
>>
>> IT Network Engineering & Technology
>>
>> Verizon Communications Inc. (VZ)
>>
>> 13101 Columbia Pike
>> <https://www..google.com/maps/search/13101+Columbia+Pike?entry=gmail&source=g>
>> FDC1 3rd Floor
>>
>> Silver Spring, MD 20904
>>
>> United States
>>
>> Phone: 301 502-1347
>>
>> Email: gyan.s.mishra@verizon.com
>>
>> www.linkedin.com/in/networking-technologies-consultant
>>
>>
>>
>> _______________________________________________
>> spring mailing list
>> spring@ietf.org
>> https://www.ietf.org/mailman/listinfo/spring
>>
>> _______________________________________________
>> spring mailing list
>> spring@ietf.org
>> https://www.ietf.org/mailman/listinfo/spring
>>
> --
>
> Gyan S. Mishra
>
> IT Network Engineering & Technology
>
> Verizon Communications Inc. (VZ)
>
> 13101 Columbia Pike
> <https://www.google.com/maps/search/13101+Columbia+Pike?entry=gmail&source=g>
> FDC1 3rd Floor
>
> Silver Spring, MD 20904
>
> United States
>
> Phone: 301 502-1347
>
> Email: gyan.s.mishra@verizon.com
>
> www.linkedin.com/in/networking-technologies-consultant
>
> _______________________________________________
> spring mailing list
> spring@ietf.org
> https://www.ietf.org/mailman/listinfo/spring
>
> --

Gyan S. Mishra

IT Network Engineering & Technology

Verizon Communications Inc. (VZ)

13101 Columbia Pike FDC1 3rd Floor

Silver Spring, MD 20904

United States

Phone: 301 502-1347

Email: gyan.s.mishra@verizon.com

www.linkedin.com/in/networking-technologies-consultant