Re: [mpls] Draft submitted - MPLS Entropy Block

"Joel M. Halpern" <jmh@joelhalpern.com> Tue, 02 June 2020 22:16 UTC

Return-Path: <jmh@joelhalpern.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 C11373A1078 for <mpls@ietfa.amsl.com>; Tue, 2 Jun 2020 15:16:40 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.098
X-Spam-Level:
X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=joelhalpern.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 KGeYAovnroeG for <mpls@ietfa.amsl.com>; Tue, 2 Jun 2020 15:16:39 -0700 (PDT)
Received: from mailb2.tigertech.net (mailb2.tigertech.net [208.80.4.154]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7C9F93A1074 for <mpls@ietf.org>; Tue, 2 Jun 2020 15:16:39 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by mailb2.tigertech.net (Postfix) with ESMTP id 49c5x32d3bz1p4Tn; Tue, 2 Jun 2020 15:16:39 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=joelhalpern.com; s=2.tigertech; t=1591136199; bh=IPD4pUOUoAls44HS4swnsE87d3kA847zW6J/BbJ4m0U=; h=Subject:To:References:From:Date:In-Reply-To:From; b=kp9fAyhJX7sbEScMD6DZC0P583DSDLyTnx4Lygl9mlK0kqUsc7l0v0HrX5nCx8bAp DxIfo1YiZ1BDIobHAlDEnpVtcMXOvnUXV1hsJ4mrCEkLdlP2fzUVwjUuW9HN7opKI9 zj8g/G7EqBJY7OQzh9GcGgWgMLaqL/De0gToJFg4=
X-Virus-Scanned: Debian amavisd-new at b2.tigertech.net
Received: from [192.168.128.43] (209-255-163-147.ip.mcleodusa.net [209.255.163.147]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mailb2.tigertech.net (Postfix) with ESMTPSA id 49c5x26B2kz1p0Cf; Tue, 2 Jun 2020 15:16:38 -0700 (PDT)
To: Jeff Tantsura <jefftant.ietf@gmail.com>, "mpls@ietf.org" <mpls@ietf.org>
References: <VI1PR07MB3168E8FD0C1562DB7B48C40CE18B0@VI1PR07MB3168.eurprd07.prod.outlook.com> <188d0d07-5e1f-4422-b144-b1ac547558c0@Spark> <8884715b-fcc9-201d-dc92-78027599ec51@joelhalpern.com> <76b40a4a-87ed-4c37-a830-ef9327a83f82@Spark>
From: "Joel M. Halpern" <jmh@joelhalpern.com>
Message-ID: <57f4fd7d-75ba-914c-9d76-6bc30f24c5bd@joelhalpern.com>
Date: Tue, 2 Jun 2020 18:16:38 -0400
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.8.1
MIME-Version: 1.0
In-Reply-To: <76b40a4a-87ed-4c37-a830-ef9327a83f82@Spark>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: en-US
Content-Transfer-Encoding: 8bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/mpls/oEsXH9q0N2M1SWpnwm5cOkIUREI>
Subject: Re: [mpls] Draft submitted - MPLS Entropy Block
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: Tue, 02 Jun 2020 22:16:41 -0000

RFC 8662 is readable piece of work.  And it explains well the choices 
and complications for where to place ELI / EL pairs.  it does not, in 
nay place I could see, discuss whether there are alternatives to using 
the pairs.  Which is reasonable.  using the pairs is the agreed current 
standard.

The draft be colleagues have written asks the question as to whether 
there are reasonable techniques that would allow us to leave out the ELI 
from those pairs.  It may be that we as a community prefer to keep the 
pairs.  But given that there are ways to reduce the stack, it seems 
worth asking.

Yours,
Joel

On 6/2/2020 5:18 PM, Jeff Tantsura wrote:
> Joel,
> 
> My assertion is based on reading the draft, no magic involved. None of 
> what you have mentioned below is discussed in the draft, hence ignored.
> 8662 goes in details as to why particular options have been chosen/rejected.
> 
> Cheers,
> Jeff
> On Jun 2, 2020, 2:01 PM -0700, Joel M. Halpern <jmh@joelhalpern.com>om>, wrote:
>> Jeff, you assertion that the authors are ignoring existing work seems to
>> border on mind-reading. Binding SIDs (ala 8662) are a way to reduce
>> label stack depth. It is a useful tool. Being able to remove the
>> Entropy Label Indicator would also be beneficial.
>>
>> The proposal does recognize that one may well need more than one entropy
>> label (and thus labels aimed at different targets) in the stack. The
>> initial portion of the document does focus on the single entropy label
>> case to make the idea clear. The authors (i am not one of them) are
>> well aware of the work on advertising various attributes of label depeth
>> for generation and processing.
>>
>> Yours,
>> Joel
>>
>> On 6/2/2020 4:54 PM, Jeff Tantsura wrote:
>>> Hello co-authors,
>>>
>>> The solution proposed ignores all the previous work done to address this
>>> particular issue. Without going into more details
>>> Please read RFC8662 to better understand all the different pieces 
>>> involved.
>>> draft-ietf-isis-mpls-elc/draft-ietf-ospf-mpls-elc specifically to
>>> understand control plane involved.
>>>
>>> Cheers,
>>> Jeff
>>> On Jun 2, 2020, 1:47 AM -0700, Jiang He
>>> <jiang.he=40ericsson.com@dmarc.ietf.org>rg>, wrote:
>>>>
>>>> Hello All,
>>>>
>>>> I just submitted a draft,
>>>> https://datatracker.ietf.org/doc/draft-jiang-mpls-entropy-block/ .  it
>>>> describes an approach for MPLS load balance, by  allocating a specific
>>>> MPLS label block for entropy usage.
>>>>
>>>> The purpose is to mitigate the limitation of the number of labels can
>>>> be pushed and the number of labels can be inspected when looking for
>>>> entropy information.
>>>>
>>>> Your comments are highly appreciated!
>>>>
>>>> Regards,
>>>>
>>>> Jiang
>>>>
>>>> _______________________________________________
>>>> mpls mailing list
>>>> mpls@ietf.org
>>>> https://www.ietf.org/mailman/listinfo/mpls
>>>
>>> _______________________________________________
>>> mpls mailing list
>>> mpls@ietf.org
>>> https://www.ietf.org/mailman/listinfo/mpls
>>>