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

Robert Raszuk <robert@raszuk.net> Fri, 24 July 2015 20:21 UTC

Return-Path: <rraszuk@gmail.com>
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 354D41A1F73 for <mpls@ietfa.amsl.com>; Fri, 24 Jul 2015 13:21:16 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.277
X-Spam-Level:
X-Spam-Status: No, score=-1.277 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no
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 IB5hbQfOcLf9 for <mpls@ietfa.amsl.com>; Fri, 24 Jul 2015 13:21:14 -0700 (PDT)
Received: from mail-wi0-x22e.google.com (mail-wi0-x22e.google.com [IPv6:2a00:1450:400c:c05::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A84B31A1C06 for <mpls@ietf.org>; Fri, 24 Jul 2015 13:21:13 -0700 (PDT)
Received: by wicmv11 with SMTP id mv11so77470446wic.0 for <mpls@ietf.org>; Fri, 24 Jul 2015 13:21:12 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=wJlbrhtJcMTTG39c5y5qNlN8NSgDLZX7N3Dm2g3ewGc=; b=HN4TKZafMoJBgdsocDzbRh1HfRuJAi2u0DaMBlTv8kv2AJoPupRb/RfpBJu7KO1tQG wFWmLyWf+8doS4CJtFbDNqd7FfyDzYgCB83Xq7aRAHIkchRmdQsNae3FifviYIxlNqJ+ D0RfEjbCbbMq6IT+yc6QgG8AJzd6tM9qz0vlFDR41vqR3vQafzy0LYAy8sT1Eal8uLj5 hYuGVwa9YDupH5Ja+NWuoixpi7ueZmdz6CAyK5FDX3pRHEBF2n5UXj2s7cZsvhT6E+Gq i2ddOWIKIXSYQne6XRFhgDPJ22DdjyGFOUk9yqatjvlvwnuIR796d+kBZ1LuGvpkCPBs DCsg==
MIME-Version: 1.0
X-Received: by 10.181.13.195 with SMTP id fa3mr283531wid.7.1437769272482; Fri, 24 Jul 2015 13:21:12 -0700 (PDT)
Sender: rraszuk@gmail.com
Received: by 10.194.95.168 with HTTP; Fri, 24 Jul 2015 13:21:12 -0700 (PDT)
In-Reply-To: <CAA=duU2mHzgJQAvTyPqpU4-WYB=jVjPGbyfdEsTNwH+AP09dnQ@mail.gmail.com>
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> <CAA=duU2mHzgJQAvTyPqpU4-WYB=jVjPGbyfdEsTNwH+AP09dnQ@mail.gmail.com>
Date: Fri, 24 Jul 2015 22:21:12 +0200
X-Google-Sender-Auth: 6s7-c9gb9pg2QrODaP9afjn_CtM
Message-ID: <CA+b+ERnrm-sT1xxuFvRrmFGF=k3wv3k8TeQR-ZYb6veod9F2wA@mail.gmail.com>
From: Robert Raszuk <robert@raszuk.net>
To: "Andrew G. Malis" <agmalis@gmail.com>
Content-Type: multipart/alternative; boundary="f46d043c07d4c1637d051ba4be1e"
Archived-At: <http://mailarchive.ietf.org/arch/msg/mpls/e42-JYMmTajRwBBukKmpfhqKVxs>
Cc: "mpls@ietf.org" <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
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 20:21:16 -0000

Andy,

Let me make it very simple.

This discussion is not about how to build a LSR. This discussion is also
not about modyfing anything in the data plane as far as MPLS encapsulation
is concerned.

This thread is about amending 3031 with new primitive such that new control
planes would be able to be used in a straight forward way to program it.

Practical example:

Assume I have a HSDN model and want to set DC labels from controller to the
switch using mpls YANG I2RS channel - how would I do it ?

Please provide real YANG or YIN example where I can bind label 44 to
anycast address 1.1.1.44 where this address is a ghost loopback from my
MPLS WAN to DC44 gateways.

With that please do reference drafts used as a normative references for
provided encoding.

This is as simple as this :)

Best,
R.


On Fri, Jul 24, 2015 at 10:03 PM, Andrew G. Malis <agmalis@gmail.com> wrote:

> Robert,
>
> You're free to implement your switch as you see fit. If your switch sees
> identical in and out labels being provisioned (by whatever means), then you
> are free to store that in an internal FIB/LIB as NOSWAP, and your data
> plane will be optimized. The nice thing is that externally, your switch
> (and controller, or control plane) will conform to existing MPLS specs, and
> interoperate with existing equipment. This will give your customers a way
> to gracefully migrate from the old switches to new ones without requiring a
> fork lift upgrade, coordinating both the data and control planes.
>
> Cheers,
> Andy
>
> On Fri, Jul 24, 2015 at 6:55 PM, Robert Raszuk <robert@raszuk.net> wrote:
>
>> 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.
>>>
>>
>> _______________________________________________
>> mpls mailing list
>> mpls@ietf.org
>> https://www.ietf.org/mailman/listinfo/mpls
>>
>>
>