Re: [OSPF] Signaling Entropy Label Capability Using OSPF - draft-ietf-ospf-mpls-elc-00

"Acee Lindem (acee)" <acee@cisco.com> Thu, 14 April 2016 11:21 UTC

Return-Path: <acee@cisco.com>
X-Original-To: ospf@ietfa.amsl.com
Delivered-To: ospf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D2A2812E420; Thu, 14 Apr 2016 04:21:57 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -15.517
X-Spam-Level:
X-Spam-Status: No, score=-15.517 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.996, SPF_PASS=-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 9Fr8UePkbtNx; Thu, 14 Apr 2016 04:21:56 -0700 (PDT)
Received: from alln-iport-7.cisco.com (alln-iport-7.cisco.com [173.37.142.94]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 438A512E422; Thu, 14 Apr 2016 04:21:56 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=5708; q=dns/txt; s=iport; t=1460632916; x=1461842516; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=ALedy9KWFdJwu0s3vjgufb0hx86JA71wHD2//3rMKM8=; b=NcWHvTHcuYM7chUM74K3bRfwS8hodqa0mJCrmskANGqI95lmtWIQ7sKX M6HIFtrHATKl9MxiiJmc8/aAuTlz/+iFPLLXzl9kVhympH+/CQmF5EDhc nBfWZr19GeNvegpvm7GQ1km+Aam/uVj02nrRzJcDc+7/NmUVOiZZ9Qnr+ 0=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AWAgCAfA9X/4YNJK1egzhTfQa4GoIPA?= =?us-ascii?q?Q2BcSKFbAIcgRg4FAEBAQEBAQFlJ4RBAQEBBCMRRQwEAgEIEQQBAQECAiMDAgI?= =?us-ascii?q?CMBQBCAgCBAENBYgpDq90kkEBAQEBAQEBAQEBAQEBAQEBAQEBAQERBHyIboECh?= =?us-ascii?q?D2DAoJWAQSNUoo5AYV2iBaBZ4ROgyiFM48oAR4BAUKDZ2yIfH4BAQE?=
X-IronPort-AV: E=Sophos;i="5.24,484,1454976000"; d="scan'208";a="261297071"
Received: from alln-core-12.cisco.com ([173.36.13.134]) by alln-iport-7.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 14 Apr 2016 11:21:55 +0000
Received: from XCH-RTP-015.cisco.com (xch-rtp-015.cisco.com [64.101.220.155]) by alln-core-12.cisco.com (8.14.5/8.14.5) with ESMTP id u3EBLt2x003759 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Thu, 14 Apr 2016 11:21:55 GMT
Received: from xch-rtp-015.cisco.com (64.101.220.155) by XCH-RTP-015.cisco.com (64.101.220.155) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Thu, 14 Apr 2016 07:21:54 -0400
Received: from xch-rtp-015.cisco.com ([64.101.220.155]) by XCH-RTP-015.cisco.com ([64.101.220.155]) with mapi id 15.00.1104.009; Thu, 14 Apr 2016 07:21:54 -0400
From: "Acee Lindem (acee)" <acee@cisco.com>
To: Xuxiaohu <xuxiaohu@huawei.com>, "draft-ietf-ospf-mpls-elc@ietf.org" <draft-ietf-ospf-mpls-elc@ietf.org>
Thread-Topic: Signaling Entropy Label Capability Using OSPF - draft-ietf-ospf-mpls-elc-00
Thread-Index: AQHRlBj81Lqya0qQckSeteuSX15/fJ+HehHggABhRACAAU3x0IAALjaA
Date: Thu, 14 Apr 2016 11:21:54 +0000
Message-ID: <D334F462.5A9A3%acee@cisco.com>
References: <D331595E.5903B%acee@cisco.com> <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE0D539826@NKGEML515-MBX.china.huawei.com> <D333B410.59E29%acee@cisco.com> <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE0D53A075@NKGEML515-MBX.china.huawei.com>
In-Reply-To: <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE0D53A075@NKGEML515-MBX.china.huawei.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-ms-exchange-messagesentrepresentingtype: 1
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: [10.116.152.202]
Content-Type: text/plain; charset="utf-8"
Content-ID: <31F14A64F21F1C4A982B681FEECC6264@emea.cisco.com>
Content-Transfer-Encoding: base64
MIME-Version: 1.0
Archived-At: <http://mailarchive.ietf.org/arch/msg/ospf/dDcuY3X3KHGajfqjm0nI919pE0M>
Cc: OSPF WG List <ospf@ietf.org>
Subject: Re: [OSPF] Signaling Entropy Label Capability Using OSPF - draft-ietf-ospf-mpls-elc-00
X-BeenThere: ospf@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: The Official IETF OSPG WG Mailing List <ospf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ospf>, <mailto:ospf-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ospf/>
List-Post: <mailto:ospf@ietf.org>
List-Help: <mailto:ospf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ospf>, <mailto:ospf-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 14 Apr 2016 11:21:58 -0000

Hi Tiger, 

On 4/14/16, 5:09 AM, "Xuxiaohu" <xuxiaohu@huawei.com> wrote:

>Hi Acee,
>
>> -----Original Message-----
>> From: Acee Lindem (acee) [mailto:acee@cisco.com]
>> Sent: Wednesday, April 13, 2016 8:41 PM
>> To: Xuxiaohu; draft-ietf-ospf-mpls-elc@ietf.org
>> Cc: OSPF WG List
>> Subject: Re: Signaling Entropy Label Capability Using OSPF -
>> draft-ietf-ospf-mpls-elc-00
>> 
>> Hi Tiger,
>> 
>> On 4/13/16, 3:41 AM, "Xuxiaohu" <xuxiaohu@huawei.com> wrote:
>> 
>> >Hi Acee,
>> >
>> >Thanks for your comments. Please see my response in line.
>> >
>> >> -----Original Message-----
>> >> From: Acee Lindem (acee) [mailto:acee@cisco.com]
>> >> Sent: Tuesday, April 12, 2016 1:39 AM
>> >> To: draft-ietf-ospf-mpls-elc@ietf.org
>> >> Cc: OSPF WG List
>> >> Subject: Signaling Entropy Label Capability Using OSPF -
>> >> draft-ietf-ospf-mpls-elc-00
>> >>
>> >> Authors,
>> >>
>> >> We will soon be progressing the OSPFv2 SR draft. What is your intent
>> >>for this  draft? It is missing:
>> >>
>> >>     1. A figure with the RI encoding like other OSPF documents
>> >
>> >Will add two figures for ELC TLV and RLSDC TLV respectively.
>> 
>> Can you come up with a better name than RLSDC? It appears this would
>>obviate
>> the need for the recent MSD proposal but that is a much better name.
>
>RLSDC has been replaced by RLDC (Readable Label Depth Capability) in the
>latest version. If I understood it correctly, MSD and RLD are used to
>indicate different things, e.g., the former is used to indicate how many
>labels to maximum extent could be imposed by the ingress node while the
>latter is used to indicate how many labels to maximum extent could be
>read by a intermediate node.

Ok - this will be clearer once the usage section is added. I like RLDC
better than RLSDC. 


>
>> >>     2. Discussion as to precisely how the capability would be used by
>> >>a router in  an OSPF routing domain. For example, must a router remove
>> >>the EL if the  next-hop doesn’t support it?
>> >
>> >This document only describes how the ELC and RLSDC are advertised via
>> >OSPF. As for how these capabilities would be used are actually
>> >described in
>> >https://tools.ietf.org/html/draft-ietf-mpls-spring-entropy-label. By
>> >the way, a router doesn't need to remove the EL if the next-hop doesn't
>> >support it. The only requirement on using EL is: An ingress LSR cannot
>> >insert ELs for packets going into a given tunnel unless an egress LSR
>>has
>> indicated via signaling that it can process ELs on that tunnel.
>> 
>> Can you add a short section referencing the applicable section in this
>>document.
>
>Sure. Do you have any suggest on the text in such section?

I could write this but you think with 5 authors for a draft that only has
1 1/2 pages of content - one of you would be able to write this.



>
>> 
>> >
>> >>     3. A discussion of backward compatibility for the new
>> >>Router-Information  LSA capability.
>> >
>> >Is it enough to add the following text:
>> >
>> >"To be compatible with RFC7770, ELC and RLSDC TLVs SHOULD continue to
>> >be advertised in the first instance, i.e., 0, of the Router
>>Information LSA."
>> 
>> I was talking more on the level of usage of the capability than
>>advertisement.
>> Since this is new, there should be any RI LSAs considerations.
>
>The EL capability is used by ingress LSRs to determine whether an EL
>could be inserted into a given LSP tunnel, and the RLD capability is used
>by ingress LSRs to determine whether it's necessary to insert an EL for a
>given LSP tunnel in the case where there has already been at least one EL
>in the label stack. The above has been mentioned in the Introduction
>section. I'm not sure that I fully understood your point. If not, could
>you give any suggestion on the discussion of backward compatibility?

What happens if not all routers in the domain support capability
advertisement? 

Thanks,
Acee 


>
>Best regards,
>Xiaohu (Tiger)
>
>> Thanks,
>> Acee
>> 
>> 
>> 
>> >
>> >Best regards,
>> >Xiaohu
>> >
>> >> Thanks,
>> >> Acee
>> >
>