Re: [mpls] how does it work if ....

Stewart Bryant <> Thu, 25 March 2021 17:51 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 5D8793A28DB for <>; Thu, 25 Mar 2021 10:51:52 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.096
X-Spam-Status: No, score=-1.096 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, FREEMAIL_REPLY=1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_BLOCKED=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id OEn0homBF39v for <>; Thu, 25 Mar 2021 10:51:47 -0700 (PDT)
Received: from ( [IPv6:2a00:1450:4864:20::430]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 15FCC3A28F7 for <>; Thu, 25 Mar 2021 10:51:46 -0700 (PDT)
Received: by with SMTP id j18so3191918wra.2 for <>; Thu, 25 Mar 2021 10:51:46 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=LGSdgq6X8I+5vT09t+POCG2itV3xrYeL0ky8kVuqZ2Q=; b=ong2xl67ZWZ+3O27+mZzF0rMVWplvPjEdhLMxpek6phKe4nbApL+WgKmUWZ1ApDxkD rsxPLuxTxdV53B1MM5OjG242/9bvpzd3jRHTy5oEshmgFsXZzb2L4v+9erTq4yue1+Ii zUdlOBAd6np1sWXwjB6lCberm1sjXUnmPXGIykewViIqp8Sc9/ijI+GQaac11eZu8iT/ PQg2mZdt3UuHw44vB6XJ2DY4n9ZuAOrKltju3ZqQAA8IdBoMLQBC8DRd83IAPq8N9ToP kxE6s4zKxsW9YX+lAGifXuTnBRTz8ICjZ9LPF/ah43suCYRw+623eU/hjm1fEAYQLmY3 9YoQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=LGSdgq6X8I+5vT09t+POCG2itV3xrYeL0ky8kVuqZ2Q=; b=HLB/M6t6++T55L3oxSIX8P30Sq1Vr/TMnUF37qtSW0+rk4+JQAxAlFwudjAuaA+frH 4usCA6GKig3YpDuZtsyWHUbU5pU/rkicCAe9PR2WEBpo+00F4WSgylm88JBLfpAk8sMP Sqgq5QXgE+Lp3jcySIkGvqq+r9CmqjM8h/DQ/NfHdwBTrh3emEWvSV2RNE0a5XRb4iFA /RwtkYpKlX9FfJbWpZCFTAy6br21veZiZOKMuMZo6FnfdJs2h7r9Bv1MDR61O89UA+qT bx2Iwlt+cbq8m1OUZ+lKtZ9DPV/gAi8T7SApcGkxShrtdyEFOeG2E3/JckhQMCJWdbH6 x2TA==
X-Gm-Message-State: AOAM5305a03C234wJTuU5phC0kTYm6GMncoyy0RVyB/pk2JhZZP1eeP6 OewhyLpeKvwKILfdptl7dZE=
X-Google-Smtp-Source: ABdhPJxmlKKcJV8nVV4UOj/OCUumhpaRlHwro6CLXRZODvUGWSf7lcqMudYoEIONA4ZwTlXa8KwGOA==
X-Received: by 2002:adf:f148:: with SMTP id y8mr9997766wro.107.1616694704918; Thu, 25 Mar 2021 10:51:44 -0700 (PDT)
Received: from [] ([]) by with ESMTPSA id a14sm8655237wrn.5.2021. (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Thu, 25 Mar 2021 10:51:44 -0700 (PDT)
From: Stewart Bryant <>
Message-Id: <>
Content-Type: multipart/alternative; boundary="Apple-Mail=_4A712A39-9D03-4A4F-9DE9-818D97026464"
Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.\))
Date: Thu, 25 Mar 2021 17:51:40 +0000
In-Reply-To: <>
Cc: Stewart Bryant <>, "" <>, Kireeti Kompella <>
To: loa Andersson <>
References: <> <> <>
X-Mailer: Apple Mail (2.3608.
Archived-At: <>
Subject: Re: [mpls] how does it work if ....
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Multi-Protocol Label Switching WG <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Thu, 25 Mar 2021 17:51:53 -0000


Reply in line

> On 25 Mar 2021, at 04:56, Loa Andersson <> wrote:
> Stewart,
> inline please.
> On 18/03/2021 00:34, Stewart Bryant wrote:
>> You only pop the label to see the xSPL if you are the destination.
> What do you mean by "destination", are you referring to the node that will pop the top label with the SPLs encoding information beneath? I we disable the PHP, thast would be the PE, right?


> So that mean that we can't encode HbH behavior?

Well, we have crossed the rubicon regarding looking further down the stack to take a forwarding decision. We did this formally with the ELI/EL pair, and have been doing it informally with the five tupple ECMP hash for a long time.

> And info theat relates to forwarding is also not very useful, since the packet reached its destination.

Indeed, so an LSR is going to have to look for this, and ideally this should be optional behaviour like the EL search is.

Presumably BTW the reason that Kireeti chose to attach his new functionality to the ELI and presumably also the EL is that his (and many other forwarders) was looking for this anyway, so it is not much more work or stack space.

>> If you do not know about the xSPL you should not have been sent the packet in the first place. That would be a routing/control plane failure.
> So we need some type of mechanism that tells potential ingress LER's which of its reachable are capable to extract inf from SPL's?

We need that, but we need that for any stack action other than pop single label and forward IP packet which is the only default MPLS action.

Similarly if we are forwarding along a path that needs an action we need to know that the on-path LSRs can execute that action on the packet.

So, I don’t think that this is anything beyond business as usual.

Best regards


> /Loa
>> If you receive it by mistake, and consider that it is for you (unlikely but possible) so you pop the label, you will find an unknown xSPL and presumably drop the packet.
>> So I that is safe.
>> What is going to be difficult is with one of Kireeti’s reused Els. That will work fine at a P router, but a PE is going to not process the packet properly. This cannot be a PW or Detnet since that has another label as a gatekeeper, so we nee think what happens if it is an IP packet, in which case the ECMP defeat nibble will be found. This should be unexpected, so the packet will be dropped.
>> If there is an old P router that does not understand the xSPL it will just swap and forward as before.
>> You can always program a P router not to PHP (we did that with MPLS-TP for example). It is more work for the receiving PE, but it needs to be capable of dealing with that or it should not be used in that role with this label stack.
>> So assuming that Kireeti and I have the same vision of how this works, it looks safe to me. However we have to look at every corner and strong exception to validate the approach.
>> Stewart
>>> On 17 Mar 2021, at 14:18, Loa Andersson <> wrote:
>>> Kireeti,
>>> I'm looking at your slides from the joint meeting, in particular slide #3, where you say at thye bottom:
>>>  "Corollary: such labels MUST NOT reach the top of stack (by popping
>>>   labels above them)"
>>> How is that backwards compatible.
>>> If you  have an old LSR, that don't know to look at the bSPL or eSPL underneath the top label. I assume that the top label will be swapped and the packet forwarded.
>>> What is the pen-ultimate LSR is "old" and just pop the top label, how can the PE sort this out?
>>> /Loa
>>> -- 
>>> Loa Andersson                        email:
>>> Senior MPLS Expert                
>>> Bronze Dragon Consulting             phone: +46 739 81 21 64
>>> _______________________________________________
>>> mpls mailing list
> -- 
> Loa Andersson                        email: <>
> Senior MPLS Expert                 <>
> Bronze Dragon Consulting             phone: +46 739 81 21 64