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

From: <[email-masked]>
Date: Wed, 3 Dec 2008 17:36:08 +0100

Support.

> -----Message d'origine-----
> De : [email-masked] [mailto:[email-masked]] De la part de Yakov Rekhter
> Envoyé : lundi 24 novembre 2008 20:51
> À : [email-masked]
> Objet : [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: Uli Bornhauser <[email-masked]>
Date: Thu, 04 Dec 2008 10:15:54 +0100

Hi Robert,

here should be a simple example for the problem regarding Add-path, Best
/ Second Best, and Border Router Attr Set I mentioned:

-------------------------------------

---------+        RR        +--------
      ASx|   d1 .    . d1   |ASy
         |     .      .     |
 R-ID.6.....C-ID.5  C-ID.8.....R-ID.2
     q1->|    .        .    |<-q2
         |    .        .    |
---------+    .        .    +--------
              .        .
         MED2 .        . MED1
       +------.--------.----+
       |ASz p1.        .p2  |
       |      .        .    |
       |   R-ID.3    R-ID.9 |

-------------------------------------
q1, q2, p1, p2: Paths advertised from neighboring systems.
     R: Routers in neighboring systems, Route Reflector or Clients
     C: Client in own System
    RR: Route Reflector in own System
*-ID.x: Router has BGP ID .x
    d1: Links with a distance of 1
   ASa: AS with ID a

Client C-ID.5 receives the paths q1 and p1. Path p1 is the best (lower
BGP ID, .3) and path q1 is the second best.
Client C-ID.8 receives the paths q2 and p2. Path q2 is the best (lower
BGP ID, .2) and path p2 is the second best.

Both clients advertise both path to the reflector RR of the system.

Comparison of p1, p2, q1, q2 at RR:
p1 is discarded due to the higher MED (2, path p2 has a MED of 1)
p2 and q2 are discarded due to the higher BGP ID (.8)
--> Path q1 is the "first" best on RR.
--> Path p1 is also removed (due to the same BGP ID .5 (or even
Nexthop), cf. Draft)

Comparison of p2, q2 at RR:
p2 is discarded due to the higher BGP ID in the Border Router Attribute Set
--> Path q2 is the second best.

As a result, *the best path of RR is the second best of C-ID.5*. This
configuration is stable, as path p2 is neither best or second best.
Thus, it is not reflected to the clients.

Regards

Uli

Robert Raszuk schrieb:
> Hi Uli,
>
>>>  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.
>
>> 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
>> I hope I will find some time to email an ASCII example for such a
>> configuration.
>
> Please do. It would be quite helpful.
>
> > Manav, I believe that Addpath in hardly usable without having a
> > 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.

-- 
______________________________________________________________
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: Thu, 4 Dec 2008 03:29:18 -0800

Hi Uli,

 > Client C-ID.5 receives the paths q1 and p1.

This is already not the correct observation. In the correct architecture 
of this network (no misconfiguration) C-ID.5 would receive all 4 paths. 
Therefor p2 will win.

Cheers,
R.

---

From: Uli Bornhauser <[email-masked]>
Date: Thu, 04 Dec 2008 13:30:01 +0100

Hi Robert,

I think I did not get your point yet. Why do you think that a
misconfiguration is needed for the example?
Client C-ID.5 keeps two eBGP sessions (to R-ID.6 and R-ID.3) and thus
receives q1 and p1. Client C-ID.8 also holds two external sessions (to
R-ID.9 and R-ID.2) and receives p2 and q2. The Route Reflector of
clients C-ID.5 and C-ID.8 receives all paths, and re-advertises its
first and second best (which are q1 and q2).
Thus, client C-ID.5 is provided with q1, q2, and p1. Knowing q2 has no
effect on its routing decision. Path p2 is not visible at C-ID.5 at all.

Can you please explain I detail from where client C-ID.5 should learn
path p2?

Thank you and Regards

Uli

Robert Raszuk schrieb:
> This is already not the correct observation. In the correct
> architecture of this network (no misconfiguration) C-ID.5 would
> receive all 4 paths. Therefor p2 will win.
>
> Cheers,
> R.
>
>> Hi Robert,
>>

---

From: Robert Raszuk <[email-masked]>
Date: Thu, 4 Dec 2008 04:36:59 -0800

Hi Uli,

I was assuming that RR would advertise all paths not just best and 
second best.

But you are in general very correct that regardless of what RR 
propagates via IBGP domain the rtr_id of the advertising peer is still 
subject to be compared before the attr_set hence we have an issue.

In full mesh ibgp that would not be the problem, but in the RR case it 
still  think is.

I propose we talk offline and try to come up together on the best 
solution considering your work already in this space.

Cheers,
R.

---

From: Danny McPherson <[email-masked]>
Date: Fri, 5 Dec 2008 09:26:54 -0700

On Dec 4, 2008, at 5:36 AM, Robert Raszuk wrote:

> propagates via IBGP domain the rtr_id of the advertising peer is  
> still subject to be compared before the attr_set hence we have an  
> issue.
>
> In full mesh ibgp that would not be the problem, but in the RR case  
> it still  think is.
>

As an aside, this is another reason why comparing MEDs
for a prefix with paths learned from different ASes is
a bad idea.

-danny

---

From: <[email-masked]>
Date: Fri, 12 Dec 2008 17:38:16 +0100

Support! 

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