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

Lucy yong <> Mon, 20 June 2016 19:38 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 0AC5412D1D5 for <>; Mon, 20 Jun 2016 12:38:54 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -5.636
X-Spam-Status: No, score=-5.636 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-1.426, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=0.01] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 53bO-Xm9cfpu for <>; Mon, 20 Jun 2016 12:38:50 -0700 (PDT)
Received: from ( []) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id E069412D6A6 for <>; Mon, 20 Jun 2016 12:38:49 -0700 (PDT)
Received: from (EHLO ([]) by (MOS 4.3.7-GA FastPath queued) with ESMTP id CMH43783; Mon, 20 Jun 2016 19:38:46 +0000 (GMT)
Received: from ( by ( with Microsoft SMTP Server (TLS) id; Mon, 20 Jun 2016 20:38:45 +0100
Received: from ([]) by ([]) with mapi id 14.03.0235.001; Mon, 20 Jun 2016 12:38:42 -0700
From: Lucy yong <>
To: Eric C Rosen <>
Thread-Topic: [mpls] I-D Action: draft-rosen-mpls-rfc3107bis-01.txt
Thread-Index: AQHRu0WQuArjVPNYwkm9pBBbHtbxHZ/uAHZwgAVMEYD//42ZsA==
Date: Mon, 20 Jun 2016 19:38:42 +0000
Message-ID: <2691CE0099834E4A9C5044EEC662BB9D572A3D86@dfweml501-mbb>
References: <> <2691CE0099834E4A9C5044EEC662BB9D5729A50D@dfweml501-mbb> <>
In-Reply-To: <>
Accept-Language: en-US
Content-Language: en-US
x-originating-ip: []
Content-Type: multipart/alternative; boundary="_000_2691CE0099834E4A9C5044EEC662BB9D572A3D86dfweml501mbb_"
MIME-Version: 1.0
X-CFilter-Loop: Reflected
X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A090205.57684647.004D, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32
X-Mirapoint-Loop-Id: 8fc71577a03939370d828ccd1bd4e9d5
Archived-At: <>
Cc: "" <>
Subject: Re: [mpls] I-D Action: draft-rosen-mpls-rfc3107bis-01.txt
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Multi-Protocol Label Switching WG <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Mon, 20 Jun 2016 19:38:54 -0000

Hi Eric,

Pls see inline below.

From: Eric C Rosen []
Sent: Monday, June 20, 2016 2:07 PM
To: Lucy yong
Subject: Re: [mpls] I-D Action: draft-rosen-mpls-rfc3107bis-01.txt

Hi Lucy,

Thanks for reviewing 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.
I think this is a sub-case of "replacing one label with multiple labels".
[Lucy] IMO, two are different. The case here does not replace any label in NLRI, just add one or multiple labels to the NLRI.

*         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.
3107bis does not convey TTL or TC values, so I think all we need to say is that "the setting of the TTL and TC fields in the label stack of a data packet is determined by local policy".
[Lucy] True. But 3107 does describes data plane operation accordingly. So it should at least mention these fields setting must be compatible to RFC3032 because no intention to change here.

*         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.
MPLS does not have fragmentation, so it is not possible to fragment labeled packets ;-)
[Lucy] pls check RFC3032.

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.
3107bis provides a mechanism that can be used to propagate an instruction to push a sequence of labels onto a packet's label stack.
[Lucy] yes.
You're right that a router should not be instructed to push on so many labels that the MTU is exceeded.  But this is always an issue with MPLS, and is not specifically related to 3107bis.  It is outside the scope of this draft to specify procedures for determining the maximum number of labels that can be safely pushed.
[Lucy]  This mechanism adds more complex for Path MTU computation. It is good to point out it when describing data plane.

*         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>.
Whether this example corresponds to an actual use case is debatable.  The example merely shows something that can be done with the specified mechanisms.

This scenario would only be useful if S1 knows somehow that L22 will rise to the top of the packet's label stack at a node to which L22 is meaningful.
[Lucy] IMO: this is a fault case.

S1 should replace <L21, L22, ..L2k> with
   <L11,L12,...,L1k> in this case.
No, 3107bis does not (and should not) modify any of the rules for processing the label stack of an incoming packet.
[Lucy] ??