Re: [mpls] [EXTERNAL] Indicators in the stack and ancillary data after the BoS

Stewart Bryant <> Thu, 17 June 2021 07:36 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id CBE013A1108 for <>; Thu, 17 Jun 2021 00:36:11 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.097
X-Spam-Status: No, score=-2.097 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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=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 lLAohaEkYBUo for <>; Thu, 17 Jun 2021 00:36:06 -0700 (PDT)
Received: from ( [IPv6:2a00:1450:4864:20::42b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id D2E1F3A10FE for <>; Thu, 17 Jun 2021 00:36:05 -0700 (PDT)
Received: by with SMTP id v9so5551182wrx.6 for <>; Thu, 17 Jun 2021 00:36:05 -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=RlkV5JzY7nb8kF14vc/LsTuyhYFrafcFPi9dL01TjXI=; b=uXI2Ls0ndXTov5xqEFyV9S0TWlBLCLPslS3clp+Dd2u/zWorwyr9BB04N29G+KR5ai HUulUwzypmFhI92UjoEBo6D/tf1mnimmwPoEqjCRyojzy0MI27p5l4G6rv8rKbV9w7f9 /KH5Gb3r36QJ8qfLAE+ufqSzuYRFDtWgAjUItaTnH0KQBLcRjOs5p0MQE9jM6//Ot+M8 ifwyAOALs1jSzxzgUwdjQ7wVUZToiYS20/KP0RwFvqr9VatFEeojA/hRMfYoDCJMfa63 Jos0Zr4r5g7WL+KgbbNdfYz7jSGOCqKHahG0okXjTt6RwZevv3u0PXLlpPP53dx43oGa r2SQ==
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=RlkV5JzY7nb8kF14vc/LsTuyhYFrafcFPi9dL01TjXI=; b=cffjKezIz81MyM/+YdBNgR3+aGe0vEcZOIMWc8lfMAcb+Cy9hBmpTvuQmjsoPfHC/i rTB76ipp8Kv8hwcw67EVOMalDEsVTe9U3cKTEZ8eacU0YgZQPudW3X9dKbON73Fny/fg yaI20LBMumwBdMmhhnYpbah86kRFGFqgIpWhATUNCj+3O/0XTS+iRS1p9HBbaPnj34BH bpdVTElnq/t/RM0JYf/Ovl06sAi9gSQju88ZcTONl4xL7ZiTqORabmTVrksAjC0hQKyy O6Rb7CTOwufDxrdy9JoETPghqbAPTX8zOitW75Wup3/muPelS4nz1WMS+C/3VeNE/IK6 HOMA==
X-Gm-Message-State: AOAM530Fc5H/I9zqJ+HjtewxhnJbn21LYEDHNckoOml/k8eQ7byjCBXF 2aOBopTrepQg+DAwAW3rh4Y=
X-Google-Smtp-Source: ABdhPJyPg/mLWgkdh80k5Hn/tqnKAEQvXFn8I2iHGHg7PkKY5O4FiEIGJqMbkpo/Dll6hPaDpLBEdw==
X-Received: by 2002:a05:6000:1888:: with SMTP id a8mr3830198wri.11.1623915363527; Thu, 17 Jun 2021 00:36:03 -0700 (PDT)
Received: from [] ([]) by with ESMTPSA id m126sm7122646wmm.17.2021. (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Thu, 17 Jun 2021 00:36:03 -0700 (PDT)
From: Stewart Bryant <>
Message-Id: <>
Content-Type: multipart/alternative; boundary="Apple-Mail=_AD7343E4-5AA2-42F7-9A25-37A6114176AE"
Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.\))
Date: Thu, 17 Jun 2021 08:35:58 +0100
In-Reply-To: <>
Cc: Stewart Bryant <>, "" <>, "" <>
To: Alexander Vainshtein <>
References: <,> <> <> <>
X-Mailer: Apple Mail (2.3608.
Archived-At: <>
Subject: Re: [mpls] [EXTERNAL] Indicators in the stack and ancillary data after the BoS
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, 17 Jun 2021 07:36:12 -0000

> On 17 Jun 2021, at 07:45, Alexander Vainshtein <> wrote:
> While that might be the case, I think that the Open DT may give it a try and investigate how the existing systems will handle GAL being not the BoS label.
> [[Sasha]] Great minds think alike! One useful step could be collecting the known actual behavior of popular implementations in this case, say, by running a survey among the vendors – what do you think?

That is actually a considerable amount of work that will take a while.

It seems to me that an old implementation that received a ToS GAL not at BoS would at best throw an exception or worst be unpredictable.

The original assumed processing model is to take the context of the PW label or PW+FAT label, discover the GAL and then process the GAL in the context of the PW label.

When we extended GAL to apply to LSPs we again had the model that the GAL operated in the context of the LSP label that preceded it for context. It was still BoS.

Putting the GAL further up the stack is a new behaviour.

If it arrives at an LSR that knows the new semantic all is good.

If it arrives at an LSR that does not know the new semantic then 

a) An error has occurred either in setting up the LSP, or in forwarding.

b) The behaviour at the receiving node is unpredictable, but in any well written implementation should just result in the packet being dropped and counted as with any other Mal-formed packet.

So I would think that it is OK to have multiple GALs and GALs not at BoS IFF the creator of the LSP ensured that all LSRs on the LSP, including ECMP and FRR paths that found the GAL at ToS were known to be able to process it correctly.

A GAL not at BoS and not at ToS should not be inspected or processed by any LSR that did not know what it was doing, and to attempt to precess it would be a violation of the normal MPLS processing model.

- Stewart