Re: [Pce] PCE WG Last Call on draft-ietf-pce-pcep-domain-sequence-07
"Adrian Farrel" <adrian@olddog.co.uk> Thu, 23 April 2015 19:41 UTC
Return-Path: <adrian@olddog.co.uk>
X-Original-To: pce@ietfa.amsl.com
Delivered-To: pce@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8B4BB1B31BF for <pce@ietfa.amsl.com>; Thu, 23 Apr 2015 12:41:54 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -100.701
X-Spam-Level:
X-Spam-Status: No, score=-100.701 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, RCVD_IN_DNSWL_LOW=-0.7, USER_IN_WHITELIST=-100] autolearn=ham
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 caSRJbsVNIEM for <pce@ietfa.amsl.com>; Thu, 23 Apr 2015 12:41:50 -0700 (PDT)
Received: from asmtp4.iomartmail.com (asmtp4.iomartmail.com [62.128.201.175]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 364AC1B31AF for <pce@ietf.org>; Thu, 23 Apr 2015 12:41:36 -0700 (PDT)
Received: from asmtp4.iomartmail.com (localhost.localdomain [127.0.0.1]) by asmtp4.iomartmail.com (8.13.8/8.13.8) with ESMTP id t3NJfYEe015591 for <pce@ietf.org>; Thu, 23 Apr 2015 20:41:34 +0100
Received: from 950129200 (dsl-sp-81-140-15-32.in-addr.broadbandscope.com [81.140.15.32]) (authenticated bits=0) by asmtp4.iomartmail.com (8.13.8/8.13.8) with ESMTP id t3NJfWvs015580 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO) for <pce@ietf.org>; Thu, 23 Apr 2015 20:41:33 +0100
From: Adrian Farrel <adrian@olddog.co.uk>
To: pce@ietf.org
References: <19334_1429116183_552E9517_19334_4447_1_552E950C.10801@orange.com>
In-Reply-To: <19334_1429116183_552E9517_19334_4447_1_552E950C.10801@orange.com>
Date: Thu, 23 Apr 2015 20:41:31 +0100
Message-ID: <01e401d07dfd$80411090$80c331b0$@olddog.co.uk>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Outlook 14.0
Thread-Index: AQGGXJvzVbNd21k+ZQ9QbRmvineAHJ3vQXGQ
Content-Language: en-gb
X-TM-AS-MML: disable
X-TM-AS-Product-Ver: IMSS-7.1.0.1576-7.5.0.1018-21500.002
X-TM-AS-Result: No--16.777-10.0-31-10
X-imss-scan-details: No--16.777-10.0-31-10
X-TMASE-MatchedRID: yebcs53SkkCNzq3eoWWJyVVN8laWo90M7yWPaQc4INRxhlodgAVtLwLy tDvV39h+2s6JOBmw1fILoxOdDlMkxiVqTewNlt0e9Ib/6w+1lWQ/8/aVSQRDEdJgDNnoqapanHP z7V1fJXhGB3TzS/Hmuk6zK25Kuz5SPp7ZTuOgazpH4a2iJdV4MfO0KyEIB98tMKZRiezcUtOamz IlyR/J8UUxwYlyuej+jvO9okoNeNOiXdgrlKZp5wPZZctd3P4BksOw0wa4r0QuaIC/E9/9wcit/ eCfvDyiBAQXUXuTX3pW7mE9psQoBA6X1bDqRHQvQpxiLlDD9FUzc8FC0MEwT1j/amLs8rQSHOWW /Rp/isopTBCqN/Cg+7bsElu59WymYAYPI4P1xFhv/kcFnp29GBkqnRJng/51ZJY6r7aDSHbB0D2 PYBe2TCnBLSaI9zPULvMIe0E5FRi5tHnmLGv3x4lD2T5imTkJ+nvSwfDbaCVVhUzKT4buI94n/J j/2rsfctp4k2S63CEZdVDNhC7p2YL3TiCL6H+FjhXy0Khej9LtJ8uAdizt/t9zZd3pUn7K8bKA2 Su/YQ3TMX6wHah+zrhX/lUQGcewEO6iheizlV6CHMvbSebVG8/rSr8VfmGwq8z7POX8FJP1O9p2 Fcb2DeVGjmZbJjjR9PXZ/dCh86OCMqAweHRD0JMSBMTQNiSA9ISHwCrIdS8hvFjBsLEZNB4ua24 ul9od+5JRaCmcBiwkTJQ1cE/Kew4mAn6Exf2OB05B1LT2M8UZYA38gj3BxDASEdbkpUDPOsOe9d qXwy8SOLfkcwR6VdonkHkoMRM+rRlLslggfyqeAiCmPx4NwLTrdaH1ZWqCHOI0tZ7A+B36C0ePs 7A07QKmARN5PTKc
Archived-At: <http://mailarchive.ietf.org/arch/msg/pce/OKqxQVtPnB49m0Nr5YxFHwNAUb0>
Subject: Re: [Pce] PCE WG Last Call on draft-ietf-pce-pcep-domain-sequence-07
X-BeenThere: pce@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
Reply-To: adrian@olddog.co.uk
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: <http://www.ietf.org/mail-archive/web/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: Thu, 23 Apr 2015 19:41:54 -0000
Hi, While I have frequently questioned the need for this function in an IRO, I have done a quick review of this document. I don't guarantee to have found all of the issues, but I do conclude that the document is not ready for publication as an RFC. Cheers, Adrian === It seems to me that the text here treats the domain sequence as a separate thing rather than just some new IRO subobjects that can be included in a PCReq. This shows in some of my comments below. Perhaps you need some more words to explain how to interleave the normal subobjects with the new ones. --- It is fine that this is an experimental document, but I do wonder: what the experiment is; how to confine the experiment so it doesn't impact other nodes or networks (see my comments on 3.4.3 and 3.5.1.2; what I need to do to all nodes in the experimental network; how I judge the success of the experiment. --- I question the inclusion of the word "shortest" in the Abstract, and I don't find it repeated in the Introduction where I looked to find a citation that indicated that it is a "key requirement". In fact, I think that the term "shortest" is in some senses conflicting with the concept of including other constraints. I would solve this by accepting that "as short as possible given the other constraints" is itself just a constraint. Thus... OLD The ability to compute shortest constrained Traffic Engineering Label NEW The ability to compute constrained Traffic Engineering Label END ...and... OLD to compute inter-domain constrained shortest paths across a predetermined sequence of domains . NEW to compute inter-domain constrained paths across a predetermined sequence of domains. END And in 3.4.3 OLD A PCC builds an IRO to encode the Domain-Sequence, so that the cooperating PCEs should compute an inter-domain shortest constrained path across the specified sequence of domains. NEW A PCC builds an IRO to encode the Domain-Sequence, so that the cooperating PCEs should compute an inter-domain constrained path across the specified sequence of domains. END --- Section 1 has some duplication. I think you can delete: A PCE determines the next PCE to forward the request based on the Domain-Sequence. In a multi- domain path computation, a Path Computation Client (PCC) MAY indicate the sequence of domains to be traversed using the Include Route Object (IRO) defined in [RFC5440]. When the sequence of domains is not known in advance, the Hierarchical PCE (H-PCE) [RFC6805] architecture and mechanisms can be used to determine the Domain-Sequence. And move: This document defines a standard way to represent and encode a Domain-Sequence in various scenarios including P2P LSP, P2MP LSP, and use of H-PCE. ... to later in the section. This also removes two problems with: In a multi- domain path computation, a Path Computation Client (PCC) MAY indicate the sequence of domains to be traversed using the Include Route Object (IRO) defined in [RFC5440]. 1. I don't think the upper case "MAY" is necessary or appropriate. 2. I think that 5440 only gives you half of what you want, which is why you are writing this document! But you actually catch and explain this in the paragraphs that follow. --- The 2119 language in Section 3.2 doesn't seem right. You are describing how things are, not how things have to be. I think you can use just normal language. It also doesn't seem right in 3.3 where you are describing how things work, not what implementations have to do. --- There seems to be some duplication in section 3.3. For example, o Include Route Object (IRO): As per [RFC5440], used to specify set of network elements that MUST be traversed. The subobjects in IRO are used to specify the Domain-Sequence that MUST be traversed to reach the destination. --- In 3.4.1 you are repeating some material that isn't really needed. The following subobject types are used in IRO. Type Subobject 1 IPv4 prefix 2 IPv6 prefix 4 Unnumbered Interface ID 32 Autonomous system number (2 Byte) 33 Explicit Exclusion (EXRS) --- In 3.4.1.2, I don't understand why you need two sub-object types. You could certainly handle the encoding within the same sub-object so you are presumably worried about distinguishing between an OSPF area ID and an IS-IS area ID. I suppose that there is a faint chance that one AS is running two IGPs at once and the administrator has decided to give the same ID to two areas, one from each IGP. Is that what you're worried about? --- 3.4.1.2 gives [ISO10589] as a reference for the definition of an area ID. It surprised me that we don't have an IETF reference for this. Can you check with the chairs of the ISIS WG that this is the right reference. --- In 3.4.1.2 for the IS-IS variant, you have... Length: Variable. As per [RFC3209], the total length of the subobject in bytes, including the L, Type and Length fields. The Length MUST be at least 4, and MUST be a multiple of 4. Wouldn't a length of 4 mean that there was no area ID included? --- 3.4.3 lists four references for IRO subobjects: [RFC3209], [RFC3473], [RFC3477], and [RFC4874]. But RFC 3473 is not listed at http://www.iana.org/assignments/pcep/pcep.xhtml#iro-subobject --- In 3.4.3 If a PCE encounters a subobject that it does not support or recognize, it MUST act according to the setting of the L-bit in the subobject. If the L-bit is clear, the PCE MUST respond with a PCErr with Error-Type TBD4 "Unrecognized subobject" and set the Error-Value to the subobject type code. If the L-bit is set, the PCE MAY respond with a PCErr as already stated or MAY ignore the subobject: this choice is a local policy decision. This links to 5.2. You are defining behavior in this I-D for a non-compliant node. But a non-compliant node doesn't support this I-D! That is, an implementation of 5440 will look at the received IRO and see the unknown subobject and act according to 5440 not according to this document. You have to ask yourselves: - What does my 5440 implementation do with an unknown subobject? - Is that behavior documented and do I simply need to point to that? - Do we need an update to 5440 to say how to handle unknown subobjects? --- In 3.4.3 Note that a particular domain in the Domain-Sequence can be identified by :- o A single IGP Area: Only the IGP (OSPF or ISIS) Area subobject is used to identify the next domain. (Refer Figure 1) o A single AS: Only the AS subobject is used to identify the next domain. (Refer Figure 2) o Both an AS and an IGP Area: AS and Area in combination are used to identify the next domain. In this case the order is AS Subobject followed by Area. (Refer Figure 3) This is not clear. If I identify two domains in the sequence, the first with an AS subobject and the second with an Area subobject, how is this distinguished from the third case that you list? I think you have to clarify how this works. Isn't it the case that an area ID can only ever have context within a specific AS? Isn't it the case that if you supply an AS followed by an area you are not controlling the entry area to the AS? Does all that actually mean that you need the area subobject to carry the AS number? --- 3.4.3 The Subobjects representing an internal node, a Boundary Node or an Inter-AS-Link MAY also influence the selection of the path. I guess you mean "MAY be included by a PCC to influence the selection of the path". --- In 3.5 you are repeating some material that isn't really needed because it is already in other documents and the IANA registry. The following subobject types are defined to be used in XRO as defined in [RFC3209], [RFC3477], [RFC4874], and [RFC5521]. Type Subobject 1 IPv4 prefix 2 IPv6 prefix 4 Unnumbered Interface ID 32 Autonomous system number (2 Byte) 34 SRLG 64 IPv4 Path Key 65 IPv6 Path Key But, anyway, it should be 5520 not 5521. --- For 3.5.1.2 I have the same questions as for 3.4.1.2 --- 3.5.1.2 has If a PCE that supports XRO and encounters a subobject that it does not support or recognize, it MUST act according to the setting of the X-bit in the subobject. If the X-bit is clear, the PCE MUST respond with a PCErr with Error-Type TBD4 "Unrecognized subobject" and set the Error-Value to the subobject type code. If the X-bit is set, the PCE MAY respond with a PCErr as already stated or MAY ignore the subobject: this choice is a local policy decision. Similar to 3.4.3... This links to 5.2. You are defining behavior in this I-D for a non-compliant node. But a non-compliant node doesn't support this I-D! That is, an implementation of 5440 will look at the received IRO and see the unknown subobject and act according to 5440 not according to this document. You have to ask yourselves: - What does my 5440 implementation do with an unknown subobject? - Is that behavior documented and do I simply need to point to that? - Do we need an update to 5440 to say how to handle unknown subobjects? --- 3.7 lead me to look at 5.1. 5.1 is confusing... The "PCEP Parameters" registry contains a subregistry "PCEP Objects" with an entry for the Include Route Object (IRO), Exclude Route Object (XRO) and Explicit Route Object (ERO). IANA is requested to add further subobjects as follows: 7 ERO 10 IRO 17 XRO Subobject Type Reference TBD1 4 byte AS number [This I.D.] TBD2 OSPF Area ID [This I.D.] TBD3 IS-IS Area ID [This I.D.] I think you mean to ask IANA to make the same three assignments from all three registries. This text: - doesn't make that clear - doesn't identify the registries correctly - there is no PCEP ERO registry! You probably want... IANA maintains the "Path Computation Element Protocol (PCEP) Numbers" at http://www.iana.org/assignments/pcep/pcep.xhtml. Within this registry IANA maintains two sub-registries: - "IRO Subobjects" http://www.iana.org/assignments/pcep/pcep.xhtml#iro-subobject - "XRO Subobjects" http://www.iana.org/assignments/pcep/pcep.xhtml#xro-subobject IANA is requested to make identical additions to these registries as follows: Subobject Type Reference TBD1 4 byte AS number [This I.D.] TBD2 OSPF Area ID [This I.D.] TBD3 IS-IS Area ID [This I.D.] But you will also need to change the text in 3.7 because you can't make additions to the PCEP ERO subobject registry when it doesn't exist! And you can't make changes to the RSVP ERO subobject registry in the PCE working group. --- In 3.7 you have.. The format of the new ERO subobjects is similar to new IRO subobjects, refer Section 3.4. "similar"? --- Figure 1 has some extra pipes (|) in the ABR between area 2 and area 0. --- 4.1.1 says... AS is optional and it MAY be skipped. I don't think you mean "skipped". If the AS is present it MUST be processed because it has to be checked. Additionally, you have already told us that the examples are not normative. So: - you must not use 2119 language - you need to check that the normative text *is* present in section 3 So in 4.2.1 I think you mean... AS is optional. If it is not present, the receiver will deduce that there is no change in the AS. But somewhere you will need to clarify a few things (I think I asked questions about some of this as I read section 3) about the order of subobjects and how they are interleaved in the three objects. Essentially you have... - The Area subobject is optional. - The AS subobject is optional. - If an Area subobject is not preceded by an AS subobject then the receiver MUST act as though there is no change in AS from the previous subobject. - If an AS subobject is present then it changes the AS for all subsequent subobjects that do not themselves change the AS. - Subobjects that may change the AS are: - IP addresses that are present in another AS - Unnumbered interfaces that are present in another AS - AS numbers - Path key identifiers that expand to path segments that include changes to the AS - AS and Area subobjects may be interspersed with other subobjects without change to the previously specified processing. Whether this goes in section 3 (which feels natural) or in section 4 (where you have any number of other small normative items) is up to you, but if it is in section 4 you really need to make much clearer that I need to read the section! --- Figure 3 is "interesting". Aren't AS interconnects always provided in Area 0, or am I embarrassing myself? --- The option for encoding the inter-AS link in section 4.3 is legitimate, but excessive. You do not need to show both link ends since it would be impossible to use one end of the link without using the other end! --- I think it is fine for section 4.5 to make a reference to 7334, but it is wrong to do so in a way that suggests that 7334 is *the* way to do inter-domain P2MP path computation since that RFC describes an experiment. Similarly, [PCE-P2MP-PER-DEST] is also experimental (and has expired!). In both cases, this is notwithstanding that this document is an experiment itself. --- Figure 4 has the same typo in the ABR as in Figure 1. --- In 4.6 "ERO Object" should be EROO :-) --- In 4.6 you have: The ERO can contain an ordered sequence of subobjects such as AS and Area (OSPF/ISIS) subobjects. In this case, the Domain-Sequence appear as: +---------+ +---------+ +---------+ +---------+ |ERO | |Sub | |Sub | |Sub | |Object | |Object | |Object | |Object | |Header | |Area 2 | |Area 0 | |Area 4 | | | | | | | | | | | | | | | | | +---------+ +---------+ +---------+ +---------+ +---------+ +---------+ +---------+ +---------+ +---------+ |ERO | |Sub | |Sub | |Sub | |Sub | |Object | |Object AS| |Object | |Object | |Object | |Header | |100 | |Area 2 | |Area 0 | |Area 4 | | | | | | | | | | | | | | | | | | | | | +---------+ +---------+ +---------+ +---------+ +---------+ This is confusing. I think you mean to indicate a choice. However, I have no clear understanding of why this is a good example since: - the Ingress PCE 'PCE(1)' would more logically be in Area 1 - the ERO could contain the identifiers of the ABRs - Area 2 is presumably taken as read by the requesting PCE so doesn't need to be included - if Area 2 needs to connect to anything out of area it has to go through Area 0, so including that is superfluous --- Section 4.7 uses "SHOULD". Under what circumstances MAY the PCE-Sequence have lower or equal precedence? You also say: Note that Domain-Sequence IRO constraints should still be checked as per the rules of processing IRO. ...Why don't I have to check the XRO and EXRS? --- 4.8 has [DOMAIN-SUBOBJ] extends the notion of abstract nodes by adding new subobjects for IGP Areas and 4-byte AS numbers. These subobjects MAY be included in Explicit Route Object (ERO), Exclude Route object (XRO) or Explicit Exclusion Route Subobject (EXRS) in RSVP-TE. Is it right to provide normative language for RSVP-TE in this document? --- This is a bit odd... 7.6. Impact On Network Operations Mechanisms defined in this document do not have any impact on network operations in addition to those already listed in [RFC5440]. I thought the whole point was to impact network operations! --- While it is OK for this document and [DOMAIN-SUBOBJ] to only have informational references to each other, I think it would be sensible to try to tie them together in the RFC Editor Queue so that they get considered together, so that any issues can be synchronised, and so that there are no surprises with code points. I guess the chairs can talk to the TEAS chairs and the ADs to make this happen, or you could upgrade the references to be normative. Maybe a normative reference would be more in keeping with the revision to 5.1 and 4.8 I think you should make because there is no PCEP ERO subobject registry. > -----Original Message----- > From: Pce [mailto:pce-bounces@ietf.org] On Behalf Of > julien.meuric@orange.com > Sent: 15 April 2015 17:43 > To: pce@ietf.org > Subject: [Pce] PCE WG Last Call on draft-ietf-pce-pcep-domain-sequence-07 > > Dear PCE & TEAS WGs, > > This message initiates a 2-week WG last call on > draft-ietf-pce-pcep-domain-sequence-07. Please send your comments to the > PCE mailing list by Wednesday April 29. > > Thanks, > > JP & Julien > > > ______________________________________________________________ > ___________________________________________________________ > > 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. > > _______________________________________________ > Pce mailing list > Pce@ietf.org > https://www.ietf.org/mailman/listinfo/pce
- [Pce] PCE WG Last Call on draft-ietf-pce-pcep-dom… julien.meuric
- Re: [Pce] PCE WG Last Call on draft-ietf-pce-pcep… Huaimo Chen
- Re: [Pce] PCE WG Last Call on draft-ietf-pce-pcep… Dhruv Dhody
- Re: [Pce] PCE WG Last Call on draft-ietf-pce-pcep… Udayasree palle
- [Pce] 答复: PCE WG Last Call on draft-ietf-pce-pcep… Lizhenbin
- Re: [Pce] PCE WG Last Call on draft-ietf-pce-pcep… Leeyoung
- Re: [Pce] PCE WG Last Call on draft-ietf-pce-pcep… Vishnu Pavan Beeram
- Re: [Pce] PCE WG Last Call on draft-ietf-pce-pcep… Adrian Farrel
- Re: [Pce] PCE WG Last Call on draft-ietf-pce-pcep… Zhangxian (Xian)
- Re: [Pce] PCE WG Last Call on draft-ietf-pce-pcep… Dhruv Dhody
- Re: [Pce] PCE WG Last Call on draft-ietf-pce-pcep… Adrian Farrel
- Re: [Pce] PCE WG Last Call on draft-ietf-pce-pcep… BELOTTI, SERGIO (SERGIO)
- Re: [Pce] PCE WG Last Call on draft-ietf-pce-pcep… Dhruv Dhody
- Re: [Pce] PCE WG Last Call on draft-ietf-pce-pcep… BELOTTI, SERGIO (SERGIO)
- Re: [Pce] PCE WG Last Call on draft-ietf-pce-pcep… julien.meuric