Re: [Lsr] [mpls] Comments on draft-ietf-mpls-spring-entropy-label

"Acee Lindem (acee)" <acee@cisco.com> Fri, 06 July 2018 11:20 UTC

Return-Path: <acee@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 91679130EA3; Fri, 6 Jul 2018 04:20:47 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.509
X-Spam-Level:
X-Spam-Status: No, score=-14.509 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_DKIMWL_WL_HIGH=-0.01, 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 NMUj6W-TxEa7; Fri, 6 Jul 2018 04:20:44 -0700 (PDT)
Received: from alln-iport-8.cisco.com (alln-iport-8.cisco.com [173.37.142.95]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 841D5126CB6; Fri, 6 Jul 2018 04:20:44 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=57624; q=dns/txt; s=iport; t=1530876044; x=1532085644; h=from:to:cc:subject:date:message-id:mime-version; bh=PzaRWKDLO3pH5a4atmoMDne6fJ3tc3U1F6O7+e0UXfU=; b=JHbXm/j8ePpU+rJXLyrGLTvWQ26t47m1/8cfFs/6Abl8PjJMRoVuVwKm OLd+A0CTaeUanC5tp8vSivTEJhKhLIG6RGKiZmcsrKzfVc15TkKvaexlI SKg8EWiThTxiteVY3Ufg44xwBbhGXUSMZGZX3ftXNnJLwC4z8amuh6ogX g=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: A0D/AQDM+T5b/5FdJa1cGQEBAQEBAQEBAQEBAQcBAQEBAYJTdmJ/KAqDcJQ5gWUiiDaMehSBZgsYAQqESQIXghYhNRcBAgEBAgEBAm0cDIU2AQEBAQMBASFLCxIBBgIRAwEBASEBBgMCBB8GCxQJCgQBDQUUgwwBgRtMAxUPjU2bSIIchxQNgS6BNQWIbYIVgQ4BJwyCXIJWQgEBAoErARIBPwYQgksxgiQCh0kZbIkchzorCQKMFYMLgUCEDIgMiwSGYAIREwGBJB8BNSY7cXAVOyoBgj4JghsXiFmFPm8BjRiBH4EaAQE
X-IronPort-AV: E=Sophos;i="5.51,315,1526342400"; d="scan'208,217";a="138940265"
Received: from rcdn-core-9.cisco.com ([173.37.93.145]) by alln-iport-8.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 06 Jul 2018 11:20:43 +0000
Received: from XCH-RTP-012.cisco.com (xch-rtp-012.cisco.com [64.101.220.152]) by rcdn-core-9.cisco.com (8.14.5/8.14.5) with ESMTP id w66BKhh3000958 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Fri, 6 Jul 2018 11:20:43 GMT
Received: from xch-rtp-015.cisco.com (64.101.220.155) by XCH-RTP-012.cisco.com (64.101.220.152) with Microsoft SMTP Server (TLS) id 15.0.1320.4; Fri, 6 Jul 2018 07:20:42 -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.1320.000; Fri, 6 Jul 2018 07:20:42 -0400
From: "Acee Lindem (acee)" <acee@cisco.com>
To: "Ketan Talaulikar (ketant)" <ketant=40cisco.com@dmarc.ietf.org>, "徐小虎(义先)" <xiaohu.xxh@alibaba-inc.com>, Jeff Tantsura <jefftant.ietf@gmail.com>, "stephane.litkowski" <stephane.litkowski@orange.com>, "mpls@ietf.org" <mpls@ietf.org>
CC: "lsr@ietf.org" <lsr@ietf.org>, "pce@ietf.org" <pce@ietf.org>
Thread-Topic: [Lsr] [mpls] Comments on draft-ietf-mpls-spring-entropy-label
Thread-Index: AQHUFRtgGpvlAPnlqkudFHQhe9Vb6A==
Date: Fri, 06 Jul 2018 11:20:42 +0000
Message-ID: <1300246B-BE81-4F77-8413-6874B96379B5@cisco.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: multipart/alternative; boundary="_000_1300246BBE814F7784136874B96379B5ciscocom_"
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/lsr/9TegEuDE0DyGlkN0yfHRdkQPA3w>
Subject: Re: [Lsr] [mpls] Comments on draft-ietf-mpls-spring-entropy-label
X-BeenThere: lsr@ietf.org
X-Mailman-Version: 2.1.26
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: Fri, 06 Jul 2018 11:20:48 -0000

Hi Keten, Xiaohu,

I agree with Ketan. The level of MSD support is dependent on the MSD type and fully specified in the IGP drafts for MSD type 1.

Thanks,
Acee

From: Lsr <lsr-bounces@ietf.org> on behalf of "Ketan Talaulikar (ketant)" <ketant=40cisco.com@dmarc.ietf.org>
Date: Thursday, July 5, 2018 at 10:23 PM
To: "Xiaohu (Tiger) Xu" <xiaohu.xxh@alibaba-inc.com>, Jeff Tantsura <jefftant.ietf@gmail.com>, Stephane Litkowski <stephane.litkowski@orange.com>, "mpls@ietf.org" <mpls@ietf.org>
Cc: "lsr@ietf.org" <lsr@ietf.org>, "pce@ietf.org" <pce@ietf.org>
Subject: Re: [Lsr] [mpls] Comments on draft-ietf-mpls-spring-entropy-label

Hi Xiaohu,

The IGP drafts define MSD as a framework that enable advertisements for various type of SID limits – starting with the Base MSD Type – 1. You are referring to this generic construct of MSD in the text you quote below. It is, however, the Base MSD (type 1) which is aligned with the definition in PCEP-SR.

IMHO the PCEP-SR draft definition should be updated to refer to this base MSD type.

Thanks,
Ketan

From: mpls <mpls-bounces@ietf.org> On Behalf Of ???(??)
Sent: 06 July 2018 06:55
To: Jeff Tantsura <jefftant.ietf@gmail.com>; stephane.litkowski <stephane.litkowski@orange.com>; mpls@ietf.org
Cc: lsr@ietf.org; pce@ietf.org
Subject: Re: [mpls] Comments on draft-ietf-mpls-spring-entropy-label

Hi Jeff,

Thanks for your clarification. IMHO, no matter the MSD information is provided by whatever protocol, the semantics of the MSD itself should be unified in the IETF community. Otherwise, it would introduce unnecessary confusion to implementors and operators.

It said in the OSPF-MSD draft:
"

   MSD: Maximum SID Depth - the number of SIDs a node or one of its

   links can support"



What does the "support" exactly mean? It seems at least to me a little bit ambiguous compared to the MSD concept as defined in the PCEP-SR draft.



Best regards,

Xiaohu




------------------------------------------------------------------
From:Jeff Tantsura <jefftant.ietf@gmail.com<mailto:jefftant.ietf@gmail.com>>
Send Time:2018年7月6日(星期五) 07:48
To:stephane.litkowski <stephane.litkowski@orange.com<mailto:stephane.litkowski@orange.com>>; 徐小虎(义先) <xiaohu.xxh@alibaba-inc.com<mailto:xiaohu.xxh@alibaba-inc.com>>; mpls@ietf.org<mailto:mpls@ietf.org> <mpls@ietf.org<mailto:mpls@ietf.org>>
Cc:lsr@ietf.org <lsr@ietf.org<mailto:lsr@ietf.org>>; pce@ietf.org<mailto:pce@ietf.org> <pce@ietf.org<mailto:pce@ietf.org>>
Subject:Re: [mpls] Comments on draft-ietf-mpls-spring-entropy-label

Hi,

Please see inline (MSD section).
Hope this clarifies, thanks!

Cheers,
Jeff



[jeff] both IGP drafts have identical description of the BMI-MSD:
“Base MPLS Imposition MSD (BMI-MSD) signals the total number of MPLS labels a node is capable of imposing, including all service/transport/special labels.”
PCEP draft supports only a subset of overall MSD functionality and in general it is expected that this info would come from IGPs(BGP-LS).
However the functoriality provided by PCEP is inline with the  BMI-MSD definition in the IGP drafts, at the node granularity only though.


3. Section 5 introduces the MSD concept. I wonder whether this concept is aligned with the MSD concept as defined in the PCEP-SR draft or the MSD concept as defined in the IGP-MSD draft. In PCEP-SR draft, it said "

The "Maximum SID Depth" (1

   octet) field (MSD) specifies the maximum number of SIDs (MPLS label

   stack depth in the context of this document) that a PCC is capable of

   imposing on a packet.



In the IGP-MSD draft, it said "

MSD of type 1 (IANA Registry), called Base MSD is used to signal the

   total number of SIDs a node is capable of imposing, to be used by a

   path computation element/controller.  "



If I understand it correctly, the MSD in this draft==the MSD in PCEP-SR draft==the Base MSD (i.e., the MSD of type 1), No?

[SLI] Today, the two IGP drafts does not seem to agree on the definition

ISIS says:” Base MPLS Imposition MSD (BMI-MSD) signals the total number of MPLS
   labels a node is capable of imposing, including all
   service/transport/special labels.”

OSPF says:” MSD of type 1 (IANA Registry) is used to signal the number of SIDs a
   node is capable of imposing, to be used by a path computation
   element/controller and is only relevant to the part of the stack
   created as the result of the computation.”

MSD is just MSD is defines a maximum number of labels to be pushed. This is the definition we use and it is compliant with the one used in PCEP-SR:

“The "Maximum SID Depth" (1
   octet) field (MSD) specifies the maximum number of SIDs (MPLS label
   stack depth in context of this document) that a PCC is capable of
   imposing on a packet.”

As we also say: “This includes any kind of labels (service, entropy, transport...).”, we are compliant with the BMI-MSD defined in IS-IS.



Best regards,
Xiaohu

_________________________________________________________________________________________________________________________



Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc

pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler

a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,

Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.



This message and its attachments may contain confidential or privileged information that may be protected by law;

they should not be distributed, used or copied without authorisation.

If you have received this email in error, please notify the sender and delete this message and its attachments.

As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.

Thank you.
_______________________________________________ mpls mailing list mpls@ietf.org<mailto:mpls@ietf.org> https://www.ietf.org/mailman/listinfo/mpls