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

[Linda Dunbar <[e-mail]>]

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:[e-mail]]
> 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.