Re: [mpls] [Idr] [bess] draft-rosen-mpls-rfc3107bis

Robert Raszuk <> Fri, 01 April 2016 21:35 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 3753D12D6F9; Fri, 1 Apr 2016 14:35:39 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.399
X-Spam-Status: No, score=-2.399 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.199, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id dsBXe0q4fsWO; Fri, 1 Apr 2016 14:35:36 -0700 (PDT)
Received: from ( [IPv6:2a00:1450:4010:c07::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id AB2F512D6D8; Fri, 1 Apr 2016 14:35:35 -0700 (PDT)
Received: by with SMTP id k79so90163310lfb.2; Fri, 01 Apr 2016 14:35:35 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc; bh=NraeDOxzHT6xKPnnF27FvW1NPF9PIVLGSABpDsoRqEY=; b=FPDevFBCQLhJ55DSgB6oCpoQudnACdyVCxUeUM1vlw4wbmDyWTKKVreV8hWQ0YcD5B 60bJtN80v6m87DZT6R6QnA12AVr9jF8KztsBIzflEC7K2LzLXunTZkdLcC7fVPoSHv78 sHG7879SMsCDwhR+nApFj5g7cSungM5wpAyOu9/aQPo3B57qqj6Xh5XTf4zQ8ZJj/CSZ S4FfvEXxsXikyETYBr8qhZDplL91L+8p7/0IXzlTFUJk3BbOAswuI570Gwl0vc1/z1kK Xwcaa79XJBgfarMK0JW7MN0nZEK/VDTvAQJv8yliPzukOm3OFP+s1/xzrEAQZtwjUslX Kjqg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20130820; h=x-gm-message-state:mime-version:sender:in-reply-to:references:date :message-id:subject:from:to:cc; bh=NraeDOxzHT6xKPnnF27FvW1NPF9PIVLGSABpDsoRqEY=; b=FlylAM69r+fouwGmVopx3sEsseCELXLXdzX9HoKrTj/pifYSWbS4JU3u5Ce7MPvrfr GgX/9vp3+Qbz2WEXzS9rH2Mo6yfo8ClXal8ua/ZQ3JeIbAU1KkeKjJ7p4Kc85y9DDwHg ayDqBku91Kyc+WL3HyNzj6lW8lSE7+VTZ5A+NaAGYhGCWrWJ19ePL5AOxIqm+wi1wiDW 8cjhUgpxU/0IGLaZUsdl8aCbkWoXZu0t3qFJonoTN/4VxN2/kUckSqVkfro9rwaEIpnZ wm5ncZbJkLYDn0ZsZuLhDyYgwtV4Aq4zWumMHh2DK+0uQgihNUJ2rvK9vS4z8OHlkLtf 4QRw==
X-Gm-Message-State: AD7BkJJijqtP2nVfRTNpKVe7RppcaXbfqjImKluyBxmvCR1Os1a3S8AnXi1N6yys9wObJWir2lOwg01MzX0nrw==
MIME-Version: 1.0
X-Received: by with SMTP id l19mr2834321lfb.27.1459546533835; Fri, 01 Apr 2016 14:35:33 -0700 (PDT)
Received: by with HTTP; Fri, 1 Apr 2016 14:35:33 -0700 (PDT)
In-Reply-To: <>
References: <3515_1458832652_56F4050B_3515_774_1_53C29892C857584299CBF5D05346208A0F819B1E@OPEXCLILM21.corporate.adroot.infra.ftgroup> <> <9656_1458905159_56F52047_9656_7014_1_53C29892C857584299CBF5D05346208A0F81AAA7@OPEXCLILM21.corporate.adroot.infra.ftgroup> <> <> <>
Date: Fri, 01 Apr 2016 23:35:33 +0200
X-Google-Sender-Auth: s1x6nZEIaHchybZQ5tBfQkxcp6U
Message-ID: <>
From: Robert Raszuk <>
To: "Acee Lindem (acee)" <>
Content-Type: multipart/alternative; boundary="001a1140ead8aebac2052f7328a4"
Archived-At: <>
Cc: "" <>, BESS <>, "" <>
Subject: Re: [mpls] [Idr] [bess] draft-rosen-mpls-rfc3107bis
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: Fri, 01 Apr 2016 21:35:39 -0000

Hi AC,

I am much less concern if we must be stuck to 3107 till retirement.

I think it would be much smoother on many levels to leave 3107 as is and
propose better solution for interdomain label exchange with BGP in new RFC.

With time we can obsolete 3107.

Such model has been done in the past and worked pretty well AFAIK.


On Fri, Apr 1, 2016 at 11:29 PM, Acee Lindem (acee) <> wrote:

> Hi Robert,
> I think this would defeat the purpose of clarifying RFC 3101 multi-label
> behavior in a BIS draft. Let’s see if we can reach consensus first.
> Thanks,
> Acee
> From: Idr <> on behalf of Robert Raszuk <
> Date: Friday, April 1, 2016 at 4:23 PM
> To: Eric C Rosen <>
> Cc: Bruno Decraene <>, "" <
>>, BESS <>, IDR List <>
> Subject: Re: [Idr] [bess] draft-rosen-mpls-rfc3107bis
> Hi Eric,
> I have read your proposed draft as well as watched this thread with a bit
> of an interest.
> To me the best compromise - which is to agree with Bruno's points as well
> as address your intentions is simply to request new SAFI for 3107bis.
> From the draft you are really not updating 3107 base spec but obsoleting
> it which to me looks like a bad idea.
> You are even requesting to remove IANA reference to original spec. How
> would IANA know when is it safe to do that .. meaning when all
> implementations will not suddenly support and all deployments will enable
> 3107bis ?
> New SAFI requires a new capability which you are asking for anyway.
> As far as implementations please keep in mind very important point that
> some implementations treat SAFI 1 & 4 in single table and some in separate
> tables. That when mixed with 3107bis may just explode if not in new set of
> bugs then with operational nightmare. While we are at this it would be much
> cleaner to mandate in the new spec to have 3107bis always to use separate
> tables as compared with from SAFI 1.
> Thx,
> Robert.
> PS.
> As we all know 3107(bis) tries to add NNI to MPLS. However it must be very
> well stated that this is only one deployment option for interdomain
> encapsulation. I would very much like to see a section indicating that IPv6
> or/and IPv4 be used as an alternative encap for those applications which
> require it and when needed provide local bindings between intradomain MPLS
> and interdomain IP.
> On Fri, Apr 1, 2016 at 6:44 PM, Eric C Rosen <> wrote:
>> On 3/25/2016 7:25 AM, wrote:
>>> I'm quite sure you have deployed  implementations, from several
>>>> prominent vendors, that will not properly handle this case.
>>> I'm waiting for this/these implementation(s) to make a public statement
>>> in this thread / IETF WGs. Then we can discuss whether the issue comes from
>>> RFCF3107 or from the implementation.
>>> If none make a public statement, we should assume that all
>>> implementations are capable of receiving multiple labels, as per RFC 3107.
>> I strongly disagree with this.  We should not ignore the facts just
>> because you don't like the way the facts were gathered.
>> A better approach would be to have operators state whether they have any
>> deployments in which the "multiple labels" feature is used in a
>> multi-vendor environment.  It is very useful when working on a "bis" draft
>> to determine which features have been proven to work in a multi-vendor
>> environment and which have not.
>> Any non-compliant implementation may create interoperability issues and
>>> unpredictable results.
>>>  From an IETF standpoint, the question is whether a RFC 3107
>>> implementation would create interoperability issues, up to shutting down
>>> the BGP session.
>> There are deployed 3107 implementations which always assume that the NLRI
>> contains a single label.  If you tried to interwork these with 3107
>> implementations that send multiple labels , you will experience the kind of
>> disruption.  3107bis tries to allow the use of multiple labels while
>> preventing this sort of disruption from occurring.
>> If you mean that some non-compliant implementation do not work, well
>>> let's fix them.
>> The situation is that there is a commonly deployed "bug" in old
>> implementations, but it is not seen because the bug is in a feature that no
>> one has been using.  If new implementations use that feature, the bug will
>> be seen, and network disruption will occur. One could say "fix all the old
>> implementations", but it seems wiser to have new implementations avoid
>> tickling the bug.   The Capability is not proposed  for the purpose of
>> helping the vendors, it's there to help the operators.
>> I'm not sure why you think there would be BGP session drops due to
>> 3107bis; if a 3107 implementation sends multiple labels to a 3107bis
>> implementation, I think the 3107bis implementation would do
>> "treat-as-withdraw" rather than "drop the session".
>> Perhaps a reasonable approach for 3107bis would be the following:
>> - A 3107bis implementation will not send multiple labels to a peer unless
>> the Capability has been received from that peer.  (This prevents 3107bis
>> implementations from tickling the 'bug' in 3107 implementations.)
>> - A 3107bis implementation will accept multiple labels from a peer even
>> in the absence of the Capability.
>> Another approach would be to have a knob that determines whether the
>> Capability needs to be used before multiple labels are advertised.
>> _______________________________________________
>> BESS mailing list