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

From: Aleksi Suhonen <[email-masked]>
Date: Mon, 01 Mar 2010 09:45:20 +0000

Hi,

I had a lot of questions when I read this draft, but most of them were 
answered by just rereading it. These ones remained:

This community is sort of identical to the MED attribute? Only this one 
is controlled by the receiver, where as MED is (supposed to be) 
controlled by the sender? Or did I misinterpret something? What happens 
when both are specified on the same route?

Consider an exchange point with 1Gbps and 10Gbps ports. If the receiver 
and the sender of a route have different speed ports, how is this 
community supposed to behave?

Is the mapping between bandwidth and the community value supposed to be 
implementation specific or up to the router configuration? Has someone 
given thought to what happens to this community when we get Exabit/s or 
Zettabit/s ports on the Internet?

I guess they are silly questions, but I then guess I'm a silly person,

-- 
	Aleksi Suhonen

---

From: <[email-masked]>
Date: Mon, 1 Mar 2010 12:06:42 +0100

Hi Pradosh, Rex, John, all,

Please find below some comments on the draft

> Introduction
[..]
>   it might be useful to provide the speaker with information that
would
>   help it distribute the traffic unequally based on the cost of the
>   external (DMZ) link.

Why "cost" instead of "bandwidth"?

> Link Bandwidth Extended Community
>
>   When a BGP speaker receives a route from a directly connected
>   external neighbor (the external neighbor that is one IP hop away)

Why restricting to directly connected neighbour? Even with multihop eBGP
sessions (between loopback or across IP routers) I guess we could
(configure and) advertise the bandwidth of the (AS) external link.

> The community is optional non-transitive.  A border router MUST strip
the
>   link bandwidth community from a route when it advertises the route
to
>   an external neighbor.

For some readers, the purpose of the second sentence may be ambiguous:
- is this redundancy with the first one (non-transitive)?
- is it overriding the RFC 4360 definition of "non-transitive"?

Given that the RFC 4360 definition of non-transitivity, could already be
subject to interpretation (cf draft-decraene-idr-rfc4360-clarification )
I would suggest removing the second sentence, or at least clarifying its
purpose (e.g. Therefore, as defined in RFC 4360, ") and then
copy/pasting the RFC 4360 text. (which BTW makes a distinction between
external neighbors within or across confederation, while the current
text in the draft does not)

> The bandwidth of the link is expressed as 4 octets in IEEE floating
point
>   format, units being bytes per second.

As generally link bandwidth are expressed in bits per seconds (e.g. 2,5G
10G, 40G, 100G) to avoid possible misunderstanding or misinterpretation,
it might be useful to stress that that the unit is indeed bytes per
second. E.g. "The bandwidth of the link is expressed as 4 octets in IEEE
floating point format, units being bytes (not bits!) per second."

Note that the above proposed wording is already used in some routing
area's RFC (4203, 5543, 5307) which all states "The units are bytes (not
bits!)  per second"

Thanks,
Best regards,
Bruno

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of
John
> G. Scudder
> Sent: Friday, February 26, 2010 7:44 PM
> To: [email-masked] List
> Subject: [Idr] Working Group Last Call for BGP Link Bandwidth
> ExtendedCommunity, draft-ietf-idr-link-bandwidth-01.txt
> 
> 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
> _______________________________________________
> Idr mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/idr

---

From: Pradosh Mohapatra <[email-masked]>
Date: Mon, 1 Mar 2010 12:14:17 -0800

On Mar 1, 2010, at 1:45 AM, Aleksi Suhonen wrote:

> Hi,
> 
> I had a lot of questions when I read this draft, but most of them were answered by just rereading it. These ones remained:
> 
> This community is sort of identical to the MED attribute? Only this one is controlled by the receiver, where as MED is (supposed to be) controlled by the sender? Or did I misinterpret something? What happens when both are specified on the same route?

And additionally MED is actually used in the best path selection process, whereas link bandwidth is not. Link bandwidth comes into effect after the bestpath and multipath selection process (as specified in the deployment considerations section) to do unequal load sharing of traffic across the selected paths. To that effect, they are complimentary and both can be present in the UPDATE message.

> 
> Consider an exchange point with 1Gbps and 10Gbps ports. If the receiver and the sender of a route have different speed ports, how is this community supposed to behave?

The ext community explicitly encodes the dmz links' bandwidth (e.g. egress router's points of attachment).

> 
> Is the mapping between bandwidth and the community value supposed to be implementation specific or up to the router configuration? Has someone given thought to what happens to this community when we get Exabit/s or Zettabit/s ports on the Internet?

The draft specifies:
"The bandwidth of the link is expressed as 4 octets in IEEE floating point format, units being bytes per second. 
"
Also look at Bruno's comment to make this explicit.

- Pradosh

---

From: <[email-masked]>
Date: Wed, 3 Mar 2010 14:42:43 +0100

One additional comment on the draft.

I guess that implicitly, the draft considers that no more than _one_
Link Bandwidth extended community should be attached to a route. If so,
for the sake of clarity and to avoid possible issues, I'm in favour of
stating it explicitly in the document.

Then, how is it proposed to enforce this uniqueness? I could think of
two ways:
-a- the Service Provider / user is responsible for this.
-b- the implementation enforce it

In both case, I guess this translates into removing existing Link
Bandwidth Extended Community(ies) when setting one.

AFAIC, I'm in favour of option "b" (enforced by the implementation). As:
- In case of issue, I could blame the implementation rather than myself
:-)
- It seems easier and more effective to do it (correctly) in half a
dozen implementations rather than 10 000s of configurations.

Comments welcomed. 

Thanks,
Regards,
Bruno

> From: [email-masked]
> 
> > A URL for the draft is
http://tools.ietf.org/html/draft-ietf-idr-link-