Hi there I've performed my WG shepherd review of this draft - here are my comments. I will wait for a response from the authors and an update before preparing the shepherd report.
Cheers Jon Note to WG Chairs This document depends on two others: draft-ietf-pce-iro-update and draft-ietf-teas-rsvp-te-domain-subobjects. All three documents should progress in step. Higher Level Points What is the use case for being able to mix AS number with the other subobject types? This feels a bit over-engineered to me, as it results in us having to define subtle rules about "changing the AS" in the IRO. I think it is unlikely that a PCC will know anything about the contents of a neighbouring AS. Am I missing a use case? Technical Comments Section 3.4.1: This section duplicates draft-ietf-teas-rsvp-te-domain-subobjects-02 and cannot be present in both (the code points are being allocated from the same IANA registry). You should remove this section from the document and instead refer to the TEAS draft. ------ Section 3.4.1.2: IS-IS area IDs can vary from 1 to 13 bytes in length (max NSAP length is 20, minus 1 byte for NSEL, minus 6 bytes for SysID). This should be fixed in the TEAS draft (I see the drafts have overlap in authors). ------ Section 3.4.4, this paragraph: For each inclusion, the PCC clears the L-bit to indicate that the PCE is required to include the domain, or sets the L-bit to indicate that the PCC simply desires that the domain be included in the Domain- Sequence. That's not what the L bit means. If L is set then this is a loose hop, i.e. the PCE is free to interpose nodes in between this (abstract) node and the previous (abstract) node that do not belong to either abstract node. It does not mean that the given abstract node is optional. If an IRO is given then the computed path MUST traverse all hops (RFC 5440). This remark also applies to the next-but-one paragraph. ------ Section 3.4.4 gives a set of rules for processing the IRO that specify when the area changes in the IRO, or when the AS changes in the IRO. It took me a while to understand why you were doing this. I have one quibble - I don't think an unnumbered link can change the AS because its identifiers are not global, they are only meaningful within the context of an AS. I would give these rules in a different way, as follows. Please let me know whether you think this is clearer. * A PCC may intersperse Area and AS subobjects with other subobjects without change to the previously specified processing of those subobjects in the IRO. * When a PCE parses an IRO, it interprets each subobject according to the AS number associated with the preceding subobject. We call this the "current AS". Certain subobjects modify the current AS, as follows. o The current AS is initialized to the AS number of the PCC. o If the PCE encounters an AS subobject, then it updates the current AS to this new AS number. o If the PCE encounters an Area subobject, then it assumes that the area belongs to the current AS. o If the PCE encounters an IP address that is globally routable, then it updates the current AS to the AS that owns this IP address. This document does not define how the PCE learns which AS owns the IP address. o If the PCE encounters an IP address that is not globally routable, then it assumes that it belongs to the current AS. o If the PCE encounters an unnumbered link, then it assumes that it belongs to the current AS. * <Then give similar rules for updating the current area.> * <Then explain that the current AS and current area influence the selection of the next PCE in the chain, in the case that this PCE does not own the given AS or area.> ------ Section 3.5.1 and its subsections will need some updates to refer to the TEAS draft. ------ In section 3.6, there are a couple of subtleties that you should cover. Firstly, if an EXRS subobject is associated with a different AS than the preceding IRO subobject, should that change the "current AS"? If not, what is the meaning of placing such an EXRS in between two IRO subobjects that belong to the same AS - is that invalid? Secondly, if an EXRS is placed in between two IRO subobjects that are associated with different ASes, with which AS should the EXRS subobjects be associated? ------ Section 7.2 A MIB module for management of the PCEP is being specified in a separate document [RFC7420]. That MIB module allows examination of individual PCEP messages, in particular requests, responses and errors. Not actually true - you can't look at individual PCEP messages in the MIB. Editorial Section 1 paragraph 4. Final sentence should be two sentences. Also, use of "this document" is ambiguous. Suggest: "The use of Autonomous System (AS) (albeit with a 2-Byte AS number) as an abstract node representing a domain is defined in [RFC3209]. In the current document, we specify new subobjects to include or exclude domains, including IGP areas and Autonomous Systems (4-Byte as per [RFC6793])." ------ Section 1 paragraph 5. It is unclear what this means. Please clarify or delete. ------ Section 3.4.3 - I'd prefer to split this section into "PCC Procedures" and "PCE Procedures". The first paragraph is unnecessary. ------ Section 3.4.4 - these two paragraphs seem to just repeat RFC 5440. I think they should be removed. If a PCE receives an IRO in a Path Computation request (PCReq) message that contains subobjects defined in this document, that it does not recognize, it will respond according to the rules for a malformed object as per [RFC5440]. The PCE MAY also include the IRO in the PCErr to indicate in which case the IRO SHOULD be terminated immediately after the unrecognized subobject. [...] A successful path computation reported in a path computation reply message (PCRep) MUST include an ERO to specify the path that has been computed as specified in [RFC5440] following the sequence of domains. Ditto the final paragraph of 3.5.1.2. Ditto the final paragraph of 3.7. ------ Section 4 should probably be entitled "Examples" to make it clearer that this section contains no normative text. ------ In section 4.1 you should clarify that the endpoints are in areas 2 and 4. Nits Section 1.1 para 1: "specify" -> "specifies" Section 3.2 point 3: "constraint" -> "constrain" Section 3.2 point 4: semicolon should be period. Section 3.4.3 paragraph 4: "comprising of" -> "comprising" Section 3.4.4 "Following processing rules" -> "The following processing rules"
_______________________________________________ Pce mailing list [email protected] https://www.ietf.org/mailman/listinfo/pce
