Re: [Lsr] Flooding Topology Computation Algorithm - draft-cc-lsr-flooding-reduction-08 Working Group Adoption Call

[Gyan Mishra <[e-mail]>]

Great Thanks Sarah!!

Gyan

On Thu, May 21, 2020 at 10:59 PM Sarah Chen <[e-mail]> wrote:

> Hi, Gyan,
>
> I presented
> https://www.ietf.org/id/draft-chen-lsr-dynamic-flooding-algorithm-00.html in
> the last IETF. You may find the slides below helpful in understanding the
> algorithm:
>
>
> https://datatracker.ietf.org/meeting/interim-2020-lsr-01/materials/slides-interim-2020-lsr-01-sessa-2-dynamic-flooding-algo-sarah.pdf
>
> Thanks,
> Sarah
>
> On Thu, May 21, 2020 at 7:32 PM Gyan Mishra <[e-mail]> wrote:
>
>>
>> I see the diagrams Appendix A -  reviewing
>>
>> Thanks
>>
>> Gyan
>>
>
>> On Thu, May 21, 2020 at 10:13 PM Gyan Mishra <[e-mail]>
>> wrote:
>>
>
>>> I think for both drafts it would be good to have a stick diagram at a
>>> minimum.
>>>
>>> I majored in EE with math  minor and both drafts are hard to follow
>>> without a diagram with labels showing the exact topology examples.
>>>
>>> Four main topologies - full mesh, partial mesh and leaf spine ( 2 tier)
>>> and CLOS ( 3 tier) - real world scenario’s.
>>>
>>> From the interim meeting was their a slide deck visual topology shared?
>>>
>>> That would help.
>>>
>>> https://datatracker.ietf.org/doc/html/draft-cc-lsr-flooding-reduction-08
>>>
>>> 4.1
>>>
>>> Step 1 - Build Cq candidate queue
>>>
>>> For each node B on FT whose D is one (from minimum to maximum
>>>        node ID), find a link L attached to B such that L's remote node R
>>>        has minimum D and ID, add link L between B and R into FT and
>>>        increase B's D and R's D by one.  Return FT.
>>>
>>> My interpretation is the algorithm an iterative loop and starts with any
>>> node in the candidate list so could start from edge and work left to right
>>> or vice versa.  For loop to build FT from Cq = with each node B with
>>> directly attached node R via link L.  Increment node B from Cq until the FT
>>> is build for all nodes.  Instead of starting with a wide diameter FT
>>> matching physical topology we start micro topology with D=1 and go node by
>>> node.
>>>
>>> 4.2
>>>
>>> 1.  Finding and removing the first element with node A in Cq that is
>>>        not on FT and one PH's D in PHs < MaxD and PH's D < PH's ConMaxD.
>>>
>>>        If A is root R0, then add the element into FT
>>>
>>>        otherwise  (i.e., A != R0 with one PH's D in PHs < MaxD and PH's
>>>           D < PH's ConMaxD.  Assume that PH is the first one in PHs
>>>           whose D < MaxD and PH's D < PH's ConMaxD), PH's D++, and add A
>>>           with D = 1 and PHs = {PH} into FT.
>>>
>>>        Note:  if there is no element with a node in Cq satisfying the
>>>           conditions, then algorithm may be restarted from R0, ++MaxD,
>>>           Cq = {(R0,D=0,PHs = { })}, FT = { };
>>>
>>> This is similar to 4.1 with micro topology with 2 directly connected
>>> nodes
>>>
>>> https://www.ietf.org/id/draft-chen-lsr-dynamic-flooding-algorithm-00.html
>>>
>>> My interpretation of the algorithm from the verbiage.
>>>
>>> So this draft starts in the middle of the topology and is geared towards
>>> leaf spine 2 or 3 tier clos topology.
>>>
>>> For this one we build the bi graph so that could be leaf connected to
>>> two spines or spine connected to two leafs and iteratively build out the FT
>>> topology 3 node arch  spine leaf spine or leaf spine leaf.
>>>
>>> Kind regards
>>>
>>> Gyan
>>>
>>
>>> On Thu, May 21, 2020 at 7:01 PM Acee Lindem (acee) <[e-mail]>
>>> wrote:
>>>
>> Hi Gyan,
>>>>
>>>>
>>>>
>>>> *From: *Gyan Mishra <[e-mail]>
>>>> *Date: *Thursday, May 21, 2020 at 4:20 PM
>>>> *To: *Acee Lindem <[e-mail]>
>>>> *Cc: *Huaimo Chen <[e-mail]>, "[e-mail]" <
>>>> [e-mail]>
>>>> *Subject: *Re: [Lsr] Flooding Topology Computation Algorithm -
>>>> draft-cc-lsr-flooding-reduction-08 Working Group Adoption Call
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> Yes and I have started reviewing the LSR mail archives as I am late in
>>>> the discussion for this.
>>>>
>>>>
>>>>
>>>> If you have link to any particular dates in the archives would be
>>>> helpful.
>>>>
>>>>
>>>>
>>>> No – it was more an “evolution” than an “epiphany”.
>>>>
>>>>
>>>>
>>>> That sums up all the questions I have so if all answered in the
>>>> archives then I am all set.
>>>>
>>>>
>>>>
>>>> I support the draft moving forward as flood reduction is a much needed
>>>> feature.
>>>>
>>>>
>>>>
>>>> I think overall both drafts will really help large data centers with
>>>> any overlay underlay vxlan spine leaf meshed CLOS highly meshed topology
>>>> that scales out horizontally with a large spine footprint - this is a much
>>>> much needed feature.  This also helps eliminate complexity of the
>>>> workaround of using BGP in the underlay which to me adds tremendous
>>>> complexity.
>>>>
>>>>
>>>>
>>>> Here is the other recently presented dynamic flooding draft.
>>>>
>>>>
>>>>
>>>>
>>>> https://datatracker.ietf.org/doc/draft-chen-lsr-dynamic-flooding-algorithm/
>>>>
>>>>
>>>>
>>>> You can see they both make use of the dynamic flooding infra in
>>>> https://datatracker.ietf.org/doc/draft-ietf-lsr-dynamic-flooding/
>>>>
>>>>
>>>>
>>>> Thanks,
>>>>
>>>> Acee
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> Kind regards
>>>>
>>>>
>>>>
>>>> Gyan
>>>>
>>>>
>>>>
>>>> On Thu, May 21, 2020 at 4:07 PM Acee Lindem (acee) <[e-mail]>
>>>> wrote:
>>>>
>>>> Speaking as WG Co-chair:
>>>>
>>>>
>>>>
>>>> Hi Gyan,
>>>>
>>>>
>>>>
>>>> I guess you’ve joined this discussion late. It might be a good idea to
>>>> review the LSR mailing list archives.
>>>>
>>>>
>>>>
>>>> *From: *Gyan Mishra <[e-mail]>
>>>> *Date: *Thursday, May 21, 2020 at 1:51 PM
>>>> *To: *Huaimo Chen <[e-mail]>
>>>> *Cc: *Acee Lindem <[e-mail]>, "[e-mail]" <[e-mail]>
>>>> *Subject: *Re: [Lsr] Flooding Topology Computation Algorithm -
>>>> draft-cc-lsr-flooding-reduction-08 Working Group Adoption Call
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> On Thu, May 21, 2020 at 11:01 AM Huaimo Chen <[e-mail]>
>>>> wrote:
>>>>
>>>> Hi Gyan,
>>>>
>>>>
>>>>
>>>>     Thanks much for your questions.
>>>>
>>>>
>>>>
>>>>  Gyan> How does this draft compare to the WG LC draft for flood
>>>> reduction.  Would they be two eventual standard options in the operators
>>>> toolbox  or competing features for optimized flood reduction. Would having
>>>> two flood reduction features standardized versus one default IGP flood
>>>> reduction feature be confusing for operators.  Just as it was confusing to
>>>> me..
>>>>
>>>> https://datatracker.ietf.org/doc/draft-ietf-lsr-dynamic-flooding/
>>>> <https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fdraft-ietf-lsr-dynamic-flooding%2F&data=02%7C01%7Chuaimo.chen%40futurewei.com%7C60df274544ba4b75447f08d7fd947201%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637256686327604003&sdata=TGrkecn6m9liviazX7qqPglGqYEWu5Ekg2FRIaDpBZ8%3D&reserved=0>
>>>>
>>>>
>>>>
>>>>     [HC]: This draft plus the draft for flooding reduction can provide
>>>> two modes of flooding reductions (i.e., centralized mode and distributed
>>>> mode). The latter describes the two modes, but does not include any
>>>> flooding topology computation algorithm for the distributed mode. The
>>>> former proposes a flooding topology computation algorithm to be used
>>>> in the distributed mode.
>>>>
>>>>
>>>>
>>>>    Gyan> It maybe a good idea for both documents to reference each
>>>> other as to how they play together or  in some respects if any provide a
>>>> homogeneous complete holistic solution for flooding problem being solved.
>>>>
>>>>
>>>>
>>>> It is a good idea to have this new draft reference the dynamic-flooding
>>>> but not vice-versa. The existing dynamic flooding draft provides a
>>>> framework for any dynamic flooding algorithm that provides a separate
>>>> flooding topology. This algorithm is just the first to be formally proposed
>>>> in a draft. Note that another algorithm was presented during the LSR
>>>> virtual interim which replaced IETF 107.
>>>>
>>>>
>>>>
>>>> In my opinion it may not be a bad idea even to combine both drafts so
>>>> the solution is complete and holistic.  This will also make the overall
>>>> specification flow nicely.
>>>>
>>>>
>>>>
>>>> No – we’re not going to do this.
>>>>
>>>>
>>>>
>>>> Thanks,
>>>>
>>>> Acee
>>>>
>>>>
>>>>
>>>> I know that efforts were made by LSR to have a common IGP solution,
>>>> however there are many inherent differences between ISIS and OSPF that from
>>>> IGP Link state protocol perspective you can treat like apples to apples but
>>>> really it’s apples and oranges.  Maybe it might we wise to have separate
>>>> draft for both and have references linking together as the same algorithm
>>>> concept and mathematically however the actual code implementation would
>>>> vary as the LSDB link state data structures are completely different.
>>>>
>>>>
>>>>
>>>> Later = Dynamic flooding = 2 modes Centralized leader based and
>>>> distributed
>>>>
>>>>
>>>>
>>>> https://datatracker.ietf.org/doc/draft-ietf-lsr-dynamic-flooding/
>>>>
>>>>
>>>>
>>>> This later draft per section excerpt provides both centralized and
>>>> distributed algorithm see below
>>>>
>>>>
>>>>
>>>> *6.4 <https://datatracker.ietf.org/doc/html/draft-ietf-lsr-dynamic-flooding-05#section-6.4>.  Area Leader Responsibilities*
>>>>
>>>>
>>>>
>>>>    If the Area Leader operates in centralized mode, it MUST advertise
>>>>
>>>>    algorithm 0 in its Area Leader Sub-TLV..  In order for Dynamic
>>>>
>>>>    Flooding to be enabled it also MUST compute and advertise a flooding
>>>>
>>>>    topology for the area.  The Area Leader may update the flooding
>>>>
>>>>    topology at any time, however, it should not destabilize the network
>>>>
>>>>    with undue or overly frequent topology changes.  If the Area Leader
>>>>
>>>>    operates in centralized mode and needs to advertise a new flooding
>>>>
>>>>    topology, it floods the new flooding topology on both the new and old
>>>>
>>>>    flooding topologies.
>>>>
>>>>
>>>>
>>>>    If the Area Leader operates in distributed mode, it MUST advertise a
>>>>
>>>>    non-zero algorithm in its Area Leader Sub-TLV.
>>>>
>>>>
>>>>
>>>>    When the Area Leader advertises algorithm 0 in its Area Leader Sub-
>>>>
>>>>    TLV and does not advertise a flooding topology, Dynamic Flooding is
>>>>
>>>>    disabled for the area.  Note this applies whether the Area Leader
>>>>
>>>>    intends to operate in centralized mode or in distributed mode.
>>>>
>>>>
>>>>
>>>>    Note that once Dynamic Flooding is enabled, disabling it risks
>>>>
>>>>    destabilizing the network.
>>>>
>>>>
>>>>
>>>> *6.5 <https://datatracker.ietf.org/doc/html/draft-ietf-lsr-dynamic-flooding-05#section-6.5>.  Distributed Flooding Topology Calculation*
>>>>
>>>>
>>>>
>>>>    If the Area Leader advertises a non-zero algorithm in its Area Leader
>>>>
>>>>    Sub-TLV, all nodes in the area that support Dynamic Flooding and the
>>>>
>>>>    value of algorithm advertised by the Area Leader MUST compute the
>>>>
>>>>    flooding topology based on the Area Leader's advertised algorithm.
>>>>
>>>>
>>>>
>>>>    Nodes that do not support the value of algorithm advertised by the
>>>>
>>>>    Area Leader MUST continue to use standard flooding mechanism as
>>>>
>>>>    defined by the protocol.
>>>>
>>>>
>>>>
>>>>    Nodes that do not support the value of algorithm advertised by the
>>>>
>>>>    Area Leader MUST be considered as Dynamic Flooding incapable nodes by
>>>>
>>>>    the Area Leader.
>>>>
>>>>
>>>>
>>>>    If the value of the algorithm advertised by the Area Leader is from
>>>>
>>>>    the range 128-254 (private distributed algorithms), it is the responsibility of the
>>>>
>>>> network operator to guarantee that all nodes in the area have a common understanding of what the given algorithm value represents.
>>>>
>>>>
>>>>
>>>> Former = WG LC
>>>>
>>>> https://datatracker.ietf.org/doc/html/draft-cc-lsr-flooding-reduction-08
>>>>
>>>>
>>>>
>>>> Provides algorithm for distributed mode for this draft as well as the
>>>> algorithm to be used for distributed mode later dynamic flooding draft
>>>>
>>>>
>>>>
>>>> Separate question-
>>>>
>>>>
>>>>
>>>> In light of the flooding algorithm and seeing that at the bottom of
>>>> section 6.5 mentions flooding algorithm are the IANA codepoints reserved
>>>> for flooding unique and non overlapping with the flex algo codepoints I
>>>> believe 0-127.  I would think the flooding algorithm range of values is
>>>> completely separate since a different function then flex algo values.
>>>>
>>>>
>>>>
>>>> https://datatracker.ietf.org/doc/html/draft-ietf-lsr-flex-algo-07
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> Best Regards,
>>>>
>>>> Huaimo
>>>> ------------------------------
>>>>
>>>> *From:* Gyan Mishra <[e-mail]>
>>>> *Sent:* Thursday, May 21, 2020 10:36 AM
>>>>
>>>>
>>>> *To:* Huaimo Chen <[e-mail]>
>>>> *Cc:* Acee Lindem (acee) <acee=[e-mail]>;
>>>> [e-mail] <[e-mail]>
>>>> *Subject:* Re: [Lsr] Flooding Topology Computation Algorithm -
>>>> draft-cc-lsr-flooding-reduction-08 Working Group Adoption Call
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> On Wed, May 20, 2020 at 11:59 PM Huaimo Chen <[e-mail]>
>>>> wrote:
>>>>
>>>> Hi Gyan,
>>>>
>>>>
>>>>
>>>>     Thanks much for your questions. My answers are inline below with
>>>> [HC].
>>>>
>>>>
>>>>
>>>> Best Regards,
>>>>
>>>> Huaimo
>>>> ------------------------------
>>>>
>>>> *From:* Gyan Mishra <[e-mail]>
>>>> *Sent:* Wednesday, May 20, 2020 11:14 AM
>>>> *To:* Huaimo Chen <[e-mail]>
>>>> *Cc:* Acee Lindem (acee) <acee=[e-mail]>;
>>>> [e-mail] <[e-mail]>
>>>> *Subject:* Re: [Lsr] Flooding Topology Computation Algorithm -
>>>> draft-cc-lsr-flooding-reduction-08 Working Group Adoption Call
>>>>
>>>>
>>>>
>>>> Huaimo
>>>>
>>>>
>>>>
>>>> This is a much needed feature that operators have been needing for
>>>> densely meshed topologies that commonly exist in data centers to
>>>> accommodate very high bandwidth E-W traffic.
>>>>
>>>> [HC]: Thank you very much.
>>>>
>>>>
>>>>
>>>> Below is link from Cisco which has introduced feature for dynamic
>>>> flooding in clos high density ECMP data center topologies.
>>>>
>>>>
>>>>
>>>> Please look at the feature description and it does seem to be exactly
>>>> the same as this draft.  Please confirm.
>>>>
>>>> [HC]: It seems different.
>>>>
>>>>
>>>>
>>>> There maybe other vendors due to industry demand have to get the
>>>> feature deployed before it reaches standards vendor consensus with the IETF.
>>>>
>>>>
>>>>
>>>>
>>>> https://www.cisco.com/c/en/us/products/collateral/switches/nexus-9000-series-switches/white-paper-c11-743015.html
>>>> <https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.cisco.com%2Fc%2Fen%2Fus%2Fproducts%2Fcollateral%2Fswitches%2Fnexus-9000-series-switches%2Fwhite-paper-c11-743015.html&data=02%7C01%7Chuaimo.chen%40futurewei.com%7C60df274544ba4b75447f08d7fd947201%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637256686327604003&sdata=CPEu2451qkfD9440Ihj1bKPWl%2BzH%2BiuYUwuWpfzR%2B0Q%3D&reserved=0>
>>>>
>>>>
>>>>
>>>> We are testing this feature and planning to deploy but wanted to ensure
>>>> that this is the same as the draft on the standards track.
>>>>
>>>> [HC]: The feature appears implemented draft "Dynamic Flooding on Dense
>>>> Graphs", which does not include any flooding topology computation
>>>> algorithm..
>>>>
>>>>
>>>>
>>>>     Gyan> How does this draft compare to the WG LC draft for flood
>>>> reduction.  Would they be two eventual standard options in the operators
>>>> toolbox  or competing features for optimized flood reduction. Would having
>>>> two flood reduction features standardized versus one default IGP flood
>>>> reduction feature be confusing for operators.  Just as it was confusing to
>>>> me.
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> https://datatracker.ietf.org/doc/draft-ietf-lsr-dynamic-flooding/
>>>> <https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fdraft-ietf-lsr-dynamic-flooding%2F&data=02%7C01%7Chuaimo.chen%40futurewei.com%7C60df274544ba4b75447f08d7fd947201%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637256686327604003&sdata=TGrkecn6m9liviazX7qqPglGqYEWu5Ekg2FRIaDpBZ8%3D&reserved=0>
>>>>
>>>>
>>>>
>>>> Kind regards
>>>>
>>>>
>>>>
>>>> Gyan
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> On Tue, May 19, 2020 at 11:52 PM Huaimo Chen <[e-mail]>
>>>> wrote:
>>>>
>>>> Hi Gyan,
>>>>
>>>>
>>>>
>>>>     Thank you very much for your questions and support.
>>>>
>>>>
>>>>
>>>>     This Flooding Topology Computation algorithm can be used in the
>>>> Dynamic Flooding on Dense Graphs to compute the flooding topologies for
>>>> the data center clos dense meshed topologies with many ECMP paths. It can
>>>> be used by the area leader in the centralized mode to compute the flooding
>>>> topology.
>>>>
>>>>
>>>>
>>>> Best Regards,
>>>>
>>>> Huaimo
>>>> ------------------------------
>>>>
>>>> *From:* Lsr <[e-mail]> on behalf of Gyan Mishra <
>>>> [e-mail]>
>>>> *Sent:* Tuesday, May 19, 2020 2:39 AM
>>>> *To:* Yanhe Fan <[e-mail]>
>>>> *Cc:* [e-mail] <[e-mail]>; Acee Lindem (acee) <acee=
>>>> [e-mail]>
>>>> *Subject:* Re: [Lsr] Flooding Topology Computation Algorithm -
>>>> draft-cc-lsr-flooding-reduction-08 Working Group Adoption Call
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> I support WG adoption and have a few questions related to the draft.
>>>>
>>>>
>>>>
>>>> Does this flooding algorithm use the dynamic flooding algorithm used in
>>>> data center clos dense meshed topologies with many ECMP paths where the
>>>> flood is decoupled from the physical topology.  In the dynamic flooding
>>>> algorithm mentioned in centralized mode the flooding is computed by the
>>>> area leader and distributed to all nodes.  In distributed mode each mode
>>>> the area leader determines the algorithm and then each node computes the
>>>> flooding topology based on the algorithm.
>>>>
>>>>
>>>>
>>>> This dynamic algorithm for optimized flood reduction would reduce the
>>>> amount of redundant flooding in highly densely meshed ospf or Isis
>>>> topologies.  So this optimization of flooding would improving overall link
>>>> state routing protocol convergence.
>>>>
>>>>
>>>>
>>>> Gyan
>>>>
>>>>
>>>>
>>>> On Mon, May 18, 2020 at 3:37 PM Yanhe Fan <[e-mail]>
>>>> wrote:
>>>>
>>>> Support it as a co-author.
>>>>
>>>>
>>>>
>>>> Thanks,
>>>>
>>>> Yanhe
>>>>
>>>>
>>>>
>>>> *From:* Lsr <[e-mail]> *On Behalf Of *Acee Lindem (acee)
>>>> *Sent:* Friday, May 15, 2020 3:40 PM
>>>> *To:* [e-mail]
>>>> *Subject:* [Lsr] Flooding Topology Computation Algorithm -
>>>> draft-cc-lsr-flooding-reduction-08 Working Group Adoption Call
>>>>
>>>>
>>>>
>>>> This begins a 3 week (due to holidays) WG adoption call for the
>>>> “Flooding Topology Computation Algorithm” draft. Please issue your support
>>>> or objection to this list by 11:59 PM, UTC on June 5th, 2020. Here is
>>>> a URL for your convenience.
>>>>
>>>>
>>>>
>>>> https://datatracker.ietf.org/doc/draft-cc-lsr-flooding-reduction/
>>>> <https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fdraft-cc-lsr-flooding-reduction%2F&data=02%7C01%7Chuaimo.chen%40futurewei.com%7C60df274544ba4b75447f08d7fd947201%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637256686327614000&sdata=FkKUWXneiQIUtjkGB6RITfo0vAt2qhkwDWB%2BghP7%2FLg%3D&reserved=0>
>>>>
>>>>
>>>>
>>>> Thanks,
>>>> Acee
>>>>
>>>> _______________________________________________
>>>> Lsr mailing list
>>>> [e-mail]
>>>>
>>>> https://www..ietf.org/mailman/listinfo/lsr
>>>> <https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Flsr&data=02%7C01%7Chuaimo.chen%40futurewei.com%7C60df274544ba4b75447f08d7fd947201%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637256686327623992&sdata=tyEhpdkwdbAVJqAlvbfzNxb7n1qLGrrEZ%2FBjEKa9rVs%3D&reserved=0>
>>>>
>>>> --
>>>>
>>>> *Error! Filename not specified.*
>>>> <https://nam11.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.verizon.com%2F&data=02%7C01%7Chuaimo.chen%40futurewei.com%7C60df274544ba4b75447f08d7fd947201%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637256686327633988&sdata=ii1nTDHCkuMU0AfaMkLjY6N2ww2STRdJBbhHozWSL9I%3D&reserved=0>
>>>>
>>>> *Gyan
>>>> <https://www.google.com/maps/search/13101%0D%0A+Columbia+Pike+%0D%0A+Silver%0D%0A+Spring,+MD?entry=gmail&source=g>Mishra*
>>>>
>>>>
>>>> <https://www.google.com/maps/search/13101%0D%0A+Columbia+Pike+%0D%0A+Silver%0D%0A+Spring,+MD?entry=gmail&source=g>*Network
>>>> Solutions Architect *
>>>>
>>>>
>>>>
>>>> *M 301 502-1347 13101 Columbia Pike
>>>> <https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.google.com%2Fmaps%2Fsearch%2F13101%2BColumbia%2BPike%2B%250D%250A%2BSilver%2BSpring%2C%2BMD%3Fentry%3Dgmail%26source%3Dg&data=02%7C01%7Chuaimo.chen%40futurewei.com%7C60df274544ba4b75447f08d7fd947201%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637256686327653980&sdata=TYHrbd1wDXt4p2yDXi%2Fqm3XEmjK4V7zu3caXeNJFthU%3D&reserved=0>
>>>> <https://www.google.com/maps/search/13101%0D%0A+Columbia+Pike+%C2%A0+%0D%0A+Silver%0D%0A+Spring,+MD?entry=gmail&source=g>
>>>> *Silver Spring, MD
>>>> <https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.google.com%2Fmaps%2Fsearch%2F13101%2BColumbia%2BPike%2B%250D%250A%2BSilver%2BSpring%2C%2BMD%3Fentry%3Dgmail%26source%3Dg&data=02%7C01%7Chuaimo.chen%40futurewei.com%7C60df274544ba4b75447f08d7fd947201%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637256686327663981&sdata=5b0tVVJLdEO9%2FuAksAsc0BAqy%2F%2F%2BE7EBPjRlkKvvOH4%3D&reserved=0>
>>>>
>>>>
>>>> <https://www.google.com/maps/search/13101%0D%0A+Columbia+Pike+%C2%A0+%0D%0A+Silver%0D%0A+Spring,+MD?entry=gmail&source=g>
>>>>
>>>>
>>>> --
>>>>
>>>> *Error! Filename not specified.*
>>>> <https://nam11.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.verizon.com%2F&data=02%7C01%7Chuaimo.chen%40futurewei.com%7C60df274544ba4b75447f08d7fd947201%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637256686327673971&sdata=Bbk8qEHi1RU7J1x%2FNP11v8CYcnDLszZQiNRLmklSDOY%3D&reserved=0>
>>>>
>>>> *Gyan Mishra*
>>>>
>>>> *Network Solutions Architect *
>>>>
>>>>
>>>>
>>>> *M 301 502-1347
>>>> <https://www.google.com/maps/search/13101%0D%0A+Columbia+Pike+%0D%0A+Silver%0D%0A+Spring,+MD?entry=gmail&source=g>13101
>>>> Columbia Pike
>>>> <https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.google.com%2Fmaps%2Fsearch%2F13101%2BColumbia%2BPike%2B%250D%250A%2BSilver%2BSpring%2C%2BMD%3Fentry%3Dgmail%26source%3Dg&data=02%7C01%7Chuaimo.chen%40futurewei.com%7C60df274544ba4b75447f08d7fd947201%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637256686327683966&sdata=2sVGWVhM3Sbk84D2ZyaCYUGfp5wDLt8U8uLpgMJuwSU%3D&reserved=0>
>>>> <https://www.google.com/maps/search/13101%0D%0A+Columbia+Pike+%C2%A0+%0D%0A+Silver%0D%0A+Spring,+MD?entry=gmail&source=g>
>>>> *Silver Spring, MD
>>>> <https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.google.com%2Fmaps%2Fsearch%2F13101%2BColumbia%2BPike%2B%250D%250A%2BSilver%2BSpring%2C%2BMD%3Fentry%3Dgmail%26source%3Dg&data=02%7C01%7Chuaimo.chen%40futurewei.com%7C60df274544ba4b75447f08d7fd947201%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637256686327693961&sdata=OQccpoFntfT0LMaEVNaWmGhkqFbTKJLWu4PIlTuKFoA%3D&reserved=0>
>>>>
>>>>
>>>>
>>>> <https://www.google.com/maps/search/13101%0D%0A+Columbia+Pike+%C2%A0+%0D%0A+Silver%0D%0A+Spring,+MD?entry=gmail&source=g>
>>>>
>>>> --
>>>>
>>>> *Error! Filename not specified.*
>>>> <https://nam11.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.verizon.com%2F&data=02%7C01%7Chuaimo.chen%40futurewei.com%7C60df274544ba4b75447f08d7fd947201%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637256686327693961&sdata=zKzhCcHJbUpzdvulN4y1N92e6KJKAEqHvdF5KDKJKH8%3D&reserved=0>
>>>>
>>>> *Gyan Mishra*
>>>>
>>>> *Network Solutions Architect *
>>>>
>>>>
>>>>
>>>> *M 301 502-1347 13101 Columbia Pike
>>>> <https://www.google.com/maps/search/13101+Columbia+Pike+%0D%0A+Silver+Spring,+MD?entry=gmail&source=g>
>>>> <https://www.google.com/maps/search/13101+Columbia+Pike+%C2%A0+%0D%0A+Silver+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>
>>>>
>>>> <https://www.google.com/maps/search/13101+Columbia+Pike+%0D%0A+Silver+Spring,+MD?entry=gmail&source=g>
>>>>
>>>>
>>>>
>>>> <https://www.google.com/maps/search/13101+Columbia+Pike+%C2%A0+%0D%0A+Silver+Spring,+MD?entry=gmail&source=g>
>>>>
>>>> --
>>>>
>>>> *Error! Filename not specified.* <http://www.verizon.com/>
>>>>
>>>> *Gyan Mishra*
>>>>
>>>> *Network Solutions Architect *
>>>>
>>>>
>>>>
>>>> *M 301 502-1347 13101 Columbia Pike
>>>> <https://www.google.com/maps/search/13101+Columbia+Pike+%0D%0A+Silver+Spring,+MD?entry=gmail&source=g>
>>>> <https://www.google.com/maps/search/13101+Columbia+Pike+%C2%A0+%0D%0A+Silver+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>
>>>>
>>>> <https://www.google.com/maps/search/13101+Columbia+Pike+%0D%0A+Silver+Spring,+MD?entry=gmail&source=g>
>>>>
>>>>
>>>>
>>>> <https://www.google.com/maps/search/13101+Columbia+Pike+%C2%A0+%0D%0A+Silver+Spring,+MD?entry=gmail&source=g>
>>>>
>>>> --
>>>>
>>>> [image: Image removed by sender.] <http://www.verizon.com/>
>>>>
>>>> *Gyan Mishra*
>>>>
>>>> *Network Solutions Architect *
>>>>
>>>>
>>>>
>>>> *M 301 502-1347 13101 Columbia Pike
>>>> <https://www.google.com/maps/search/13101+Columbia+Pike+%0D%0A+Silver+Spring,+MD?entry=gmail&source=g>
>>>> <https://www.google.com/maps/search/13101+Columbia+Pike+%C2%A0+%0D%0A+Silver+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>
>>>>
>>>> <https://www.google.com/maps/search/13101+Columbia+Pike+%0D%0A+Silver+Spring,+MD?entry=gmail&source=g>
>>>>
>>>>
>>>>
>>>> <https://www.google.com/maps/search/13101+Columbia+Pike+%C2%A0+%0D%0A+Silver+Spring,+MD?entry=gmail&source=g>
>>>>
>>> --
>>>
>>> <http://www.verizon.com/>
>>>
>>> *Gyan Mishra*
>>>
>>> *Network Solutions A**rchitect *
>>>
>>>
>>>
>>> *M 301 502-134713101 Columbia Pike
>>> <https://www.google.com/maps/search/13101+Columbia+Pike+%C2%A0+%0D%0A+Silver+Spring,+MD?entry=gmail&source=g> *Silver
>>> Spring, MD
>>> <https://www.google.com/maps/search/13101+Columbia+Pike+%C2%A0+%0D%0A+Silver+Spring,+MD?entry=gmail&source=g>
>>>
>>> --
>>
>> <http://www.verizon.com/>
>>
>> *Gyan Mishra*
>>
>> *Network Solutions A**rchitect *
>>
>>
>>
>> *M 301 502-134713101 Columbia Pike
>> <https://www.google.com/maps/search/13101+Columbia+Pike+%C2%A0+%0D%0A+Silver+Spring,+MD?entry=gmail&source=g> *Silver
>> Spring, MD
>> <https://www.google.com/maps/search/13101+Columbia+Pike+%C2%A0+%0D%0A+Silver+Spring,+MD?entry=gmail&source=g>
>>
>> _______________________________________________
>> Lsr mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/lsr
>>
> --

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

*Gyan Mishra*

*Network Solutions A**rchitect *



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