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

From: "Liam Casey" <[email-masked]>
Date: Tue, 14 Dec 1999 16:38:06 -0500

A label can only be from per-interface space if the receiving LSR can tell
which i/f it arrived one. With BGP there is no help from being a label in a
tunnel, since the label can be used in many tunnels. Eg, A route reflector
passes on the label to other BGP speakers.

Liam

	-----Original Message-----
	From:	Bora Akyol [SMTP:[email-masked]]
	Sent:	December 14, 1999 4:06 PM
	To:	Casey, Liam [SKPK:NS00-I:EXCH]
	Cc:	Eric Rosen; Yakov Rekhter; [email-masked]'
	Subject:	Re: Last Call on BGP Labels, Label Type
Clarifications requested

	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

---

From: Eric Gray <[email-masked]>
Date: Tue, 14 Dec 1999 16:44:36 -0500

Liam,

	Unfortunately I have to disagree.  It is possible
to implement your BGP box such that the LSP to a BGP peer
has its own logical interface.  It's even conceivable that
it would retain this same logical identity in moving from
one physical interface to another - though that's a bit of
a different story.

	There's a BIG problem with using the per-platform
label space with stacked labels.  The containing LSP hides
the inner label from intermediate devices which might - for
example - be able to determine that someone is fraudulently
using an external link.

	Using the per-platform label space has this security
hole in general if one is not careful whose labels one trusts.

--
Eric Gray

Liam Casey wrote:
> 
> A label can only be from per-interface space if the receiving LSR can
> tell which i/f it arrived one. With BGP there is no help from being a
> label in a tunnel, since the label can be used in many tunnels. Eg, A
> route reflector passes on the label to other BGP speakers.
> 
> Liam
> 
>      >      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
>      >      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