Re: [mpls] [Pals] ELI/EL for the PW
Shahram Davari <shahram.davari@broadcom.com> Wed, 15 November 2017 22:54 UTC
Return-Path: <shahram.davari@broadcom.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 B3E44128D0F for <mpls@ietfa.amsl.com>; Wed, 15 Nov 2017 14:54:01 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level:
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=broadcom.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 Th4sPDm60FVg for <mpls@ietfa.amsl.com>; Wed, 15 Nov 2017 14:53:57 -0800 (PST)
Received: from mail-qt0-x231.google.com (mail-qt0-x231.google.com [IPv6:2607:f8b0:400d:c0d::231]) (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 57165128B93 for <mpls@ietf.org>; Wed, 15 Nov 2017 14:53:57 -0800 (PST)
Received: by mail-qt0-x231.google.com with SMTP id n61so38247986qte.10 for <mpls@ietf.org>; Wed, 15 Nov 2017 14:53:57 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=broadcom.com; s=google; h=mime-version:subject:from:in-reply-to:date:cc:message-id:references :to; bh=A74dJTzylO50T8oIQF2Wa2hb0H79ZG/t5dGyaNEUTho=; b=IOqN42mZt+mdUD31EizI7FErmuVfZXslnitAAynJ8if3BRJ4Y6kje63hDxTTnvANZP BGxWYPj5ifUEtqys22Llxv6P0/lT5rWwDTIIXRxWPkvvPZdkHATHjeo9nXpn9yDyweNw AlLxQtCPQEWthbc/CD/e26/t5MnDDmW0MazUg=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :message-id:references:to; bh=A74dJTzylO50T8oIQF2Wa2hb0H79ZG/t5dGyaNEUTho=; b=SyYu6OQbaEUwf99ydjL9viuR6j565GuihqQtwbyS9er5lylLb4/VZsl+WagrURVWSM WLO6lZZ7gM8F9GGYv87S6l7qIHC8C1unXD8xaGIrXnbo0nzqiQBwZbvHAiE19/NWohvp KWvfg6dDoX2L8+Qh9KEdLDlOAHwF2yNyBaw/djlvanB5x0+SQsV2Ybgdv143cTdH+F2h mrHX4vMfwJElkGj6kwt5Zp4xY/dPZQVyUY2oedp2V+4Vcz0b+xXO+aH/dCUzNbcLX1Sg JHhjOZ0V20hG+vrYjOUcm5E+0By+xp5fv4PvgwwxXhCyx2ICyan067wvHC1uAxTF202I AYUw==
X-Gm-Message-State: AJaThX7eQeIgI4WMFWQmvbf8DVJSNlLyyK/nFDSGJx1PAxKUT6wjifz8 YUEu22BQPQthWyJ5a/twkRH71HX0O8M=
X-Google-Smtp-Source: AGs4zMaqTuOnApS/fZTV6c2xrVosjsy9CuS5HbmIxaHMvm5ZMB56CXUj8tBfu5rKsZfnFMDo9+gstg==
X-Received: by 10.55.27.88 with SMTP id b85mr27114108qkb.144.1510786436285; Wed, 15 Nov 2017 14:53:56 -0800 (PST)
Received: from c02rq0djfvh9.dhcp.broadcom.net ([216.31.219.19]) by smtp.gmail.com with ESMTPSA id m6sm14928886qti.14.2017.11.15.14.53.54 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Wed, 15 Nov 2017 14:53:55 -0800 (PST)
Content-Type: multipart/alternative; boundary="Apple-Mail=_48882BA7-9DEB-4BBC-9CFC-E466CB29647B"
Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\))
From: Shahram Davari <shahram.davari@broadcom.com>
In-Reply-To: <683f4b93-a3ae-ada5-f716-be7c409188e2@gmail.com>
Date: Wed, 15 Nov 2017 14:53:53 -0800
Cc: pals@ietf.org, "mpls@ietf.org" <mpls@ietf.org>
Message-Id: <1A447EAF-9C33-4469-A86C-45C7456DB013@broadcom.com>
References: <EE709087-637C-4647-ABB8-DA5FFAE45D7D@ciena.com> <HE1PR03MB17223A1FC7707363B423E00C9D280@HE1PR03MB1722.eurprd03.prod.outlook.com> <741BDF3F-C90F-44FF-AD59-A29CF612FBBD@ciena.com> <AM4PR03MB1713192DD3D35A69667EDAB79D290@AM4PR03MB1713.eurprd03.prod.outlook.com> <A756C03C-90E3-4BEC-95C0-B07836C8AE5E@ciena.com> <683f4b93-a3ae-ada5-f716-be7c409188e2@gmail.com>
To: Stewart Bryant <stewart.bryant@gmail.com>
X-Mailer: Apple Mail (2.3124)
Archived-At: <https://mailarchive.ietf.org/arch/msg/mpls/O5J4bVVO4ItCPdrRoctF0oduNJg>
Subject: Re: [mpls] [Pals] ELI/EL for the PW
X-BeenThere: mpls@ietf.org
X-Mailman-Version: 2.1.22
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: Wed, 15 Nov 2017 22:54:02 -0000
Himanshu We can’t consider the PW label as PW-LSP, even though there is a PW label swapping at S-PE. At most you can consider it as PW-LSP only at the S-PE but not at the Terminating PE. We can’t do it is because we need to get packet processing context from PW label such as the Payload Type (IP, Ethernet, etc.), Existence of CW, and whether we are doing PHP or not, etc. If we assume PW-LSP then we can’t get any of these information from PW label. So I really object to using ELI/EL below PW label. Existing HW that complies to RFCs can’t support this. Thx Shahram > On Nov 15, 2017, at 12:06 AM, Stewart Bryant <stewart.bryant@gmail.com> wrote: > > Copying the thread to MPLS to include them in the discussion. > > Please will copy future discussion to MPLS on this topic. > > Thanks > > Stewart > > > On 15/11/2017 06:14, Shah, Himanshu wrote: >> Hi Sasha – >> >> I understand that and I do not want to belabor my point. >> So just to clarify my point, you can view MS-PW as “PW-LSP” >> with S-PE as “PW-LSR”. In that context, ELI/EL below PW label, >> makes sense. >> >> FAT PW RFC predates the ELI/EL, but if that was not the case, >> ELI/EL easily would have been used as the solution the way I describe above. >> >> But that is all water under the bridge. >> So, let us move on. >> >> On the follow on topic on the guideline, >> Where we say “when both are supported ONLY ONE (ELI/EL or FAT label) SHOULD be used”. >> >> Since FAT label does not protect from ECMP based on DPI beyond PW CW, BOTH schemes are >> required since FAT label suffers same mis-ordering consequences. >> In addition, S-PE MUST preserve and/or regenerate ELI/EL above PW label, >> If WG chose to provide guidelines on how to avoid mi-ordering in the presence of such switches. >> >> Thanks, >> Himanshu >> >> From: "Alexander com>" <Alexander.Vainshtein@ecitele.com> <mailto:Alexander.Vainshtein@ecitele.com> >> Date: Wednesday, November 15, 2017 at 1:48 PM >> To: "pals@ietf.org" <mailto:pals@ietf.org> <pals@ietf.org> <mailto:pals@ietf.org>, "Shah, Himanshu" <hshah@ciena.com> <mailto:hshah@ciena.com> >> Subject: Re: [Pals] ELI/EL for the PW >> >> Himanshu, >> Of course EL/ELI can be placed anywhere in the stack. But it can only be inserted if the Egress LSR for the tunnel supports it. And in MS-PW each S-PE terminates the tunnel LSP. >> >> From my POV flow labels are the ONLY right mechanism for adding entropy to MS-PWs end-to-end. >> >> Thump typed by Sasha Vainshtein >> >> From: Shah, Himanshu <hshah@ciena.com> <mailto:hshah@ciena.com> >> Sent: Wednesday, November 15, 2017 3:24:54 AM >> To: Alexander Vainshtein; pals@ietf.org <mailto:pals@ietf.org> >> Subject: Re: [Pals] ELI/EL for the PW >> >> Hi Shasha, >> >> You are correct about how it is written in RFC 6790. >> >> I did talk to Kireeti briefly in the hallway about placement of ELI/EL and MS-PW. >> He also did say the same but he also said that it does not matter where you place it, >> as far as processing of the ELI/EL, would work irrespective. >> >> MS-PW technology throws the monkey ranch. >> One could just support 6790 and not 6391 for PW if ELI/EL placed below PW label. >> It solves preservation of entropy across S-PE, nicely. >> >> Thanks, >> Himanshu >> >> From: "Alexander com>" <Alexander.Vainshtein@ecitele.com> <mailto:Alexander.Vainshtein@ecitele.com> >> Date: Tuesday, November 14, 2017 at 8:14 PM >> To: "pals@ietf.org" <mailto:pals@ietf.org> <pals@ietf.org> <mailto:pals@ietf.org>, "Shah, Himanshu" <hshah@ciena.com> <mailto:hshah@ciena.com> >> Subject: Re: [Pals] ELI/EL for the PW >> >> Himamshu and all, >> I respetfully disagree. >> >> As I see it, RFC 6790 in Section 4.2 Ingress LSR" inambiguously states that EL and ELI, if used, between thr TL and "application label" (if spplication lsbel is used). It also specifies, that EL and ELI are only pushed on an incoming packet if the tunnel egress LSR has signaled that it can handle EL on the specific tunnel LSP it terminates. >> >> To me this means that in the case of a MS-PW, EL and ELI CANNOT preserved by an S-PE. Whether they can be generated by an SPE is another story. >> >> FAT labels, on the contrary, are always the BoS labels and thrrfore are preserved by SPEs of a MS-PW. >> >> Did I miss something substantial? >> >> Thump typed by Sasha Vainshtein >> >> From: Pals <pals-bounces@ietf.org> <mailto:pals-bounces@ietf.org> on behalf of Shah, Himanshu <hshah@ciena.com> <mailto:hshah@ciena.com> >> Sent: Tuesday, November 14, 2017 5:30:13 AM >> To: pals@ietf.org <mailto:pals@ietf.org> >> Subject: [Pals] ELI/EL for the PW >> >> The PALS WG discussions yesterday at the IETF100, we discussed the competing >> FAT PW and ELI/EL for the PW and its fate at S-PE. >> >> I mentioned this at Mike but got lost in subsequent discussions. >> >> FAT PW label as well as ELI/EL for PW (based on microflow within PW) resides >> below PW label. Thus, @ingress PE, once microflow is identified, either ELI/EL >> or FAT PW label is pushed. >> >> @S-PE, PW label swap does not have to preserve the ELI/EL while doing PW label swapping, >> BECAUSE it is already below the PW label, just like how FAT PW label would be. >> >> I confirmed this from our data plane engineer. >> (we can check with Kireeti as well) >> >> I would like to know if other vendors are doing this differently?? >> >> Given this is true, for the switches that do DPI past PW control word for ECMP, >> FAT PW label would suffer the same misordering as no FAT PW label >> However, ELI/EL would NOT – because of the presence of ELI >> >> Thanks, >> Himanshu >> >> ___________________________________________________________________________ >> >> 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. >> ___________________________________________________________________________ >> >> >> >> _______________________________________________ >> Pals mailing list >> Pals@ietf.org <mailto:Pals@ietf.org> >> https://www.ietf.org/mailman/listinfo/pals <https://www.ietf.org/mailman/listinfo/pals> > > _______________________________________________ > mpls mailing list > mpls@ietf.org <mailto:mpls@ietf.org> > https://www.ietf.org/mailman/listinfo/mpls <https://www.ietf.org/mailman/listinfo/mpls>
- Re: [mpls] [Pals] ELI/EL for the PW Stewart Bryant
- Re: [mpls] [Pals] ELI/EL for the PW Shahram Davari
- Re: [mpls] [Pals] ELI/EL for the PW Shah, Himanshu