Subject: [Idr] Comments on draft-zhang-idr-bgp-entire-routes-reflect-00.txt

From: "Manav Bhatia" <[email-masked]>
Date: Tue, 19 Jul 2005 09:43:00 +0530

Hi Zhang,

There are some things that are not clear to me as I went through your draft.

[1] The Entire RR capability that you talk of enables a client to inform the
RR that it can "handle withdrawn routes segment that contains a NEXT_HOP".
But how does this help? Say the RR has multiple ways to reach a destination.
If it tries to announce this reachability information multiple times, then
the subsequent UPDATEs will be considered as implicit withdrawals for the
previous announcements. Thus, you need a way to tell your remote BGP peer
that the UPDATE that is being sent now is not an implicit withdrawal, but a
regular UPDATE that it needs to append and not replace.

I don't see this discussed anywhere in the document.

[2] If you ever want BGP to load balance or advertise multiple paths then
you need to consider the AS_PATHs. Would the RR in your case advertise
multiple paths only if *all* the path attributes are same or would it also
do this given different, but equivalent, path attributes? An example of the
latter case would be two paths with AS_PATHs {X Y Z} and {X A Z}
respectively. It's the latter case that's more realistic and hence more
interesting.

We presented a similar idea (draft-bhatia-ecmp-routes-in-bgp-01.txt) in the
IDR WG that does this and takes care of all the scenarios that I just
mentioned. You can look at the slides at
http://www1.ietf.org/proceedings_new/04nov/slides/idr-1/sld1.htm

We are working on updating our original document and should be posting it
soon.

Thanks,
Manav

--
Manav Bhatia
Member of Technical Staff
Riverstone Networks, Inc.
http://www.riverstonenet.com 

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

---

From: Zhang Renhai <[email-masked]>
Date: Tue, 19 Jul 2005 15:41:44 +0800

Hi,  Manav

 Please see inline. 

----- Original Message ----- 
From: "Manav Bhatia" <[email-masked]>
To: <[email-masked]>
Cc: <[email-masked]>
Sent: Tuesday, July 19, 2005 12:13 PM
Subject: Comments on draft-zhang-idr-bgp-entire-routes-reflect-00.txt

> regular UPDATE that it needs to append and not replace.

Yes, here a method is need to make the subsequent UPDATEs not an implicit
withdrawl,  prevously I thought of a method, that is , for the client with which
RR has negotiated the capability, there will be no the implicit withdrawals any 
more, instead, when updating the routes , RR should first advertises the withdraw
explicitly, I don't think it a good method lately. So, as you say, a indication can
be included in the subsequent UPDATEs when reflecting more than one routes
to a destination, and this should be coverd in the future version, but the mechanism 
is still not clear now, anyone is encouraged to contribute this.

> respectively. It's the latter case that's more realistic and hence more
The AS_PATH attribute is not related to the capability, in fact, the Next Hop
attribute is the key factor, the client can make the load balancing only among the 
different next hop, multiple paths with the same next hop have no meaning to 
loading balancing and only one route is reflected to the client, otherwise, all routes
will be advertised to the client, wrt which routes are used to performing load balancing, 
it's the local dicision of the client.

> http://www1.ietf.org/proceedings_new/04nov/slides/idr-1/sld1.htm
I will study your draft, thanks.

Regards,
Zhang

---

From: "Manav Bhatia" <[email-masked]>
Date: Tue, 19 Jul 2005 13:55:48 +0530

Hi Zhang,

!> The AS_PATH attribute is not related to the capability, in 
!> fact, the Next Hop
!> attribute is the key factor, the client can make the load 
!> balancing only among the 
!> different next hop, multiple paths with the same next hop 
!> have no meaning to 

I am talking about multiple paths with different NEXT_HOPs.

For example, two routes with the following attributes:

AS_PATH {X, Y, Z} NEXT_HOP N1
and 
AS_PATH {A, B, Z} NEXT_HOP N2

You need a way to advertise this information.
 
!> loading balancing and only one route is reflected to the 
!> client, otherwise, all routes
!> will be advertised to the client, wrt which routes are used 
!> to performing load balancing, 
!> it's the local dicision of the client.

If a BGP peer is receiving the above two paths and is splitting the load or
is doing multipath using N1 and N2, then it MUST inform its downstream peers
about the AS_PATHs that will be used when forwarding the data. You have to
do that to avoid AS Path loops.

Manav

!> 
!> > 
!> > We presented a similar idea 
!> (draft-bhatia-ecmp-routes-in-bgp-01.txt) in the
!> > IDR WG that does this and takes care of all the scenarios 
!> that I just
!> > mentioned. You can look at the slides at
!> > http://www1.ietf.org/proceedings_new/04nov/slides/idr-1/sld1.htm
!> > 
!> I will study your draft, thanks.
!> 
!> Regards,
!> Zhang
!> 
!> > We are working on updating our original document and 
!> should be posting it
!> > soon.
!> > 
!> > Thanks,
!> > Manav
!> > 
!> > --
!> > Manav Bhatia
!> > Member of Technical Staff
!> > Riverstone Networks, Inc.
!> > http://www.riverstonenet.com 
!> > 
!> 
!> 
!> 
!> _______________________________________________
!> Idr mailing list
!> [email-masked]
!> https://www1.ietf.org/mailman/listinfo/idr

---

From: Zhang Renhai <[email-masked]>
Date: Tue, 19 Jul 2005 16:39:23 +0800

Hi, Manav

----- Original Message ----- 
From: "Manav Bhatia" <[email-masked]>
To: "'Zhang Renhai'" <[email-masked]>
Cc: <[email-masked]>
Sent: Tuesday, July 19, 2005 4:25 PM
Subject: RE: [Idr] Re: Comments ondraft-zhang-idr-bgp-entire-routes-reflect-00.txt

> You need a way to advertise this information.
According the rule I mentioned in the last mail, the RR will reflect the two
routes, the key change on the RR about this capability is that the RR doesn't
make the routes selection between the routes with different next hop.So I
think there is no contradiction with your point on this aspect.
> do that to avoid AS Path loops.
Sure, I guess your concern is that when forwording the routes performing the load
balancing as one route, the AS_PATH attribute must be changed consequently, e.g., changing 
some AS from sequence to set, correct? Indeed, the AS_PATH should be considered
carefully.
If this is nacessary in the draft, I will cover it in the future version.

Thanks,
Zhang

---

From: Zhang Renhai <[email-masked]>
Date: Tue, 19 Jul 2005 16:44:11 +0800

complementarity:

----- Original Message ----- 
From: "Manav Bhatia" <[email-masked]>
To: "'Zhang Renhai'" <[email-masked]>
Cc: <[email-masked]>
Sent: Tuesday, July 19, 2005 4:25 PM
Subject: RE: [Idr] Re: Comments ondraft-zhang-idr-bgp-entire-routes-reflect-00.txt

> You need a way to advertise this information.

[complementarity] Using the different UPDATE packets.

---

From: Robert Raszuk <[email-masked]>
Date: Tue, 19 Jul 2005 05:16:52 -0700

Zhang,

Would you be so kind to comment what proposed in your draft has not 
already been addressed in our ADD_PATHs proposal RR functionality wise ?

Ref: draft-walton-bgp-add-paths-03.txt

Thx,
R.

---

From: Zhang Renhai <[email-masked]>
Date: Tue, 19 Jul 2005 20:04:55 +0800

Hi, Manav
 
 I can't find the draft you mentioned below, are you sure the name is correct?

Thanks 
Zhang