Subject: [Idr] Comments on draft-uttaro-idr-add-paths-guidelines-03

From: <[email-masked]>
Date: Sun, 7 Nov 2010 09:16:18 +0100

Hi authors, working group,

I think this draft is really valuable in helping us providers getting a finer approach to add-path. I therefore would encourage the authors in improving it, hopefully my comments/questions will help you doing so.

-  In section 4.2, IMHO a reference to the deployment of add-path in the network (eg partial, full) is missing. For instance, what are the risks in terms of routing because of a partial deployment of add-path due to a temporary situation (scenario where we would migrate to add-path) or because of cases where we wouldn't/couldn't deploy add-path everywhere in the network (too old machinery for instance). A link to section 5.2 may be sufficient, however I think that this point is too quickly approached there. Is this done in purpose?

- In section 4.3.1, there is a contradiction in the sentence "A MANDATORY mode should be present in any implementation that claims compliance with [Add-Paths]". IMO, a mandatory implies a MUST and not a SHOULD afterwards, as it is done in the rest of the document.

- In section 4.3.1.2, regarding the sentence 

   Path optimality and backup path optimality are not guaranteed, but as

   path diversity is better, the nexthops of the chosen primary and

   backup path are more likely to be closer to the router than with

   classical BGP.

   , you state that the diversity is better without referring to what it is better. It seems obvious to me that it is better than « classical BGP », but maybe it was compared to other thing. In any case, I think it would be worth précising it.

Best,

Greg

---

From: "UTTARO, JAMES (ATTLABS)" <[email-masked]>
Date: Mon, 8 Nov 2010 10:01:35 -0500

Comments In-Line..

Jim Uttar

From: [email-masked] [mailto:[email-masked]] 
Sent: Sunday, November 07, 2010 3:16 AM
To: UTTARO, JAMES (ATTLABS); [email-masked]; [email-masked]; [email-masked]; [email-masked]; [email-masked]
Cc: [email-masked]
Subject: Comments on draft-uttaro-idr-add-paths-guidelines-03

[Jim U>] There are a number of applications where the deployment of add-paths will enhance services and infrastructure. ne ex is creation of a BGP infrastructure that is used to augment/replace an existing IGP solution.. Certainly a full mesh is never desirable but using RRs creates path hiding that impacts convergence time in the event of a failure.. This infrastructure application may have different requirements than for a service i.e IPV4 services including peering, customer service, service infrastructure etc... My opinion is that as there are many apps and we cannot anticipate how folks will use add-paths. Prescribing migration strategies in the draft is counter-productive..

   classical BGP.

Best,

Greg

---

From: <[email-masked]>
Date: Tue, 9 Nov 2010 04:18:51 +0100

Thanks Jim for your answer. 

I think however you misunderstood my point. I don't want at all to prescribe any deployment strategy, my point is on the contrary to invite you to detail what would be the guidelines (ie knowing pros and cons) for deploying one strategy and as such describe, as there will be times when routers will have enable add-paths while other have not, what situations can happen so as to give guidance for deployment steps.

Hope this is clearer now,

Greg

De : UTTARO, JAMES (ATTLABS) [mailto:[email-masked]] 
Envoyé : lundi 8 novembre 2010 23:02
À : CAUCHIE Gregory RD-CORE-ISS; [email-masked]; [email-masked]; [email-masked]; [email-masked]; [email-masked]
Cc : [email-masked]
Objet : RE: Comments on draft-uttaro-idr-add-paths-guidelines-03

Comments In-Line..

Jim Uttar

   classical BGP.

Best,

Greg