Hi Dhruv, thanks for the replies. Please see [JEH} inline below... Cheers Jon
From: Dhruv Dhody [mailto:[email protected]] Sent: 10 September 2015 09:11 To: Jonathan Hardwick <[email protected]>; [email protected]; [email protected] Cc: [email protected] Subject: RE: Shepherd review of draft-ietf-pce-pcep-domain-sequence-08 <snip> 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. [Dhruv]: I followed the PKS (path-key) approach where both RFC5553 and RFC5520 describe PKS within the scope of RSVP-TE and PCEP respectively. They do carry a note, which I can also add explicitly. Note: The twins of these subobjects are carried in RSVP-TE messages as defined in [DOMAIN-SUBOBJ]. Let me know if this is acceptable? [JEH] I am not sure. My point is that there is one and only one IANA registry that contains the code points for ERO subobjects. It is shared by RSVP and PCEP. So you are not defining "twin" objects, you are defining one object that is used by two protocols. My opinion is that RFC 5520 and RFC 5553 are confused about that :) Since it is the same object I'd prefer to define it once to avoid duplication, but if for editorial reasons you feel it is better to give the format in both documents, then that's fine. ------ 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). [Dhruv]: You are right! I guess I made the mistake as I used the values from RFC4920. Unless I am reading it wrong, there needs to be an errata raised there. What do you think? [JEH] I am not sure, but I suspect that it does need an errata. ------ <snip> 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. [Dhruv]: Can the ASBR interface be unnumbered? [JEH]: I don't think so, but I'm not completely certain - perhaps in optical transport network interconnects? If you think you need to allow them to change the AS then feel free to leave it. 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.> [Dhruv]: I agree! thanks for this! Here is the updated text - The following processing rules apply for Domain-Sequence in IRO - o 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. * The current AS is initialized to the AS number of the PCC. * If the PCE encounters an AS subobject, then it updates the current AS to this new AS number. * If the PCE encounters an Area subobject, then it assumes that the area belongs to the current AS. * 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. * If the PCE encounters an IP address that is not globally routable, then it assumes that it belongs to the current AS. * If the PCE encounters an unnumbered link, then it assumes that it belongs to the current AS. o When a PCE parses an IRO, it interprets each subobject according to the Area ID associated with the preceding subobject. We call this the "current Area". Certain subobjects modify the current Area, as follows. * The current Area is initialized to the Area ID of the PCC. * If the current AS is changed, the current Area is reset and need to be determined again by current or subsequent subobject. * If the PCE encounters an Area subobject, then it updates the current Area to this new Area ID. * If the PCE encounters an IP address that belongs to a different area, then it updates the current Area to the Area that has this IP address. This document does not define how the PCE learns which Area has the IP address. * If the PCE encounters an unnumbered link that belongs to a different area, then it updates the current Area to the Area that has this link. * Otherwise, it assumes that the subobject belongs to the current Area. o In case the current PCE is not responsible for the path computation in the current AS or Area, then the PCE selects the "next PCE" in the domain-sequence based on the current AS and Area. We need to re-confirm regarding the unnumbered interface. [JEH] Looks good. I'll leave the unnumbered thing with you. ------ Section 3.5.1 and its subsections will need some updates to refer to the TEAS draft. [Dhruv]: Same as 3.4.1, added a note! Hope this is acceptable to you! [JEH] As above. ------ 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? [Dhruv]: I think it boils down to, does EXRS subobject changes the "current AS" or not? I looked at it this way, since EXRS is for exclusion which is different from the other IRO subobject it should not be part of changing "current AS". Moreover my understanding was that the processing rules for EXRS remain unchanged from RFC5521. I would like to leave it as it is. What do you think? Do you have text to propose instead? [JEH] I would propose "The EXRS subobject should be interpreted in the context of the current AS and current Area of the preceding subobject in the IRO. The EXRS subobject does not change the current AS or current Area. All other processing rules are as per [RFC5521]." ------ <snip>
_______________________________________________ Pce mailing list [email protected] https://www.ietf.org/mailman/listinfo/pce
