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

Eric C Rosen <erosen@juniper.net> Tue, 21 June 2016 14:56 UTC

Return-Path: <erosen@juniper.net>
X-Original-To: mpls@ietfa.amsl.com
Delivered-To: mpls@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 92E3212D854 for <mpls@ietfa.amsl.com>; Tue, 21 Jun 2016 07:56:09 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.792
X-Spam-Level:
X-Spam-Status: No, score=-1.792 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_DKIM_INVALID=0.01] autolearn=no autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=fail (1024-bit key) reason="fail (body has been altered)" header.d=junipernetworks.onmicrosoft.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6JYa7XkvXHPK for <mpls@ietfa.amsl.com>; Tue, 21 Jun 2016 07:56:07 -0700 (PDT)
Received: from na01-bl2-obe.outbound.protection.outlook.com (mail-bl2on0122.outbound.protection.outlook.com [65.55.169.122]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7626712D7F2 for <mpls@ietf.org>; Tue, 21 Jun 2016 07:56:07 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=junipernetworks.onmicrosoft.com; s=selector1-juniper-net; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=oog55EV25579Bu7lzRoEGrdynqRvoscFJSnpjCjE/ac=; b=Vf+OSIy3DT5Fg9ls26zQ1t5S82hK27q8aRmQ8flQ8iyh8DSMXh2XM7R1DFDps0yvyCJaaNKc8iPD/8LCu7ciQQkvaO1K8/FEAnq/k/SZMxJfIACsGNXfey8di35ePbSmscbZvZsZ9pxHAbIWJrco2fLYo6a3TpytsWbkNwG+lh4=
Authentication-Results: spf=none (sender IP is ) smtp.mailfrom=erosen@juniper.net;
Received: from [172.29.38.148] (66.129.241.12) by BL2PR05MB2178.namprd05.prod.outlook.com (10.167.98.138) with Microsoft SMTP Server (TLS) id 15.1.523.12; Tue, 21 Jun 2016 14:56:04 +0000
To: Lucy yong <lucy.yong@huawei.com>
References: <20160531140504.18647.87194.idtracker@ietfa.amsl.com> <2691CE0099834E4A9C5044EEC662BB9D5729A50D@dfweml501-mbb> <f004001c-f6ed-c0d4-d231-fa90847bfc88@juniper.net> <2691CE0099834E4A9C5044EEC662BB9D572A3D86@dfweml501-mbb>
From: Eric C Rosen <erosen@juniper.net>
Message-ID: <b3df71ec-6650-f1d1-5e4d-3af74e5b1d9e@juniper.net>
Date: Tue, 21 Jun 2016 10:56:00 -0400
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.1.1
MIME-Version: 1.0
In-Reply-To: <2691CE0099834E4A9C5044EEC662BB9D572A3D86@dfweml501-mbb>
Content-Type: multipart/alternative; boundary="------------3EFD3EF9F21EA6D75BE6BED6"
X-Originating-IP: [66.129.241.12]
X-ClientProxiedBy: BN3PR0301CA0084.namprd03.prod.outlook.com (10.160.152.180) To BL2PR05MB2178.namprd05.prod.outlook.com (10.167.98.138)
X-MS-Office365-Filtering-Correlation-Id: 7471d418-7c79-4d7b-43cf-08d399e42b85
X-Microsoft-Exchange-Diagnostics: 1; BL2PR05MB2178; 2:G8wdhL0JRfCx1YslbaxERJSgtajQ2lRLUSKkBm7SaR6dcQb4HrSUEUqWfL6FfZQ7/thDTQz/lzKtRgYoteDxD5V9nLj5apJbYyz5JvCCjojbuy1Hs/d3R2II92zRYRHZKGMrfVjQvXUBrG8bHi2IYvPIeD1ilQyirpLAQiDsOtR4LTu1dlFissQNDiUevIAl; 3:FhZ6YWYnIFABnwJHV7hepbgyBJ1kurUcR4eqqgglLbK+M/rqZKSQOo/egieH9Xw3bk26Re3kBbpzFd14Xbu4D/TIazl4FCeAIcY1aZ6xZ36EHU8exL1WGP654hhAPERa
X-Microsoft-Antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BL2PR05MB2178;
X-Microsoft-Exchange-Diagnostics: 1; BL2PR05MB2178; 25:zPWnf0d1WpDUdv7ZwcHqJmnzxe1fBExrulx+mnwyhGleYm3A0HfsPSxuk4xwEub+Ubh/W0ZREZN1IxL4u1WkNUnm8kXIAO2+JEbZA36DX8Gim6RExLyYjxCUw0NlBZjGL2jc///xwClEMAZfNALrOVfVqiT2jJTurIH39H6EATkrce7fbBepsy0HG+x4IKNOYafAx1bAnuuzw7vE8nGnMEdO2P0N+hHdy7c6moIO8p25ailE05+RbjWAUf5FDyYsI8qJSc+XhYWZPhlXsDj2QI9HAtG+JfRSbuiNYyXV7E8ouBI8QbHAdeqWvwD5P4YWm7MsO/Z5j2XgxWTXKc8JwvAVxX0Jcq1MIFOyVag+i3sCab0PsHbWRPFU+Mc/O/ElQU2FXgNduO8QP8dHlJXM3o3EHdDKVh+yMbyTkxr2mVdvIPOw/xKNAOrlCOIAfTRcTRAaO8NI0kdqeTS6kS5bc/+TAbyPUvhO5Qkx0zRBTKuXl1x4JpC7QTnuJ78bBH/wi9EpaEM849oxHmldZshnkbWduWkVjDeu9R3yIqwsAKqBZ/rRenX+cqXGwpxTRtwbPguKD1cIp356urcSUb9SZ04uIAgr8qux2z4/8CocTCEcKF20NqGp47hrbfUqARKMrkpCyYJVwgNGBT9Pyr1o8WIbOuDDfuapb8sBDdTFW/12RPUf88/2VlsTrMTdQEYztM7zFJbxF+PG0pdTLqtCDEZXxNlpLn+2rdatbBeGsixTm86MBS2C8FUSS7N7ruWcmRpK3rcXMufqnQZnuJVU1l81oWrdLn/VhmmhCwgsX94ZpJkoPxjEzBI7BmH0eFVCmvugnOZ4H+Gn684nT2nTxA==
X-Microsoft-Exchange-Diagnostics: 1; BL2PR05MB2178; 20:+4bQrT9qFQYpjh95udRcAxN/bRpOuKqnP6R1SaBEL9NPop5Mrx7qHZxIaLIk600fDy/WHjboTAgeM/ImCWw4y86F1iSCH3PxQUzzqoQSzwrlJe6XWvekbCENaUoVnhg8HUF3v7kKLJ205S0t1xlawDF19JEJnQ/ICdMxomzDqU/pbWn8nnZ3CQq8TL2K33fa8+o8AWsNuFLEtJQG+4TgUoJM/QD2YcllZnmxpowuPYmTamZ0oowb0Vpz8KUxonY0+Uca9H1Rri77iXR6J6DES83DALYIATy/gS3AA3IKfoQ8oQBFxGr5hx00cFUDWddAvXtNHRkO/AbFImWN1rwTFNcyMPOkLhbyeJfUEEN3Vo8Jfvt9TfYkwz7bSgLQtBzM2nADwmHSdKgTuvW48tzLMykM7qL0eZOZXYcFF5JGvk8Ik1gN2T1jXt6iTgrT5udTxMCtQqQKnuhPJoMU5h0ms9j/UQXFI32rZXOc1bTi/jTgEdtdMgYiVzx3zL4a2Hlv; 4:FhfRpi+ALQpWWoX0qsZ0v7VlZOerQ/J/5I78np+gjkg5TuxT6Y801TgouAv5/JL1XJMaKjsexIUfGBTypAGCxh7/E7gie/cInSyxqpNGmfg/OeDd1ek7ts/r0c6+jJE/zfnABGzC/iyTPvEnrPiQa0y+S+sdKauU6zF2DDXis6cQSmbUKdw2sr6iYOtwTagHU40kAjQm1D2U6XxI03otaKexn+UsvRwq52AHBnZDaDUB2crCPB3L5pwi8aZ3wFJpqzT4nXBVqgZ3AluuPEZwsLnfQ71DxbyHm6z6bc7QvU5BHX1P04Py8ZzKTsjSsezdlwKACvWNUiFvr6nNALmG5yImRsPfbnq/2IXKkFCDWmW47Yzyz+uoBpiOGTBVWl8aoDeJzuTJUZx8nk2LIiGCHZZCndZ5LvGBd/tx36wpZ2c=
X-Microsoft-Antispam-PRVS: <BL2PR05MB217801AC9427E3295A30605DD42B0@BL2PR05MB2178.namprd05.prod.outlook.com>
X-Exchange-Antispam-Report-Test: UriScan:(788757137089);
X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(601004)(2401047)(5005006)(8121501046)(3002001)(10201501046)(6055026); SRVR:BL2PR05MB2178; BCL:0; PCL:0; RULEID:; SRVR:BL2PR05MB2178;
X-Forefront-PRVS: 098076C36C
X-Forefront-Antispam-Report: SFV:NSPM; SFS:(10019020)(4630300001)(6049001)(6009001)(7916002)(199003)(189002)(2906002)(76176999)(84326002)(4001350100001)(64126003)(50986999)(31696002)(512944002)(8676002)(4326007)(54356999)(81166006)(81156014)(65956001)(105586002)(36756003)(77096005)(97736004)(189998001)(110136002)(42186005)(83506001)(3846002)(7736002)(6116002)(586003)(65806001)(19580405001)(31686004)(66066001)(106356001)(33646002)(230783001)(2950100001)(68736007)(101416001)(92566002)(93886004)(7846002)(86362001)(65826006); DIR:OUT; SFP:1102; SCL:1; SRVR:BL2PR05MB2178; H:[172.29.38.148]; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en;
Received-SPF: None (protection.outlook.com: juniper.net does not designate permitted sender hosts)
X-Microsoft-Exchange-Diagnostics: =?Windows-1252?Q?1; BL2PR05MB2178; 23:x3huvzx1VW2gQqUr+QocTmUyfx0HOeSoeuz+l?= =?Windows-1252?Q?9Zv/M9gbKUaJ8xK1vUEocO9qmgKNtCsX84KuVLaGsysImhqqdwALlVSv?= =?Windows-1252?Q?8QZpH+NB+I0WwHqYIXyF8hDc9d7TzsRlWoiRfyRexhpVPZVEQ8bXgc2r?= =?Windows-1252?Q?oSLk9AMrmPAE3ExfmLX2jJJ0InnNM91sDXxCpt5rn3HE+FH9E5breiFK?= =?Windows-1252?Q?tAG6WeM7M34evJ+QsIX1tke3WgHs6cG/kiDqvukfm1duvaozUx+RLhE9?= =?Windows-1252?Q?eN/94VY0so44ShED2KKXtNj4YJhVzICmfVwMMhBdiXv7vhjl8X3sBPvc?= =?Windows-1252?Q?yBcw4embXMq/9wngp8BI/nZs27Maea0Lzl0ZU/Ai7HQudjOGIdRN/qXC?= =?Windows-1252?Q?b7eGFt9ZKCoNTmk0JGKCdPDCzX11jSFynwVL6IMzFl3y3TdZGZzRiK/m?= =?Windows-1252?Q?lDABvXge3iRtBrHfGq5HQHic5e76SQI7OVPpv+Phit2UeWJoA0ZevMZC?= =?Windows-1252?Q?168Ka1d7L30//9qReNQWrCNIjFzQec+PdxvbmumELK+YPj96wVjEqwE6?= =?Windows-1252?Q?WnlKg8zLuPe9BEJ7Gi9XDZxciMGm5Ma0vM2rgA+h+N0atrkAV/lvHLtJ?= =?Windows-1252?Q?p7z8XRMLbmeeM2IpLgevgtDbAgE4lG4avRh9V/LrOxBo3MXW6+F2Qpvb?= =?Windows-1252?Q?ZnPyAntkfPajJ2VPrG3qUnnVRf7OhBf5Pak6PCMVP06Aa20hihhnBbyp?= =?Windows-1252?Q?XTbn/lwDMRw9swgmBYsFB6P5sI+YYReaNHWlQddZ4LRfF1gYh0YxZmGr?= =?Windows-1252?Q?7a1ieWNlrno0yd1ICYhDIL2seDiIk28MI0vvT4eginBwRDT0VTA8ZQYv?= =?Windows-1252?Q?UjiTm0tKxxJxu/8lrYoVHhmo0KFADOk3msJJ+TE7Iwss56e+Rz+9B0hD?= =?Windows-1252?Q?5TV72DTz6Jfn3ncZeVLBS7t8EV3qEd+xKA5+kBhBv6LntuY1C4TvKmkz?= =?Windows-1252?Q?45/3U4Xrq2HMl/N+gLhW4zsi40Q5TIEoiUTtPmrvqxFN0gjL4yixuhZG?= =?Windows-1252?Q?DshzImirOflUaqHhB8w8Hks5bCwatqQmrL9reZj+0vcSDAjMi2QK4Von?= =?Windows-1252?Q?rJrvlIbDuwRK4EpMQBuMhCTTs2OmMwb6VYWxVFQQhKowKONBgu3ZzyTl?= =?Windows-1252?Q?zatvaQN6lBg6VKTBhZaP79KgTknRQoYavSOza1Hod5Muf2LKSibaCANT?= =?Windows-1252?Q?dm3O/noHDlaygwj0g=3D=3D?=
X-Microsoft-Exchange-Diagnostics: 1; BL2PR05MB2178; 6:7jWc8lPtHca6hjj0OBlkqVIWWlA7TSb2bsNZJjEO1FXVQwR5v69RNcpjRc15MB2ZeRrXTFJ5eegm4CnwNZAZOlXpRvQ6gAXwOx9uXJ8Y9XFWo5skmPHXl61QmhWi+kgytKkyOCxrKFR6dGfRgzNv9J++Dmp0Zh5U1dAG3T18KseGU4bEaETNNDZdBydUxI1kO56DX9RIw/fjC3muatAh55jfxe735Io5hE3olwp40WAO+mJqPPK0daaHN/ojUFSHVbBRwwkYhdmt+LGXicVrHqADgJPF+vSBGVjF+8pR8es93sbpJmRL7UYDJ1U/Y9V7IqONQnyGiffZ/4rgJWrW2g==; 5:W/rI7gkREh2ZpyDj7PLZ88DEF/aDOsfX2FTi1mGzSP0Giv8h8ZvhAuF6QIsHeSY01bfykyfnixsHVThUnTRYfNZeUi5amgNK4zbFQwq0C3sEvKVCbeEURp0vw94CSqirLN+hzRR3NibIPZTcpP9N+A==; 24:tbB673IwOKyL09UHfGidBWvI1aPl0P10ZI7oSW89oAArXq6bS0HgtViP8oKJsDQ5c+86sneRkNwhC8af+4DEiKGMoMjWY5C+C5HshZncuYY=; 7:yZDoSh5M66kDaLyz2HEc6jZtm0tUaHF8CrBwQEz0fjsEFvzAFSm36jaD46tDo20cYy3yp/TPGCjoS7tTFv+JMUKJdFOk5Xx5Im/uFEpTw4utP88ShUBDAyFNre+uXOnMWacNPpWb/Fwc6kNXbDLT5VkN1+boi5SXmeB3cqNi/F2IR6R7XZlXV5YJfxdNtQPTH1KZxsqtgANXYTedBeWgt73mGxqOUEdrzzg1hlemJtYXhJ2iQPx3VmhLQ0jMm1tG
SpamDiagnosticOutput: 1:99
SpamDiagnosticMetadata: NSPM
X-OriginatorOrg: juniper.net
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 21 Jun 2016 14:56:04.7095 (UTC)
X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted
X-MS-Exchange-Transport-CrossTenantHeadersStamped: BL2PR05MB2178
Archived-At: <https://mailarchive.ietf.org/arch/msg/mpls/PUbjHMsz-bWL7uyHcMhTiYApH5w>
Cc: "mpls@ietf.org" <mpls@ietf.org>
Subject: Re: [mpls] I-D Action: draft-rosen-mpls-rfc3107bis-01.txt
X-BeenThere: mpls@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Multi-Protocol Label Switching WG <mpls.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/mpls>, <mailto:mpls-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/mpls/>
List-Post: <mailto:mpls@ietf.org>
List-Help: <mailto:mpls-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/mpls>, <mailto:mpls-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 21 Jun 2016 14:56:09 -0000

> ·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:
>
> oAdd 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. /*
>
That's the same as replacing <x> by <a,b,x>.
>
> *//*
>
>
>
> ·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./*
>
I'll add the following text:

    When pushing labels onto a packet's label stack, the Time-to-Live
    (TTL) field ([RFC3032], [RFC3443]) and the Traffic Class (TC) field
    ([RFC3032], [RFC5462]) of each label stack entry must of course be
    set.  This document does not specify any set of rules for setting
    these fields; that is a matter of local policy.

> *//*
>
>
>
> ·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./*
>
I'd forgotten that RFC3032 contains an elaborate discussion about 
applying IP fragmentation in the case where the MPLS payload is an IP 
datagram and pushing on labels might cause the MTU to be exceeded.   In 
1997, it seemed like that might be important, but I don't think those 
procedures are actually used much (if at all).

I don't think 3107bis needs to mention MTU issues, any more than any 
other draft that provides a way of distributing labels.
>
> *//*
>
> *//*
>
> 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. /*
>
The "data plane" section of 3107bis is about forming a packet's label 
stack based on the information in SAFI-128 or SAFI-4 UPDATES. It is not 
a general discussion of MPLS data plane issues.
>
> *//*
>
>
>
> ·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./*
>
As I said, this is just an example of something you could do with the 
mechanisms of 3107bis.  If there's no use case for it, no one will do it.

>
>
> 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] ??/*
>
If S1 really wanted to replace <L21,L22,...,L2k> with <L11,L12,...,L1k> 
it would program each of <L21,L22,...,L2(k-1)> as a POP, and it would 
program L2k as a "POP and then PUSH <L11,L12,...,L2k>".  But that's a 
different example than the one given in the draft.