Re: [v6ops] [E] Re: How New Version of draft-ietf-v6ops-nd-considerations-01.txt can help discussion of other drafts

[Xipengxiao <[e-mail]>]

Hi Brian, Gyan,

Thank you for the review and suggestions.  Let me first address Brian’s concern:


>> How does an enterprise operator know whether their network is subject to the issues described in the draft? We know the two extremes (a small office network can probably ignore all of this, and a large campus WiFi with BYOD access probably needs to worry about all of it). But an individual network designer, even with the careful presentation in this draft, has to decide which issues to worry about, if any, before considering a solution.



Because this draft points out that the 15 issues are triggered by just 3 causes (multicast, trusting all hosts, NCE on demand), it becomes much easier for a deployer to decide which issues are relevant – he only needs to examine which of the 3 causes are relevant.  For example, if all hosts can be trusted in his scenario, he needs not worry about the 5 issues related to that.  To make this even clearer, I will add the following text in Section 2.4:


It is worth noting that these are just potential issues. Depending on the usage scenarios, they may not actually happen. More specifically:

·        Performance issues caused by multicast only happens in large L2 networks. If one’s usage scenario is not a large L2 network, these issues will not happen.

·        Reliability issues caused by multicast only happens in wireless networks. If one’s usage scenario is not a wireless network, these issues will not happen.

·        On-link security issues caused by trusting all hosts will not happen if hosts can be trusted in one’s usage scenario.

·        Off-link attack and other issues caused by NCE-on-Demand will not happen if one already deployed an ND-optimized solution that no longer installs NCE on Demand, e.g. MBBv6 or GRAND. Otherwise, the issues can happen.

>> I'm not sure how to resolve this, but I am a bit concerned that the document could have a "freezing" effect on IPv6 deployment unless we can give such guidance.



I can understand this concern: whenever we talk about issues, people can feel nervous.  But I want to point out 2 things:

  1.  This draft already makes it easier for people to understand which issues are relevant to them, and what solutions to deal with the issues
  2.  Any IPv6 deployer will definitely do his homework to find out what issues he may encounter before he starts.  Without this draft, he would find the issues & solutions in ~30 RFCs. With this draft, he find them in one (plus some more insights like only 3 causes and isolating hosts can help).  So this draft makes his homework-doing much easier.  Yes this draft can make an IPv6 novice who are not aware of the ~30 RFCs nervous, but I would argue that they are not the people we need to worry about as they are not the do-ers.  So overall, this draft should have a positive effect for IPv6 rather than a negative effect.

Your other comments are related to advocating IPv6.  While I think it’s the right thing, I am not sure this draft should take that burden – it’s too big a task.  But I will discuss with you privately what to do for that.  My preference is to update the ISOC IPv6 portal https://www.internetsociety.org/deploy360/ipv6/ (ISOC recently agreed to update the documents that were written in 2012-2015) and persuade ISOC to take new actions – ISOC is more powerful than any of us.  If anybody is willing to join this effort in working with ISOC please let me know.

Thanks again,

XiPeng

From: v6ops <[e-mail]> On Behalf Of Gyan Mishra
Sent: Sunday, May 7, 2023 1:30 AM
To: Brian E Carpenter <[e-mail]>
Cc: IPv6 Ops WG <[e-mail]>; Mishra, Gyan S <[e-mail]>
Subject: Re: [v6ops] [E] Re: How New Version of draft-ietf-v6ops-nd-considerations-01.txt can help discussion of other drafts


From a quick google search here is nice blog on wireless segmentation options and how it works using Cisco’s proprietary PVLAN concept and identity based networking and mix of some other ideas.  Can be applicable to IPv6 ND.

http://revolutionwifi.blogspot.com/2011/01/wireless-network-segmentation-options.html?m=1#:~:text=Wireless%20Network%20Segmentation%20Requirements&text=Traditionally%2C%20wireless%20network%20segmentation%20has,as%20a%20firewall%20or%20router.



