Subject: [Idr] Working Group Last Call for BGP Link Bandwidth Extended Community, draft-ietf-idr-link-bandwidth-01.txt

From: "John G. Scudder" <[email-masked]>
Date: Fri, 26 Feb 2010 20:44:03 +0200

Folks,

This is to start the IDR WG Last Call on advancing BGP Link Bandwidth Extended Community, draft-ietf-idr-link-bandwidth-01.txt as an Proposed Standard RFC. The deadline for comments is March 15, 2010.

A URL for the draft is http://tools.ietf.org/html/draft-ietf-idr-link-bandwidth-01

--John

---

From: "Joel M. Halpern" <[email-masked]>
Date: Fri, 26 Feb 2010 14:55:07 -0500

Looking at this draft, and thinking about the interesting cases we have 
had for trying to assign traffic to links based on utilization, I really 
think that the draft needs significantly more text on how to safely use 
the information, before it can be published as an RFC.

One way to use it would be for the ingress BGP speaker to be tracking 
the bandwidth to every destination (or finer granularity if it is using 
5-tuple based path selection), and which of the multiple exists each set 
is currently using.  That would allow the router to know how much 
traffic it is shifting if it changes the allocation.

Conversely, if the router is trying to use this advertisement without 
some form of knowledge about how much traffic it is affecting, and which 
traffic is currently reflected in the advertisements it is seeing, 
things can get very ugly and oscillatory.

Also, if this is going to affect the decision process, and if the 
traffic is not tunneled, then care must be taken so that the decision 
process is stable across the domain.  Otherwise, trying to adjust for 
bandwidth when you don't actually know where the traffic is going to go, 
is pretty strange.

I can understand the value in addressing the problem.  (Tom Scholl 
brought up a different approach to the same problem, which also had 
issues, at NANOG this week.)  I am considered that as currently written 
we are not saying enough to make it safe to use this information.

Yours,
Joel M. Halpern

John G. Scudder wrote:
> _______________________________________________
> Idr mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/idr
>

---

From: Robert Raszuk <[email-masked]>
Date: Fri, 26 Feb 2010 22:10:25 +0100

Hi Joel,

> had for trying to assign traffic to links based on utilization,

+

 > brought up a different approach to the same problem,

... leads me to believe that you are talking about different problem set 
then what the draft aims to address.

The draft proposes to carry the _static_ value of external peering 
link's cost.

The draft does not attempts to change this value as a function of amount 
of transiting traffic. The only change of this value and potential need 
to re-advertise received paths would be trigger based on manual 
operator's reconfiguration of link cost.

I see no oscillation of any sort which this solution may cause. It just 
allows to perform unequal cost bgp level load balancing.

The value is mapped to next hop so I am not sure I would share your 
point of view of "not knowing where the traffic is going to". I think 
this is implict assumption that to activate unequal cost load balancing 
one needs to have some form of encapsulation between the sender and next 
hop.

Cheers,
R.

> I really
> is currently using. That would allow the router to know how much traffic
> it is shifting if it changes the allocation.
>
>> This is to start the IDR WG Last Call on advancing BGP Link Bandwidth
>> Extended Community, draft-ietf-idr-link-bandwidth-01.txt as an
>> Proposed Standard RFC. The deadline for comments is March 15, 2010.
>>
>> A URL for the draft is
>> http://tools.ietf.org/html/draft-ietf-idr-link-bandwidth-01
>>
>> --John

---

From: Robert Raszuk <[email-masked]>
Date: Fri, 26 Feb 2010 22:17:18 +0100

Hi John,

I have two comments for the current text of the draft:

1.

This actually occurred when I was replying to Joel's mail ...

The draft does not say that this attribute should not be propagated 
further when anywhere in the AS domain the next hop self has been 
configured.

IMHO we should keep next hop and Link Bandwidth Community tightly coupled.

2.

The current text says:

    same.  Alternatively, the path between the load sharing router and
    the exit points could be label switched.

I would propose to replace it with:

    same.  Alternatively, the path between the load sharing router and
    the exit points could be label switched or IP encapsulated.

or

    same.  Alternatively, the path between the load sharing router and
    the exit points could be using some form of encapsulation.

Many thx,
R.

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

---

From: "Joel M. Halpern" <[email-masked]>
Date: Fri, 26 Feb 2010 16:18:53 -0500

Ahh.  Then I misunderstood the draft.  If all it means to carry is the 
static capacity, then no, there is no osciallation problem.
However, it is tricky to utilize such a static value in forwarding 
policy, unless one starts getting into fuzzy logic.

We (the IDR working group) have a tendency to craft tools with uses in 
mind, but not to explain how they would be used.  This seems to be 
counter-productive for standards.

Yours,
Joel