Re: [mpls] draft-fang-mpls-label-forwarding-no-swap - how much does it really save?

"Adrian Farrel" <adrian@olddog.co.uk> Fri, 24 July 2015 17:15 UTC

Return-Path: <adrian@olddog.co.uk>
X-Original-To: mpls@ietfa.amsl.com
Delivered-To: mpls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9717D1A00DB for <mpls@ietfa.amsl.com>; Fri, 24 Jul 2015 10:15:43 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.599
X-Spam-Level:
X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, USER_IN_WHITELIST=-100] autolearn=ham
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 rmwJTTcUMled for <mpls@ietfa.amsl.com>; Fri, 24 Jul 2015 10:15:41 -0700 (PDT)
Received: from asmtp1.iomartmail.com (asmtp1.iomartmail.com [62.128.201.248]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 324F61A01D5 for <mpls@ietf.org>; Fri, 24 Jul 2015 10:15:40 -0700 (PDT)
Received: from asmtp1.iomartmail.com (localhost.localdomain [127.0.0.1]) by asmtp1.iomartmail.com (8.13.8/8.13.8) with ESMTP id t6OHFce3032017; Fri, 24 Jul 2015 18:15:38 +0100
Received: from 950129200 ([193.86.236.114]) (authenticated bits=0) by asmtp1.iomartmail.com (8.13.8/8.13.8) with ESMTP id t6OHFZ3b032004 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO); Fri, 24 Jul 2015 18:15:36 +0100
From: "Adrian Farrel" <adrian@olddog.co.uk>
To: "'Robert Raszuk'" <robert@raszuk.net>, "'Eric Rosen'" <erosen@juniper.net>
References: <55AD19F2.1010206@cisco.com> <4A6CE49E6084B141B15C0713B8993F2831F73A21@SJEXCHMB12.corp.ad.broadcom.com> <55AD2DAD.4060908@juniper.net> <4A6CE49E6084B141B15C0713B8993F2831F73F3A@SJEXCHMB12.corp.ad.broadcom.com> <55AD416D.2020306@juniper.net> <CA+b+ER=nEqxiHigEFbgY9LehQMRNH8rOzQKeTQpmMrHh6_-MEA@mail.gmail.com> <55B15C59.5040105@juniper.net> <CA+b+ERnWSg-BoxhntMmSXfBfj0mWhscuZ1VUdUkC0k0xDLd4Tw@mail.gmail.com> <55B267F6.80106@juniper.net> <CA+b+ER=BOPeUPdPr2QKvCPhfTOECD9HMMzSQ44jXn0hxYUMA-g@mail.gmail.com>
In-Reply-To: <CA+b+ER=BOPeUPdPr2QKvCPhfTOECD9HMMzSQ44jXn0hxYUMA-g@mail.gmail.com>
Date: Fri, 24 Jul 2015 18:15:35 +0100
Message-ID: <0a8501d0c634$5bfa6540$13ef2fc0$@olddog.co.uk>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_NextPart_000_0A86_01D0C63C.BDBECD40"
X-Mailer: Microsoft Outlook 14.0
Thread-Index: AQIFBBCy8RZ/CxlvQaWWNxgEokAwzgDc/jE5Ab0WRiYCPfPxeAJiCcHdAUJKZgkCwfGxfQHS611nAniJ1ZYCdpOzxpzyXAcA
Content-Language: en-gb
X-TM-AS-MML: disable
X-TM-AS-Product-Ver: IMSS-7.1.0.1576-8.0.0.1202-21702.001
X-TM-AS-Result: No--15.565-10.0-31-10
X-imss-scan-details: No--15.565-10.0-31-10
X-TMASE-MatchedRID: pS5owHKhBO1lTYPLUKF/gFPjo7D4SFg47yWPaQc4INSbaqf1L9+tlMfc 5pKTMK1blRAqH5ShNK9LTmvmHr3PYmk5Fql3Faa7NZCDXJ6NLva51wB2BUjzGe2u9WxDRZ0zXKw CKu8R/Ry2XuqHnmj9++IeHix5zjCgA7AwN7T59//aize54oCwVFuI4UV3KJUx35L50wsSJmzP5C AUvjYQxABPgGVUx4910bpcWhh9XDP31EmIMyYYYpJEUO2qIzlLdWAGleXmdhiCsBeCv8CM/XZru QG5/1P7NNAbhni610GcwLltVNRH4kdHAKAtVHxtGQvJP9N22OUYZdGd023v1bOi3GkmFCcDWB1C Tktboe5S8gtop+q6+eTtIFjW0OaXwrxsKoa/qe1NVr4vdmCpzuMEJWD9LEZvIbxYwbCxGTQmqhy u6WdG0eOd/LibTZRKXl1vY2XJLWKQFHd0cGjNx+wSNio74PJoOIBtb6gQTfhqv/+QKNcPLoG4sP POSZLXbEAys37MeSadMqejfEhpkkPzOtpuVTEBBEfU2vugRF1WAndncnBsR9dMDzSLr8ovgeCFp S4r9xerwWnpGvL3AREDiHAifYwNR1vveBQPCRdCvapcIkxJX66IBbSnfz+3ut/GVGOoEneALjqn IlNKdNXjKfop/WvT3wqC9Qsu3hf9+rKlRf1WaEtzk37SzX4NlPV6Vaqi4bDxxaAXDrCns4j7J3j zONjdJa6rGJR4RfowuiDzT/FFiVHi+vC6FxL8BU4uU+5y12ot0t+aIVLt+5KzWy3+GmBuXM4pVH n2LwM/makG0+v97t639oRBFUkeQ0pFGvYtteueAiCmPx4NwGmRqNBHmBve1kTfEkyaZdxFGCd0S 0NCsq/R+pz0aM7ztYB7WoMMLSBSpFb/JfWjZRzLd2k9LjIpCStjCuOR/hg=
Archived-At: <http://mailarchive.ietf.org/arch/msg/mpls/IjYtWSpPwBGfUpOb4WNSiD2ejQw>
Cc: mpls@ietf.org
Subject: Re: [mpls] draft-fang-mpls-label-forwarding-no-swap - how much does it really save?
X-BeenThere: mpls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
Reply-To: adrian@olddog.co.uk
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: Fri, 24 Jul 2015 17:15:43 -0000

