Re: [mpls] Working Group Last Call for "Signaling Entropy Label Capability and Entropy Readable Label-stack Depth Using ISIS" - draft-ietf-isis-mpls-elc-07

Peter Psenak <ppsenak@cisco.com> Mon, 02 September 2019 11:03 UTC

Return-Path: <ppsenak@cisco.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 A3F7F120108; Mon, 2 Sep 2019 04:03:46 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.502
X-Spam-Level:
X-Spam-Status: No, score=-14.502 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.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 mbzZNm2HLjTd; Mon, 2 Sep 2019 04:03:44 -0700 (PDT)
Received: from aer-iport-3.cisco.com (aer-iport-3.cisco.com [173.38.203.53]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 72B0112006A; Mon, 2 Sep 2019 04:03:43 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4565; q=dns/txt; s=iport; t=1567422224; x=1568631824; h=subject:to:cc:references:from:message-id:date: mime-version:in-reply-to:content-transfer-encoding; bh=I5i6KvvLFIaf0bAIdksRiu8tHBXDhDa0ynDlGyUMUac=; b=nDZfRKIFQQLmKW8R2NA7s8kFIrcHkcWUNPVk4s0iowBaNdA4JQdld9PW WJj5cvw0foY6VtcUMddNouXSnWxuiwbrI6fAOv5kiNcM/zA8jU3JrQ4t1 imjbcQwG7wanJbjJd3Xs3mnd8WTksYMI1GyzAt0XLS4YMrx2wSHLKBAUB 4=;
X-IronPort-AV: E=Sophos;i="5.64,458,1559520000"; d="scan'208";a="16198133"
Received: from aer-iport-nat.cisco.com (HELO aer-core-2.cisco.com) ([173.38.203.22]) by aer-iport-3.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 02 Sep 2019 11:03:41 +0000
Received: from [10.147.24.38] ([10.147.24.38]) by aer-core-2.cisco.com (8.15.2/8.15.2) with ESMTP id x82B3fT2008311; Mon, 2 Sep 2019 11:03:41 GMT
To: bruno.decraene@orange.com, "Acee Lindem (acee)" <acee@cisco.com>, "lsr@ietf.org" <lsr@ietf.org>, "draft-ietf-isis-mpls-elc@ietf.org" <draft-ietf-isis-mpls-elc@ietf.org>
Cc: "mpls@ietf.org" <mpls@ietf.org>, "lsr-ads@ietf.org" <lsr-ads@ietf.org>
References: <B645A02C-1267-41C8-988F-A9FA4DE565B4@cisco.com> <MN2PR11MB36473898226B71BB5926E5E7C1BE0@MN2PR11MB3647.namprd11.prod.outlook.com> <21833_1567418380_5D6CE80C_21833_195_1_53C29892C857584299CBF5D05346208A48BE4C18@OPEXCAUBM43.corporate.adroot.infra.ftgroup>
From: Peter Psenak <ppsenak@cisco.com>
Message-ID: <ed441ea1-bdab-c26a-747f-6f747bb8cdd1@cisco.com>
Date: Mon, 2 Sep 2019 13:03:41 +0200
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:60.0) Gecko/20100101 Thunderbird/60.7.0
MIME-Version: 1.0
In-Reply-To: <21833_1567418380_5D6CE80C_21833_195_1_53C29892C857584299CBF5D05346208A48BE4C18@OPEXCAUBM43.corporate.adroot.infra.ftgroup>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: en-US
Content-Transfer-Encoding: 8bit
X-Outbound-SMTP-Client: 10.147.24.38, [10.147.24.38]
X-Outbound-Node: aer-core-2.cisco.com
Archived-At: <https://mailarchive.ietf.org/arch/msg/mpls/wfQTBjvLrSbIlxa72Qn2SFt2OuE>
Subject: Re: [mpls] Working Group Last Call for "Signaling Entropy Label Capability and Entropy Readable Label-stack Depth Using ISIS" - draft-ietf-isis-mpls-elc-07
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: Mon, 02 Sep 2019 11:03:47 -0000

Hi Bruno,

