Re: [Lsr] I-D Action: draft-ietf-ospf-mpls-elc-15.txt

wangyali <wangyali11@huawei.com> Wed, 03 June 2020 14:01 UTC

Return-Path: <wangyali11@huawei.com>
X-Original-To: lsr@ietfa.amsl.com
Delivered-To: lsr@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AB0FA3A0B08 for <lsr@ietfa.amsl.com>; Wed, 3 Jun 2020 07:01:09 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.898
X-Spam-Level:
X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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
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 wVJ2CTilTpNt for <lsr@ietfa.amsl.com>; Wed, 3 Jun 2020 07:01:08 -0700 (PDT)
Received: from huawei.com (lhrrgout.huawei.com [185.176.76.210]) (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 1FBE53A0B04 for <lsr@ietf.org>; Wed, 3 Jun 2020 07:01:08 -0700 (PDT)
Received: from lhreml718-chm.china.huawei.com (unknown [172.18.7.106]) by Forcepoint Email with ESMTP id CB3E6B6CB718CF061FA5 for <lsr@ietf.org>; Wed, 3 Jun 2020 15:01:06 +0100 (IST)
Received: from lhreml718-chm.china.huawei.com (10.201.108.69) by lhreml718-chm.china.huawei.com (10.201.108.69) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.1913.5; Wed, 3 Jun 2020 15:01:06 +0100
Received: from DGGEML423-HUB.china.huawei.com (10.1.199.40) by lhreml718-chm.china.huawei.com (10.201.108.69) with Microsoft SMTP Server (version=TLS1_0, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA) id 15.1.1913.5 via Frontend Transport; Wed, 3 Jun 2020 15:01:06 +0100
Received: from DGGEML524-MBX.china.huawei.com ([169.254.1.54]) by dggeml423-hub.china.huawei.com ([10.1.199.40]) with mapi id 14.03.0487.000; Wed, 3 Jun 2020 22:01:01 +0800
From: wangyali <wangyali11@huawei.com>
To: "Acee Lindem (acee)" <acee@cisco.com>, "lsr@ietf.org" <lsr@ietf.org>
Thread-Topic: [Lsr] I-D Action: draft-ietf-ospf-mpls-elc-15.txt
Thread-Index: AQHWOAIEh2jjpQCPdkmVCgD6vsrWz6jGuuaA//+peICAAIhDkA==
Date: Wed, 03 Jun 2020 14:01:01 +0000
Message-ID: <1520992FC97B944A9979C2FC1D7DB0F404E7EFB2@dggeml524-mbx.china.huawei.com>
References: <159100094287.10006.5637389500374152632@ietfa.amsl.com> <1520992FC97B944A9979C2FC1D7DB0F404E7EF31@dggeml524-mbx.china.huawei.com> <4B5EBBE2-3ED3-4C30-8018-4460166E81A4@cisco.com>
In-Reply-To: <4B5EBBE2-3ED3-4C30-8018-4460166E81A4@cisco.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.108.203.65]
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Archived-At: <https://mailarchive.ietf.org/arch/msg/lsr/-GE_5dpSOZWxIMHEqt_-sN2Ecfs>
Subject: Re: [Lsr] I-D Action: draft-ietf-ospf-mpls-elc-15.txt
X-BeenThere: lsr@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Link State Routing Working Group <lsr.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/lsr>, <mailto:lsr-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/lsr/>
List-Post: <mailto:lsr@ietf.org>
List-Help: <mailto:lsr-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/lsr>, <mailto:lsr-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 03 Jun 2020 14:01:10 -0000

Hi Acee,

Thanks for your kind suggestion. 

Best regards,
Yali

-----Original Message-----
From: Acee Lindem (acee) [mailto:acee@cisco.com] 
Sent: Wednesday, June 3, 2020 9:46 PM
To: wangyali <wangyali11@huawei.com>; lsr@ietf.org
Subject: Re: [Lsr] I-D Action: draft-ietf-ospf-mpls-elc-15.txt

