Re: [mpls] Request for comments on draft-malis-mpls-sfc-encapsulation-00.txt

Stewart Bryant <> Mon, 25 June 2018 18:58 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 188DE130EF1; Mon, 25 Jun 2018 11:58:16 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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 Zxz2OD-fP26N; Mon, 25 Jun 2018 11:58:13 -0700 (PDT)
Received: from ( [IPv6:2a00:1450:400c:c09::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 7612A130EF0; Mon, 25 Jun 2018 11:58:13 -0700 (PDT)
Received: by with SMTP id x6-v6so10404673wmc.3; Mon, 25 Jun 2018 11:58:13 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-transfer-encoding:content-language; bh=jJegQwuv7g+WZWn3YQJbVKfLsPK9Db2mUtCoj7vuKDw=; b=bVoRII0UhFZNq1JTQy4YCFCKu43MaSj8fUYN11JSBrpD8mMSDVG6HJToVYaaaXIbBr eJRyVeOP6+xwIIfCRMzhvlWRw16PJpDeSVSZ5Hr+Wdt91IMWyXC8kSBgtPCzZzgGtD5Q spY1oSFqPML1JcsNKsKrQD4dYUbSuGQ9EoEJxdpVzqIUaBL+tESDhqBa7DJUWz/djAtD p6Fc0VX6b0p23xs0E3cwBMTWC3Vb8pzGi2g/1lcTV3SQ7InQv8g53QuvmH3mDlEgYFAt OdYFkItrQvQjYuG+mHQpzJ8Tm3QSbO+NyrJJL7GdsHmPv1kFByd3t9VmHBFeoZfvharv scTA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding :content-language; bh=jJegQwuv7g+WZWn3YQJbVKfLsPK9Db2mUtCoj7vuKDw=; b=tJf9c67UhBH5h+6cIKtm7MRo1faDv7pN7xrvnjxLGun60m4b6Zzi4Yrg9DNHQs38Xf 50EzkF75AMGMHmkiH2ZFb6ADBmdKmb6w2zauQaWibsDthA7qDYUo/Gz/UAAj8vB7yj5N rP7KbiWSZVbBLWPn7t5yFiCegr26/ymm1DoJ6gs0qXe883S4EC8/AzkLm//PMNng/Dfy 2Dz0xpqZAOapVktQXNATaNzEr9BMegfvrOz1G0dIHCs1BjZzWvfS7oU5xFSwMEK7944a qB4aOiJRsPYyO3PIvRgaEErs7Hg8lo0K1uEGdN5Xm6qirx55YVAR9HLEODldPTZYlXSb ci7A==
X-Gm-Message-State: APt69E3x8l9fL5LaPuqa3+NQ5OmXqRb2oz1VY3cQwigsqkCeyB521ANo rySUiWfPa+mSR5u4C0o1TbYwvrA+
X-Google-Smtp-Source: AAOMgpc1fI/a4LNRO0Pk1l1SHh/U41J5VugK+9PzHmockweb303BCBe2v0yHLY9XtKRSo9QQ47S3YQ==
X-Received: by 2002:a1c:78b:: with SMTP id 133-v6mr2011766wmh.59.1529953091361; Mon, 25 Jun 2018 11:58:11 -0700 (PDT)
Received: from [] ( []) by with ESMTPSA id z14-v6sm7462204wma.11.2018. (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 25 Jun 2018 11:58:10 -0700 (PDT)
To: Eric C Rosen <>, Alexander Vainshtein <>, "Andrew G. Malis" <>
Cc: "" <>, "" <>
References: <> <> <>
From: Stewart Bryant <>
Message-ID: <>
Date: Mon, 25 Jun 2018 19:58:09 +0100
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.8.0
MIME-Version: 1.0
In-Reply-To: <>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit
Content-Language: en-GB
Archived-At: <>
Subject: Re: [mpls] Request for comments on draft-malis-mpls-sfc-encapsulation-00.txt
X-Mailman-Version: 2.1.26
Precedence: list
List-Id: Multi-Protocol Label Switching WG <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Mon, 25 Jun 2018 18:58:26 -0000

Hi Eric

Your description is what I would expect to happen.

The question is always  what should you leave unsaid as it is obvious to 
those skilled in the art, and creates maximum flexibility to allow 
innovation, and what should you say to resolve ambiguity and prevent an 
unnecessary infinity of functional combinations?

On 25/06/2018 18:34, Eric C Rosen wrote:
> It's always a bit tricky to specify the precise rules for creating a 
> label stack.  I think the rules for creating the label stack atop an 
> NSH packet are probably something like the following.  Suppose one has 
> an NSH packet, and one has chosen a target node on the network, where 
> that target node is (or contains) the SFF that next needs to receive 
> the NSH packet (the target SFF).  Then create the label stack as follows:
> - Push on zero or more labels that are to be interpreted by the target 
> SFF.  (I guess the GAL label could be an example here.)
> - Push on the SFF label.  (A label that, at the target node, is 
> associated with the target SFF.)
> - Push on zero or more additional labels such that (a) the resulting 
> label stack will cause the packet to be transported to the target 
> node, and (b) when the packet arrives at the target node, either:
>   * the SFF label will be at the top of the label stack, or
>   * the SFF label will rise to the top of the label stack before the 
> packet is forwarded to another node and before the packet is 
> dispatched to a higher layer.
> It's probably best to also state that PHP MUST NOT be applied to the 
> SFF label.  (I realize that the control plane is out of scope here, 
> but whatever the control plane is, it needs to set up the PHP 
> appropriately.)

For that to happen you would need to pop two labels which can only 
happen by error, which is something we can mitigate against, but never 
completely avoid.

> It would be good to say what the SFF is supposed to do if it gets an 
> MPLS packet rather than an NSH packet (i.e., if the SFF label is not 
> BoS).  The SFF might or might not understand the label following the 
> SFF label. 
I imagine that would be a parameter of the SFF label. You would 
certainly need to know which type the packet was to get the MAC layer right.

> Also, if the following label is v4-explicit-null or v6-explicit-null, 
> does that convey any semantics? 
Probably which ethernet type to use if going to the SF over a LAN.

> Frankly, I wonder if it's a bit dangerous to allow labels below the 
> SFF label, as this will cause problems if the SFF label is programmed 
> to cause a dispatch of the remaining packet to a procedure that does 
> not understand MPLS at all and is expecting to see an NSH packet.

It depends how the packet gets from the SFF to the SF. If it is pure 
internal processing on the SFF and no further checking that would be a 
problem, although you could prevent it with an SFF rule, but in any case 
where the packet was sent across a network the MAC type ought to be MPLS 
in which case the SFF would bin the packet as unknown/unexpected type.

> It would be good to say where something like the entropy label would 
> appear in the stack.  Before the SFF label?  Or after?  Or either?
Certainly before, but there is a case for both else we will end up also 
needing FAT labels.

Thanks for your thoughts, we will reflect them in the next version.

- Stewart

> _______________________________________________
> mpls mailing list