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

Tianran Zhou <zhoutianran@huawei.com> Tue, 02 June 2020 06:14 UTC

Return-Path: <zhoutianran@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 7383A3A07E9 for <lsr@ietfa.amsl.com>; Mon, 1 Jun 2020 23:14:21 -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 oYFzH5Hi94vA for <lsr@ietfa.amsl.com>; Mon, 1 Jun 2020 23:14:19 -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 71FCF3A07E6 for <lsr@ietf.org>; Mon, 1 Jun 2020 23:14:19 -0700 (PDT)
Received: from lhreml716-chm.china.huawei.com (unknown [172.18.7.106]) by Forcepoint Email with ESMTP id B9CE04019EF8FB2C6B65 for <lsr@ietf.org>; Tue, 2 Jun 2020 07:14:16 +0100 (IST)
Received: from nkgeml704-chm.china.huawei.com (10.98.57.158) by lhreml716-chm.china.huawei.com (10.201.108.67) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.1913.5; Tue, 2 Jun 2020 07:14:16 +0100
Received: from nkgeml707-chm.china.huawei.com (10.98.57.157) by nkgeml704-chm.china.huawei.com (10.98.57.158) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.1913.5; Tue, 2 Jun 2020 14:14:13 +0800
Received: from nkgeml707-chm.china.huawei.com ([10.98.57.157]) by nkgeml707-chm.china.huawei.com ([10.98.57.157]) with mapi id 15.01.1913.007; Tue, 2 Jun 2020 14:14:13 +0800
From: Tianran Zhou <zhoutianran@huawei.com>
To: Peter Psenak <ppsenak@cisco.com>, "lsr@ietf.org" <lsr@ietf.org>
Thread-Topic: [Lsr] I-D Action: draft-ietf-ospf-mpls-elc-15.txt
Thread-Index: AQHWN/DEGazemhRAckeFEHMsuT7ekqjDkxGA//99TwCAAcaWYA==
Date: Tue, 02 Jun 2020 06:14:13 +0000
Message-ID: <c8dbae93fe214f5e9ff258fb69bcdc08@huawei.com>
References: <159100094287.10006.5637389500374152632@ietfa.amsl.com> <44240a91d7e246bcad13b0f4da5d52f9@huawei.com> <1abba73e-cb09-d4a4-da45-dce441a4eb74@cisco.com>
In-Reply-To: <1abba73e-cb09-d4a4-da45-dce441a4eb74@cisco.com>
Accept-Language: zh-CN, en-US
Content-Language: zh-CN
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.108.203.79]
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/76NN138ENtrsJ4TZK5BFBTqCkVg>
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: Tue, 02 Jun 2020 06:14:21 -0000

Hi Peter,

I do not understand how RFC8667 relates to ELC signaling.
RFC 8667 "have been defined to signal labels", but "This draft defines a mechanism to signal the ELC using IS-IS."

On the other hand, RFC 8667 is the extension for segment routing. 
Is this draft only for segment routing, or be generic?

Another thing I am not clear is the difference between "multi-area" and "multi-domain" here after:
   "Even though ELC is a property of the node, in some cases it is
   advantageous to associate and advertise the ELC with a prefix.  In a
   multi-area network, routers may not know the identity of the prefix
   originator in a remote area, or may not know the capabilities of such
   originator.  Similarly, in a multi-domain network, the identity of
   the prefix originator and its capabilities may not be known to the
   ingress LSR."

Tianran

-----Original Message-----
From: Peter Psenak [mailto:ppsenak@cisco.com] 
Sent: Monday, June 1, 2020 6:56 PM
To: Tianran Zhou <zhoutianran@huawei.com>; lsr@ietf.org
Subject: Re: [Lsr] I-D Action: draft-ietf-ospf-mpls-elc-15.txt

Tianran,

On 01/06/2020 12:49, Tianran Zhou wrote:
> Hi Authors,
> 
> I see the following words in the introduction.
> "   Recently, mechanisms have been defined to signal labels via link-
>     state Interior Gateway Protocols (IGP) such as IS-IS [RFC8667].  "
> 
> It's not clear to me what the " mechanisms " are. Could you please add some reference or text on this?

the reference is there - RFC8667.


thanks,
Peter

> 
> Thanks,
> Tianran
> 
> -----Original Message-----
> From: Lsr [mailto:lsr-bounces@ietf.org] On Behalf Of 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
> 
> _______________________________________________
> Lsr mailing list
> Lsr@ietf.org
> https://www.ietf.org/mailman/listinfo/lsr
> 
>