On Sat, May 6, 2023 at 6:07 PM Brian E Carpenter <[e-mail]<mailto:[e-mail]>> wrote:
One other case might be worth giving as an example. I just spent a few days in a hotel, and it reminded me that most hotels now apply room-by-room WiFi isolation. Of course they usually don't provide IPv6 at all, but at least they are set up for isolation already. (Not sure what they do in public areas, but the IETF meetings team must be fully up to date on this topic.)

(It would be a great leap forward if we could persuade the solution providers for hotels to enable IPv6 as standard.)

Regards
    Brian

On 06-May-23 17:31, Mishra, Gyan S wrote:
>
> Hi Brian
>
> Good point.  As you mentioned SOHO or Campus WIFi can avoid all problems and the main focus of the draft is FBB, MBB and Enterprise networks.
>
> I think we could add a ND deployment considerations section to help operators and in there we could have a table that categorizes the issues in section 2 as to which are the ones to focus on by the different use cases you mentioned honing in on the main issue map to the particular use case.
>
> Hi Xipeng
>
>  From Brian’s really good point as we are biased here and want to advocate for IPv6 deployment and proliferation we want to maybe have that twist in the draft that we consciously in the back of our minds we want to help and not make it more difficult for operators deploying IPv6 and wherever possible can throw in a benefit of IPv6 over IPv4 where applicable so this draft can really pave the way for operators stuck in the mud trying to decide, and now we can push them over the fence to deploy IPv6.
>
> ..here is a good example..
>
> In section 2.1 you may want to mention one of the major advantages in a L2 environment with IPv6 as compare to IPv4 is that IPv4 has the concept of all Fs broadcast and unknown unicast  which is also broadcast flooded out all switch ports where with IPv6 the concept of broadcast does not exist and so all typical IPv4 broadcast and unknown unicast is done via multicast constraint of traffic to only interesting ports and not blindly flooding out all ports as done with IPv4 ARP broadcast which can lead to meltdowns from ARP storms.  So that is eliminated and constrained to multicast but requires all L2 switches to have mld snooping enabled globally and if not enabled the IPv6 multicast traffic still gets broadcasted out.
>
> Most WIFI vendors Aruba, Cisco, Juniper have a workaround that they are able to keep the upstream join IIL as multicast but can convert all the OIL downstream MLDv2 requests to Unicast and so you still conserve bandwidth as the incoming stream is a single multicast steam, however the OIL downstream joins are all converted to unicast so then you don’t have the performance hit with lowest common denominator for multicast issue.  So this can apply to ND optimization for multicast.
>
> Section 2.2
>
> So in public networks like airport or coffee spot hotspots you are using WIFI and not LAN connections and so in those cases use secure WIFI and not open unsecured WIFI.
>
> For enterprise LAN using 802.1x for port level access security.  That can prevent attack vector since now everyone has to authenticate like you do with secured WIFI to get on the network.
>
> 2.3 For DC Space NVO VXLAN and GENEVE maybe mention proxy ARP and proxy ND  ARP / ND suppression feature which saves on the state info being flooded in evpn control plane for every flow it’s only for the first packet and then all subsequent flows to same egress we generate suppression cache entry.  In what I described here it saves on ND queuing and flood within the domain but the remote mac are all still learned in the control plane.  This is different then section 3.5 SARP which is traditional non NVO DC.
>
> Thanks
>
> Gyan
>
> On Fri, May 5, 2023 at 7:48 PM Brian E Carpenter <[e-mail]<mailto:[e-mail]> <mailto:[e-mail]<mailto:[e-mail]>>> wrote:
>
>     Hi XiPeng,
>
>     One question I have arises from this remark:
>
>      > If someone is to deploy IPv6, especially in an enterprise (i.e. IPv6 1st-hop), going through this draft to find out what ND issues one may encounter
>
>     How does an enterprise operator know whether their network is subject to the issues described in the draft? We know the two extremes (a small office network can probably ignore all of this, and a large campus WiFi with BYOD access probably needs to worry about all of it). But an individual network designer, even with the careful presentation in this draft, has to decide which issues to worry about, if any, before considering a solution.
>
>     I'm not sure how to resolve this, but I am a bit concerned that the document could have a "freezing" effect on IPv6 deployment unless we can give such guidance.
>
>     Regards
>          Brian Carpenter
>
>     On 29-Apr-23 10:14, Xipengxiao wrote:
>      > Hi folks,
>      >
>      > We just released a new version of draft-ietf-v6ops-nd-considerations. The main changes are:
>      >
>      > •New title: Selectively Isolating Hosts to Prevent Potential Neighbor Discovery Protocol Issues
>      >
>      > •Add a New Section: 4.3. Applicability of Subnet Isolation with Shared Medium
>      >
>      > •Tidy-up Section 4
>      >
>      > So far, this draft gets little attention and review.  We think it’s because this draft is like a “ND issues and solutions manual”.  When you are not doing THAT thing, reading a manual can be boring, especially because the draft gets into a fair amount of details about ND issues and solutions.  So we would like to highlight the value of this draft and call for more reviews:
>      >
>      >  1. It summarized various ND issues and solutions from 30+ RFCs into a 1-stop reference;
>      >  2. It’s the first draft to point out that the 15 ND issues are triggered by just 3 causes.  This makes future protocol solution or operations solution much easier – it’s easier and more effective to handle 3 causes than 15 individual issues;
>      >  3. This draft tabulates the solutions for each issue, and the applicability of the commonly used solutions. This can be handy for future draft discussion.  For example, lately draft-collink receives a lot of discussions.  This draft can help draft-collink’s development & discussion in the following ways:
>      >      1. The problem that draft-collink is trying to solve, a host has more IPv6 addresses than the NCEs its router keeps -> packet loss, is essentially a “NCE exhaustion” issue described in our draft.  From the “issue-solution” table (Table 1) you can quickly find that among the solutions for this issue, Unique Prefix Per Host is one of the most suitable for this situation.  Draft-collink is indeed a flavor of Unique Prefix Per Host;
>      >      2. Several people on the mailing list are concerned that the draft-collink solution has limitations, and want the co-authors to point out where the solutions are applicable and where it is not.  Several people have pointed out some limitations.  But all are done in an ad-hoc way (i.e. you think about it, you may find some limitations, but you may also miss some limitations).  In comparison, our draft already has systematic coverage of the advantages, disadvantages and applicability of Unique Prefix Per Host.  Reading and referencing our draft can save the community time in discussing draft-collink and future drafts.  We acknowledge that our draft may not be 100% complete either, but we argue that reviewing and completing it is a good investment, because the community will save time in future ND-related draft discussion.
>      >  4. If someone is to deploy IPv6, especially in an enterprise (i.e. IPv6 1^st -hop), going through this draft to find out what ND issues one may encounter and follow the guidelines to pick a suitable solution can save him/her a lot of time than doing his/her own study.
>      >
>      > Thank you very much if you read to this point.  We hope you can review this draft to further improve it. We believe it’s a good investment for the WG.
>      >
>      > XiPeng & the co-authors
>      >
>      > -----Original Message-----
>      > From: [e-mail]<mailto:[e-mail]> <mailto:[e-mail]<mailto:[e-mail]>> <[e-mail]<mailto:[e-mail]> <mailto:[e-mail]<mailto:[e-mail]>>>
>      > Sent: Thursday, April 27, 2023 10:09 AM
>      > To: Vasilenko Eduard <[e-mail]<mailto:[e-mail]> <mailto:[e-mail]<mailto:[e-mail]>>>; Eduard Metz <[e-mail]<mailto:[e-mail]> <mailto:[e-mail]<mailto:[e-mail]>>>; Vasilenko Eduard <[e-mail]<mailto:[e-mail]> <mailto:[e-mail]<mailto:[e-mail]>>>; Gyan Mishra <[e-mail]<mailto:[e-mail]> <mailto:[e-mail]<mailto:[e-mail]>>>; Nick Buraglio <[e-mail]<mailto:[e-mail]> <mailto:[e-mail]<mailto:[e-mail]>>>; Xipengxiao <[e-mail]<mailto:[e-mail]> <mailto:[e-mail]<mailto:[e-mail]>>>
>      > Subject: New Version Notification for draft-ietf-v6ops-nd-considerations-01.txt
>      >
>      > A new version of I-D, draft-ietf-v6ops-nd-considerations-01.txt
>      >
>      > has been successfully submitted by XiPeng Xiao and posted to the IETF repository.
>      >
>      > Name:                       draft-ietf-v6ops-nd-considerations
>      >
>      > Revision:       01
>      >
>      > Title:              Selectively Isolating Hosts to Prevent Potential Neighbor Discovery Protocol Issues
>      >
>      > Document date:     2023-04-27
>      >
>      > Group:                       v6ops
>      >
>      > Pages:                        31
>      >
>      > URL: https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_archive_id_draft-2Dietf-2Dv6ops-2Dnd-2Dconsiderations-2D01.txt&d=DwIGaQ&c=udBTRvFvXC5Dhqg7UHpJlPps3mZ3LRxpb6__0PomBTQ&r=DnUkF34wu4mqq0UY8nn2rxBBO7qOW_D-RfNVLML28ZU&m=iotgBWTCFFWPOK6Psd06xuO4j8mIPUNqVXdxxCKgyjj2hisgbVsfmGvN6UBO4Opm&s=Ywtd7saGyuAHA43gP6EMvGuKaldKelZBDgRlHkXGN8E&e= <https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_archive_id_draft-2Dietf-2Dv6ops-2Dnd-2Dconsiderations-2D01.txt&d=DwIGaQ&c=udBTRvFvXC5Dhqg7UHpJlPps3mZ3LRxpb6__0PomBTQ&r=DnUkF34wu4mqq0UY8nn2rxBBO7qOW_D-RfNVLML28ZU&m=iotgBWTCFFWPOK6Psd06xuO4j8mIPUNqVXdxxCKgyjj2hisgbVsfmGvN6UBO4Opm&s=Ywtd7saGyuAHA43gP6EMvGuKaldKelZBDgRlHkXGN8E&e=>
>     <https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_archive_id_draft-2Dietf-2Dv6ops-2Dnd-2Dconsiderations-2D01.txt&d=DwIGaQ&c=udBTRvFvXC5Dhqg7UHpJlPps3mZ3LRxpb6__0PomBTQ&r=DnUkF34wu4mqq0UY8nn2rxBBO7qOW_D-RfNVLML28ZU&m=iotgBWTCFFWPOK6Psd06xuO4j8mIPUNqVXdxxCKgyjj2hisgbVsfmGvN6UBO4Opm&s=Ywtd7saGyuAHA43gP6EMvGuKaldKelZBDgRlHkXGN8E&e= <https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_archive_id_draft-2Dietf-2Dv6ops-2Dnd-2Dconsiderations-2D01.txt&d=DwIGaQ&c=udBTRvFvXC5Dhqg7UHpJlPps3mZ3LRxpb6__0PomBTQ&r=DnUkF34wu4mqq0UY8nn2rxBBO7qOW_D-RfNVLML28ZU&m=iotgBWTCFFWPOK6Psd06xuO4j8mIPUNqVXdxxCKgyjj2hisgbVsfmGvN6UBO4Opm&s=Ywtd7saGyuAHA43gP6EMvGuKaldKelZBDgRlHkXGN8E&e=> >
>      >
>      > Status: https://urldefense.proofpoint.com/v2/url?u=https-3A__datatracker.ietf.org_doc_draft-2Dietf-2Dv6ops-2Dnd-2Dconsiderations_&d=DwIGaQ&c=udBTRvFvXC5Dhqg7UHpJlPps3mZ3LRxpb6__0PomBTQ&r=DnUkF34wu4mqq0UY8nn2rxBBO7qOW_D-RfNVLML28ZU&m=iotgBWTCFFWPOK6Psd06xuO4j8mIPUNqVXdxxCKgyjj2hisgbVsfmGvN6UBO4Opm&s=ZsaoEH8o-7cZunTY45Q_50uy_e5msk0sfTsndGiyQFY&e= <https://urldefense.proofpoint.com/v2/url?u=https-3A__datatracker.ietf.org_doc_draft-2Dietf-2Dv6ops-2Dnd-2Dconsiderations_&d=DwIGaQ&c=udBTRvFvXC5Dhqg7UHpJlPps3mZ3LRxpb6__0PomBTQ&r=DnUkF34wu4mqq0UY8nn2rxBBO7qOW_D-RfNVLML28ZU&m=iotgBWTCFFWPOK6Psd06xuO4j8mIPUNqVXdxxCKgyjj2hisgbVsfmGvN6UBO4Opm&s=ZsaoEH8o-7cZunTY45Q_50uy_e5msk0sfTsndGiyQFY&e=>
>     <https://urldefense.proofpoint.com/v2/url?u=https-3A__datatracker.ietf.org_doc_draft-2Dietf-2Dv6ops-2Dnd-2Dconsiderations_&d=DwIGaQ&c=udBTRvFvXC5Dhqg7UHpJlPps3mZ3LRxpb6__0PomBTQ&r=DnUkF34wu4mqq0UY8nn2rxBBO7qOW_D-RfNVLML28ZU&m=iotgBWTCFFWPOK6Psd06xuO4j8mIPUNqVXdxxCKgyjj2hisgbVsfmGvN6UBO4Opm&s=ZsaoEH8o-7cZunTY45Q_50uy_e5msk0sfTsndGiyQFY&e= <https://urldefense.proofpoint.com/v2/url?u=https-3A__datatracker.ietf.org_doc_draft-2Dietf-2Dv6ops-2Dnd-2Dconsiderations_&d=DwIGaQ&c=udBTRvFvXC5Dhqg7UHpJlPps3mZ3LRxpb6__0PomBTQ&r=DnUkF34wu4mqq0UY8nn2rxBBO7qOW_D-RfNVLML28ZU&m=iotgBWTCFFWPOK6Psd06xuO4j8mIPUNqVXdxxCKgyjj2hisgbVsfmGvN6UBO4Opm&s=ZsaoEH8o-7cZunTY45Q_50uy_e5msk0sfTsndGiyQFY&e=> >
>      >
>      > Htmlized: https://urldefense.proofpoint.com/v2/url?u=https-3A__datatracker.ietf.org_doc_html_draft-2Dietf-2Dv6ops-2Dnd-2Dconsiderations&d=DwIGaQ&c=udBTRvFvXC5Dhqg7UHpJlPps3mZ3LRxpb6__0PomBTQ&r=DnUkF34wu4mqq0UY8nn2rxBBO7qOW_D-RfNVLML28ZU&m=iotgBWTCFFWPOK6Psd06xuO4j8mIPUNqVXdxxCKgyjj2hisgbVsfmGvN6UBO4Opm&s=uG6rb_NKBRlKWU1hAPQLlV-_7C1lA6FdQpN4UN1nzrI&e= <https://urldefense.proofpoint.com/v2/url?u=https-3A__datatracker.ietf.org_doc_html_draft-2Dietf-2Dv6ops-2Dnd-2Dconsiderations&d=DwIGaQ&c=udBTRvFvXC5Dhqg7UHpJlPps3mZ3LRxpb6__0PomBTQ&r=DnUkF34wu4mqq0UY8nn2rxBBO7qOW_D-RfNVLML28ZU&m=iotgBWTCFFWPOK6Psd06xuO4j8mIPUNqVXdxxCKgyjj2hisgbVsfmGvN6UBO4Opm&s=uG6rb_NKBRlKWU1hAPQLlV-_7C1lA6FdQpN4UN1nzrI&e=>
>     <https://urldefense.proofpoint.com/v2/url?u=https-3A__datatracker.ietf.org_doc_html_draft-2Dietf-2Dv6ops-2Dnd-2Dconsiderations&d=DwIGaQ&c=udBTRvFvXC5Dhqg7UHpJlPps3mZ3LRxpb6__0PomBTQ&r=DnUkF34wu4mqq0UY8nn2rxBBO7qOW_D-RfNVLML28ZU&m=iotgBWTCFFWPOK6Psd06xuO4j8mIPUNqVXdxxCKgyjj2hisgbVsfmGvN6UBO4Opm&s=uG6rb_NKBRlKWU1hAPQLlV-_7C1lA6FdQpN4UN1nzrI&e= <https://urldefense.proofpoint.com/v2/url?u=https-3A__datatracker.ietf.org_doc_html_draft-2Dietf-2Dv6ops-2Dnd-2Dconsiderations&d=DwIGaQ&c=udBTRvFvXC5Dhqg7UHpJlPps3mZ3LRxpb6__0PomBTQ&r=DnUkF34wu4mqq0UY8nn2rxBBO7qOW_D-RfNVLML28ZU&m=iotgBWTCFFWPOK6Psd06xuO4j8mIPUNqVXdxxCKgyjj2hisgbVsfmGvN6UBO4Opm&s=uG6rb_NKBRlKWU1hAPQLlV-_7C1lA6FdQpN4UN1nzrI&e=> >
>      >
>      > Diff: https://urldefense.proofpoint.com/v2/url?u=https-3A__author-2Dtools.ietf.org_iddiff-3Furl2-3Ddraft-2Dietf-2Dv6ops-2Dnd-2Dconsiderations-2D01&d=DwIGaQ&c=udBTRvFvXC5Dhqg7UHpJlPps3mZ3LRxpb6__0PomBTQ&r=DnUkF34wu4mqq0UY8nn2rxBBO7qOW_D-RfNVLML28ZU&m=iotgBWTCFFWPOK6Psd06xuO4j8mIPUNqVXdxxCKgyjj2hisgbVsfmGvN6UBO4Opm&s=ePNyyGsiu9RxWfHKJQOxA01TC3YiKdGtlhoidp3WlhA&e= <https://urldefense.proofpoint.com/v2/url?u=https-3A__author-2Dtools.ietf.org_iddiff-3Furl2-3Ddraft-2Dietf-2Dv6ops-2Dnd-2Dconsiderations-2D01&d=DwIGaQ&c=udBTRvFvXC5Dhqg7UHpJlPps3mZ3LRxpb6__0PomBTQ&r=DnUkF34wu4mqq0UY8nn2rxBBO7qOW_D-RfNVLML28ZU&m=iotgBWTCFFWPOK6Psd06xuO4j8mIPUNqVXdxxCKgyjj2hisgbVsfmGvN6UBO4Opm&s=ePNyyGsiu9RxWfHKJQOxA01TC3YiKdGtlhoidp3WlhA&e=>
>     <https://urldefense.proofpoint.com/v2/url?u=https-3A__author-2Dtools.ietf.org_iddiff-3Furl2-3Ddraft-2Dietf-2Dv6ops-2Dnd-2Dconsiderations-2D01&d=DwIGaQ&c=udBTRvFvXC5Dhqg7UHpJlPps3mZ3LRxpb6__0PomBTQ&r=DnUkF34wu4mqq0UY8nn2rxBBO7qOW_D-RfNVLML28ZU&m=iotgBWTCFFWPOK6Psd06xuO4j8mIPUNqVXdxxCKgyjj2hisgbVsfmGvN6UBO4Opm&s=ePNyyGsiu9RxWfHKJQOxA01TC3YiKdGtlhoidp3WlhA&e= <https://urldefense.proofpoint.com/v2/url?u=https-3A__author-2Dtools.ietf.org_iddiff-3Furl2-3Ddraft-2Dietf-2Dv6ops-2Dnd-2Dconsiderations-2D01&d=DwIGaQ&c=udBTRvFvXC5Dhqg7UHpJlPps3mZ3LRxpb6__0PomBTQ&r=DnUkF34wu4mqq0UY8nn2rxBBO7qOW_D-RfNVLML28ZU&m=iotgBWTCFFWPOK6Psd06xuO4j8mIPUNqVXdxxCKgyjj2hisgbVsfmGvN6UBO4Opm&s=ePNyyGsiu9RxWfHKJQOxA01TC3YiKdGtlhoidp3WlhA&e=> >
>      >
>      > Abstract:
>      >
>      >     Neighbor Discovery (ND) is a key protocol of IPv6 first-hop. ND uses
>      >
>      >     multicast extensively and trusts all hosts. In some scenarios like
>      >
>      >     wireless networks, multicast can be inefficient. In other scenarios
>      >
>      >     like public access networks, hosts may not be trustable.
>      >
>      >     Consequently, ND has potential issues in various scenarios. The
>      >
>      >     issues and the solutions for them are documented in more than 30
>      >
>      >     RFCs. It is difficult to keep track of all these issues and
>      >
>      >     solutions. Therefore, an overview and some guidelines are useful.
>      >
>      >     This document firstly summarizes the known ND issues and
>      >
>      >     optimization solutions into a one-stop reference. Analyzing these
>      >
>      >     solutions reveals an insight: isolating hosts is effective in
>      >
>      >     preventing ND issues. Five isolation methods are proposed and their
>      >
>      >     applicability is discussed. Guidelines are then described for
>      >
>      >     selecting a suitable isolation method based on the deployment
>      >
>      >     scenario.
>      >
>      > The IETF Secretariat
>      >
>      >
>      > _______________________________________________
>      > v6ops mailing list
>      > [e-mail]<mailto:[e-mail]> <mailto:[e-mail]<mailto:[e-mail]>>
>      > https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_v6ops&d=DwIGaQ&c=udBTRvFvXC5Dhqg7UHpJlPps3mZ3LRxpb6__0PomBTQ&r=DnUkF34wu4mqq0UY8nn2rxBBO7qOW_D-RfNVLML28ZU&m=iotgBWTCFFWPOK6Psd06xuO4j8mIPUNqVXdxxCKgyjj2hisgbVsfmGvN6UBO4Opm&s=JTSJnPnU_XZPFiP-DTjKTxl05rWSR7oeRXQ0B4-_ok4&e= <https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_v6ops&d=DwIGaQ&c=udBTRvFvXC5Dhqg7UHpJlPps3mZ3LRxpb6__0PomBTQ&r=DnUkF34wu4mqq0UY8nn2rxBBO7qOW_D-RfNVLML28ZU&m=iotgBWTCFFWPOK6Psd06xuO4j8mIPUNqVXdxxCKgyjj2hisgbVsfmGvN6UBO4Opm&s=JTSJnPnU_XZPFiP-DTjKTxl05rWSR7oeRXQ0B4-_ok4&e=>
>
> --
>
> <http://www.verizon.com/>
>
> *Gyan Mishra*
>
> *IT Technologist & Innovations Specialist*
>
> *Associate Fellow-Network Design*
>
> /Network Solutions A//rchitect, /
>
> /R&S, SP SME & Protocol Design Expert/
>
> /Global Technology Services/
>
> /O 240 970-6287
> M 301 502-1347
> /
>
> /
> /
>
_______________________________________________
v6ops mailing list
[e-mail]<mailto:[e-mail]>
https://www.ietf.org/mailman/listinfo/v6ops
--

[http://ss7.vzw.com/is/image/VerizonWireless/vz-logo-email]<http://www.verizon.com/>

Gyan Mishra

Network Solutions Architect

Email [e-mail]<mailto:[e-mail]>

M 301 502-1347