Subject: [Idr] draft-rfernando-idr-link-bandwidth-00.txt as IDR WG document

From: Yakov Rekhter <[email-masked]>
Date: Tue, 24 Mar 2009 07:00:59 -0700

Folks,

Just to add to the e-mail below, if anyone is aware of the IPR
related to the draft, please follow the procedurs of rfc3979.

Yakov.
------- Forwarded Message

Date:    Tue, 24 Mar 2009 06:53:45 -0700
From:    Yakov Rekhter <[email-masked]>
To:      [email-masked]
Subject: [Idr] draft-rfernando-idr-link-bandwidth-00.txt as IDR WG document

Folks,

At the IDR WG meeting yesterday we had a fairly strong consensus
for accepting draft-rfernando-idr-link-bandwidth-00.txt as an IDR
WG document. Given that, unless we have a fairly strong consensus
on the mailing list against accepting this draft, the draft will
be accepted as an IDR WG document.  The deadline for comments is
April 6, 2009.

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

------- End of Forwarded Message

---

From: "PAPADIMITRIOU Dimitri" <[email-masked]>
Date: Tue, 24 Mar 2009 18:33:24 +0100

Yakov:

The Link Bandwidth Community used to be part of the BGP Extended
Communities Attribute document (now RFC4360) until it was removed in v09
after review. At that it was stated that in order to perform
BW-proportional BGP load-balancing, BGP multipath load balancing should
be first documented. Isn't this condition still valid in the present
case and the corr.mechanisms to be documented beyond limited deployment
consideration part of Section 3?

Thanks,
-dimitri.

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On 
> Behalf Of Yakov Rekhter
> Sent: Tuesday, March 24, 2009 3:01 PM
> To: [email-masked]

---

From: Rex Fernando <[email-masked]>
Date: Fri, 27 Mar 2009 12:57:28 -0700

Hi Dimitri,

|  The Link Bandwidth Community used to be part of the BGP Extended
|  Communities Attribute document (now RFC4360) until it was removed in v09
|  after review. At that it was stated that in order to perform
|  BW-proportional BGP load-balancing, BGP multipath load balancing should
|  be first documented. Isn't this condition still valid in the present
|  case and the corr.mechanisms to be documented beyond limited deployment
|  consideration part of Section 3?

The draft lists the cases (although not in so many words) where link bandwidth can be safely deployed i.e. when the candidate paths are identical until the IGP distance step in path selection or you have a tunneled network. Either of these would ensure loop freedom. And that's all there is to it.

We'll be happy to omit the word "multipath" from the draft since it lacks prior definition and expand on the deployment scenarios a bit if you feel strongly about it.

- Rex

---

From: "PAPADIMITRIOU Dimitri" <[email-masked]>
Date: Sat, 28 Mar 2009 18:08:22 +0100

Hi Fernando: 

> From: Rex Fernando [mailto:[email-masked]] 
> Sent: Friday, March 27, 2009 8:57 PM
> To: PAPADIMITRIOU Dimitri; Yakov Rekhter; [email-masked]
> Subject: RE: [Idr] draft-rfernando-idr-link-bandwidth-00.txt 
> as IDR WGdocument
> 
> Hi Dimitri,
> 
> The draft lists the cases (although not in so many words) 
> where link bandwidth can be safely deployed i.e. when the 
> candidate paths are identical until the IGP distance step in 
> path selection or you have a tunneled network. Either of 
> these would ensure loop freedom. And that's all there is to it.
> 
> We'll be happy to omit the word "multipath" from the draft 
> since it lacks prior definition and expand on the deployment 
> scenarios a bit if you feel strongly about it.

I think we have first to agree on the definition of "link bandwidth"

- either consider the link bandwidth as the "nominal link capacity"
which is thus a fixed and configured value (equivalent to link cost)
that does not result in variability in the multipath selection process
at the border router (PE1 in the slide material) beside local policy
decision. this would lead to a control-driven usage of this attribute.

- or consider the link bandwidth as the "available link bandwidth" aka
"residual capacity" which thus leaves possibility for varying the
multipath selection process over time depending on the actual value of
this attribute. this would lead to a traffic-driven usage of this
attribute. 

I would be advisable that you clarify on this point to see how to
consider Section 3 statement:

"The usage of this community is restricted to the cases where BGP
multipath can be safely deployed."

Thanks,
-dimitri.