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 <hayabusa...@gmail.com> wrote: > > I see the diagrams Appendix A - reviewing > > Thanks > > Gyan > > On Thu, May 21, 2020 at 10:13 PM Gyan Mishra <hayabusa...@gmail.com> > 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) <a...@cisco.com> >> wrote: >> >>> Hi Gyan, >>> >>> >>> >>> *From: *Gyan Mishra <hayabusa...@gmail.com> >>> *Date: *Thursday, May 21, 2020 at 4:20 PM >>> *To: *Acee Lindem <a...@cisco.com> >>> *Cc: *Huaimo Chen <huaimo.c...@futurewei.com>, "lsr@ietf.org" < >>> lsr@ietf.org> >>> *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) <a...@cisco.com> >>> 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 <hayabusa...@gmail.com> >>> *Date: *Thursday, May 21, 2020 at 1:51 PM >>> *To: *Huaimo Chen <huaimo.c...@futurewei.com> >>> *Cc: *Acee Lindem <a...@cisco.com>, "lsr@ietf.org" <lsr@ietf.org> >>> *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 <huaimo.c...@futurewei.com> >>> 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 <hayabusa...@gmail.com> >>> *Sent:* Thursday, May 21, 2020 10:36 AM >>> >>> >>> *To:* Huaimo Chen <huaimo.c...@futurewei.com> >>> *Cc:* Acee Lindem (acee) <acee=40cisco....@dmarc.ietf.org>; lsr@ietf.org >>> <lsr@ietf.org> >>> *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 <huaimo.c...@futurewei.com> >>> wrote: >>> >>> Hi Gyan, >>> >>> >>> >>> Thanks much for your questions. My answers are inline below with >>> [HC]. >>> >>> >>> >>> Best Regards, >>> >>> Huaimo >>> ------------------------------ >>> >>> *From:* Gyan Mishra <hayabusa...@gmail.com> >>> *Sent:* Wednesday, May 20, 2020 11:14 AM >>> *To:* Huaimo Chen <huaimo.c...@futurewei.com> >>> *Cc:* Acee Lindem (acee) <acee=40cisco....@dmarc.ietf.org>; lsr@ietf.org >>> <lsr@ietf.org> >>> *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 <huaimo.c...@futurewei.com> >>> 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 <lsr-boun...@ietf.org> on behalf of Gyan Mishra < >>> hayabusa...@gmail.com> >>> *Sent:* Tuesday, May 19, 2020 2:39 AM >>> *To:* Yanhe Fan <y...@casa-systems.com> >>> *Cc:* lsr@ietf.org <lsr@ietf.org>; Acee Lindem (acee) <acee= >>> 40cisco....@dmarc.ietf.org> >>> *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 <y...@casa-systems.com> wrote: >>> >>> Support it as a co-author. >>> >>> >>> >>> Thanks, >>> >>> Yanhe >>> >>> >>> >>> *From:* Lsr <lsr-boun...@ietf.org> *On Behalf Of *Acee Lindem (acee) >>> *Sent:* Friday, May 15, 2020 3:40 PM >>> *To:* lsr@ietf.org >>> *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 >>> Lsr@ietf.org >>> 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> >>> *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> >>> >>> >>> >>> -- >>> >>> *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> >>> *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> >>> >>> >>> >>> -- >>> >>> *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> >>> *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> >>> >>> >>> >>> -- >>> >>> *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> >>> *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> >>> >>> >>> >>> -- >>> >>> [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> >>> *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> >>> >>> >>> >> -- >> >> <http://www.verizon.com/> >> >> *Gyan Mishra* >> >> *Network Solutions A**rchitect * >> >> >> >> *M 301 502-134713101 Columbia Pike *Silver Spring, MD >> >> -- > > <http://www.verizon.com/> > > *Gyan Mishra* > > *Network Solutions A**rchitect * > > > > *M 301 502-134713101 Columbia Pike *Silver Spring, MD > > _______________________________________________ > Lsr mailing list > Lsr@ietf.org > https://www.ietf.org/mailman/listinfo/lsr >
_______________________________________________ Lsr mailing list Lsr@ietf.org https://www.ietf.org/mailman/listinfo/lsr
