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

Tianran Zhou <zhoutianran@huawei.com> Tue, 02 June 2020 08:39 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 A1AF03A0A36 for <lsr@ietfa.amsl.com>; Tue, 2 Jun 2020 01:39:23 -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 Tgz_Jy8ctjNU for <lsr@ietfa.amsl.com>; Tue, 2 Jun 2020 01:39:21 -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 8F3A73A0A30 for <lsr@ietf.org>; Tue, 2 Jun 2020 01:39:21 -0700 (PDT)
Received: from lhreml719-chm.china.huawei.com (unknown [172.18.7.108]) by Forcepoint Email with ESMTP id 4F070911E0518B404C1A for <lsr@ietf.org>; Tue, 2 Jun 2020 09:39:20 +0100 (IST)
Received: from nkgeml708-chm.china.huawei.com (10.98.57.160) by lhreml719-chm.china.huawei.com (10.201.108.70) 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 09:39:19 +0100
Received: from nkgeml707-chm.china.huawei.com (10.98.57.157) by nkgeml708-chm.china.huawei.com (10.98.57.160) 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 16:39:17 +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 16:39:17 +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//99TwCAAcaWYP//nZcAgACJReD//3x+AAAQ5ioQ
Date: Tue, 02 Jun 2020 08:39:16 +0000
Message-ID: <fb17a3522d834dc0a6bfe9deed26bb1f@huawei.com>
References: <159100094287.10006.5637389500374152632@ietfa.amsl.com> <44240a91d7e246bcad13b0f4da5d52f9@huawei.com> <1abba73e-cb09-d4a4-da45-dce441a4eb74@cisco.com> <c8dbae93fe214f5e9ff258fb69bcdc08@huawei.com> <57ca6539-07f6-5241-5277-1cb5406a7931@cisco.com> <70659ec46eac4912b98a41b38f5e534c@huawei.com> <80c5200e-5362-56a1-08aa-bc1cf077c1c1@cisco.com>
In-Reply-To: <80c5200e-5362-56a1-08aa-bc1cf077c1c1@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/4ZHUL-hOMNOd1kbaWbzLmYNY__k>
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 08:39:24 -0000

I think I understand your clarification.
Let me conclude, so your logic is:
We can use IGP to signal labels, though entropy label is not included. So we can use IGP to signal entropy label capability.

If so, this logic is not straight forward to me.

Tianran

-----Original Message-----
From: Peter Psenak [mailto:ppsenak@cisco.com] 
Sent: Tuesday, June 2, 2020 4:31 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 02/06/2020 10:25, Tianran Zhou wrote:
> Peter,
> 
> -----Original Message-----
> From: Peter Psenak [mailto:ppsenak@cisco.com]
> Sent: Tuesday, June 2, 2020 4:10 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 02/06/2020 08:14, Tianran Zhou wrote:
>> Hi Peter,
>>
>> I do not understand how RFC8667 relates to ELC signaling.
> 
> RFC 8667 - IS-IS Extensions for Segment Routing
> 
>> RFC 8667 "have been defined to signal labels", but "This draft defines a mechanism to signal the ELC using IS-IS."
> 
> yes, and as labels are now signaled by IGPs, we provide a method to signal ELC/ERLD by IGPs as well.
> 
> ZTR> RFC8667 signals different SID. 

no, RFC8667 is ISIS extension for SR MPLS.

> But draft-ietf-ospf-mpls-elc is about entropy label. Or do you mean entropy label is also signaled by IGP?

no, entropy label is not signaled AFAIK.

> 
>>
>> On the other hand, RFC 8667 is the extension for segment routing.
>> Is this draft only for segment routing, or be generic?
> 
> the requirement document is RFC8662, which is SR specific.
> 
> ZTR> "This draft" I mean draft-ietf-ospf-mpls-elc. So is draft-ietf-ospf-mpls-elc SR specific?

SR was a primary motivation.

regards,
Peter



> 
> Thanks,
> Tianran
> 
>>
>> 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."
> 
> 
> multi area is single IGP with multiple areas. Mutli domain is multiple IGPs.
> 
> thanks,
> Peter
> 
>>
>> 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
>>>
>>>
>>
>>
>>
> 
> 
>