Re: [armd] RtgDir review: draft-ietf-armd-problem-statement-03

["Bhatia, Manav (Manav)" <[e-mail]>]

Hi Thomas,

> 
> > However, the draft still says "multicast frames do not necessarily  
> > need to be sent to all parts of the network". I could be missing  
> > something but there still seems to be some disconnect 
> because in  the 
> > context of L2, multicast frames will be sent to all parts of  the 
> > network.
> 
> L2 IGMP snooping may be taking place, which can then result 
> in multicast traffic not being forwarded everywhere in the L2 
> broadcst domain...

Yes, that's correct. So youre suggesting that IGMP snooping will help reduce "ARP" traffic in case of IPv6. Do hosts send out MLD reports for the link local addresses that they expect to receive the Neighbor Discovery messages on? If they don't, then snooping will be of no help in reducing IPv6 ND traffic that the draft is discussing in that section.

[clipped]

> 
> > Yes it does as long as you remove the original line that I had
>   quoted.
> 
> Removing that line IMO removes something essential. It is the 
> case that on some routers (i.e., devices at the edge of an L2 
> boundary) do not have sufficient resources to process "a lot 
> of ARP traffic". "a lot" is in quotes because we don't have 
> an exact figure for what that is. This is one of the key 
> points to come out of the ARMD effort.
> 
> What exactly do you object to in that sentence?

My concern with the opening sentence of Sec 7.1 is that it generalizes large L2 domains and makes a sweeping statement that seems to suggest that all routers in large L2 domains need to process "a lot of " ARP traffic. This is patently incorrect. As I have said earlier, this issue is specific to L2 domains that see a lot of ARP/ND traffic and is not true in general for all large L2 domains. 

[clipped]

> > > 
> > > Right. The spec says "don't do this". But I believe it 
> was asserted 
> > > that some implementations do this. That said, I'm not 
> aware of any 
> > > such implementations. I would be willing to remove this 
> sentence in 
> > > the absence of known implementations of this.
> 
> To clarify, the current text says "Some routers can be 
> configured to broadcast periodic gratuitous ARPs."
> 
> This statement is true, and presumably you are not objecting 
> to that. right?

Yes, I am not.

[clipped]

> 
> How about I change the sentence:
> 
>     Gratuitous ARPs, broadcast to all nodes in the L2 broadcast
>     domain, can also pre-populate ARP caches on neighboring devices,
>     further reducing ARP traffic.
> 
> to:
> 
>     Gratuitous ARPs, broadcast to all nodes in the L2 broadcast
>     domain, may in some cases also pre-populate ARP caches on
>     neighboring devices, further reducing ARP traffic. But it is not
>     believed that pre-population of ARP entries is supported by most
>     implementations, as the ARP specification <xref
>     target="RFC0826"></xref> recommends only that pre-existing ARP
>     entries be updated upon receipt of ARP messages; it does not call
>     for the creation of new entries when none already exist.

Sounds good.

> 
> > > > 2. In Sec 7.1 you mention that routers need to drop all 
> transit  
> > > > traffic when there is no response received for an 
> ARP/ND  request. 
> > > > You should mention that in addition to this, routers 
> also  need to 
> > > > send an ICMP host unreachable error packet back to the  sender. 
> > > > ICMP error packets are generated in the control card  
> CPU. So, if 
> > > > the CPU has to generate a high number of such ICMP  errors then 
> > > > this can load the CPU. The whole process can be quite  
> CPU as well 
> > > > as buffer intensive. The CPU/buffer overload is usually 
>  mitigated 
> > > > by rate limiting the number of ICMP errors generated.
> > > 
> > > Added:
> > > 
> > >    "and may send an ICMP destination unreachable message as well."
> 
> > Why a "may"? An implementation is violating a standard if it isn't.
> 
> The might not if rate limiting says otherwise. I.e., there 
> are times when an ICMP won't be sent that is not in violation 
> of the spec.

Aah, ok. 

[clipped]

> > > 
> > > > 5. Sec 7.2 discusses issues with address resolution 
> mechanism in  
> > > > IPv6. I think its useful for this draft to discuss the 
> fact that  
> > > > unlike IPv4, IPv6 has subnets that are /64. This number 
> is quite  
> > > > large and will perhaps cover trillions of IP addresses, 
> most of  
> > > > which would be unassigned. Thus simplistic IPv6 ND 
> implementations  
> > > > can be vulnerable to attacks which inundates the CPU with huge  
> > > > requests to perform address resolution for a large 
> number of IPv6  
> > > > addresses, most of which are unassigned. As a result of this  
> > > > genuine IPv6 devices will not be able to join the network. You  
> > > > might want to refer to RFC 6583 for more details.
> > > 
> > > Ditto.
> 
> > I am fine with your resolution to the comments 3 and 4. However, I  
> > believe that 5 ought to be discussed. This document is 
> about ARP/ND  
> > issues that folks are either seeing or will see in large data  
> > centers.
> 
> To clarify: "are seeing". We can speculate at length for what 
> problems will be seen in the future. :-)

If the scope is only the former, then I am ok with you not considering point 5.

> 
> > Given this, I don't see why this should not even be 
> discussed in  this 
> > draft. I think its quite reasonable to address the above  mentioned 
> > aspect of IPv6 ND and one of way getting attention to  issue is by 
> > discussing this here in this draft.
> 
> The issue you raise above is fully documented in RFC 6583, 
> which I have added to the references (per my previous note).

Which is indeed very helpful.

[clipped]

> > > 
> > >     Security considerations for Neighbor Discovery are 
> discussed in
> > >     <xref target="RFC4861"></xref> and <xref 
> target="RFC6583"></xref>.
> 
> > This should be good. I assume that this then means that 
> there are no  
> > additional security concerns with ARPs/ND in data centers.
> 
> I don't recall any coming up in the WG.

Ok.

[clipped]

> 
> > I just noticed that Sec 8 - Summary, is redundant. Shouldnt that
>   entire text be moved to either the Abstract or the Introduction?
> 
> It's the last section of the document. The document needs a 
> summary or something (summary seems more accurate than 
> conclusions, IMO).

I will not argue on this! :-)

Cheers, Manav
>