Re: [Idr] draft-wang-idr-vpn-prefix-orf-00.txt- Adoption call (2/4/2022 to 2/18/2022)

Hi, Jeffrey:
I think you have rich experiences for the implementation of BGP features and there certainly exists some points to be overcome during the process. And any vendor can utilize their knobs to achieve this. Should we give such detail solutions spaces for the vendors’ decision and selection?
The main advantages of VPN Prefixes ORF mechanism is that it abates the side effect of overwhelming information, and also gives clues to operator to find the root causes of the abnormal results.

Aijun Wang
China Telecom

> 在 2022年2月18日，22:31，Jeffrey Haas <jhaas@pfrc.org> 写道：
> 
> Gyan,
> 
> There's two distinct discussion points here: Can you keep counters on routes per-RD+per-VRF, and having access to such a counter would you use it for an ORF.
> 
> I can tell you such a per-RD+per-VRF counter, although annoying to write, is something that could go into my implementation.  Implementors aren't fond of these types of counters because unlike the per-table counters, you're having to do filter operations and key lookups on route properties to maintain the counters rather than just keeping track of total tree contents.  
> 
> This is thus a general case of overhead.  Do you want to pay for the memory of the counter and the cost of indexing into the counter?
> 
> Picking one abstract model, for any trackable item you can have a counter built on PATRICIA for the key.  In this case, it's per-RD, per VRF.  If you implementation keeps per VRF resources, it's then the slightly cheaper just per-RD in that VRF. (Other people have different implementations.)
> 
> You're now paying for a PATRICIA lookup every time you add or delete a route from your main RIB entry.  You pay this tax during RIB maintenance operations.
> 
> It's perhaps little surprise that implementors of highly scalable implementations of BGP are wary of doing extra cost operations during RIB maintenance.
> 
> It's important to note the above is an example, and not necessarily the required implementation.  If you have belief that there's smaller numbers of RD in the system, you might choose a different lookup - say a hash table, balanced tree, etc.  The important detail is you're choosing to pay a per-RIB operation overhead for the counter.
> 
> Having chosen to pay the cost, is an ORF helpful?
> 
> Locally, having the counter, you can choose to also locally do discard.  The resource exhaustion issue is mitigated without an ORF and extra protocol machinery.
> 
> The remaining tax is the adjacent BGP router sending you extra routes you're going to throw away.
> 
> The unwanted routes do indeed "clog up" your peering session to the PE, but presumably even though excessive, they're probably stable.  Counters don't help you unless "too much" is also "stable enough to be too much".  After all, this feature isn't trying to fix route thrash.  Installing an ORF will actually generate more route updates because the adjacent router will need to send withdraws for all routes impacted by the ORF.
> 
> Having entered this fault condition where you're throwing stuff away, what is operationally expected?  Presumably with or without ORF, someone gets on the phone to tell the NOC to fix the route leak.
> 
> After the leak is fixed, you'd clear the block.  Whether the routes are recovered by withdrawing the ORF or doing a route refresh, you're still asking the adjacent router to do work.  Where is work being saved on that adjacent router?  An ORF is more filtering overhead for that router that's now per-peer rather than amortized over any form of its per-group work.
> 
> -- Jeff
> 
> 
>> On Feb 11, 2022, at 11:52 AM, Gyan Mishra <hayabusagsm@gmail.com> wrote:
>> 
>> Robert 
>> 
>> As you mentioned in this thread about RD I am speaking of source RD, however as you mentioned there is not a back pointer to the source RD as once the VPNv4 prefix is imported the Source RD is overwritten by the Local RD.
>> 
>> So then filtering is not possible on Source RD.
>> 
>> That can be a valuable feature for operators.  
>> 
>> I know Cisco and Juniper have option to sort with a show command based on any RD so I would think the back pointer must be there for the source RD field but would have to be prior to the import. 
>> 
>> Cisco XR 
>> Pre import to VRF - Source RD intact 
>> Show BGP vpnv4 unicast RD x.x.x.x:x. 
>> 
>> Post import to VRF - Source RD is overwritten by local RD
>> Show BGP vpnv4 unicast VRF ABC 
>> 
>> So the post import to VRF data structure seems to have  the back pointer to the Any RD —> maybe it is possible to filter on any RD??
>> 
>> This is more of an implementation question but seems like the data is there from what I can tell.
>> 
>> Kind Regards 
>> 
>> Gyan
>> 
>>> On Fri, Feb 11, 2022 at 4:07 AM Robert Raszuk <robert@raszuk.net> wrote:
>>> Gyan,
>>> 
>>> > Gyan> no solution exists today to filter on RD automatically as all filtering is based on RT or prefix.
>>> 
>>> RD is part of the prefix. It is not a standalone entity. Everywhere where you can filter prefix you can also filter prefix /64 which is RD. 
>>> 
>>> Thx,
>>> R.
>>> 
>>> 
>>> 
>>> 
>>>> On Fri, Feb 11, 2022 at 1:27 AM Gyan Mishra <hayabusagsm@gmail.com> wrote:
>>>> 
>>>> Robert 
>>>> 
>>>>> On Thu, Feb 10, 2022 at 2:37 PM Robert Raszuk <robert@raszuk.net> wrote:
>>>>> Gyan,
>>>>> 
>>>>> > The Crux of issue is the flood of unwanted routes by a rogue PE sourcing the 
>>>>> > unwanted flooding of RT-2 or IP prefix flooding.
>>>>> 
>>>>> 
>>>>> If this statement is really true then crux of the issue has been recognized, worked on and addressed in early 2000s. 
>>>> 
>>>>     Gyan> Unwanted is bad choice of words -  as long as the route matches the RT it’s imported wanted 
>>>> - Agreed.  So it’s wanted routes explicitly imported that is an attack vector from a source PE for the VPN exactly what Aijun is describing.  
>>>>> 
>>>>> Only routes which are wanted get propagated in a properly designed network. 
>>>> 
>>>>     Gyan> Understood 
>>>>> 
>>>>> Hint: RFC4684
>>>>> 
>>>>> Now if you accept too many of VPN routes you can not treat them as unwanted.
>>>> 
>>>>> It is like you would be throwing away passengers in the middle of the flight just because plane is running out of fuel. You need to be careful during boarding process to accept only as much as you can carry. As simple as this. 
>>>> 
>>>>    Gyan> Understood.  It’s wanted routes explicitly imported that is an an attack vector on the VPN
>>>>> 
>>>>> If you however consider problem statement Aijun is describing it seems that PE or RR which noticed some attack vector within one VPN 
>>>> 
>>>> Gyan> That is the same problem statement I was describing 
>>>> 
>>>>> could immediately report this to the mgmt station which in turn should immediately shut down the eBGP session from the CE or CEs which originate such attack. 
>>>> 
>>>> Gyan> The solution with using ORF  is an automated filtering capability with RD granularity so we can detect the source PE where the attack vector originated. 
>>>> 
>>>>> No protocol extension needed at all and immediate action can be much more effective then just pushing some ORF to RRs. 
>>>> 
>>>> Gyan> no solution exists today to filter on RD automatically as all filtering is based on RT or prefix.
>>>>> 
>>>>> Thank you,
>>>>> R.
>>>>> 
>>>>>> On Thu, Feb 10, 2022 at 7:13 PM Gyan Mishra <hayabusagsm@gmail.com> wrote:
>>>>>> Jim
>>>>>> 
>>>>>> The draft focuses on both EVPN and IP VPN as in scope to the draft as Aijun mentioned.
>>>>>> 
>>>>>> What I was mentioning was the scenario with China Telecom and the other two providers related to their specific use case being EVPN related however this solution applies to both EVPN and IP VPN.  I believe they may had IP VPN issues as well as the issue as described below can be problematic and impact any operator.  This is not an operations or design issue.
>>>>>> 
>>>>>> The solution provides granularity to filter on the source PE flooding excessive routes which could be EVPN or IP VPN.  The PE does not have to be a weak PE and could be any PE with plenty of memory and CPU as well.  
>>>>>> 
>>>>>> The Crux of issue is the flood of unwanted routes by a rogue PE sourcing the unwanted flooding of RT-2 or IP prefix flooding.
>>>>>> 
>>>>>> **  If the PE-CE maximum prefix threshold and per VPN maximum prefix threshold gets hit due to the flood of routes now that impacts the legitimate valid RT-2 or IP prefixes.  As a result all customers could be impacted that are part of the VPN or MAC VRF. So that’s the major issue this draft is solving in trying to clamp down and squash the offending rogue PE**. I mentioned this before that if you set the maximum prefix high or to the maximum you might as well not set it as it’s not helpful in the prevention of flood of routes.   You can think of this like a DDOS attack by a rogue PE impacting all customers that are part of the VPN importing the RT. 
>>>>>> 
>>>>>> The issue with weak PE or PE being overwhelmed with the flood of routes as well is an issue and this draft addresses any of those possible scenarios.
>>>>>> 
>>>>>> 
>>>>>> I mentioned EVPN  RT-2 as you may have 1000s of MAC/IP routes depending on how flat your subnet is per RT-5 so the numbers go up pretty quickly and easy to flood.  Also with 
>>>>>> 
>>>>>> The issue is worse inter-as options b as all RTs have to be accepted with knob retain-rt-all on inter-as PE ASBR for option-b and RTs cannot be filtered on RR for option-c same issue for both EVPN and IP VPN.  
>>>>>> 
>>>>>> The draft discusses why existing mechanisms PE-CE maximum prefix and per VPN maximum prefix does not help this issue.  
>>>>>> 
>>>>>> Kind Regards 
>>>>>> 
>>>>>> Gyan
>>>>>> 
>>>>>>> On Thu, Feb 10, 2022 at 6:44 AM UTTARO, JAMES <ju1738@att.com> wrote:
>>>>>>> Gyan,
>>>>>>> 
>>>>>>>  
>>>>>>> 
>>>>>>>               So, the draft is targeted to a future where network services migrate to SRV6/EVPN, not a lack of functionality in the current set of tools for existing networks except in the case of China Mobile ( I would like to understand what is unique in this network that is driving this ask ). If that is the case then the draft should focus on the deficiencies of the current tool set for these FOUs. Not sure I get the statement in re RT-2 EVPN routes, is a distinction being made between these and let’s say RT-5? 
>>>>>>> 
>>>>>>>  
>>>>>>> 
>>>>>>> Thanks,
>>>>>>> 
>>>>>>>               Jim Uttaro
>>>>>>> 
>>>>>>>  
>>>>>>> 
>>>>>>> 
>>>>>>> From: Gyan Mishra <hayabusagsm@gmail.com> 
>>>>>>> Sent: Thursday, February 10, 2022 12:35 AM
>>>>>>> To: Aijun Wang <wangaijun@tsinghua.org.cn>
>>>>>>> Cc: Susan Hares <shares@ndzh.com>; UTTARO, JAMES <ju1738@att.com>; idr@ietf.org; lizhenqiang@chinamobile.com
>>>>>>> Subject: Re: [Idr] draft-wang-idr-vpn-prefix-orf-00.txt- Adoption call (2/4/2022 to 2/18/2022)
>>>>>>> 
>>>>>>>  
>>>>>>> 
>>>>>>> Hi Jim
>>>>>>> 
>>>>>>>  
>>>>>>> 
>>>>>>> I don’t think there are many SRv6 deployments worldwide and I believe China is one of the leaders on proliferation of IPV6 by operators  as well as now SRv6.
>>>>>>> 
>>>>>>>  
>>>>>>> 
>>>>>>> Most operators around the world have large IPv4 backbones and it will take time to migrate.
>>>>>>> 
>>>>>>>  
>>>>>>> 
>>>>>>> So as Aijun is stating as more operators deploy SRv6 / EVPN and have inter-as EVPN and  with SR-TE it makes it so easy stretch EVPNs so you end up with these cases.  
>>>>>>> 
>>>>>>>  
>>>>>>> 
>>>>>>> The issue I believe is with  EVPN Type 2 route flood inter-as and not IP VPN prefixes.
>>>>>>> 
>>>>>>>  
>>>>>>> 
>>>>>>> Aijun 
>>>>>>> 
>>>>>>>  
>>>>>>> 
>>>>>>> Is that correct ?
>>>>>>> 
>>>>>>>  
>>>>>>> 
>>>>>>> Kind Regards 
>>>>>>> 
>>>>>>>  
>>>>>>> 
>>>>>>> Gyan
>>>>>>> 
>>>>>>>  
>>>>>>> 
>>>>>>> On Wed, Feb 9, 2022 at 9:31 PM Aijun Wang <wangaijun@tsinghua.org.cn> wrote:
>>>>>>> 
>>>>>>> Hi, Jim:
>>>>>>> 
>>>>>>> Actually, draft https://datatracker.ietf.org/doc/html/draft-wang-idr-vpn-routes-control-analysis/ describes more possible scenarios for the potential VPN prefixes overflow.
>>>>>>> 
>>>>>>> With the trending/deployment of EVPN/SRv6 technologies, such problems will be emerged  inevitably because it is more easy to deploy the inter-AS VPN services.
>>>>>>> 
>>>>>>> Even for the intra-AS scenario, as that discussed in the current draft, it is possible for the misconfiguration, or misbehavior of PE; or the increase of VPN prefixes in one VRF crashes some PEs in the network and influences other existing VPN services on such PEs.
>>>>>>> 
>>>>>>>  
>>>>>>> 
>>>>>>> VPN Prefix ORF mechanism gives us the capabilities to isolate the problem per VRF, not per BGP session, or per PE.
>>>>>>> 
>>>>>>> For standard activity, we should look forward to the trend, not only focus on the current status/experiences.
>>>>>>> 
>>>>>>>  
>>>>>>> 
>>>>>>> And, there are at least three operators that have widespread networks have interested in the solution, I think it will also benefit your service deployment in future.
>>>>>>> 
>>>>>>>  
>>>>>>> 
>>>>>>> Best Regards
>>>>>>> 
>>>>>>>  
>>>>>>> 
>>>>>>> Aijun Wang
>>>>>>> 
>>>>>>> China Telecom
>>>>>>> 
>>>>>>>  
>>>>>>> 
>>>>>>> From: UTTARO, JAMES <ju1738@att.com> 
>>>>>>> Sent: Thursday, February 10, 2022 12:10 AM
>>>>>>> To: lizhenqiang@chinamobile.com; Aijun Wang <wangaijun@tsinghua.org.cn>
>>>>>>> Cc: Susan Hares <shares@ndzh.com>; idr@ietf.org
>>>>>>> Subject: RE: RE: [Idr] draft-wang-idr-vpn-prefix-orf-00.txt- Adoption call (2/4/2022 to 2/18/2022)
>>>>>>> 
>>>>>>>  
>>>>>>> 
>>>>>>> Comments In-Line
>>>>>>> 
>>>>>>>  
>>>>>>> 
>>>>>>> Thanks,
>>>>>>> 
>>>>>>>               Jim Uttaro
>>>>>>> 
>>>>>>>  
>>>>>>> 
>>>>>>> Here is the thread..
>>>>>>> 
>>>>>>>  
>>>>>>> 
>>>>>>> This draft is trying to solve problems existing in networks today.
>>>>>>> 
>>>>>>> [Jim U>] Have you canvassed operators? I would be interested in the “problems” that have been identified in networks today. Pls provide data and not conjecture.
>>>>>>> 
>>>>>>> [LZQ] Is what you said conjected? If not, I believe this is a real problem. And by the way, I am from China Mobile, an operator, I don't need to canvass other operators. 
>>>>>>> 
>>>>>>>  
>>>>>>> 
>>>>>>> I understood your first statement as indicating more than just the China Mobile Network. If this work is directed towards an industry wide problem than you should canvass to see if other operators require this specification.  You may be experiencing this problem on your network due to the architecture/design of your network. Feel free to reach out to others who do not seem to be experiencing your networks problem to better understand why this draft is unnecessary..
>>>>>>> 
>>>>>>>  
>>>>>>> 
>>>>>>>  
>>>>>>> 
>>>>>>>  
>>>>>>> 
>>>>>>> From: lizhenqiang@chinamobile.com <lizhenqiang@chinamobile.com> 
>>>>>>> Sent: Wednesday, February 9, 2022 10:37 AM
>>>>>>> To: UTTARO, JAMES <ju1738@att.com>; Aijun Wang <wangaijun@tsinghua.org.cn>
>>>>>>> Cc: Susan Hares <shares@ndzh.com>; idr@ietf.org
>>>>>>> Subject: Re: RE: [Idr] draft-wang-idr-vpn-prefix-orf-00.txt- Adoption call (2/4/2022 to 2/18/2022)
>>>>>>> 
>>>>>>>  
>>>>>>> 
>>>>>>> Comments in-line beginning with [LZQ]
>>>>>>> 
>>>>>>>  
>>>>>>> 
>>>>>>> Best Regards,
>>>>>>> 
>>>>>>> Zhenqiang Li
>>>>>>> 
>>>>>>> lizhenqiang@chinamobile.com
>>>>>>> 
>>>>>>>  
>>>>>>> 
>>>>>>> From: UTTARO, JAMES
>>>>>>> 
>>>>>>> Date: 2022-02-09 21:33
>>>>>>> 
>>>>>>> To: Aijun Wang
>>>>>>> 
>>>>>>> CC: lizhenqiang@chinamobile.com; Hares; idr@ietf.org
>>>>>>> 
>>>>>>> Subject: RE: [Idr] draft-wang-idr-vpn-prefix-orf-00.txt- Adoption call (2/4/2022 to 2/18/2022)
>>>>>>> 
>>>>>>> Comments In-Line
>>>>>>> 
>>>>>>>  
>>>>>>> 
>>>>>>> Thanks,
>>>>>>> 
>>>>>>>               Jim Uttaro
>>>>>>> 
>>>>>>>  
>>>>>>> 
>>>>>>> From: Aijun Wang <wangaijun@tsinghua.org.cn> 
>>>>>>> Sent: Wednesday, February 9, 2022 7:07 AM
>>>>>>> To: UTTARO, JAMES <ju1738@att.com>
>>>>>>> Cc: lizhenqiang@chinamobile.com; Hares <shares@ndzh.com>; idr@ietf.org
>>>>>>> Subject: Re: [Idr] draft-wang-idr-vpn-prefix-orf-00.txt- Adoption call (2/4/2022 to 2/18/2022)
>>>>>>> 
>>>>>>>  
>>>>>>> 
>>>>>>> Hi, Jim:
>>>>>>> 
>>>>>>> Currently, we depended only the “maximum prefixes limit” on the PE router, so when the VPN routes surpasses the threshold, the BGP sessions with the peer will be broken.
>>>>>>> 
>>>>>>> [Jim U>] Not true. Additional routing state will be throttled. There is a notification setting and a threshold setting. The only time this was encountered was when a customer mistakenly re-distributed the GRT into their VPN. They were actually quite appreciative of our notification as it helped them quickly isolate the problem and fix it.
>>>>>>> 
>>>>>>> [LZQ] Is what you said conjected? If not, I believe this is a real problem. And by the way, I am from China Mobile, an operator, I don't need to canvass other operators. 
>>>>>>> 
>>>>>>>  
>>>>>>> 
>>>>>>>  
>>>>>>> 
>>>>>>> It will influence all the VRFs that shares within the BGP sessions.
>>>>>>> 
>>>>>>> [Jim U>] What does this mean? Is this specific to Option B?
>>>>>>> 
>>>>>>> Haven’t you encountered such problems in your network?
>>>>>>> 
>>>>>>> [Jim U>] No. 
>>>>>>> 
>>>>>>> We are trying to find the better solution than the current tools.
>>>>>>> 
>>>>>>> [Jim U>] Not required.
>>>>>>> 
>>>>>>> Aijun Wang
>>>>>>> 
>>>>>>> China Telecom
>>>>>>> 
>>>>>>>  
>>>>>>> 
>>>>>>> 在 2022年2月9日，19:54，UTTARO, JAMES <ju1738@att.com> 写道：
>>>>>>> 
>>>>>>> 
>>>>>>> 
>>>>>>> Comments In-Line..
>>>>>>> 
>>>>>>>  
>>>>>>> 
>>>>>>> Thanks,
>>>>>>> 
>>>>>>>               Jim Uttaro
>>>>>>> 
>>>>>>>  
>>>>>>> 
>>>>>>> From: Idr <idr-bounces@ietf.org> On Behalf Of lizhenqiang@chinamobile.com
>>>>>>> Sent: Wednesday, February 9, 2022 5:13 AM
>>>>>>> To: Hares <shares@ndzh.com>; idr@ietf.org
>>>>>>> Subject: Re: [Idr] draft-wang-idr-vpn-prefix-orf-00.txt- Adoption call (2/4/2022 to 2/18/2022)
>>>>>>> 
>>>>>>>  
>>>>>>> 
>>>>>>> This draft is trying to solve problems existing in networks today.
>>>>>>> 
>>>>>>> [Jim U>] Have you canvassed operators? I would be interested in the “problems” that have been identified in networks today. Pls provide data and not conjecture.
>>>>>>> 
>>>>>>> For the solution, I think it is difficult for the receiving router to decide which PE should be blocked when its VRF routes reach a threshould. Why not block any PE sending routes to the overflowing VRF? 
>>>>>>> 
>>>>>>>  
>>>>>>> 
>>>>>>> Best Regards,
>>>>>>> 
>>>>>>> Zhenqiang Li
>>>>>>> 
>>>>>>>  
>>>>>>> 
>>>>>>> li_zhenqiang@hotmail.com
>>>>>>> 
>>>>>>>  
>>>>>>> 
>>>>>>> From: Susan Hares
>>>>>>> 
>>>>>>> Date: 2022-02-04 20:39
>>>>>>> 
>>>>>>> To: idr@ietf.org
>>>>>>> 
>>>>>>> Subject: [Idr] draft-wang-idr-vpn-prefix-orf-00.txt- Adoption call (2/4/2022 to 2/18/2022)
>>>>>>> 
>>>>>>> Resending the adoption call – with the appropriate header
>>>>>>> 
>>>>>>>  
>>>>>>> 
>>>>>>> From: Idr [mailto:idr-bounces@ietf.org] On Behalf Of Susan Hares
>>>>>>> Sent: Friday, February 4, 2022 7:33 AM
>>>>>>> To: idr@ietf.org
>>>>>>> Subject: [Idr] draft-wang-idr-vpn-prefix-orf-00.txt : (2/4/2022 to 2/18/2022)
>>>>>>> 
>>>>>>>  
>>>>>>> 
>>>>>>> This begins a 2 week WG adoption call  for
>>>>>>> 
>>>>>>> draft-wang-idr-vpn-prefix-orf-00.txt
>>>>>>> 
>>>>>>> https://datatracker.ietf.org/doc/draft-wang-idr-vpn-prefix-orf.
>>>>>>> 
>>>>>>>  
>>>>>>> 
>>>>>>> In your discussion on adoption, please consider the following questions:
>>>>>>> 
>>>>>>>  
>>>>>>> 
>>>>>>> 1) Does this draft describe problems existing in networks today?
>>>>>>> 
>>>>>>>  
>>>>>>> 
>>>>>>> 2) Does the solution describe address these problems?
>>>>>>> 
>>>>>>> The solution has both a general solution and BGP encodings.
>>>>>>> 
>>>>>>>  
>>>>>>> 
>>>>>>> 3) Would the solution be useful in networks today?
>>>>>>> 
>>>>>>>  
>>>>>>> 
>>>>>>> Thank you, Susan Hares
>>>>>>> 
>>>>>>> _______________________________________________
>>>>>>> Idr mailing list
>>>>>>> Idr@ietf.org
>>>>>>> https://www.ietf.org/mailman/listinfo/idr
>>>>>>> 
>>>>>>> _______________________________________________
>>>>>>> Idr mailing list
>>>>>>> Idr@ietf.org
>>>>>>> https://www.ietf.org/mailman/listinfo/idr
>>>>>>> 
>>>>>>> -- 
>>>>>>> 
>>>>>>> 
>>>>>>> 
>>>>>>> Gyan Mishra
>>>>>>> Network Solutions Architect 
>>>>>>> Email gyan.s.mishra@verizon.com
>>>>>>> M 301 502-1347
>>>>>>> 
>>>>>>>  
>>>>>>> 
>>>>>> -- 
>>>>>> 
>>>>>> 
>>>>>> Gyan Mishra
>>>>>> Network Solutions Architect 
>>>>>> Email gyan.s.mishra@verizon.com
>>>>>> M 301 502-1347
>>>>>> 
>>>>>> 
>>>>>> _______________________________________________
>>>>>> Idr mailing list
>>>>>> Idr@ietf.org
>>>>>> https://www.ietf.org/mailman/listinfo/idr
>>>> -- 
>>>> 
>>>> 
>>>> Gyan Mishra
>>>> Network Solutions Architect 
>>>> Email gyan.s.mishra@verizon.com
>>>> M 301 502-1347
>>>> 
>>>> 
>> -- 
>> 
>> 
>> Gyan Mishra
>> Network Solutions Architect 
>> Email gyan.s.mishra@verizon.com
>> M 301 502-1347
>> 
>> 
>> _______________________________________________
>> Idr mailing list
>> Idr@ietf.org
>> https://www.ietf.org/mailman/listinfo/idr
> 
> _______________________________________________
> Idr mailing list
> Idr@ietf.org
> https://www.ietf.org/mailman/listinfo/idr