Subject: Re: [armd] draft-dunbar-armd-arp-nd-scaling

From: Linda Dunbar <[email-masked]>
Date: Thu, 29 Mar 2012 13:18:56 +0000

Kireeti, 

Thank you very much for the very constructive comments.   

My reply and follow up is inserted below:

Linda

> -----Original Message-----
> From: Kireeti Kompella [mailto:[email-masked]]
> Sent: Thursday, March 29, 2012 7:56 AM
> To: Linda Dunbar; Benson Schliesser (bschlies)
> Cc: Kireeti Kompella
> Subject: draft-dunbar-armd-arp-nd-scaling
> 
> Hi Linda, Benson:
> 
> My promised review:
> 
> High-level: seems useful as a bag of techniques that DC providers can
> use.
> 
> The recommendations come in several flavors. Some are for DC providers;
> some are for the IETF.  What might work is to put recommendations for
> DC providers in each section, and put the suggestions for IETF protocol
> changes in a "Future Work" section.

[Linda] Will do. 

> 
> Also, is there a sense of how comprehensive this discussion of
> techniques for scaling ARP/ND is?

[Linda] The draft is about practices which can be used to reduce the amount of ARP/ND requests to be handled by L2/L3 boundary routers.  So we call it "scaling ARP/ND". Do you have a better term? We need to change the name in removing the wording "BCP". 

> 
> Details:
> a) Abstract: data center environment => data center environments
> b) spurious "0" at end of Conventions used
> c) reference [ARMD-problems] needs to be fixed (cf with section 3.1)
> d) Suggested rewrite for 3.2:
> 
>    If a Layer 2 domain consists of several subnets (or VLANs) whose
>    aggregate number of hosts is large, the L2/L3 boundary routers can
>    be heavily impacted by the number of ARP/ND broadcast/multicast
>    messages received from those hosts.  This section describes some
>    commonly used practices in reducing the ARP/ND processing required
>    on L2/L3 boundary (or gateway) routers for some common traffic
> patterns.
> 
[Linda] Thanks for the good suggestion. 

> e) 3.2.1:
>    Recommendation: Use in IPv4-only networks.
> 
> [drop suggestions to change IPv6]
[Linda] OK
> 
> f) 3.2.2, first para, first line:
> When the source address is in a different subnet and the target
> 
> Suggestion: change "target" to "destination address".
[Linda] Sure. 
> 
> g) remove suggestion to change IPv6 ND protocol in Recommendation.
[Linda] Sure. 
> 
> h) 3.3: Disadvantage should mention that if ARP mappings change or go
> away, static entries could lead to persistent packet loss.
> 
> i) 3.3: Recommendation
> Most of the recommendations are for the data center provider.  Stuff
> like "change IPv6 ND protocol" and "Ask IETF to create new protocol"
> seem out of place.  (Orthogonally, I don't see the IETF dealing with
> static ARP entries.)

[Linda] OK. 
> 
> j) 3.4: calling this technique "elegant" is a value judgment whose
> validity I cannot comment on; however, it seems out of place.
> 
[Linda] Is it better to remove this section? 

> k) 3.4: Recommendation: remove the first sentence (redundant with the
> Disadvantage).
[Linda] Sure
> 
> l) 3.5, first para: redundant period at end of para.
[Linda] good catch. 

> 
> m) 3.5: Recommendation: see early comment on recommendation.
> 
> n) 4.: Perhaps call this Future Work, and focus on protocol extensions
> that might help this issue.
[Linda] good idea. 

> 
> o) 6.: if (as is possible) there is no future document, then some
> mumble on security in _this_ document.
[Linda] Sure. 

> Kireeti.

---

From: Kireeti Kompella <[email-masked]>
Date: Thu, 29 Mar 2012 06:45:47 -0700

> [Linda] The draft is about practices which can be used to reduce the amount of ARP/ND requests to be handled by L2/L3 boundary routers.  So we call it "scaling ARP/ND". Do you have a better term? W…

How about:
Common Practices for Scaling ARP and ND Request Handling

> [Linda] Is it better to remove this section? 

No, especially if, as it says, this is an extensively used technique.  If folks think that this technique is elegant, that's fine.  Otherwise change last sentence to:

However, this technique may not be appropriate for generic host migration.

Kireeti.