On 02/09/2019 11:59, bruno.decraene@orange.com wrote:
> Support.
> 
> This is needed for using MPLS Entropy Label in SR-MPLS.
> 
> Please find below some proposed comments. Please feel free to silently 
> discard.
> 
> §1 Introduction
> 
> OLD:
> 
> “This capability, referred to as Entropy
> 
> Readable Label Depth (ERLD) as defined in
> 
> [I-D.ietf-mpls-spring-entropy-label  <https://tools.ietf.org/html/draft-ietf-isis-mpls-elc-07#ref-I-D.ietf-mpls-spring-entropy-label>] may be used by ingress LSRs to
> 
> determine whether it's necessary to insert an EL for a given LSP in
> 
> the case where there has already been at least one EL in the label
> 
> stack [I-D.ietf-mpls-spring-entropy-label  <https://tools.ietf.org/html/draft-ietf-isis-mpls-elc-07#ref-I-D.ietf-mpls-spring-entropy-label>].”
> 
> NEW:
> 
> This capability, referred to as Entropy
> 
> Readable Label Depth (ERLD) as defined in
> 
> [I-D.ietf-mpls-spring-entropy-label  <https://tools.ietf.org/html/draft-ietf-isis-mpls-elc-07#ref-I-D.ietf-mpls-spring-entropy-label>] may be used by ingress LSRs to
> 
> determine the position of the EL label in the stack, and whether it's 
> necessary to insert multiple EL at different depth.

What about the slightly modified wording:

"This capability, referred to as Entropy Readable Label Depth (ERLD) as
defined in <xref target="I-D.ietf-mpls-spring-entropy-label"/> may be
used by ingress LSRs determine the position of the EL in the stack, and 
whether it's necessary to insert multiple ELs at different position in 
the label stack."

> 
> §7Security Considerations
> 
> “This document does not introduce any new security risks.”
> 
> Incorrectly setting the E flag (ELC capable) (during origination, 
> propagation, redistribution) may lead to black-holing the traffic on the 
> egress node. I believe this risk should be mentioned.

done.

thanks,
Peter
> 
> Regards,
> 
> --Bruno
> 
> *From**:*Lsr [mailto:lsr-bounces@ietf.org] *On Behalf Of * Les Ginsberg 
> (ginsberg)
> *Sent:* Monday, September 2, 2019 6:48 AM
> *To:* Acee Lindem (acee); lsr@ietf.org
> *Cc:* mpls@ietf.org; lsr-ads@ietf.org; draft-ietf-isis-mpls-elc@ietf.org
> *Subject:* Re: [Lsr] Working Group Last Call for "Signaling Entropy 
> Label Capability and Entropy Readable Label-stack Depth Using ISIS" - 
> draft-ietf-isis-mpls-elc-07
> 
> I support moving forward with these drafts.
> 
> There are clearly use cases for this functionality and the solution has 
> been vetted with providers who intend to deploy this.
> 
>     Les
> 
> *From:*Lsr <lsr-bounces@ietf.org>; *On Behalf Of *Acee Lindem (acee)
> *Sent:* Friday, August 30, 2019 12:44 PM
> *To:* lsr@ietf.org
> *Cc:* mpls@ietf.org; lsr-ads@ietf.org; draft-ietf-isis-mpls-elc@ietf.org
> *Subject:* [Lsr] Working Group Last Call for "Signaling Entropy Label 
> Capability and Entropy Readable Label-stack Depth Using ISIS" - 
> draft-ietf-isis-mpls-elc-07
> 
> We’ve gone through a number of iterations with these ELC drafts and I 
> believe they are ready and meets all the use case requirements. Note 
> that “Entropy Label for Spring tunnels” – 
> draft-ietf-mpls-spring-entropy-label-12 is on the RFC editor’s queue.
> 
> This begins a two week last call for the subject draft. Please indicate 
> your support or objection on this list prior to 12:00 AM UTC on Sept 
> 14^th , 2014. Also, review comments are certainly welcome.
> 
> Thanks,
> Acee
> 
> _________________________________________________________________________________________________________________________
> 
> Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc
> pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler
> a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,
> Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.
> 
> This message and its attachments may contain confidential or privileged information that may be protected by law;
> they should not be distributed, used or copied without authorisation.
> If you have received this email in error, please notify the sender and delete this message and its attachments.
> As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.
> Thank you.
>