Re: [Pce] PCE Applicability to ACTN

[Dhruv Dhody <[e-mail]>]

Hi Avantika,

I am forwarding the mail with your review comments to the PCE List as well

Hi WG,

We have update the document.

Name:           draft-dhody-pce-applicability-actn
Revision:       01
Title:          Applicability of Path Computation Element (PCE) for Abstraction and Control of TE Networks (ACTN)
Document date:  2016-10-19
Group:          Individual Submission
Pages:          15
URL:            https://www.ietf.org/internet-drafts/draft-dhody-pce-applicability-actn-01.txt
Status:         https://datatracker.ietf.org/doc/draft-dhody-pce-applicability-actn/
Htmlized:       https://tools.ietf.org/html/draft-dhody-pce-applicability-actn-01
Diff:           https://www.ietf.org/rfcdiff?url2=draft-dhody-pce-applicability-actn-01

The main changes are


-          Resolution of comments from Avantika

-          Comments received at mic, notably from Jon

n  Added text to highlight that not all functions need to be implemented in PCEP

   It should be noted that, in this document we list all possible ways

   in which PCEP could be used for each of the above functions, but all

   functions are not required to be implemented via PCEP.  Operator may

   choose to use the PCEP for multi domain coordination via stateful

   H-PCE but use RestConf or BGP-LS to get the topology and support

   virtualization/abstraction function.



n  Added section on Relationship to PCE based central control

Thanks!
Comments are welcome!

Regards,
Dhruv (Young & Daniele)

From: Dhruv Dhody
Sent: 18 October 2016 11:46
To: Avantika <[e-mail]>; Satish Karunanithi <[e-mail]>
Cc: Leeyoung <[e-mail]>; Dhruv Dhody <[e-mail]>
Subject: RE: PCE Applicability to ACTN

Thanks for your comments, updated in document.

See inline...

From: Avantika
Sent: 19 July 2016 10:12
To: Dhruv Dhody <[e-mail]<mailto:[e-mail]>>; Satish Karunanithi <[e-mail]<mailto:[e-mail]>>
Subject: RE: PCE Applicability to ACTN

Hi Dhruv,

I have few suggestions:

1.
   <t><xref target="I-D.ietf-pce-stateful-pce"/> also describes the active stateful PCE.
   The active PCE functionality allows a PCE to reroute an existing
   LSP or make changes to the attributes of an existing LSP, or delegate
   control of specific LSPs to a new PCE.</t>

   <t><xref target="I-D.ietf-pce-stateful-pce"/> also describes the active stateful PCE.
   The active PCE functionality allows a PCE to reroute an existing
   LSP or make changes to the attributes of an existing LSP, or PCC to delegate
   control of specific LSPs to a new PCE.</t>

2.
   <t>This document examines the PCE and ACTN architecture and describes how the PCE architecture
   is applicable to ACTN. It also list the PCEP extensions that are needed to use PCEP as an ACTN interface.
   This documents also identify any gaps in PCEP, that exist at the time of publication of this document.</t>
   </section>

   <t>This document examines the PCE and ACTN architecture and describes how the PCE architecture
   is applicable to ACTN. It also lists the PCEP extensions that are needed to use PCEP as an ACTN interface.
   This documents also identifies any gaps in PCEP, that exist at the time of publication of this document.</t>
   </section>

3.
   <xref target="I-D.dhodylee-pce-stateful-hpce"/>, for inter-domain LSP in
   Hierarchical PCE architecture, the initiation
   operations can be carried out at the parent PCE.  In which case after
   parent PCE finishes the E2E path computation, it can send the
   PCInitiate message to the child PCE, the PCE
   further propagates the initiate request to the PCC.</t>
   <t></t>

   <xref target="I-D.dhodylee-pce-stateful-hpce"/>, for inter-domain LSP in
   Hierarchical PCE architecture, the initiation
   operations can be carried out at the parent PCE.  In which case after
   parent PCE finishes the E2E path computation, it can send the
   PCInitiate message to the child PCEs, the child PCEs
   further propagate the initiate requests to the PCCs.</t>
   <t></t>

