Subject: [Idr] draft-walton-bgp-add-paths-06.txt as IDR WG document

From: Yakov Rekhter <[email-masked]>
Date: Mon, 24 Nov 2008 11:51:01 -0800

Folks,

Please send your comments on the attached. The deadline for comments
is Dec 12, 2008.

Yakov.
------- Forwarded Message

Date:    Mon, 24 Nov 2008 14:44:00 -0500
From:    "John G. Scudder" <[email-masked]>
To:      Yakov Rekhter <[email-masked]>, [email-masked]
cc:      Inter-Domain Routing List <[email-masked]>
Subject: draft-walton-bgp-add-paths-06.txt as IDR WG document

The authors would like to request that draft-walton-bgp-add- 
paths-06.txt be adopted as an IDR WG document.

Thanks,

- --John

------- End of Forwarded Message

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

---

From: Robert Raszuk <[email-masked]>
Date: Mon, 24 Nov 2008 12:03:21 -0800

I support adoption of draft-walton-bgp-add-paths-06 as an IDR WG document.

Thx,
R.

---

From: "Cayle Spandon" <[email-masked]>
Date: Mon, 24 Nov 2008 15:22:36 -0500

I support making this a WG draft.

---

From: "Harold Ritter (hritter)" <[email-masked]>
Date: Mon, 24 Nov 2008 15:25:21 -0500

I support it. 

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
Yakov Rekhter
Sent: Monday, November 24, 2008 2:51 PM
To: [email-masked]
Subject: [Idr] draft-walton-bgp-add-paths-06.txt as IDR WG document

Folks,

Please send your comments on the attached. The deadline for comments is
Dec 12, 2008.

Yakov.

Thanks,

- --John

---

From: "Pradosh Mohapatra (pmohapat)" <[email-masked]>
Date: Mon, 24 Nov 2008 13:18:51 -0800

Support.

| -----Original Message-----
| From: [email-masked] [mailto:[email-masked]] On 
| Behalf Of Yakov Rekhter
| Sent: Monday, November 24, 2008 11:51 AM
| To: [email-masked]
| Subject: [Idr] draft-walton-bgp-add-paths-06.txt as IDR WG document
| 
| Folks,
| 
| Please send your comments on the attached. The deadline for 
| comments is Dec 12, 2008.
| 
| Yakov.
| ------- Forwarded Message
| 
| Date:    Mon, 24 Nov 2008 14:44:00 -0500
| From:    "John G. Scudder" <[email-masked]>
| To:      Yakov Rekhter <[email-masked]>, [email-masked]
| cc:      Inter-Domain Routing List <[email-masked]>
| Subject: draft-walton-bgp-add-paths-06.txt as IDR WG document
| 
| The authors would like to request that draft-walton-bgp-add- 
| paths-06.txt be adopted as an IDR WG document.
| 
| Thanks,
| 
| - --John
| 
| ------- End of Forwarded Message
| 
| _______________________________________________
| Idr mailing list
| [email-masked]
| https://www.ietf.org/mailman/listinfo/idr
| 
_______________________________________________
Idr mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/idr

---

From: "Drake, John E" <[email-masked]>
Date: Mon, 24 Nov 2008 14:33:29 -0800

Yes 

>From: Yakov Rekhter [mailto:[email-masked]] 
>Sent: Monday, November 24, 2008 11:51 AM
>To: [email-masked]
>Please send your comments on the attached. The deadline for 
>comments is Dec 12, 2008.
>
>Yakov.

---

From: Keyur Patel <[email-masked]>
Date: Mon, 24 Nov 2008 15:03:29 -0800

Support.

---

From: Danny McPherson <[email-masked]>
Date: Mon, 24 Nov 2008 20:13:06 -0700

> Please send your comments on the attached. The deadline for comments

I support this draft as well...  A few minor comments below.

-danny

---
S.3: "A BGP speaker that re-advertises a route MUST generate
its own Path Identifier to be associated with the re-advertised
route."

I think the use of "re-advertised" is confusing here.  If I
understand what you're trying to say here correctly, then how
about something like:

"A BGP speaker that advertises multiple paths for a given
prefix MUST generate and advertise a unique Path Identifier
to be associated with each path for that prefix."

---
While Path Identifier assignment is purely a local matter,
for operational reasons I believe that a receiving BGP
speaker SHOULD (MUST?) preserve any Path Identifier for an
associated path on receipt.  This will aid in operational
debugging.

---
S.6 graf 1: "In particular, a new advertisement for a
given address prefix and a given path identifier replaces
a previous advertisement for the given address prefix and
the given path identifier."

I think a reword as such is somewhat clearer:

"In particular, a new advertisement for a given address
prefix and a given path identifier replaces ONLY a previous
advertisement for the given address prefix and the given
path identifier."

---
I wonder if it's necessary to state handling procedures
in S.6 of receipt of an update message that does not use
extended NLRI encoding from a peer that advertised they
support receive processing of the capability?  For example,
if an implementation wanted to optimize in some manner
where if only one path exists then don't use the the
extended NLRI encoding, because you could never pack
updates, etc..