Speaking as WG chair:

It seems were getting a number of questions and comments on these ELC signaling documents as they go to the RFC Queue. I'd like to encourage review and discussion of LSR documents earlier in the WG process. One way to facilitate this would be for the authors to solicit review and discussion on the LSR list. This can be done at any time but should be done when documents are refreshed. 

Thanks,
Acee

On 6/3/20, 7:36 AM, "Lsr on behalf of wangyali" <lsr-bounces@ietf.org on behalf of wangyali11@huawei.com> wrote:

    Hi authors,

    After reading this draft, I am not clear with following points.

    First,  as said " Even though ELC is a property of the node, in some cases it is advantageous to associate and advertise the ELC with a prefix.", what are "some cases" in which it is advantageous to associate and advertise the ELC with a prefix? And ELC is a property of the node, why don't extend the OSPF RI Opaque LSA to carry ELC?

    Second, as said " If a router has multiple interfaces, the router MUST NOT announce ELC unless all of its interfaces are capable of processing ELs. ", why do not consider ELC advertisement in link granularity? 

    Third, as said " If the router supports ELs on all of its interfaces, it SHOULD advertise the ELC with every local host prefix it advertises in OSPF.", what is the "every local host prefix"?

    Last one, as defined that ERLD is advertised in a Node MSD TLV, why the ERLD-MSD type can be received in the OSPFv2 or OSPFv3 Link MSD sub-TLV? " When the ERLD-MSD type is received in the OSPFv2 or OSPFv3 Link MSD Sub-TLV [RFC8476], it MUST be ignored."

    Best regards,
    Yali

    -----Original Message-----
    From: internet-drafts@ietf.org [mailto:internet-drafts@ietf.org] 
    Sent: Monday, June 1, 2020 4:42 PM
    To: i-d-announce@ietf.org
    Cc: lsr@ietf.org
    Subject: [Lsr] I-D Action: draft-ietf-ospf-mpls-elc-15.txt


    A New Internet-Draft is available from the on-line Internet-Drafts directories.
    This draft is a work item of the Link State Routing WG of the IETF.

            Title           : Signaling Entropy Label Capability and Entropy Readable Label Depth Using OSPF
            Authors         : Xiaohu Xu
                              Sriganesh Kini
                              Peter Psenak
                              Clarence Filsfils
                              Stephane Litkowski
                              Matthew Bocci
    	Filename        : draft-ietf-ospf-mpls-elc-15.txt
    	Pages           : 9
    	Date            : 2020-06-01

    Abstract:
       Multiprotocol Label Switching (MPLS) has defined a mechanism to load-
       balance traffic flows using Entropy Labels (EL).  An ingress Label
       Switching Router (LSR) cannot insert ELs for packets going into a
       given Label Switched Path (LSP) unless an egress LSR has indicated
       via signaling that it has the capability to process ELs, referred to
       as the Entropy Label Capability (ELC), on that LSP.  In addition, it
       would be useful for ingress LSRs to know each LSR's capability for
       reading the maximum label stack depth and performing EL-based load-
       balancing, referred to as Entropy Readable Label Depth (ERLD).  This
       document defines a mechanism to signal these two capabilities using
       OSPFv2 and OSPFv3 and BGP-LS.


    The IETF datatracker status page for this draft is:
    https://datatracker.ietf.org/doc/draft-ietf-ospf-mpls-elc/

    There are also htmlized versions available at:
    https://tools.ietf.org/html/draft-ietf-ospf-mpls-elc-15
    https://datatracker.ietf.org/doc/html/draft-ietf-ospf-mpls-elc-15

    A diff from the previous version is available at:
    https://www.ietf.org/rfcdiff?url2=draft-ietf-ospf-mpls-elc-15


    Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org.

    Internet-Drafts are also available by anonymous FTP at:
    ftp://ftp.ietf.org/internet-drafts/



    _______________________________________________
    Lsr mailing list
    Lsr@ietf.org
    https://www.ietf.org/mailman/listinfo/lsr