I see the diagrams Appendix A - reviewing Thanks
Gyan On Thu, May 21, 2020 at 10:13 PM Gyan Mishra <[email protected]> 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) <[email protected]> wrote: > >> Hi Gyan, >> >> >> >> *From: *Gyan Mishra <[email protected]> >> *Date: *Thursday, May 21, 2020 at 4:20 PM >> *To: *Acee Lindem <[email protected]> >> *Cc: *Huaimo Chen <[email protected]>, "[email protected]" < >> [email protected]> >> *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) <[email protected]> >> 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 <[email protected]> >> *Date: *Thursday, May 21, 2020 at 1:51 PM >> *To: *Huaimo Chen <[email protected]> >> *Cc: *Acee Lindem <[email protected]>, "[email protected]" <[email protected]> >> *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 <[email protected]> >> 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 <[email protected]> >> *Sent:* Thursday, May 21, 2020 10:36 AM >> >> >> *To:* Huaimo Chen <[email protected]> >> *Cc:* Acee Lindem (acee) <[email protected]>; [email protected] >> <[email protected]> >> *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 <[email protected]> >> wrote: >> >> Hi Gyan, >> >> >> >> Thanks much for your questions. My answers are inline below with [HC]. >> >> >> >> Best Regards, >> >> Huaimo >> ------------------------------ >> >> *From:* Gyan Mishra <[email protected]> >> *Sent:* Wednesday, May 20, 2020 11:14 AM >> *To:* Huaimo Chen <[email protected]> >> *Cc:* Acee Lindem (acee) <[email protected]>; [email protected] >> <[email protected]> >> *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 <[email protected]> >> 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 <[email protected]> on behalf of Gyan Mishra < >> [email protected]> >> *Sent:* Tuesday, May 19, 2020 2:39 AM >> *To:* Yanhe Fan <[email protected]> >> *Cc:* [email protected] <[email protected]>; Acee Lindem (acee) <acee= >> [email protected]> >> *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 <[email protected]> wrote: >> >> Support it as a co-author. >> >> >> >> Thanks, >> >> Yanhe >> >> >> >> *From:* Lsr <[email protected]> *On Behalf Of *Acee Lindem (acee) >> *Sent:* Friday, May 15, 2020 3:40 PM >> *To:* [email protected] >> *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 >> [email protected] >> 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 [email protected] https://www.ietf.org/mailman/listinfo/lsr
