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

"Acee Lindem (acee)" <> Wed, 13 April 2016 12:41 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id C029C12E141; Wed, 13 Apr 2016 05:41:30 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -15.517
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: (amavisd-new); dkim=pass (1024-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 0WvWFE9_GpVc; Wed, 13 Apr 2016 05:41:20 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id BE57612E109; Wed, 13 Apr 2016 05:41:19 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple;;; l=3022; q=dns/txt; s=iport; t=1460551279; x=1461760879; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=0RZ39WyoHqb0GmUhPYVdJR0Pmzmw9sYZdYiDVBcRDnM=; b=BA6d56C7G6kLzB2US+xl2/NXPgmkRZANWFl84LNTPhj80wdx17CEqrXL ztlg5DTiqKTUIC3JYVbl78W+Qxn/Xdhu56hqb/IBpwgyMZEZzwAd0CbKu 3S87GB2IMiFhdAZz2aX8rbP4GxvBspgzK/z0BMurVDWsH3vHMnuEKkQG8 I=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-AV: E=Sophos;i="5.24,479,1454976000"; d="scan'208";a="90978894"
Received: from ([]) by with ESMTP/TLS/DHE-RSA-AES256-SHA; 13 Apr 2016 12:41:18 +0000
Received: from ( []) by (8.14.5/8.14.5) with ESMTP id u3DCfI8S020846 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Wed, 13 Apr 2016 12:41:18 GMT
Received: from ( by ( with Microsoft SMTP Server (TLS) id 15.0.1104.5; Wed, 13 Apr 2016 08:41:17 -0400
Received: from ([]) by ([]) with mapi id 15.00.1104.009; Wed, 13 Apr 2016 08:41:17 -0400
From: "Acee Lindem (acee)" <>
To: Xuxiaohu <>, "" <>
Thread-Topic: Signaling Entropy Label Capability Using OSPF - draft-ietf-ospf-mpls-elc-00
Thread-Index: AQHRlBj81Lqya0qQckSeteuSX15/fJ+HehHggABhRAA=
Date: Wed, 13 Apr 2016 12:41:17 +0000
Message-ID: <>
References: <> <>
In-Reply-To: <>
Accept-Language: en-US
Content-Language: en-US
x-ms-exchange-messagesentrepresentingtype: 1
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: []
Content-Type: text/plain; charset="utf-8"
Content-ID: <>
Content-Transfer-Encoding: base64
MIME-Version: 1.0
Archived-At: <>
Cc: OSPF WG List <>
Subject: Re: [OSPF] Signaling Entropy Label Capability Using OSPF - draft-ietf-ospf-mpls-elc-00
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: The Official IETF OSPG WG Mailing List <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Wed, 13 Apr 2016 12:41:31 -0000

Hi Tiger, 

On 4/13/16, 3:41 AM, "Xuxiaohu" <> wrote:

>Hi Acee,
>Thanks for your comments. Please see my response in line.
>> -----Original Message-----
>> From: Acee Lindem (acee) []
>> Sent: Tuesday, April 12, 2016 1:39 AM
>> To:
>> 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

>>     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 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

>>     3. A discussion of backward compatibility for the new
>> 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


>Best regards,
>> Thanks,
>> Acee