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

From: "Liam Casey" <[email-masked]>
Date: Wed, 15 Dec 1999 08:22:59 -0600

Eric,

I'm not at all wedded to 'per platform label spaces'. My reason for
stipulating them for the BGP Labels draft was that I could not see how per
i/f label spaces would work given the way BGP-4 works.

Put it another way - if the BGP-4 Label distribution extensions need to
support per i/f label spaces (and I think you make a good case for that)
then the current draft is seriously deficient and not ready for last call.

Although it is possible to construct specific examples where per i/f labels
won't result in the wrong forwarding in the general case this cannot be the
case because the downstream BGP speaker can't know which containing LSP
upstream BGP peers will use the label in.

Here are three examples of why this is so.

LSR Rd hand out labels to two upstream peers who currently use containing
LSP1 and LSP2 respectively to reach Rd. A change in internal (IGP) topolopy
results in a merge of LSP2 into LSP1 upstream of Rd.

For CoS reasons two or more container LSP's exist between the upstream and
downstream BGP peers.

A route reflector is in use, or routes are redistributed so that one BGP
route advertisement and its corresponding Label is given to arbitrary
upstream  LSR's (from the point of view of the advertiser) with arbitrary
containing LSP's. 

These problems are not easy to fix in the context of BGP, the question is is
it important enough to solve them or just to note that the BGP Label
distribution protocol only works with per platform labels?

Liam 

	-----Original Message-----
	From:	Eric Gray [SMTP:[email-masked]]
	Sent:	December 14, 1999 4:45 PM
	To:	Casey, Liam [SKPK:NS00-I:EXCH]
	Cc:	Multi-Protocol Label Switching WG
	Subject:	Re: Last Call on BGP Labels, Label Type
Clarifications requested

	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
	> 
	>      -----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