Re: [mpls] I-D Action: draft-rosen-mpls-rfc3107bis-01.txt

Hi Eric,

It is good to extend MPLS to support multi label capability and operation. Here are some comments/suggestions to the draft.

*         Sn 3.2.2, the listed local policies seem all related to label swapping actions.
 it is valuable to add a new local policy as follow:

o   Add a single label or a sequence of labels to the NLRI before propagating the route.

     This policy results that, when a node receives a MPLS packet, it will pop out the label(s)
     and forward the packet to next hop.

*         Sn 4 data plane description is not sufficient. When applying mutli labels on data plane, we need to specify the rules to fill the label stack entries beside pushing labels; e.g. TTL, EXP. To backward comparable (RFC3032), need to clarify TTL, EXP processing applying to the top label before and after label process action.

*         This feature gives each next hop flexibility to determine how many labels to bind a prefix, which may impact Path MTU. We SHOULD avoid each path segment to fragment labeled packets. Either use PMTU discovery or configuration parameter to determine the proper MTU and limit the fragmentation to be done once. If a next hop decides to advertise different # of labels to different prefix, the case will be more complex. The draft needs describe this.

*         This example in Sn 4 is not correct.

   In this case, if S1 receives an MPLS data packet whose top label is
   L21 and whose second label is L22, S1 will remove both L21 and L22
  from the label stack, and replace them with <L11,L12,...L1k>.  Note
   that the fact that L21 is a context label is known only to S1; other
   BGP speakers do not know how S1 will interpret L21 (or L22).

   The ability to replace one or more labels by one or more labels can
   provide great flexibility, but must be done carefully.  Let's suppose
   again that S1 receives an UPDATE that specifies prefix P, label stack
   <L11,L12,...,L1k>, and next hop N1.  And suppose that S1 propagates
   this UPDATE to BGP speaker S2 after setting next hop self and after
   replacing the label field with <L21,L22,...L2k>.  Finally, suppose
   that S1 programs its data plane so that when it processes a received
   MPLS packet whose top label is L21, it replaces L21 with
   <L11,L12,...,L1k>, and then tunnels the packet to N1.

   In this case, BGP speaker S2 will have received a route with prefix
   P, label field <L21,L22,...L2k>, and next hop S1.  If S2 decides to
   forward an IP packet according to this route, it will push
   <L21,L22,...L2k> onto the packet's label stack, and tunnel the packet
   to S1.  S1 will replace L21 with <L11,L12,...,L1k>, and will tunnel
   the packet to N1.  N1 will receive the packet with the following
   label stack: <L11,L12,...L1k,L22,...L2k>.  While this may be useful
   in certain scenarios, it may provide unintended results in other
   scenarios. -end

   Lucy: Label <L21,L22,L2k> is advertised by S1, it does not make a sense that S1
   programs its data plane so that when it processes a received MPLS packet whose top label
   is L21, it replaces L21 with <L11,L12,..L1k>, and tunnel the packet to N1, i.e.
   N1 will receive the packet with the following
   label stack: <L11,L12,...L1k,L22,...L2k>. S1 should replace <L21, L22, ..L2k> with
   <L11,L12,...,L1k> in this case.

Regards,
Lucy

-----Original Message-----
From: mpls [mailto:mpls-bounces@ietf.org] On Behalf Of internet-drafts@ietf.org
Sent: Tuesday, May 31, 2016 9:05 AM
To: i-d-announce@ietf.org
Cc: mpls@ietf.org
Subject: [mpls] I-D Action: draft-rosen-mpls-rfc3107bis-01.txt

A New Internet-Draft is available from the on-line Internet-Drafts directories.

This draft is a work item of the Multiprotocol Label Switching of the IETF.

        Title           : Using BGP to Bind MPLS Labels to Address Prefixes

        Author          : Eric C. Rosen

      Filename        : draft-rosen-mpls-rfc3107bis-01.txt

      Pages           : 22

      Date            : 2016-05-31

Abstract:

   This document specifies a set of procedures for using BGP to

   advertise that a specified router has bound a specified MPLS label

   (or a specified sequence of MPLS labels, organized as a contiguous

   part of a label stack) to a specified address prefix.  This can be

   done by sending a BGP UPDATE message whose Network Layer Reachability

   Information field contains both the prefix and the MPLS label(s), and

   whose Next Hop field identifies the node at which said prefix is

   bound to said label(s).  This document obsoletes RFC 3107.

The IETF datatracker status page for this draft is:

https://datatracker.ietf.org/doc/draft-rosen-mpls-rfc3107bis/

There's also a htmlized version available at:

https://tools.ietf.org/html/draft-rosen-mpls-rfc3107bis-01

A diff from the previous version is available at:

https://www.ietf.org/rfcdiff?url2=draft-rosen-mpls-rfc3107bis-01

Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:

ftp://ftp.ietf.org/internet-drafts/

_______________________________________________

mpls mailing list

mpls@ietf.org<mailto:mpls@ietf.org>

https://www.ietf.org/mailman/listinfo/mpls