The MPLS WG Archive

[Olivier Bonaventure <Olivier.Bonaventure@info.fundp.ac.be>]

The IESG wrote:
> 
> The IESG has received a request from the Multiprotocol Label Switching
> Working Group to consider Carrying Label Information in BGP-4
> <draft-ietf-mpls-bgp4-mpls-04.txt> as a Proposed Standard.

The current BGP-MPLS draft [BGP-MPLS] allows a border
router to distribute one or more labels when announcing a route towards
a given. This implies that once a border router announces a route with the current draft, it
automatically agrees to accept labelled packets towards the announced
address prefix. 

This coupling between the announcement of a route (and the associated
address prefix) together with the binding to a label corresponds to today's
utilization of BGP for inter-ISP peerings and for MPLS-based VPNs. However,
there are many situations where a border router would like to 
be able to announce a route (i.e. provide reachability information)
without immediately accepting labelled packets along this route and without already 
accepting labeled packets along this route. The announcement of a route
without binding a label to this route would mean that the border
router accepts to consider LSP establishment requests with an 
appropriate signalling protocol (e.g. RSVP-TE or CR-LDP).

The decoupling between the announcement of the reachability of a prefix
and the acceptance of traffic along the announce route would allow
border routers to have a better control on the MPLS traffic flowing through
them since the acceptance of labelled packets towards a given prefix
would be subject to the establishment of a signalled LSP.
 

In [BGP-MPLS], a label stack is associated with each prefix advertised by a
border router. This is done by carrying the label stack inside the 
Network Layer Reachability Information (NLRI) using SAFI=4. In this case, the
NLRI is encoded as one or more triples of the form

      +---------------------------+
      |   Length (1 octet)        |
      +---------------------------+
      |   Label (3 octets)        |
      +---------------------------+
      .............................
      +---------------------------+
      |   Prefix (variable)       |
      +---------------------------+

In [BGP-MPLS], the label field is defined as :

"b) Label:

 The Label field carries one or more labels (that corresponds to
 the stack of labels [MPLS-ENCAPS]). Each label is encoded as 3
 octets, where the high-order bit contains "Bottom of Stack" (as
 defined in [MPLS-ENCAPS]). The following high-order three bits
 must be zero.  The remaining 20 bits contain the label value."

It would be very useful to change this text into :

"b) Label:

 The Label field carries zero or more labels. When no
 label is present, the Label field occupies zero octets.
 Otherwise, the Label field  corresponds to
 the stack of labels [MPLS-ENCAPS]). In this ase, each label 
 is encoded as 3 octets, where the high-order bit contains
 "Bottom of Stack" (as defined in [MPLS-ENCAPS]). The following 
 high-order three bits must be zero.  
 The remaining 20 bits contain the label value."


The new text would allow a border route to announce that a
prefix is reachable by using labelled packets without already
binding a label along this route. This allows the reachability
information to be decoupled from the acceptance of labelled
packets along the announced route.

An alternative to this solution could be the utilization of a
specific community value meaning that any route annouced with
this special community cannot be used to transmit labelled packets
and that an LSP must be explicitly established before using this
route. In this case, the semantics of a new empty label stack 
associated with the prefix announcement is questionnable, and I
believe that it would be simpler to allow border routers
to announce a prefix with BGP-MPLS without being always
forced to associate at least one label to this prefix.

The proposed modification to the current BGP-MPLS draft is minor.


Olivier Bonaventure