Perhaps receipt of an update for a prefix that does not
use extended ecoding from a peer that advertised the
capability should be handled normally, and not considered
or generate an error condition?

---
S.8: Perhaps there should be some text here about the
impact on Adj-RIB-In size, memory requirements, etc..,
tied in to the existing "care should be taken" text?
Also, the resulting instability that may be more widely
visible with such a feature could be a concern.

Also, perhaps some implementation detail noting that
when large numbers of routes need to be sent to a peer,
or when the peer is first "synchronizing", advertising
best paths first might be prudent.

---
S.10:  I beleive this section should have some text
about the potential abuse of such a feature.  For example,
if a peer were to advertise lots of paths for each prefix
it may result in a DoS attack.  While the peer could do
likely do this without such a feature, this does increase
the attack surface and with standard prefix-based policies
in use today they would not mitigate such an attack.

---

From: "Bhatia, Manav \(Manav\)" <[email-masked]>
Date: Tue, 25 Nov 2008 12:27:53 +0530

Hi,

I've read enough to believe that the proposed mechanism is sufficient to
advertise and withdraw multiple paths.  I am ok with this part. 

However, one key thing that isn't obvious from this draft is how the
active path(s) (the ones(s) actually inserted in the FIB and being used
for forwarding traffic) of the advertising speaker is differentiated
from other non-active paths.

Cheers, Manav 

> From: [email-masked] [mailto:[email-masked]] On 
> Behalf Of Yakov Rekhter
> Sent: Tuesday, November 25, 2008 1.21 AM
> To: [email-masked]

---

From: Enke Chen <[email-masked]>
Date: Mon, 24 Nov 2008 23:27:35 -0800

Hi, Mnav:

As described in the add-path document (sect. 7), the specific 
applications are to be addressed by the application documents.  For 
example, currently there are two such documents:

   1) BGP Persistent Route Oscillation Solution, 
draft-walton-bgp-route-oscillation-stop-01.txt  (out-dated, needs update)

  2)Fast Connectivity Restoration Using BGP Add-path, draft-pmohapat-idr-fast-conn-restore-00

The issue of "active path" vs "inavtive path" is more relevant to #2, 
and it is indeed addressed there.

Thanks.   -- Enke

---

From: "PAPADIMITRIOU Dimitri" <[email-masked]>
Date: Tue, 25 Nov 2008 14:13:46 +0100

[snip]
> visible with such a feature could be a concern.

if an id is prepended to the best path, and only the latter is
advertized this would not incur more instability than today's situation.
except if for whatever reason the BGP speaker decides to modify that id
(if my reading is correct nothing prevent this from the current
write-up)

when multiple paths (each prepended with an id) are progressively
advertized you have an effect on and then each would be progressively
removed (A:ID1, A:ID2,..., A:IDn) and then (W:ID1, W:ID2,...,W:IDn)
compared to the current situation where after the initial advertisement,
a sequence of increasing length path is advertized followed by a
withdrawal or stabilization to a newly preferred path. So the effect is
the delta on the withdrawn sequence from W:ID1,...,W:IDi (in the work
case, i=n i.e. the full sequence is withdrawn) and the delta on the
advertized sequence A:IDj,...,A:IDn (in the worst case j=2 i.e. one
would stabilize on the second path)

-d.

---

From: Danny McPherson <[email-masked]>
Date: Tue, 25 Nov 2008 07:08:37 -0700

> would stabilize on the second path)

I mean between adjacent nodes, not system wide.  More paths
means more state, more paths means more churn.  This is the
obvious trade-off here when employing add-path.

-danny

---

From: "PAPADIMITRIOU Dimitri" <[email-masked]>
Date: Tue, 25 Nov 2008 15:25:52 +0100

> From: Danny McPherson [mailto:[email-masked]] 
> Sent: Tuesday, November 25, 2008 3:09 PM
> To: PAPADIMITRIOU Dimitri
> Cc: Yakov Rekhter; [email-masked]
> Subject: Re: [Idr] draft-walton-bgp-add-paths-06.txt as IDR 
> WG document
> 
> 
> > except if for whatever reason the BGP speaker decides to 
> modify that  
> > id
> > withdrawal or stabilization to a newly preferred path. So 
> the effect  
> > is
> I mean between adjacent nodes, not system wide.  

it is this behaviour b/w adj speakers that i tried to explicitly 
characterize.

> More paths means more state, more paths means more churn.  This 
> is the obvious trade-off here when employing add-path.

you can then translate this into state maintenance/processing 
overhead.

-d.

---

From: "Pradosh Mohapatra (pmohapat)" <[email-masked]>
Date: Tue, 25 Nov 2008 07:58:21 -0800

| ---
| While Path Identifier assignment is purely a local matter, 
| for operational reasons I believe that a receiving BGP 
| speaker SHOULD (MUST?) preserve any Path Identifier for an 
| associated path on receipt.  This will aid in operational debugging.

