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

Stewart Bryant <stewart.bryant@gmail.com> Thu, 03 January 2019 16:15 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 9794113107A; Thu, 3 Jan 2019 08:15:22 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.988
X-Spam-Level:
X-Spam-Status: No, score=-1.988 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, T_KAM_HTML_FONT_INVALID=0.01, 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 NxduVLth-T2h; Thu, 3 Jan 2019 08:15:20 -0800 (PST)
Received: from mail-wr1-x429.google.com (mail-wr1-x429.google.com [IPv6:2a00:1450:4864:20::429]) (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 608A7130EF3; Thu, 3 Jan 2019 08:15:19 -0800 (PST)
Received: by mail-wr1-x429.google.com with SMTP id s12so34041071wrt.4; Thu, 03 Jan 2019 08:15:19 -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=QvR3Uw3Y2h2WxKReT+0yL6z6esc13tWh7Lt9naNOWWw=; b=NzL60lIcRq6ygJ2BbtJS85U+MWsvsZbppnYmjxPqbxsYH8CVqjXHUw4HHhCdykYl5+ NauouZTy8WeSRnaUFg4gSX0GzBZMw5W6p4Lz1nqHjOA/Bbyini3Tny5D2QwI8mLPF0Bg M9qDiPlEsutImLBLzheMdOeSsNejvQq5LdfUBPDfcwkVrTN+Blpm4mAOEir6VWTwD0YQ wwDfsImSREw6V83XRUe1DYVaKSkPvD1yZDpZOI44yOGNhnv5oe9YISXA8guQqf9Zy7ZJ TXYxO51KO4QPkCwaHGKSQr5iZjLmdLRNMPzE3dm0UnupyJ1oLHB7Su1nG5rLhk6IOnbX N6aA==
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=QvR3Uw3Y2h2WxKReT+0yL6z6esc13tWh7Lt9naNOWWw=; b=mDEVnrGz8tMi4mNH/esfUUUdEOY9HYqmhjDlw9oDGQhXp0LW6a/D+pnqgy+0jVzr+A dIdboehdO3vjwZy/OFXZNwbRfPBZsMfT3a1bfygeKYjWGg1jOKWc9jXqM++ZV+bVNECr Gf6FmdQxlYVbYk0DloposHBlF2nVPRHR5XtLnobwc4ffhjZpibFiFNb8a5DBOnt1Lq8y WJFoEjVJLm5ZQBRj2kHjuz9Hx2YE7T+uV2NGw2U9uhBTyPE4kL6fCL/uwDDiQuLrgfpe XVnvs8r7kzcEDrw/gCIAz1+K9o2Uc+ZqEP7a+fwuOLVgP8SmBh9gSRa1ayMHvDKLytim igPA==
X-Gm-Message-State: AJcUukd/Ys7GCvSv600J9yk7ZTFpuzC2vHKuJ35Yj9/YNWntFExCC5Sm k4Nz23SuhzscaEHupzBOC+Hlgjxk
X-Google-Smtp-Source: ALg8bN58D+KYgcw87uHTY2+Px5Rgr3/zM14VxabVWRvH2kwRGRpbwuVR9nVgI+vfinOKf600/DxGIw==
X-Received: by 2002:adf:eec9:: with SMTP id a9mr40577981wrp.242.1546532117407; Thu, 03 Jan 2019 08:15:17 -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 j3sm5735173wmb.39.2019.01.03.08.15.15 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 03 Jan 2019 08:15:16 -0800 (PST)
To: Alexander Vainshtein <Alexander.Vainshtein@ecitele.com>
Cc: "mpls@ietf.org" <mpls@ietf.org>, Shell Nakash <Shell.Nakash@ecitele.com>, Jun Ye <Jun.Ye@ecitele.com>, "draft-ietf-mpls-sfl-framework@ietf.org" <draft-ietf-mpls-sfl-framework@ietf.org>
References: <AM0PR03MB3828DD11E7BCB069CB2B68DA9DB40@AM0PR03MB3828.eurprd03.prod.outlook.com> <36264762-7e7a-bd18-da0c-4db51185d426@gmail.com> <VI1PR03MB383925F57BF94AFF0A4A155F9D8D0@VI1PR03MB3839.eurprd03.prod.outlook.com>
From: Stewart Bryant <stewart.bryant@gmail.com>
Message-ID: <0d5334e3-a2f9-ba99-1cbe-2602c26dbe92@gmail.com>
Date: Thu, 3 Jan 2019 16:15:14 +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: <VI1PR03MB383925F57BF94AFF0A4A155F9D8D0@VI1PR03MB3839.eurprd03.prod.outlook.com>
Content-Type: multipart/alternative; boundary="------------FCFC5AC37F1727319A0B9DB7"
Content-Language: en-GB
Archived-At: <https://mailarchive.ietf.org/arch/msg/mpls/lgVHd2S8EwiMfx9gwIW1_mIJe7c>
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 16:15:23 -0000

Sasha,

On 03/01/2019 15:19, Alexander Vainshtein wrote:
>
> Stewart,
>
> Lots of thanks for a very detailed response.
>
> I have completely missed the (now expired) SFL Control draft. It looks 
> to me as a reasonable approach for applying SFL to PWs (and PW-based 
> services) and LSPs.
>
> But using it with BGP-based services, be it BGP/MPLS IP VPN or EVPN 
> (including EVPN-based VPWS services) would be non-trivial IMHO:
>
> -There are no (bi-directional) PWs in these services
>
No, but to do a performance measurement we need to establish a label 
that is unique to the pair.
>
> -There may be no end-to-end tunnel LSPs (e.g., if inter-AS Option B is 
> used)
>
If it is interAS there may be a security issue, but Section 4 specifies 
the use of the RFC6374 return address TLV so we can get the message to 
the responder on the normal LSP and get the reply back using IP.


> -Sending SFL Request messages with GAL and ACH following the VPN 
> application label is possible, but I do not see how the Reply can be 
> sent back
>
> -I do not think these messages can be piggy-backed on MP-BGP (even if 
> these days lots of things are).
>
> Did I miss something?
>
Please look at section 4. The only concern I have is whether I need to 
add security to the system to cope with the inter AS case.

Best regards

Stewart


> Regards,
>
> Sasha
>
> Office: +972-39266302
>
> Cell: +972-549266302
>
> Email:  Alexander.Vainshtein@ecitele.com
>
> *From:*Stewart Bryant <stewart.bryant@gmail.com>;
> *Sent:* Thursday, January 3, 2019 4:27 PM
> *To:* Alexander Vainshtein <Alexander.Vainshtein@ecitele.com>;; 
> draft-ietf-mpls-sfl-framework@ietf.org
> *Cc:* mpls@ietf.org; Shell Nakash <Shell.Nakash@ecitele.com>;; Jun Ye 
> <Jun.Ye@ecitele.com>;
> *Subject:* Re: A question about draft-ietf-mpls-sfl-framework
>
> 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
>     <mailto: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.
>     ___________________________________________________________________________
>
>
> ___________________________________________________________________________
>
> 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.
> ___________________________________________________________________________