Robert, 
You want to specify the interface between control plane and data plane?
That's OK (although it may have been done once or twice before).
And if you want to specify the interface between the management plane and the data plane, that is also OK (although it has been done before as well).
 
If you want to specify that for a packet with incoming label the operation is NO-SWAP, that's OK.
But note that your data model (to be generic) is going to need to also support SWAP.
Thus, you will have objects...
IN-INTERFACE (ifid)
IN-LABEL (label)
OPERATION {POP, PUSH, SWAP, NO-SWAP} 
OUT-INTERFACE (ifid)
OUT-LABEL (label)
 
Setting OPERATION to NO-SWAP saves you from setting OUT-LABEL, but doesn't save you from needing the object in your data model. So it is a trade in the design of the data model and either approach is fine. 
 
You can see a similar model in the LSR MIB module (3813 IIRC) and in the olde ATM MIB modules.
 
None of the above has the slightest to do with 3031 being right or wrong.
 
Adrian
 
 
From: mpls [mailto:mpls-bounces@ietf.org] On Behalf Of Robert Raszuk
Sent: 24 July 2015 17:55
To: Eric Rosen
Cc: mpls@ietf.org
Subject: Re: [mpls] draft-fang-mpls-label-forwarding-no-swap - how much does it really save?
 
Eric,
This discussion to me is not related to data plane.
I look at it from control plane perspective which needs to pass label values to date plane.
Creating non standard optimised APIs or YANG models to send single label or artificially send identical labels an in and out when given architecture does not have it seems like no-op to me.
Best,
R.
On Jul 24, 2015 6:29 PM, "Eric C Rosen" <erosen@juniper.net> wrote:
On 7/23/2015 5:31 PM, Robert Raszuk wrote:
Going by your logic we would have a notion of "incoming IP address" and
"outgoing IP address" in all routers in the world doing basic non NAT
routing

I'm not sure I understand what it means to "have a notion ... in all routers".  A given router only needs to implement the functionality that it needs to provide to those who are going to deploy it.

However, certainly there is a distinction to be made between "incoming" and "outgoing" even in the case of "pure" IP.  The incoming IP header of a packet is always different than the outgoing IP header of that packet, due to the need to modify the TTL and checksum fields.

In addition, as you point out, the incoming source address field may be different than the outgoing source address field, due to NAT.  And use of the source routing option can result in there being a difference between the incoming destination address field and the outgoing destination address field.

Another interesting case is tunnel stitching, where the incoming source and destination address fields may both be different than the outgoing source and destination address fields.  If you want to optimize for tunnel stitching, you precompute the rewrite string, and to the forwarding plane it looks like an ordinary case of forwarding a packet.

Of course, if your platform doesn't need to perform any of these functions, it doesn't have to implement them.  Similarly, if you think that the most common operation (or even the only operation) your platform will have to perform on an MPLS packet is "don't modify the label stack except for the TTL of the top entry", nothing stops you from optimizing for that case.

BTW, I understand perfectly well that there is some controversy about whether it is or is not a good idea to use domain-wide labels, but that is not a data plane issue, and the use of domain-wide labels does not require a change in the data plane architecture.