Re: [bess] SHL label

Anush Mohan <anush.iitm@gmail.com> Wed, 05 June 2019 03:38 UTC

Return-Path: <anush.iitm@gmail.com>
X-Original-To: bess@ietfa.amsl.com
Delivered-To: bess@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 47321120397 for <bess@ietfa.amsl.com>; Tue, 4 Jun 2019 20:38:03 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.997
X-Spam-Level:
X-Spam-Status: No, score=-1.997 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_HELO_NONE=0.001, 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 j-TZk2f2NxN2 for <bess@ietfa.amsl.com>; Tue, 4 Jun 2019 20:38:01 -0700 (PDT)
Received: from mail-vs1-xe32.google.com (mail-vs1-xe32.google.com [IPv6:2607:f8b0:4864:20::e32]) (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 3A72A1202E9 for <bess@ietf.org>; Tue, 4 Jun 2019 20:38:01 -0700 (PDT)
Received: by mail-vs1-xe32.google.com with SMTP id l125so14841211vsl.13 for <bess@ietf.org>; Tue, 04 Jun 2019 20:38:01 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=qs19BDMM6u4OaAB//qTvsP2m3ltChN9xWbizGxqvQGk=; b=hk7BxhSdXkdyE1SObQ45AcrLzYK9HFEGnBMmeGgZ3MNdbF/1SpCUAGmBeyR5rYFr9e RyXkm7tqFVoMhIQLQHv/s8+ErFwTMqJaWypUw5z+ghOQJdT2QOEvZf7YhOgTPTscZb4+ 15Zf/Ad6fLfczccDt3o3LFpiffVNHi9t/uMRk+AQrZo8pf6nnDzx0KdhFKWlO02N1K80 Ar/xVRVrwEgwa+7NJXv/mTsBvBw9YQQLTGbidzca+sVia755csnowsjMFMULh9lFBcYa tonz/kFocdkYOYGmj7VVUdek8cqLXo55rHntEO3JTuJ9b1qbZLWUr5FBIibH52ddywS6 07lQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=qs19BDMM6u4OaAB//qTvsP2m3ltChN9xWbizGxqvQGk=; b=H2ewfPcwJe0eacecqyyKePddcHF6NlgeJvr8aZ4X/jh+gw0Ps3wH+ZN4/QzxwNXzsU J91rfl6j94Bn/BVjtyQllTHR0qgozB/od1ChPXHq2lvQL7TrGhIjscjVqDW/4dqYQEiC 0DUd2fLFBTzNs0E5kjD3dByVRV1hLtfEjmPfENEG+MqLLUCRrg5TIJOBmhLNCZJYj0Yu x2r9Hy0MFzgNCGIQBNhq+1K/q9CwX5nrbZe5BpPcQcUtvXFriqW6dXDPXEf0Cg6VaEwV qFsqbjm84sm005xFtWWxTPw90Pr6OhBa768v4Q4qSnVx3hacQePO+5tMos34az9aLMW/ 1TYA==
X-Gm-Message-State: APjAAAUSyVb86aNfDggdVUbzD7njwaX6c8BNFzbuH8dzlRo9wEq5vZBP 7ZyJTshOiSmW6k8V3RU98VQKWlcF+0cYPUvqpRA=
X-Google-Smtp-Source: APXvYqyqd5auZt3nsaGHyNTMCilNzLO1k9jetBRGxeZFuLNATcqDrDiUiyH/lSguXYIfvFoJz04R8VVElUpz66aq/LI=
X-Received: by 2002:a67:6d44:: with SMTP id i65mr19196149vsc.106.1559705879999; Tue, 04 Jun 2019 20:37:59 -0700 (PDT)
MIME-Version: 1.0
References: <CAAG_SC-_P53HzYYPBTwag2bN6WOk+xbOM88E6A1Zfg73Aa_Apw@mail.gmail.com> <0307BA53-B141-4D65-9BD8-0BC0D63BBD4D@nokia.com> <AM0PR03MB38286DCF7007B81EC60D3F539D150@AM0PR03MB3828.eurprd03.prod.outlook.com>
In-Reply-To: <AM0PR03MB38286DCF7007B81EC60D3F539D150@AM0PR03MB3828.eurprd03.prod.outlook.com>
From: Anush Mohan <anush.iitm@gmail.com>
Date: Wed, 05 Jun 2019 09:07:43 +0530
Message-ID: <CAO76cfUPUFze+Z1qAzCnEU=XGVRD9puxJCKsk_9OgcVe==tFOg@mail.gmail.com>
To: Alexander Vainshtein <Alexander.Vainshtein@ecitele.com>
Cc: gangadhara reddy chavva <meetgangadhara@gmail.com>, "bess@ietf.org" <bess@ietf.org>, "Rabadan, Jorge (Nokia - US/Mountain View)" <jorge.rabadan@nokia.com>
Content-Type: multipart/alternative; boundary="000000000000ee7a0c058a8b520b"
Archived-At: <https://mailarchive.ietf.org/arch/msg/bess/sAuQm_PJzkNNniYK0rQPiNvFWCU>
Subject: Re: [bess] SHL label
X-BeenThere: bess@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: BGP-Enabled ServiceS working group discussion list <bess.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/bess>, <mailto:bess-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/bess/>
List-Post: <mailto:bess@ietf.org>
List-Help: <mailto:bess-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/bess>, <mailto:bess-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 05 Jun 2019 03:38:04 -0000

hi,

   I had a follow up question regarding this.

  If we are using P2MP tunnel for replicating BUM traffic, the ESI-label is
assigned by upstream PE, but actually programmed by downstream PEs in the
context of upstream-PE. In this case, does the upstream-PE still need to
assign this label from its platform label-space ? ( In other words this
label can't be used by upstream-PE to receive any incoming label traffic)

  The scenario I want to clarify is: we already  have an EVI using P2MP
tunnel for replicating BUM traffic, configured on this ES.
  And later we configure another EVI on this ES, where we want to use
ingress replication for sending BUM traffic.


Regards
Anush


On Tue, Jun 4, 2019 at 8:33 PM Alexander Vainshtein <
Alexander.Vainshtein@ecitele.com> wrote:

> Hi all,
> I concur with Jorge.
>
> The ESI label is allocated per MH ES and does not depend on the service or
> on the method by which BUM frames are deliverd. This method only affects
> the way in which it is used:
> - in the case of ingress replication a copy that is sent to the specific
> LE attached to a given MH ES uses the label this PE has advertised for this
> ES. I.e. it is used as downstream-allocated
> - In the case of P2MP LSPs (where all PEs receive the same copy) the
> transmitter uses the ESI label it has allocated for the ES (it is
> upstream-allocated), and each receiver uses the label(s) that identify the
> transmitter PE  as the context labels for its correct processing.
>
> RFC 7474 is quite clear in this regard from my POV.
>
>
> Thumb typed by Sasha Vainshtein
>
>
>
> From: Rabadan, Jorge (Nokia - US/Mountain View)
> Sent: Tuesday, June 4, 15:38
> Subject: Re: [bess] SHL label
> To: gangadhara reddy chavva, bess@ietf.org
>
>
> Hi,
>
> The ESI label is signaled in the A-D per ES route(s), and those routes are
> (should be) service agnostic.
> Also as you can see in RFC7432, the ESI label is downstream allocated for
> ingress replication but upstream allocated for p2mp - So it’s not that you
> allocate different ESI label per service, but the label that you use has
> different owner.
>
> I think RFC7432 is pretty clear about this. Not sure where the confusion
> is.
>
> Thanks.
> Jorge
>
> *From: *gangadhara reddy chavva <meetgangadhara@gmail.com>
> *Date: *Monday, June 3, 2019 at 2:05 PM
> *To: *"bess@ietf.org" <bess@ietf.org>, "Rabadan, Jorge (Nokia -
> US/Mountain View)" <jorge.rabadan@nokia.com>
> *Subject: *SHL label
>
> Hi Jorge,
>
> I have a Question on EVPN MH SHL(split horizon label).
>
> Can ESI share the different SHL label for the same ESI?
>
> *case 1:* in the same ESI one customer EVPN VPN can have ingress
> replication for the BUM traffic and second EVPN VPN ine the same ESI can do
> P2MP? in this case SHL label should be different.
>
> *case 2: *can VPLS allocate one SHL and VPWS can allocate diffrent SHL
> label? or SHL should be same per ESI irrespective of number of applications
> enabled in that ESI.
>
> Thanks,
> Gangadhar
>
>
>
>
> ___________________________________________________________________________
>
> 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.
> ___________________________________________________________________________
> _______________________________________________
> BESS mailing list
> BESS@ietf.org
> https://www.ietf.org/mailman/listinfo/bess
>