Re: [Pce] Review of draft-ietf-pce-inter-area-as-applicability

["Daniel King" <[e-mail]>]

Hi Dhruv, 

Great review! 

Thanks for the detailed comments. We will digest and update/discuss
accordingly. 

BR, Dan. 

-----Original Message-----
From: Dhruv Dhody [mailto:[e-mail]] 
Sent: 31 March 2016 05:21
To: [e-mail]
Cc: [e-mail]; Jonathan Hardwick <[e-mail]>;
Dhruv Dhody <[e-mail]>
Subject: Review of draft-ietf-pce-inter-area-as-applicability

Hi Authors, WG,

As promised here is the review of the Inter-Area and AS applicability draft.

Main Points -
*************

   (1) We should add text to indicate that the inter-domain
   considerations for stateful PCE is out of scope and may be handled
   in a different document.

   (2) The draft has some content common with RFC6805, we can
      (a) add reference and keep the text;
      (b) add reference and condense the text;
      (c) keep as it is;

   (3) A section on inter-AS link and boundary node (ABR/ASBR)
   considerations can be added.

   (4) Some text is repetitive, editors can look if reorganization
   would help to avoid it.

   (5) Some inter-area considerations (5.1.3 and 5.2) can also be
   applied to inter-AS, we should also have section for -
      (a) Inter-AS Diverse Path Computation (perhaps merged with
      Inter-AS Recovery?)
      (b) Control and Recording of AS Crossing


Minor -
*******

   Section 1.5
      Regarding the last statement

           The PCE
           discovery mechanism defined in [RFC5088] and [RFC5089] allow
           the discovery of PCEs and disclosure of information related to
           inter-area and inter-AS capable PCEs across area and AS
boundaries.

      This seem to suggest that the the information is leaned across AS
      boundary, which IGP based discovery wont do. I suggest to remove
      "across area and AS boundaries".

      Also the section heading doesn't match the text, I think we
      can make this section "Inter-area and Inter-AS Capable PCE
      Discovery".

   Section 4.3
      The heading "Domain Meshes" seem to suggest a mesh between
      domains, but the text seem to focus on the topology within
      domain.

   Section 4.4
      OLD
           Whenever an specific connectivity service is required to have 1+1
           protection feature, two completely disjoint paths must be
           established on an end to end fashion. In a multi-domain
environment
           without, this can be accomplished either by selecting domain
           diversity, or by ensuring diverse connection within a domain. In
           order to compute the route diversity, it could be helpful to have
           SRLG information in the domains.
      NEW
           Whenever an specific connectivity service is required to have 1+1
           protection feature, two completely disjoint paths must be
           established in an end to end fashion. In a multi-domain
environment,
           this can be accomplished either by selecting domain diversity, or
by
           ensuring diverse connection within a domain. The domain diversity
           ensures diversity in the transit domain, the diverse path should
           be computed within the ingress and egress domain. In order to
compute
           the path diversity, it could be helpful to also have SRLG
information
           in the domains.

   Section 4.5
      Should we also mention the capability for Synchronized
      domain diverse path computation?

   Section 5.1.1
      - Repeated text from Section 5 can be removed.
      - [draft-ietf-pce-pcep-domain-sequence] added include or
      exclude area itself.

   Section 6.1.1
      Better description in section 6.1.3 (of the same title), this
      can be removed.

   Section 6.2
      Add reference to RFC4216

   Section 6.3
      Can this text be made more crisp?
      - backup can be computed after primary or at the same time
      - not sure about "PCE protection and redundancy" in this context?
      - s/patch computation/batch computation/

   Section 7.1
      - Inter-as connectivity can be populated via [RFC5392] and
      [RFC5316].
      - In last para, I am not sure about the relationship between
      boundary node in TED and selecting the next PCE in the path?

   Section 7.2
      Can this be made '7.1.1' to indicate "Provisioning Techniques"
      relates to TED?

   Section 7.5
      Why is per-domain [RFC5152] considered in this section?

   Section 7.6
      RFC 6805 doesn't mention discovery of parent/child PCE? Only
      static configuration is defined there.

   Section 12.1
      The text is currently from RFC6805, with focus on "across AS"
      and "aggregation". Perhaps this can be updated a bit to include
      the use of BGP-LS in the context of PCE servers.

   Section 13.1, 13.2
      Text relevant to specific inter-as and inter-area considerations
      can be added.

   Section 14
      We can add some more details regarding
      - PCEP over TCP [RFC6952]
      - Support for TCP-AO [RFC5925] and [PCEPS]

Editorial -
***********
   Expand on first use -
      - Autonomous System (AS)
      - Operational Support System (OSS)

   Section 1
      - s/used to discovery the/used to discover the/

   Section 1.1
      - [Extra space] "area ( as per [RFC4726]"
      - Suggested rewording avoiding "route computation" and clarifying
      that small topologies refer to number of domains.
      OLD:
        It is assumed that the PCE architecture should only be applied
        to small inter-domain topologies and not to solve route
        computation issues across large groups of domains, i.e. the
        entire Internet.
      NEW:
        It is assumed that the PCE architecture is not applied to
        a large group of domains, such as Internet.

   Section 1.2.1
      OLD
         The PCC-PCE capability awareness can
         configured using static configuration or by listening to the
         periodic advertisements generated by PCEs.
      NEW
         The PCC-PCE capability awareness can be
         configured using static configurations or by automatic and
         dynamic PCE discovery procedures.

      Regarding the last para

           A PCE may cooperate with other PCEs to determine intermediate
loose
           hops. End-to-end path segments may be kept confidential through
the
           application of path keys, to protect partial or full path
           information. A path key that is a token that replaces a path
segment
           in an explicit route. The path key mechanism is described in
           [RFC5520]

      Since this paragraph is about path keys, I see the first statement
      about loose hops to be misplaced. The path keys were introduced
      as alternate to loose hope signaling.

   Section 2
      - The term CSPF not used in the document, can be removed

   Section 3.2
      s/else the receiving PCE PCC will be/
       /else the receiving PCE or PCC will be/

   Section 4.6
      Last sentence -
      s/IGP area or an Autonomous Systems./
       /IGP area or a 4-Byte AS number./

   Section 5.1.3
      Add H-PCE [RFC6805] in last sentence.

   Section 7.4
      s/Otherwise, BRPC [RFC5441] will be used./
       /Otherwise, BRPC [RFC5441] or HPCE [RFC6805] will be used./

   Section 9
      s/PCEP P2MP procedures defined in [RFC7334]./
       /inter-domain P2MP procedures defined in [RFC7334]./

   Section 11
      s/delegated/requested/
      - as delegation has a different meaning in stateful PCE


******

Thank You! Apologies for taking some time with this promised review.

Regards,
Dhruv