Re: [Pce] WG Last Call for draft-ietf-pce-segment-routing-11
Jonathan Hardwick <Jonathan.Hardwick@metaswitch.com> Fri, 19 January 2018 10:52 UTC
Return-Path: <Jonathan.Hardwick@metaswitch.com>
X-Original-To: pce@ietfa.amsl.com
Delivered-To: pce@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1B2CD12D7E9 for <pce@ietfa.amsl.com>; Fri, 19 Jan 2018 02:52:34 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.001
X-Spam-Level:
X-Spam-Status: No, score=-2.001 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_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=metaswitch.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 JDWBQahrvNDw for <pce@ietfa.amsl.com>; Fri, 19 Jan 2018 02:52:31 -0800 (PST)
Received: from NAM01-BY2-obe.outbound.protection.outlook.com (mail-by2nam01on0103.outbound.protection.outlook.com [104.47.34.103]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 52F2B1200C5 for <pce@ietf.org>; Fri, 19 Jan 2018 02:52:31 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=metaswitch.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=ZHfEPS0g1gp7mCWI3FnClPnkWBKr/eJhKBB0Bl7ghrY=; b=KGfr2nmlo09axetUYEw2O1cIlXSvgQ4HjH8oI1seYRZER6tHuvXzxj1MWCTZzTch2Z68bc0VmSvz8tFZb0fpPcvtKKcQPKAGhd2k9arNMpTpXm/bndknNaprnB4oIGKLn4CG6FBMxTtC4G62ceTgP3of1ScudacGRWWZEMF2K7M=
Received: from CY4PR0201MB3603.namprd02.prod.outlook.com (52.132.99.21) by CY4PR0201MB3524.namprd02.prod.outlook.com (52.132.103.19) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.407.7; Fri, 19 Jan 2018 10:52:28 +0000
Received: from CY4PR0201MB3603.namprd02.prod.outlook.com ([fe80::90b3:9263:cb68:13be]) by CY4PR0201MB3603.namprd02.prod.outlook.com ([fe80::90b3:9263:cb68:13be%13]) with mapi id 15.20.0407.012; Fri, 19 Jan 2018 10:52:28 +0000
From: Jonathan Hardwick <Jonathan.Hardwick@metaswitch.com>
To: "adrian@olddog.co.uk" <adrian@olddog.co.uk>, 'Julien Meuric' <julien.meuric@orange.com>, "pce@ietf.org" <pce@ietf.org>
Thread-Topic: [Pce] WG Last Call for draft-ietf-pce-segment-routing-11
Thread-Index: AQFQ78boL6p8yRK+uRlGO6QlG/yHQqR/fr3AgADH4zA=
Date: Fri, 19 Jan 2018 10:52:28 +0000
Message-ID: <CY4PR0201MB3603BFD60E9B9B697DAFC02D84EF0@CY4PR0201MB3603.namprd02.prod.outlook.com>
References: <1315a404-7c2c-90ea-35d8-86a712200879@orange.com> <01d001d390af$4e6ba3b0$eb42eb10$@olddog.co.uk>
In-Reply-To: <01d001d390af$4e6ba3b0$eb42eb10$@olddog.co.uk>
Accept-Language: en-GB, en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
authentication-results: spf=none (sender IP is ) smtp.mailfrom=Jonathan.Hardwick@metaswitch.com;
x-originating-ip: [86.132.72.20]
x-ms-publictraffictype: Email
x-microsoft-exchange-diagnostics: 1; CY4PR0201MB3524; 7:D1QJIgDcTUENDRsXOOdhUWaxRukqExwAagWmoWajh/L3pxtSE2OCtvnTMH3ftfPq+PrTp17LU9Ga8jR6tvODex6rpTGbsdkS+tRndVlbmsqEfIhmDnSoJTW76RL1EvkLu2geJweKnMMtt9YGy+9R13WWcL8nAwK1Ny2FDb1KKryz/gWb8RQjm/ZmviWXQGQip8n1nAEqTg9uIjVptoDmgTme0OYdfl4LqGRuUL8XChG5fPbPy+rYZ33KvHuUD1yI
x-ms-exchange-antispam-srfa-diagnostics: SSOS;
x-ms-office365-filtering-correlation-id: e5cddd0d-0780-4b6c-45e8-08d55f2abbc6
x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(7020095)(4652020)(5600026)(4604075)(3008032)(2017052603307)(7153060)(7193020); SRVR:CY4PR0201MB3524;
x-ms-traffictypediagnostic: CY4PR0201MB3524:
x-microsoft-antispam-prvs: <CY4PR0201MB35246A1849F795F278A16F5384EF0@CY4PR0201MB3524.namprd02.prod.outlook.com>
x-exchange-antispam-report-test: UriScan:(18271650672692);
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040470)(2401047)(5005006)(8121501046)(3002001)(93006095)(93001095)(3231023)(944501161)(10201501046)(6041268)(20161123564045)(20161123562045)(20161123558120)(20161123560045)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(6072148)(201708071742011); SRVR:CY4PR0201MB3524; BCL:0; PCL:0; RULEID:(100000803101)(100110400095); SRVR:CY4PR0201MB3524;
x-forefront-prvs: 0557CBAD84
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(39850400004)(366004)(39380400002)(396003)(346002)(376002)(189003)(199004)(13464003)(3846002)(6116002)(74316002)(81166006)(59450400001)(8676002)(81156014)(478600001)(2950100002)(33656002)(102836004)(8936002)(53546011)(3280700002)(7736002)(6506007)(72206003)(305945005)(3660700001)(966005)(99286004)(2900100001)(2501003)(5250100002)(2906002)(7696005)(230783001)(106356001)(76176011)(105586002)(68736007)(14454004)(55016002)(6246003)(6436002)(25786009)(26005)(53936002)(66066001)(5660300001)(6306002)(9686003)(97736004)(86362001)(229853002)(110136005)(316002); DIR:OUT; SFP:1102; SCL:1; SRVR:CY4PR0201MB3524; H:CY4PR0201MB3603.namprd02.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en;
received-spf: None (protection.outlook.com: metaswitch.com does not designate permitted sender hosts)
x-microsoft-antispam-message-info: NrPbyKga9Ve9WusvfbKLMQu6FB2o6pjPABeCtel6rGl5goYJvOhXcZ+9qbDHd0klgmUlzhFe+aoXlMjPXfBlbQ==
spamdiagnosticoutput: 1:99
spamdiagnosticmetadata: NSPM
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-OriginatorOrg: metaswitch.com
X-MS-Exchange-CrossTenant-Network-Message-Id: e5cddd0d-0780-4b6c-45e8-08d55f2abbc6
X-MS-Exchange-CrossTenant-originalarrivaltime: 19 Jan 2018 10:52:28.4516 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 9d9e56eb-f613-4ddb-b27b-bfcdf14b2cdb
X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY4PR0201MB3524
Archived-At: <https://mailarchive.ietf.org/arch/msg/pce/LMV4cZ-k_ztiq1nEsmyINUDJrAc>
Subject: Re: [Pce] WG Last Call for draft-ietf-pce-segment-routing-11
X-BeenThere: pce@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: Path Computation Element <pce.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/pce>, <mailto:pce-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/pce/>
List-Post: <mailto:pce@ietf.org>
List-Help: <mailto:pce-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/pce>, <mailto:pce-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 19 Jan 2018 10:52:34 -0000
Adrian Many thanks for your review. The authors will need to discuss your comments, and then we'll get back to you. Best regards Jon -----Original Message----- From: Pce [mailto:pce-bounces@ietf.org] On Behalf Of Adrian Farrel Sent: 18 January 2018 22:55 To: 'Julien Meuric' <julien.meuric@orange.com>; pce@ietf.org Subject: Re: [Pce] WG Last Call for draft-ietf-pce-segment-routing-11 Hi, I reviewed this draft as part of the WG last call. It is important work and needs to be published as an RFC. However, there are some places where the clarity could be improved and so increase the chances of interoperable implementations. I have clustered the nits at the end of this email. Thanks, Adrian ========= Section 3 In SR networks, an ingress node of an SR path appends all outgoing packets with an SR header consisting of a list of SIDs (or MPLS labels in the context of this document). Conventionally, "append" means to add to the end (although it can mean to arbitrarily add). I think you want "prepend" although the sentence is still clumsy and might be better as... In an SR network, the ingress node of an SR path prepends an SR header to all outgoing packets. The SR header consists of a list of SIDs (or MPLS labels in the context of this document). --- Section 3 (same paragraph) I think this is not quite true. Well, it is true that signaling is not needed, but not true that the header has all the necessary information in all cases - the IGP may need to resolve a path to a Node SID. Perhaps... The header has all necessary information so that in combination with the information distributed by the IGP, the packets can be guided from the ingress node to the egress node of the path, and hence there is no need for any signaling protocol. --- Section 3 para 2 has the same "append" problem, and also overstates what is carried in the ERO. Suggest... OLD In a PCEP session, LSP information is carried in the Explicit Route Object (ERO), which consists of a sequence of subobjects. Various types of ERO subobjects have been specified in [RFC3209], [RFC3473], and [RFC3477]. In SR networks, an ingress node of an SR path appends all outgoing packets with an SR header consisting of a list of SIDs (or MPLS labels in the context of this document). SR-TE LSPs computed by a PCE can be represented in one of the following forms: NEW In PCEP messages, LSP route information is carried in the Explicit Route Object (ERO), which consists of a sequence of subobjects. Various ERO subobjects have been specified in [RFC3209], [RFC3473], and [RFC3477]. In SR networks, an ingress node of an SR path prepends an SR header to all outgoing packets. The SR header consists of a list of SIDs (or MPLS labels in the context of this document). SR-TE paths computed by a PCE can be represented in one of the following forms: END However, I wonder why you have picked just those three RFCs to reference. Many other RFCs also define ERO subobjects. The full list is RFC3209 RFC3473 RFC3477 RFC4874 RFC5520 RFC5553 RFC7570 RFC7898 RFC7897 ...but listing them all would be odd. --- Section 3 o An ordered set of IP address(es) representing network nodes/links: In this case, the PCC needs to convert the IP address(es) into the corresponding MPLS labels by consulting its Traffic Engineering Database (TED). The PCC does not have a TED. It does have an LSDB as distributed by the IGP and this will contain the SRGBs and SIDs that allow labels to be computed. But I am surprised that this work is offloaded to the PCC since the PCE has all the information to do this task. Why did the WG want to add this option? And then... o An ordered set of SID(s) s/SID(s)/SIDs/ This list of SIDs would need to be converted to labels by the PCC by applying the SRGB offsets. Again, why make the PCC do this? And finally... o An ordered set of both MPLS label(s) and IP address(es): In this case, the PCC needs to convert the IP address(es) into the corresponding SID(s) by consulting its TED. This mixture of the previous two cases seems to compound the level of complexity. Can't the PCE just know it is making an SR path and supply a list of MPLS labels corresponding to the SIDs? --- 5.1.1 ---> 9 You should probably set up a registry for other SR PCE Capability sub- TLV flags. --- 5.1.2 ----> 6 If a PCEP speaker receives a PATH-SETUP-TYPE-CAPABILITY TLV with a PST list containing PST=1, but the SR-PCE-CAPABILITY sub-TLV is absent, then the PCEP speaker MUST send a PCErr message with Error- Type 10 (Reception of an invalid object) and Error-Value TBD1 (to be assigned by IANA) (Missing PCE-SR-CAPABILITY sub-TLV) and MUST then close the PCEP session. Suppose an implementation receives an Open with PST=1 but doesn't understand (or doesn't support) that value. Is it still required to perform this check? Hopefully not. --- 5.3.1 The figure and the following text can be explicit about the value 36 since it has already been assigned. Type is the type of the SR-ERO subobject. This document defines the SR-ERO subobject type, and requests a new codepoint from IANA. --- 5.3.1 (under Length) has As mentioned earlier, an SR-ERO subobject MUST have at least SID or NAI. This is good and does tie in with what is written in earlier sections. However, 5.3.1 starts with An SR-ERO subobject consists of a 32-bit header followed by the SID and the NAI associated with the SID. The SID is a 32-bit number. The size of the NAI depends on its respective type, as described in the following sections. That makes it sound like they are both mandatory, and the figure doesn't help. A little rewording would go a long way, and you could add "(optional)" to the figure. --- 5.3.1 SID Type (ST) indicates the type of information associated with the SID contained in the object body. When ST value is 0, SID MUST NOT be null and NAI MUST be null. Does "null" mean "all zeros" or "absent"? See also the definition of the S and F flags. --- 5.3.1 Other ST values are described later in this document. It would be friendly to provide a list somewhere. Do you need a registry? --- 5.3.1 Flags is used to carry any additional information pertaining to SID. You need to say how to set the unused bits. Do you need a registry? --- * M: When this bit is set, the SID value represents an MPLS label stack entry as specified in [RFC5462] where only the label value is specified by the PCE. Other fields (TC, S, and TTL) fields MUST be considered invalid, and PCC MUST set these fields according to its local policy and MPLS forwarding rules. "considered invalid"? You probably mean "ignored". RFC5462 is not the right reference. It only renamed EXP to TC and does not define the other fields. You should reference 3032 and you will pick up TC through the updates clause. (Ditto other places where the ref is made). --- 5.3.2 has text like Length is 8, 20, or 24 depending on either SID or NAI or both are included in the subobject. But NAI must be present or we wouldn't be talking about NAI types. So, you need (e.g.) Length is 20 or 24 depending on whether the SID is absent or also included in the subobject. --- 5.3.2 OLD 'IPv6 Node ID' is specified as an IPv6 address. In this case, ST and Length are 2, and Length is 8, 20, or 24 depending on either SID or NAI or both are included in the subobject. NEW 'IPv6 Node ID' is specified as an IPv6 address. In this case, ST is 2, and Length is 8, 20, or 24 depending on either SID or NAI or both are included in the subobject. --- 5.3.3 If both M and C bits of an SR- ERO subobject are set, and if a PCEP speaker finds erroneous setting in one or more of TC, S, and TTL fields, it MUST send a PCErr message with Error-Type = 10 ("Reception of an invalid object") and Error- Value = 4 ("Bad label format"). But didn't the definition of the C flag say that a not MAY overwrite those fields according to local policy? So this is MUST send PCErr or overwrite the fields. --- 5.3.3 If a PCC receives a stack of SR-ERO subobjects, and the number of stack exceeds the maximum number of SIDs that the PCC can impose on the packet, it MAY send a PCErr message with Error-Type = 10 ("Reception of an invalid object") and Error-Value = 3 ("Unsupported number of Segment ERO subobjects"). And if it doesn't send the PCErr, what should it do? --- 5.3.3 When a PCEP speaker detects that all subobjects of ERO are not identical, and if it does not handle such ERO, it MUST send a PCErr message with Error-Type = 10 ("Reception of an invalid object") and Error-Value = 5 ("Non-identical ERO subobjects"). "Not identical" could have so many meanings here! - Presumably you don't mean that all SIDs have the same value - You might be referring to all flags - You might be referring to just the M and C flags - You might mean that the ERO must contain all SR-ERO subobjects or no SR-ERO subobjects Please clarify and possibly rename the error value. (See also 5.4.1). --- 5.3.3 When a PCEP speaker receives an SR-ERO subobject in which ST is 0, SID MUST be present and NAI MUST NOT be present(i.e., S-flag MUST be 0, F-flag MUST be 1, and the Length MUST be 8). Otherwise, it MUST consider the entire ERO object invalid and send a PCErr message with Error-Type = 10 ("Reception of an invalid object") and Error-Value = 11 ("Malformed object"). The PCEP speaker MAY include the malformed SR-ERO object in the PCErr message as well. This text is good. But it makes me think: what about the ST values 1 through 5 if the NAI is absent? --- ======== Nits Update to the new BCP14 (RFC2119/8174) language and place it as Section 2 of the document as required by RFC7322. --- Need to expand "SR" on first use in the body of the document. --- Section 1 para 1 has two cases where "SR architecture" should be "the SR architecture". --- S1P1 OLD and is always global within SR/IGP domain NEW and is always identified uniquely within the SR/IGP domain END --- S1P1 s/e.g./e.g.,/ --- S1P1 OLD within SR/IGP domain NEW an within SR/IGP domain END -- draft-ietf-pce-pce-initiated-lsp is now RFC8281 --- 5.2 Took some time to parse... OLD In order to setup an SR-TE LSP using SR, RP or SRP object MUST include PATH-SETUP-TYPE TLV NEW In order to setup an SR-TE LSP using SR, the RP or SRP object MUST include PATH-SETUP-TYPE TLV END --- 5.3 and 5.4 Please avoid saying "ERO Object" and "RRO Object" --- Throughout the document, please don't do the optional plural thing. E.g., "may contain one or more TLV(s)" English likes you to use the plural even when the singular is possible. E.g., "may contain one or more TLVs" > -----Original Message----- > From: Pce [mailto:pce-bounces@ietf.org] On Behalf Of Julien Meuric > Sent: 15 January 2018 09:38 > To: pce@ietf.org > Subject: [Pce] WG Last Call for draft-ietf-pce-segment-routing-11 > > Dear PCE WG, > > Best wishes for this new year, full of interoperable specifications. > Let us begin by resuming our work in progress. > > This message starts a 2-week WG last call for > draft-ietf-pce-segment-routing-11. Please send your feedback on the > I-D to the PCE mailing list by Monday January 29. _______________________________________________ Pce mailing list Pce@ietf.org https://www.ietf.org/mailman/listinfo/pce
- Re: [Pce] WG Last Call for draft-ietf-pce-segment… Jonathan Hardwick
- Re: [Pce] WG Last Call for draft-ietf-pce-segment… Jonathan Hardwick
- Re: [Pce] WG Last Call for draft-ietf-pce-segment… Jonathan Hardwick
- Re: [Pce] WG Last Call for draft-ietf-pce-segment… Jonathan Hardwick
- Re: [Pce] WG Last Call for draft-ietf-pce-segment… Adrian Farrel
- [Pce] WG Last Call for draft-ietf-pce-segment-rou… Julien Meuric
- Re: [Pce] WG Last Call for draft-ietf-pce-segment… Adrian Farrel
- Re: [Pce] WG Last Call for draft-ietf-pce-segment… Jonathan Hardwick
- Re: [Pce] WG Last Call for draft-ietf-pce-segment… Dhruv Dhody
- Re: [Pce] WG Last Call for draft-ietf-pce-segment… Julien Meuric
- Re: [Pce] WG Last Call for draft-ietf-pce-segment… Cyril Margaria
- Re: [Pce] WG Last Call for draft-ietf-pce-segment… Dhruv Dhody