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

["Mishra, Gyan S" <[e-mail]>]

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]> 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] <[e-mail]>
> > Sent: Thursday, April 27, 2023 10:09 AM
> > To: Vasilenko Eduard <[e-mail]>; Eduard Metz <
> [e-mail]>; Vasilenko Eduard <[e-mail]>;
> Gyan Mishra <[e-mail]>; Nick Buraglio <[e-mail]>;
> Xipengxiao <[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=
> >
> >
> > 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=
> >
> >
> > 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=
> >
> >
> > 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=
> >
> >
> > 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]
> >
> 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-6287M 301 502-1347*