Right. It MUST preserve the path-id that it received in the path
structure since the id would be used for replacing any new 
advertisement received for that path or removing the path upon 
withdrawl.

| ---
| I wonder if it's necessary to state handling procedures in 
| S.6 of receipt of an update message that does not use 
| extended NLRI encoding from a peer that advertised they 
| support receive processing of the capability?  For example, 
| if an implementation wanted to optimize in some manner where 
| if only one path exists then don't use the the extended NLRI 
| encoding, because you could never pack updates, etc..
| 
| Perhaps receipt of an update for a prefix that does not use 
| extended ecoding from a peer that advertised the capability 
| should be handled normally, and not considered or generate an 
| error condition?

This makes parsing extremely difficult. Reception of the capability
from a peer is the only indication that the UPDATE parsing needs
to retrieve the first four octets as path-id and the prefix
follows after that. How would you differentiate an UPDATE message
where prefixes are encoded with path-id vs. another where they
aren't?

If a speaker is able to send only one path and has advertised
add-path capability, there are simpler ways to encode a (dummy)
path-id, like always encode 0 or 1 or whatever...

- Pradosh

---

From: Danny McPherson <[email-masked]>
Date: Tue, 25 Nov 2008 09:09:53 -0700

> advertisement received for that path or removing the path upon

Ahh, of course..

> path-id, like always encode 0 or 1 or whatever...

While I'm an advocate of this work, I'm just a little
concerned about the fact that we're introducing more paths,
and advertising the capability may well result in considerable
reductions in the ability to update pack, etc..

Some explicit text around error handling would be useful here.

Of course, the call was to become a WG document, not WG LC,
and so none of my queries should be considered gating.

-danny

---

From: Robert Raszuk <[email-masked]>
Date: Tue, 25 Nov 2008 09:15:32 -0800

Hi Danny,

 > reductions in the ability to update pack, etc..

How would it ? Path_id is part of NLRI not any of the attached attributes.

Yes some applications which build on top of add-path may require new 
attributes but after all this is the price one needs to pay distribute 
more then best path around. And I think the numerous applications of the 
latter proves the price vs benefit much into the benefit zone.

Cheers,
R.

---

From: Danny McPherson <[email-masked]>
Date: Tue, 25 Nov 2008 11:02:10 -0700

> How would it ? Path_id is part of NLRI not any of the attached  

Duh, I completely overlooked this.  OK, nix that
concern.

> attributes but after all this is the price one needs to pay  
> distribute more then best path around. And I think the numerous  
> applications of the latter proves the price vs benefit much into the  
> benefit zone.

I don't disagree with that, as I stated a moment ago.

-danny

---

From: "Rajiv Asati (rajiva)" <[email-masked]>
Date: Tue, 25 Nov 2008 14:50:18 -0500

> where prefixes are encoded with path-id vs. another where they
	
Correct.

> path-id, like always encode 0 or 1 or whatever...

It will be worth adding some text in the draft along the above line. 

Cheers,
Rajiv

> Pradosh Mohapatra (pmohapat)
> Sent: Tuesday, November 25, 2008 10:58 AM
> To: Danny McPherson; Yakov Rekhter
> Cc: [email-masked]
> Subject: Re: [Idr] draft-walton-bgp-add-paths-06.txt as IDR WG
document

---

From: Uli Bornhauser <[email-masked]>
Date: Wed, 26 Nov 2008 10:13:08 +0100

Hi Enke, Manav,

I agree to Manav that Addpath is sufficient to advertise and withdraw
multiple paths.

> and it is indeed addressed there.
The idea sketched in the Fast Connectivity Restoration draft is a step
in the right direction. However, there are still configurations possible
where inactive paths are incorrectly rated as active ones. Such examples
show that the Border router attr_set as currently design is not
sufficient to solve the active/inactive rating problem in general. As
Manav, I believe that Addpath in hardly usable without having a
mechanism that inherently avoids this problem. I hope I will find some
time to email an ASCII example for such a configuration.

Regards

Uli
>>> From: [email-masked] [mailto:[email-masked]] On Behalf
>>> Of Yakov Rekhter

-- 
______________________________________________________________
ULI BORNHAUSER                University of Bonn
                              Institute of Computer Science IV
Web:   www.cs.bonn.edu/IV/ub  Roemerstr. 164
Email: [email-masked]      D - 53117 Bonn
Phone: +49 (228) 73 - 4550    Germany
Fax:   +49 (228) 73 - 4571

---

From: Robert Raszuk <[email-masked]>
Date: Wed, 26 Nov 2008 02:29:25 -0800

Hi Uli,

> I hope I will find some time to email an ASCII example for such a configuration.

Please do. It would be quite helpful.

 > mechanism that inherently avoids this problem.

Add-path as currently proposed is a base specification. Each application 
using add-path may choose to define it's own set of primitives and rules.

For example if I would like to use add-path to send all the paths from a 
router to my BGP looking glass or other BGP monitor I really don't need 
much more then it is defined in the base spec.

Cheers,
R.