Re: [mpls] A question about draft-ietf-mpls-sfl-framework

Stewart Bryant <stewart.bryant@gmail.com> Thu, 03 January 2019 14:27 UTC

Return-Path: <stewart.bryant@gmail.com>
X-Original-To: mpls@ietfa.amsl.com
Delivered-To: mpls@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 14FFB12EB11; Thu, 3 Jan 2019 06:27:16 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.998
X-Spam-Level:
X-Spam-Status: No, score=-1.998 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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
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 g3ULLDPAhSsE; Thu, 3 Jan 2019 06:27:14 -0800 (PST)
Received: from mail-wm1-x332.google.com (mail-wm1-x332.google.com [IPv6:2a00:1450:4864:20::332]) (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 C0DE112785F; Thu, 3 Jan 2019 06:27:13 -0800 (PST)
Received: by mail-wm1-x332.google.com with SMTP id m22so30595364wml.3; Thu, 03 Jan 2019 06:27:13 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language; bh=vwBZGGHspv4LUZiGm7U4CkS/tkCDq7DwK3ut60MSu5Y=; b=dFZGg6NNXU35D8tAODmABAFSfbRSLqHwQFl7dRg9DJB3etQYb/olHtKwIbrO+uwiaH HMNlmMsj7ok2pjNNKdCtji/NZ97dp/rt86jV9ne6dSeuQgF0qBV0hw400rqbq/dXeN84 jt8uxdiQk93ukJ2jmn3/TzVyXMGeFjexnWJa5NY9Ewleg83PfQkqHFht3Mp1fMDNAvRb RKBUKf+DtJFcrnb7nUxsY9fr7OPTmemgH1/M3fMe7r58QrEVDe+ZXMrB6V83JW2bytHr 7qCvR9NiGSeYHwa6PlL48ZYd/2dCHrKw+oFXFBOIwn2zTd0AIm4aqpVg7AM5jNnbc18v o9jQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language; bh=vwBZGGHspv4LUZiGm7U4CkS/tkCDq7DwK3ut60MSu5Y=; b=QY3ZiM+DdL9ccptiThYRQpQiWUjuNg2ExwRpx39oqQCAq+hHWTtr69hofnP7tdIEzH 5IAWKzapRRYKYYgtnhHv/lIxlk3limudSsFtkojUXwb1O7unchkhQjkQMRdJHogWvnu3 ZVHB0HsPCl8yG2PXsywlwnoCFObHekWK8LvMpSkh4DB4hUaggk0x2af0hi5XUEgmWUYn kTToj/2fLDmTWLlJDe+iTdwgsvkSAcpnNKKu1uNle6MeL6QrqkX4y+yfeBaKTQRQenL/ smRQ5wLyJMsvsuuGuixyhjoplyPtyeXeCbD9/4yK1snHFGeN3vAXdnpDByYt94Qvadgo SiHQ==
X-Gm-Message-State: AA+aEWbYeVfZonlKY+LFQJJzzB5nYc5SyAsIpz7aVTp0Wy3Q/ocwSm8b dODtBkLYuJEIb5PFqge6yQA=
X-Google-Smtp-Source: AFSGD/VLO4ADqOTyJarD0RtaFP52h99KdbBzyh6iU6VkzXaBh7rvR2zk9qm92awAxVe73ps2sY8Y3w==
X-Received: by 2002:a1c:868a:: with SMTP id i132mr36955222wmd.49.1546525632136; Thu, 03 Jan 2019 06:27:12 -0800 (PST)
Received: from [192.168.2.198] (host213-123-124-182.in-addr.btopenworld.com. [213.123.124.182]) by smtp.gmail.com with ESMTPSA id n11sm199497wrw.60.2019.01.03.06.27.11 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 03 Jan 2019 06:27:11 -0800 (PST)
To: Alexander Vainshtein <Alexander.Vainshtein@ecitele.com>, "draft-ietf-mpls-sfl-framework@ietf.org" <draft-ietf-mpls-sfl-framework@ietf.org>
Cc: "mpls@ietf.org" <mpls@ietf.org>, Shell Nakash <Shell.Nakash@ecitele.com>, Jun Ye <Jun.Ye@ecitele.com>
References: <AM0PR03MB3828DD11E7BCB069CB2B68DA9DB40@AM0PR03MB3828.eurprd03.prod.outlook.com>
From: Stewart Bryant <stewart.bryant@gmail.com>
Message-ID: <36264762-7e7a-bd18-da0c-4db51185d426@gmail.com>
Date: Thu, 3 Jan 2019 14:27:10 +0000
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.4.0
MIME-Version: 1.0
In-Reply-To: <AM0PR03MB3828DD11E7BCB069CB2B68DA9DB40@AM0PR03MB3828.eurprd03.prod.outlook.com>
Content-Type: multipart/alternative; boundary="------------6A21211B6971F469FB621982"
Content-Language: en-GB
Archived-At: <https://mailarchive.ietf.org/arch/msg/mpls/xdx_MT9hHPKxQN7wWlxLtjmRBMk>
Subject: Re: [mpls] A question about draft-ietf-mpls-sfl-framework
X-BeenThere: mpls@ietf.org
X-Mailman-Version: 2.1.29
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: Thu, 03 Jan 2019 14:27:16 -0000

On 25/12/2018 11:45, Alexander Vainshtein wrote:
>
> Dear authors of draft-ietf-mpls-sfl-framework 
> <https://tools.ietf.org/html/draft-ietf-mpls-sfl-framework-04>;,
>
> I have a question about use of Synonymous Flow Labels in the when 
> application labels are present.
>
> The relevant text in Section 4.1 of the draft says:
>
>    At the egress LSR the LSP label is popped (if present).  Then the SFL
>
>    is processed in exactly the same way as the corresponding application
>
>    label would have been processed.
>
> If the application label has been statically configured in the egress 
> LSR,  then, presumably, so would be each of the Synonymous labels.
>
Yes.
>
> However, if the application label has been dynamically allocated by 
> the egress LSR and advertised to ingress LSR using some control plane 
> mechanisms, then the synonymous labels would also have to be 
> dynamically allocated and advertised by the same control plane mechanisms.
>
Not necessarily.

We had a proposal for a simple control plane that I propose to refresh:

https://tools.ietf.org/html/draft-bryant-mpls-sfl-control-02

The idea with this is that the application control protocol runs as 
normal and this protocol modifies the label for SFL purposes.

There was a lot of interest in the WG at the time for modifying each and 
every control protocol, but there is not much interest in writing the 
drafts needed to do it.

> The draft in question is a framework draft and does not discuss any 
> control plane issues (at least I have not found any mention of such 
> issues in the text).
>
> I wonder if any work on control plane mechanisms for advertisement of 
> synonymous labels is going on or planned. ( A quick search in the 
> documents of the MPLS, BESS and PALS WGs did not find any relevant 
> documents).
>
Only the one I cite above.

I would be more than willing to work with anyone (actively or just as a 
reviewer) that wanted to write the control plane drafts.

> If the intended applicability of the SFL framework is just for 
> statically configured application labels, this should be explicitly 
> stated in the draft IMHO.
>
No, I think the intent was always that there would be a control plane if 
needed.

Best regards

Stewart


> Your timely feedback would be highly appreciated.
>
> Regards, and lots of thanks in advance,
>
> Sasha
>
> Office: +972-39266302
>
> Cell:      +972-549266302
>
> Email:   Alexander.Vainshtein@ecitele.com
>
>
> ___________________________________________________________________________
>
> This e-mail message is intended for the recipient only and contains 
> information which is
> CONFIDENTIAL and which may be proprietary to ECI Telecom. If you have 
> received this
> transmission in error, please inform us by e-mail, phone or fax, and 
> then delete the original
> and all copies thereof.
> ___________________________________________________________________________