Subject: Re: [Idr] draft-uttaro-idr-add-paths-guidelines-03.txt as IDR WG document

From: Jeff Tantsura <[email-masked]>
Date: Wed, 27 Oct 2010 22:42:40 -0400

Yes/support
Regards,
Jeff

----- Original Message -----
From: [email-masked] <[email-masked]>
To: [email-masked] <[email-masked]>
Cc: [email-masked] <[email-masked]>; [email-masked] <[email-masked]>
Sent: Wed Oct 27 20:59:56 2010
Subject: Re: [Idr] draft-uttaro-idr-add-paths-guidelines-03.txt as IDR WG	document

This 2 week call (10/27 - 11/10) for interest in having: 

http://tools.ietf.org/html/draft-uttaro-idr-add-paths-guidelines-03

"Best Practices for Advertisement of Multiple Paths in BGP" 

As normal, vote on the mail list.

Sue and John

_______________________________________________
Idr mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/idr

---

From: <[email-masked]>
Date: Thu, 28 Oct 2010 14:44:24 +0200

Jim, Virginie, Pierre, Roberto, Adam, Pradosh,
All,

I think this is a useful document. Thanks for it.
Below some comments on the draft:

1) Backup path: One of the non-best paths toward a prefix.

>From reading the draft, it's not fully clear to me if a second path whose BGP Next Hop is the same (or advertised in the IGP by the same router) than the first path is considered as a backup path or not. IMO
- If no, the definition should reflect this.
- If yes, such backup path does not provide fact connectivity restoration in case of node (ASBR failure)

2) 3.1. Fast Connectivity Restoration
2.a)
"   2. RR receives the withdrawal, and propagates it to its other client
      peers, routers B, C and D.

   3. When router B receives the withdrawal of path (A)"

As per you hypothesis, RR knows a back up path. Therefore IMO at step 2 RR should advertise path C. At step 3 router B should receive an update of path C.

(by "withdrawal" you may be referring to an implicit withdraw of path A, but that would be less explicit for the reader.).

2.b)
This is arguable, but IMO, the example should focus on the gain brought by BGP ADD PATH (i.e. the ability to send multiple paths over a BGP session). As such, in the non ADD-PATH case, we could consider the use of BGP external best. In that case, the RR would have full path diversity even without add path. (That would change a few things in the analysis of the example.)

In the end, you probably need a more complex example topology to illustrate the benefit of ADD PATH.

3) 
" A MANDATORY mode should be present in any implementation
   that claims compliance with [Add-Paths]. "

I'd rather say compliant with _this_ document (vs Add-Paths).

4) " Best Practices for Advertisement of Multiple Paths in BGP "

This document seems to restrict the discussion to iBGP / intra AS only. If this is the case, I think this should be reflected in the abstract and probably in the title.

5) From Add-Paths section 7: " Care
   needs to be taken in its deployment to ensure consistent routing and
   forwarding in a network, the details of which will be described in
   separate application documents. "

I think this is applicable to this document.
In particular, I think the document should discuss the effects of having different path selection modes used on different iBGP neighbour. If there are adverse effects, would this bring any value for each BGP speaker to advertise a BGP capability to advertise the add-path mode they are using?

Section 5.2 introduce a first discussion on this but only provides 2 examples. I think a complete discussion would be useful to help ISP in their deployment of add path.

Also, what about if 2 RR serving the same iBGP clients have different path selection mode, or have not strictly the same order for the path? And if one iBGP client lose an iBGP session to one of its RR.

...

Section 5.3 also introduce a first discussion on this, but again it only gives 2 examples of "wrong" design. It would be useful for ISP to either have _all_ the wrong cases or the recommendations to make sure the design is good. (or both).

6) " 4.3.1.2. Advertise N Paths"

I understand that the advertisement is limited to N path.
I think the document should better specify which are those path.
- Could be any path? (so N is simply an upper bound of the control plane load)
- Are _the_ N consecutive best path? In this case how are the best path computed? (e.g. remove the previous selected path, remove the paths having the same BGP Next-Hop / Originator of the path previously connected, remove the paths having a BGP Next-Hop advertised in the IGP by the same node(s) of the previously selected path...)

7) Optimal routing + one backup path
Is there a mode which provides optimal routing, no routing oscillation and one back up path for fast recovery? Something like " All AS-Wide Best Paths" + one backup path if not already advertised as per the previous rule?

8) " If two levels of encapsulation are used in the network
   as described in [RFC4364], this is not an issue, as only the ingress
   router performs a lookup in its BGP-fed FIB. "

I think some implementations allow the egress router to also perform an IP look up in its VRF. Would this be an issue? If yes, I think this should be clearly stated. If no, the sentence needs to be reworded to include this case.

9) Appendix A. Other Path Selection Modes

IMO it would be interesting to explain, for each mode, why it is not considered any more as valid / useful mode.

10) summary
I would find useful to add a summary (e.g. table) indicating the benefit (as listed in §3) and cost (as listed in §4.3) of each proposed mode.

Thanks,
Regards,
Bruno