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

Peter Psenak <ppsenak@cisco.com> Wed, 03 June 2020 15:04 UTC

Return-Path: <ppsenak@cisco.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 A8C923A092C for <lsr@ietfa.amsl.com>; Wed, 3 Jun 2020 08:04:29 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -9.601
X-Spam-Level:
X-Spam-Status: No, score=-9.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.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 GITlzd6CiJa8 for <lsr@ietfa.amsl.com>; Wed, 3 Jun 2020 08:04:28 -0700 (PDT)
Received: from aer-iport-3.cisco.com (aer-iport-3.cisco.com [173.38.203.53]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CFA103A09AC for <lsr@ietf.org>; Wed, 3 Jun 2020 08:04:27 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=5299; q=dns/txt; s=iport; t=1591196668; x=1592406268; h=subject:to:references:from:message-id:date:mime-version: in-reply-to:content-transfer-encoding; bh=UUs7qWgDaFgjiBPWH3zvgyMV8dCG3caSjer6aLp3BTs=; b=iB0yZm9Qb3QKUd4CUsct8NJe/ExkEPv9R3yKdwVjWBAuGzAZDR814mws Y84030yfnQKSnq6xdvBZxd+ob8FUzz71E0IzpEaF+j2kKoZP/wpXbBEwo 1qhk5EZsR9r4Cy8dFi7d5Heu2X+X2GLeZfuRN9HfKzq642kQJF30yLkA0 8=;
X-IPAS-Result: A0DDAQCku9de/xbLJq1mGwEBAQEBAQEBBQEBARIBAQEDAwEBAUCBSoMaVAEgEiyEJYkBh2olmhKBaAsBAQEOGAsMBAEBhEQCghwlOBMCAwEBAQMCAwEBAQEFAQEBAgEGBG2FWwyFcgEBAQECAQEBDBUVLQkXBAsRBAEBAQICERIDAgInHwkIBgEMBgIBAYMiAYJcIA+uD3aBMoQ+Ag5BQoNpgUCBDiqMZoFBP4ERJwyBX34+gmcBAQIBARiBAoEGglWCYASZWpoSgmOCfIU4kDkHAx2CZ4EUh3iEa41ckHGJfpQygWoigVYzGggbFRohgmkJRxkNkEwXiGOFRD8DMDcCBggBAQMJjmkBAQ
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-AV: E=Sophos;i="5.73,468,1583193600"; d="scan'208";a="24434103"
Received: from aer-iport-nat.cisco.com (HELO aer-core-3.cisco.com) ([173.38.203.22]) by aer-iport-3.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 03 Jun 2020 15:04:23 +0000
Received: from [10.60.140.51] (ams-ppsenak-nitro2.cisco.com [10.60.140.51]) by aer-core-3.cisco.com (8.15.2/8.15.2) with ESMTP id 053F4Nci009535; Wed, 3 Jun 2020 15:04:23 GMT
To: wangyali <wangyali11@huawei.com>, "lsr@ietf.org" <lsr@ietf.org>
References: <159100094287.10006.5637389500374152632@ietfa.amsl.com> <1520992FC97B944A9979C2FC1D7DB0F404E7EF31@dggeml524-mbx.china.huawei.com> <625407eb-cb0b-6b2f-3636-e9098d3b591b@cisco.com> <1520992FC97B944A9979C2FC1D7DB0F404E7EFA0@dggeml524-mbx.china.huawei.com>
From: Peter Psenak <ppsenak@cisco.com>
Message-ID: <728d22eb-eea7-9967-1f2c-fabaeba9cd1c@cisco.com>
Date: Wed, 03 Jun 2020 17:04:22 +0200
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:60.0) Gecko/20100101 Thunderbird/60.7.0
MIME-Version: 1.0
In-Reply-To: <1520992FC97B944A9979C2FC1D7DB0F404E7EFA0@dggeml524-mbx.china.huawei.com>
Content-Type: text/plain; charset="utf-8"; format="flowed"
Content-Language: en-US
Content-Transfer-Encoding: 7bit
X-Outbound-SMTP-Client: 10.60.140.51, ams-ppsenak-nitro2.cisco.com
X-Outbound-Node: aer-core-3.cisco.com
Archived-At: <https://mailarchive.ietf.org/arch/msg/lsr/ra_Dn11XRIUarDLwuMBToV1yzIg>
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 15:04:30 -0000

Yali,

On 03/06/2020 15:51, wangyali wrote:
> Hi Peter,
> 
> Thanks for your reply. please see inline <Yali>.
> 
> -----Original Message-----
> From: Peter Psenak [mailto:ppsenak@cisco.com]
> Sent: Wednesday, June 3, 2020 7:44 PM
> To: wangyali <wangyali11@huawei.com>; lsr@ietf.org
> Subject: Re: [Lsr] I-D Action: draft-ietf-ospf-mpls-elc-15.txt
> 
> Yali,
> 
> 
> On 03/06/2020 13:35, wangyali 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?
> 
> this has been discussed on the WG alias endlessly, please go over the archives.
> <Yali> Thanks. I think I lost some emails. I will search them. While I suggest give an illustration or some examples about the "some cases" in the draft. Please take it into account.

I will not make any changes to the draft at this point. The draft is in 
the RFC queue, too late to make changes.

> 
>>
>> 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?
> 
> and how do you as a remote router know over which interface, or better line card, the traffic that you are sending going to arrive on a remote node? Does not make much sense.
> <Yali> So can we say that ELC advertisement in node granularity is expressed by host prefix attributes advertisement?

yes, pretty much that is the idea.


> 
>>
>> 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"?
> 
> it's a locally generated 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."
> 
> yes, what's wrong with that statement?
> <Yali> I think it will not happen. Why is it necessary to specify this case?

If someone sends this as link MSD, we need to say how to deal with it as 
in general MSDs can be send as node or link attributes.

regards,
Peter



> 
> regards,
> Peter
> 
> 
>>
>> 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
>>
>>
> 
> 
>