Subject: [Idr] draft-scudder-idr-ebgp-rr-00

From: Shane Amante <[email-masked]>
Date: Tue, 25 Oct 2011 21:29:20 -0600

Hi John,

I've read over this draft and have a couple of questions & comments:
1)  Is it correct to assume that one use case of this draft is running EBGP to a Route Reflector as in Inter-AS Option C, where one definitely wants to avoid changing NEXT_HOP on eBGP learned routes from the adjacent AS, particularly when the RR's are "Control Plane" only devices.  Would a brief mention of this draft's applicability toward Inter-AS Option C be helpful?
2)  In Section 3, it's difficult to understand the intent of the 2nd bullet, because it's not using the terminology of RFC 4456:
   o  The speaker SHOULD NOT add a CLUSTER_LIST to EBGP-learned routes
      when advertising them into IBGP.
Specifically, when you say "advertising them into IBGP", do you mean:
    a)  A Non-Client IBGP peer;
    b)  A Client peer;
    c)  Both (a) and (b)?

Could you add a few words to the above statement in the draft so it aligns with terminology in 4456, to avoid any unnecessary confusion?

FWIW, I assume you most likely meant (a), which means that a CLUSTER_LIST would still get added for incoming EBGP routes, by the RR, when 'reflecting' the route to a client peer in order to preserve the behavior of Section 8 of RFC 4456, namely avoiding routing information loops through misconfiguration (of a client)?  

Thanks,

-shane