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

Xuxiaohu <xuxiaohu@huawei.com> Wed, 13 April 2016 08:10 UTC

Return-Path: <xuxiaohu@huawei.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 7F9AE12D8A1; Wed, 13 Apr 2016 01:10:13 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.217
X-Spam-Level:
X-Spam-Status: No, score=-5.217 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.996, SPF_PASS=-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 ytNtx_-aW1ZO; Wed, 13 Apr 2016 01:10:09 -0700 (PDT)
Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 73F9712D80C; Wed, 13 Apr 2016 01:10:07 -0700 (PDT)
Received: from 172.18.7.190 (EHLO lhreml706-cah.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id CHF94365; Wed, 13 Apr 2016 08:10:05 +0000 (GMT)
Received: from NKGEML413-HUB.china.huawei.com (10.98.56.74) by lhreml706-cah.china.huawei.com (10.201.5.182) with Microsoft SMTP Server (TLS) id 14.3.235.1; Wed, 13 Apr 2016 09:10:05 +0100
Received: from NKGEML515-MBX.china.huawei.com ([fe80::a54a:89d2:c471:ff]) by NKGEML413-HUB.china.huawei.com ([10.98.56.74]) with mapi id 14.03.0235.001; Wed, 13 Apr 2016 16:09:55 +0800
From: Xuxiaohu <xuxiaohu@huawei.com>
To: "Carlos Pignataro (cpignata)" <cpignata@cisco.com>, "Acee Lindem (acee)" <acee@cisco.com>, "draft-ietf-ospf-mpls-elc@ietf.org" <draft-ietf-ospf-mpls-elc@ietf.org>
Thread-Topic: [OSPF] Signaling Entropy Label Capability Using OSPF - draft-ietf-ospf-mpls-elc-00
Thread-Index: AQHRlEvBpcuRzR4OpEWJ4X+miwJxNJ+Hhvew
Date: Wed, 13 Apr 2016 08:09:55 +0000
Message-ID: <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE0D539860@NKGEML515-MBX.china.huawei.com>
References: <D331AA68.3F8A8%cpignata@cisco.com>
In-Reply-To: <D331AA68.3F8A8%cpignata@cisco.com>
Accept-Language: zh-CN, en-US
Content-Language: zh-CN
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.111.99.55]
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-CFilter-Loop: Reflected
X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A020203.570DFEDE.001A, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=0.0.0.0, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32
X-Mirapoint-Loop-Id: 9448aad51e50029710ab9330b5711744
Archived-At: <http://mailarchive.ietf.org/arch/msg/ospf/dYZo9z8-ULr7MBgVhOMgCOr46zU>
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: Wed, 13 Apr 2016 08:10:13 -0000

Hi Carlos,

Thanks for your comments. Please see my response inline.

> -----Original Message-----
> From: OSPF [mailto:ospf-bounces@ietf.org] On Behalf Of Carlos Pignataro
> (cpignata)
> Sent: Tuesday, April 12, 2016 7:42 AM
> To: Acee Lindem (acee); draft-ietf-ospf-mpls-elc@ietf.org
> Cc: OSPF WG List
> Subject: Re: [OSPF] Signaling Entropy Label Capability Using OSPF -
> draft-ietf-ospf-mpls-elc-00
> 
> Authors,
> 
> For this draft, it would be useful to also discuss and understand a few other
> things, such as:
> 
> I. Has an approach similar to FAT-PW for LB (instead of the {ELI; EL} Entropy
> Label approach) been considered? It would save label stack entries, and allow
> precise positioning. Has this been ruled out?

This document only describes how the ELC and RLSDC are advertised via OSPF. How these capabilities would be used are actually described in https://tools.ietf.org/html/draft-ietf-mpls-spring-entropy-label. As for an approach similar to FAT-PW, it may deserve a separate doc.

> II. Definition of behavior for networks with hybrid support (some nodes support
> ELC, some do not). Like, can/should EL;ELI be used if some nodes in the path do
> not support it? This will be a very common case. Some downstream NHs might
> support it and some don¹t.

See above.

> III. Are there multi instance or flooding scope implications?

As for multi-instances, the following text would be added into the next revision if the WG believe it's appropriate:

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

As for the flooding scope, it said in the doc that "The scope of the advertisement depends on the application but it is recommended that it SHOULD be AS-scoped."

> IV. As specified, there is no relationship between ELC and RLDC. Seems there is.
> Do these need to be supported simultaneously? Say, a node does not support
> ELC but advertises RLDC, what¹s that mean?

ELC and RLDC don't need to be supported simultaneously. For instance, a non-egress node doesn't need to support ELC but it's desirable to advertise the RLDC.

> V. There are several operational considerations which are just unadressed.
> Say, a new LC is inserted in a node, which does not support ELC, or supports a
> RLD smaller than what¹s been advertised. Or...

As for ELC, there is no difference from the current use of ELC as specified in RFC6790. In other words, a router should not advertise the ELC unless all of its LCs support ELC. In fact, this point has been raised before, the WG consensus was that there is no need to mention it explicitly in the doc, if I remembered it correctly. As for ELD, it said in the doc that "If a router has multiple linecards with different capabilities of reading the maximum label stack depth, the router MUST advertise the smallest one in the RLDC TLV. "

> VI. No security implications sounds quite optimistic :-)

Do you have any good suggestion on the security considerations?

Best regards,
Xiaohu

> Thanks,
> 
> < Carlos.
> 
> -----Original Message-----
> From: OSPF <ospf-bounces@ietf.org> on behalf of "Acee Lindem (acee)"
> <acee@cisco.com>
> Date: Monday, April 11, 2016 at 2:38 PM
> To: "draft-ietf-ospf-mpls-elc@ietf.org" <draft-ietf-ospf-mpls-elc@ietf.org>
> Cc: OSPF WG List <ospf@ietf.org>
> Subject: [OSPF] 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
> >    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?
> >    3. A discussion of backward compatibility for the new
> >Router-Information LSA capability.
> >
> >Thanks,
> >Acee
> >
> >_______________________________________________
> >OSPF mailing list
> >OSPF@ietf.org
> >https://www.ietf.org/mailman/listinfo/ospf
> 
> _______________________________________________
> OSPF mailing list
> OSPF@ietf.org
> https://www.ietf.org/mailman/listinfo/ospf