Re: [mpls] [OSPF] ??: WG Last Call for "Signalling ELC using OSPF"

Acee Lindem <acee.lindem@gmail.com> Mon, 21 November 2016 17:19 UTC

Return-Path: <acee.lindem@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 76F8112948E; Mon, 21 Nov 2016 09:19:20 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.699
X-Spam-Level:
X-Spam-Status: No, score=-2.699 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_LOW=-0.7, SPF_PASS=-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 cLz0qX3sdLx4; Mon, 21 Nov 2016 09:19:18 -0800 (PST)
Received: from mail-qk0-x231.google.com (mail-qk0-x231.google.com [IPv6:2607:f8b0:400d:c09::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 A2DA5129441; Mon, 21 Nov 2016 09:19:17 -0800 (PST)
Received: by mail-qk0-x231.google.com with SMTP id n21so360024509qka.3; Mon, 21 Nov 2016 09:19:17 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=Ln5L2FW3DIzrrF8ll3r+T4GwdUvr4pP2dGaF0YZG/uk=; b=e1d7ME30TNqYEWyCZRqz+yYEPER8hmnU8QNA3E13SUqEpmlrhqW/kZeFNS74t/pJH6 nQNJpwQtpD5dnQx6QuAzlICdxMhpUfOSBBzQppKWNBQZ+1/Gw3jjR2g+O4z50bOXGaJy xY0RlLx3mJmeKU4wYB2CFjObOhHuHsDNpnCfw/3agrVDsK8afx5eebDALadypKj2a3cI psyib3LYX2804jDi+keypLprlHY5t8lmwR8ottjeQFWZCz2KDO22HckcLW1VlMiKDLDe MaH0TJzFdaXvFrrdemquxLVX1HteTgtIONSkA3xfb8GS2EpNwIDJjCbvpQu37FfrdYG7 a8yg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=Ln5L2FW3DIzrrF8ll3r+T4GwdUvr4pP2dGaF0YZG/uk=; b=VjUIrxLUUe8xxF5+eoJuYXx6gC4aintNMx4yJj8PB3iAnm7HK6GM7VFzGKFYQYR2V6 YpZJ5z6LK/xoru00+662KVJqwZ1kzsWpsGVO2KdYSBkwWPIzw/K7SMDROjJLFJyvMR64 FpEulskjDMdB4u11ETCYrKs7kMfmKYu2XuEEthN++vtb977My4aCdiK6hW4viZWuGtyO wjZ9WcBoZcRCENabzUwgmDqpZExj0Rve9SoL6RHR+Y4HN6/kvfedJfhEnEr47cDwP3wV Sus2J0QtzhkbErJ20OuMdh27IFAieT9RtOjDsfJTnEKu980lDZ2GbWiAWYLB5rNT1G9J l6gA==
X-Gm-Message-State: AKaTC03Imlq/R6OBS8tCiKiWqMyOAbfNmbxGY46f9JqY9I6vg/BgX+eouM6XTzAcqBa82g==
X-Received: by 10.55.5.145 with SMTP id 139mr16974196qkf.77.1479748756687; Mon, 21 Nov 2016 09:19:16 -0800 (PST)
Received: from rtp-acee-8819.cisco.com ([173.38.117.87]) by smtp.gmail.com with ESMTPSA id s89sm11641706qkl.27.2016.11.21.09.19.14 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 21 Nov 2016 09:19:15 -0800 (PST)
From: Acee Lindem <acee.lindem@gmail.com>
X-Google-Original-From: Acee Lindem <aceelindem@gmail.com>
Message-Id: <BFDA50F1-7CCC-4D42-9A47-A22BB1A45910@gmail.com>
Content-Type: multipart/alternative; boundary="Apple-Mail=_0EF1CBE7-F8F9-49D9-ABDB-34DC4CBAB6E7"
Mime-Version: 1.0 (Mac OS X Mail 10.1 \(3251\))
Date: Mon, 21 Nov 2016 12:19:14 -0500
In-Reply-To: <D4588FD4.8A454%acee@cisco.com>
To: "Acee Lindem (acee)" <acee@cisco.com>
References: <D4438504.8827B%acee@cisco.com> <16761_1478515435_58205AEB_16761_1458_1_53C29892C857584299CBF5D05346208A1EC6CD2A@OPEXCLILM21.corporate.adroot.infra.ftgroup> <D44692FE.88550%acee@cisco.com> <28362_1478603748_5821B3E4_28362_100_6_53C29892C857584299CBF5D05346208A1EC703D3@OPEXCLILM21.corporate.adroot.infra.ftgroup> <0361DDF1-086E-4E94-8EC6-6C38CBA19B76@cisco.com> <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE2BB2B73B@NKGEML515-MBX.china.huawei.com> <20678_1478768186_5824363A_20678_143_1_53C29892C857584299CBF5D05346208A1EC72B94@OPEXCLILM21.corporate.adroot.infra.ftgroup> <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE2BB2B97E@NKGEML515-MBX.china.huawei.com> <23297_1478784668_5824769C_23297_3960_1_53C29892C857584299CBF5D05346208A1EC73217@OPEXCLILM21.corporate.adroot.infra.ftgroup> <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE2BB2BF6A@NKGEML515-MBX.china.huawei.com> <D44DC081.88C99%acee@cisco.com> <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE2BB3317C@NKGEML515-MBX.china.huawei.com> <17816_1479120670_58299718_17816_688_3_53C29892C857584299CBF5D05346208A1EC772AB@OPEXCLILM21.corporate.adroot.infra.ftgroup> <5082_1479121544_58299A88_5082_3792_4_d485722b-6920-480f-8993-0eb383703f96@OPEXCLILM44.corporate.adroot.infra.ftgroup> <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE2BB3568E@NKGEML515-MBX.china.huawei.com> <28959_1479490211_582F3AA3_28959_7751_1_53C29892C857584299CBF5D05346208A1EC95702@OPEXCLILM21.corporate.adroot.infra.ftgroup> <D454EA3F.8A24B%acee@cisco.com> <18196_1479739414_58330816_18196_348_1_53C29892C857584299CBF5D05346208A1EC97A9F@OPEXCLILM21.corporate.adroot.infra.ftgroup> <D4588FD4.8A454%acee@cisco.com>
X-Mailer: Apple Mail (2.3251)
Archived-At: <https://mailarchive.ietf.org/arch/msg/mpls/_JkTqoN5RCugcgGnuLhsDAG2_44>
Cc: "mpls@ietf.org" <mpls@ietf.org>, OSPF WG List <ospf@ietf.org>
Subject: Re: [mpls] [OSPF] ??: WG Last Call for "Signalling ELC using OSPF"
X-BeenThere: mpls@ietf.org
X-Mailman-Version: 2.1.17
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, 21 Nov 2016 17:19:20 -0000

One grammar correction below. 

> On Nov 21, 2016, at 12:01 PM, Acee Lindem (acee) <acee@cisco.com> wrote:
> 
> Hi Bruno, 
> 
> From: Bruno Decraene <bruno.decraene@orange.com <mailto:bruno.decraene@orange.com>>
> Date: Monday, November 21, 2016 at 9:43 AM
> To: Acee Lindem <acee@cisco.com <mailto:acee@cisco.com>>, Xiaohu Xu <xuxiaohu@huawei.com <mailto:xuxiaohu@huawei.com>>
> Cc: OSPF WG List <ospf@ietf.org <mailto:ospf@ietf.org>>, "mpls@ietf.org <mailto:mpls@ietf.org>" <mpls@ietf.org <mailto:mpls@ietf.org>>, "Carlos Pignataro (cpignata)" <cpignata@cisco.com <mailto:cpignata@cisco.com>>
> Subject: RE: [OSPF] ??: WG Last Call for "Signalling ELC using OSPF"
> 
> Hi Acee,
>  
> From: Acee Lindem (acee) [mailto:acee@cisco.com <mailto:acee@cisco.com>] 
> Sent: Saturday, November 19, 2016 12:33 AM
> To: DECRAENE Bruno IMT/OLN; Xuxiaohu
> Cc: OSPF WG List; mpls@ietf.org <mailto:mpls@ietf.org>; Carlos Pignataro (cpignata)
> Subject: Re: [OSPF] ??: WG Last Call for "Signalling ELC using OSPF"
>  
> Hi Bruno, 
>  
> From: OSPF <ospf-bounces@ietf.org <mailto:ospf-bounces@ietf.org>> on behalf of Bruno Decraene <bruno.decraene@orange.com <mailto:bruno.decraene@orange.com>>
> Date: Friday, November 18, 2016 at 11:30 AM
> To: Xiaohu Xu <xuxiaohu@huawei.com <mailto:xuxiaohu@huawei.com>>
> Cc: OSPF WG List <ospf@ietf.org <mailto:ospf@ietf.org>>, "mpls@ietf.org <mailto:mpls@ietf.org>" <mpls@ietf.org <mailto:mpls@ietf.org>>, "Carlos Pignataro (cpignata)" <cpignata@cisco.com <mailto:cpignata@cisco.com>>
> Subject: Re: [OSPF] ??: WG Last Call for "Signalling ELC using OSPF"
>  
> Hi Xiaohu,
>  
> Please see inline [Bruno]
>  
> From: Xuxiaohu [mailto:xuxiaohu@huawei.com <mailto:xuxiaohu@huawei.com>] 
> Sent: Monday, November 14, 2016 1:00 PM
> To: DECRAENE Bruno IMT/OLN
> Cc: OSPF WG List; Carlos Pignataro (cpignata); mpls@ietf.org <mailto:mpls@ietf.org>
> Subject: ??: [OSPF] ??: WG Last Call for "Signalling ELC using OSPF"
>  
> Hi Bruno,
>  
> Could you please explain why the defination of the RLDC should be specific to the LB behavior of the transit LSR?
> [Bruno] The whole purpose of EL and ELC is to improve load balancing of MPLS packets on transit LSR.
> According to §6 of your draft, RLDC is also used to improve load-balancing : “The RLDC is used by ingress LSRs
>    to determine whether it's necessary to insert an EL for a given LSP
>    tunnel in the case where there has already been at least one EL in
>    the label stack. »
>  
> What would be the point for the ingress to add an additional EL, within the RLDC of LSR A, if LSR A do not use this EL to improve the load balancing?
> cf my example below where a LSR can read 5 labels, yet do not use those 5 labels for the load-balancing hence would not benefit from adding an EL within those 5 labels.
> BTW, it would be useful for the discussion if you could reply to the content of my email sent: Monday, November 14, 2016 (also included below). As this was already the second time I send this example on the OSPF mailing list.
> 
> 
>  
>  
> If I understand correctly, it seems that the text proposed by you conflict with Acee's take (see blow):
>  
> "   1. The standards track IGP drafts should have a precise definition of RLD and so not require a normative reference to the MPLS entropy draft (which is informational). The IGP drafts need not precisely specify how the information is used - this can be specified via a reference to the MPLS draft. 
>    2. The MPLS draft should precisely specify the initial use case of entropy label insertion at the ingress of the LSP. It should not limit the applicability of RLDC to this use case. "
>  
> [Bruno] I’m not seeing any conflict. I agree with both points. In this thread, I’m working on 1, i.e. having a clear definition of RLD.  But I would also like that this RLD advertisement be effective in improving the load-balancing of MPLS packets.
>  
> I think Readable Label Depth (RLD) should be independent of EL Capability (ELC). It allows advertisement of the the maximum number of labels an OSPF router will examine in a received MPLS encapsulated packet. 
>  If an OSPF Router supports ELC, it would imply that it support the EL Capability within RLD labels.
> [Bruno] Would work for me, assuming that this is stated in the document, and :s/support the EL Capability within RLD labels/for load-balancing purpose, use the EL within RLD labels.
> I would propose the following text: “RLDC is the maximum number of labels, from the top of the stack, where the MPLS transit LSR searches for the ELI,EL pair and load-balance based on the EL if present.”
> 
> I would completely decouple the two capabilities. Here is the text I would recommend. 
> 
> The Readable Label Depth (RLD) is the maximum number of labels, starting with top or first label in the stack, that an LSR can examine in a received MPLS packet.  The supported RLD can be important when searching for an entropy label for purpose of load-balancing as the <ELI, EL> pair must be included in the first RLD labels in the stack. 

The Readable Label Depth (RLD) is the maximum number of labels, starting with top or first label in the stack, that an LSR can examine in a received MPLS packet.  The supported RLD is important when searching for an entropy label for the purposes of load-balancing as the <ELI, EL> pair must be included in the first RLD labels in the stack. 

Thanks,
Acee



> 
>  
> think ELC should be defined in RFC 6790 and the SPRING Entropy label draft as opposed to the IGP advertisement drafts. 
> [Bruno] I tend to agree that the definition of RLD, or the load-balancing behavior of a transit LSR supporting EL, would be better specified by the MPLS WG. Then the value advertised by control plane protocols/signaling.
> https://tools.ietf.org/html/rfc7325#section-2.4.5 <https://tools.ietf.org/html/rfc7325#section-2.4.5> talks about this, but the document is informational, and the text is a bit too large/ open to have the LSR behavior advertised in the IGP using a single integer.
> But this option may delay a lot the IGP draft, unless it is splitted in 2 parts (as ELC is ready). Alternatively, I’m ok with your above  proposition.
> 
> Why can’t we simply use the definition of entropy processing included in RFC 6790 section 4? 
> 
> Thanks,
> Acee 
> 
> _______________________________________________
> OSPF mailing list
> OSPF@ietf.org <mailto:OSPF@ietf.org>
> https://www.ietf.org/mailman/listinfo/ospf <https://www.ietf.org/mailman/listinfo/ospf>