Subject: RE: Last Call on BGP Labels, Label Type Clarifications requested

From: "Liam Casey" <[email-masked]>
Date: Tue, 14 Dec 1999 14:55:44 -0600

Eric/Yakov,

Your ID is commendable in its brevity. I feel though that readers would be
helped by making explicit several currently implicit assumptions about the
labels that are being distributed. Please consider the following:

1)	Stating that the labels being distributed are for use in LSP tunnels
that must exist between the BGP speaker receiving the receiving the route
and the next hop advertised for the route.
2)	Stating that only labels from a "per platform label space" can be
distributed using BGP-4.
3)	Related to 1, mention the use of route reflectors, which while they
are BGP peers to LSRs, presumably don't have to be LSR's themselves nor
label distribution peers. After all sec 3.29.1 of [MPLS-ARCH] advances BGP
route reflectors as the reason why using BGP to distribute labels has a
scaling advantage over using LDP

My other concern is with the TLV encoding. I think that designing for the
future would dictate a nested TLV encoding so that:
1)	a label type could be carried - yes I know that the only labels
being distributed are not top of stacks and therefor must be the 20 bit
variety but maybe in the future the level 1 LSP could be a lambda with an
ATM label next.
2)	Prefixes would also have a type - IPv4, IPv6 etc

Liam Casey

---

From: Bora Akyol <[email-masked]>
Date: Tue, 14 Dec 1999 13:05:33 -0800

I think that use of per platform space can be avoided using hierarchical
tunnels (a.k.a label stacks).

Bora

Liam Casey wrote:

>
>
> Eric/Yakov,
>
> Your ID is commendable in its brevity. I feel though that readers
> would be helped by making explicit several currently implicit
> assumptions about the labels that are being distributed. Please
> consider the following:
>
>   1. Stating that the labels being distributed are for use in LSP
>      tunnels that must exist between the BGP speaker receiving the
>      receiving the route and the next hop advertised for the route.
>   2. Stating that only labels from a "per platform label space" can be
>      distributed using BGP-4.
>   3. Related to 1, mention the use of route reflectors, which while
>      they are BGP peers to LSRs, presumably don't have to be LSR's
>      themselves nor label distribution peers. After all sec 3.29.1 of
>      [MPLS-ARCH] advances BGP route reflectors as the reason why using
>      BGP to distribute labels has a scaling advantage over using LDP
>
>
> My other concern is with the TLV encoding. I think that designing for
> the future would dictate a nested TLV encoding so that:
>
>   1. a label type could be carried - yes I know that the only labels
>      being distributed are not top of stacks and therefor must be the
>      20 bit variety but maybe in the future the level 1 LSP could be a
>      lambda with an ATM label next.
>   2. Prefixes would also have a type - IPv4, IPv6 etc
>
>
> Liam Casey