4.
The PNC (or child PCE) uses PCEP to communicate to
the network device already.
Do you mean: "The PNC (or child PCE) already uses PCEP to communicate to
the network device."

5.

This could as simple as a domain topology map as described
    in <xref target="RFC6805"/> or it can have full topology information of all
domains.

This could be as simple as a domain topology map as described
    in <xref target="RFC6805"/> or it can have full topology information of all
    domains.

6.
The latter is not scalable and thus an abstracted topology of each domain
interconnected by inter-domain links is the most common case.

Is there also a problem of confidentiality in the latter?
[Dhruv] Yes but I wanted to avoid confidentiality from the text here and highlight scalability only as in ACTN we assume trusted domain.

7.    <list style="symbols">
        <t>Topology Change: When the PNC learns of any topology change, the PNC needs
        to decide if the change needs to be notified to the MDSC. This is dependent on
        the level abstraction between the MDSC and the PNC.</t>
        </list>
</t>

    <list style="symbols">
        <t>Topology Change: When the PNC learns of any topology change, the PNC needs
        to decide if the change needs to be notified to the MDSC. This is dependent on
        the level of abstraction between the MDSC and the PNC.</t>
        </list>
    </t>

8.    <t>VN Instantiate: MDSC is requested to instantiate a VN, the minimal information
    that is required would be a VN identifier, a set of end points. Various path
    computation and setup constraints and objective functions may also be provided.
In PCE terms, a VN Instantiate can be considered as a set of Path belonging to the same VN.

    <t>VN Instantiate: MDSC is requested to instantiate a VN, the minimal information
    that is required would be a VN identifier and a set of end points. Various path
    computation and, setup constraints and objective functions may also be provided.
    In PCE terms, a VN Instantiate can be considered as a set of Path paths belonging to the same VN.

9.        <t>Per Domain Path Instantiation: Based on the above path computation, MDSC
        can issue the path instantiation request to each PNC via PCInitiate message (see <xref target="I-D.dhodylee-pce-stateful-hpce"/>
        and <xref target="I-D.leedhody-pce-vn-association"/>). The message from MDSC to PNC can contain a partial path, in which case the PNC
        computes the full path in the domain.

Do we need to handle in text the cases in which MDSC given path is different from the path computed by PNC? (may be based on timing issue or maybe because abstraction makes two paths same to MDSC but PNC can make finer distinction (I am very confident if second case is permitted in abstraction principles..))
[Dhruv]: I added this text instead -

In case PNC generates an abstract topology to the MDSC, the PCInitiate/PCUpd messages from the
   MDSC to a PNC will contain a path with abstract nodes and links. PNC would need to take that as an
   input for path computation to get a path with physical nodes and links. Similarly PNC would convert
   the path received from the device (with physical nodes and links) into abstract path (based on the
   abstract topology generated before with abstract nodes and links) and reported to the MDSC.

10. Is there a need to add text for E2E (parent LSP) MBB handling?
[Dhruv]: I have added -

This should be done in make-before-break fashion.

I am shying away from putting more details right now.

Regards,
Avantika


From: Dhruv Dhody
Sent: 04 July 2016 11:07
To: Satish Karunanithi; Udayasree palle; Avantika
Subject: FW: PCE Applicability to ACTN

Please provide comments....

From: Dhruv Dhody
Sent: 04 July 2016 11:05
To: Leeyoung <[e-mail]<mailto:[e-mail]>>; [e-mail]<mailto:[e-mail]>
Cc: Dhruv Dhody ([e-mail]<mailto:[e-mail]>) ([e-mail]<mailto:[e-mail]>) <[e-mail]<mailto:[e-mail]>>
Subject: PCE Applicability to ACTN

Hi,

I have written the draft version for this document. Please provide comments or directly make changes in the xml/txt.
Please forward to anyone else who you think can help...

Thanks!

Regards,
Dhruv