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

[Dhruv Dhody <[e-mail]>]

Hi Jon, WG,

Apologies for the delay!

Please see inline...
I have also attached the working copy and the diff.

From: Pce [mailto:[e-mail]] On Behalf Of Jonathan Hardwick
Sent: 28 August 2015 22:02
To: [e-mail]<mailto:[e-mail]>; [e-mail]<mailto:[e-mail]>
Cc: [e-mail]<mailto:[e-mail]>
Subject: [Pce] Shepherd review of draft-ietf-pce-pcep-domain-sequence-08

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?

[Dhruv]: In case the domain sequence is configured at PCC, I agree with you. But if domain-sequence is computed (by parent-PCE, which may have a bit more information) we wanted to have an encoding option for the IRO to include details internal to the AS during this experiment.

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?

------

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?

------

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.

[Dhruv]: Yes, you are right! I would remove this and simply refer to the section 4.3.3.1 of [RFC3209] (as done in [IRO-UPDATE]).
------

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?

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

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

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?

------

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.

[Dhruv]: Oops! As a MIB contributor, I know that! Updated!

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

[Dhruv]: Ack
------

Section 1 paragraph 5.  It is unclear what this means.  Please clarify or delete.

[Dhruv]: Ack
------

Section 3.4.3 - I'd prefer to split this section into "PCC Procedures" and "PCE Procedures".  The first paragraph is unnecessary.

[Dhruv]: Ack
------

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.

[Dhruv]: This was added to address the comment regarding the scope of this experiment. I have kept it but with some rewording.

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

[Dhruv]: removed.

Ditto the final paragraph of 3.5.1.2.
Ditto the final paragraph of 3.7.

[Dhruv]: As above.

------

Section 4 should probably be entitled "Examples" to make it clearer that this section contains no normative text.

[Dhruv]: Ack

------

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"

[Dhruv]: Done! Thanks for pointing them out!

Thanks again for the detailed review.

Regards,
Dhruv