Re: [Pce] Shepherd review of draft-ietf-pce-pcep-domain-sequence-08

[Dhruv Dhody <[e-mail]>]

Hi Jon,

See inline [Dhruv2]:

From: Jonathan Hardwick [mailto:[e-mail]]
Sent: 14 September 2015 22:52
To: Dhruv Dhody; [e-mail]; [e-mail]
Cc: [e-mail]
Subject: RE: Shepherd review of draft-ietf-pce-pcep-domain-sequence-08

Hi Dhruv, thanks for the replies.  Please see [JEH} inline below...
Cheers
Jon


From: Dhruv Dhody [mailto:[e-mail]]
Sent: 10 September 2015 09:11
To: Jonathan Hardwick <[e-mail]<mailto:[e-mail]>>; [e-mail]<mailto:[e-mail]>; [e-mail]<mailto:[e-mail]>
Cc: [e-mail]<mailto:[e-mail]>
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.

[Dhruv2]: I get that, but the same practice has been carried out for EXRS as well between RFC4874 and RFC5521, I am just following the precedence :)
I prefer to keep it as of now, but completely open to change if required.

------

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.

[Dhruv2]: I have raised errata! [http://www.rfc-editor.org/errata_search.php?rfc=4920&eid=4480]

------

<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.

[Dhruv2]: I discussed this offline, and it was suggested that theoretically it is a possibility, and thus I would prefer to keep it.

<snip>

------

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]."

[Dhruv2]: Thanks for the text, Updated!

I will post the updated version now!
Thanks for your review and apologies for delay.

Regards,
Dhruv
------

<snip>