Re: [Pce] WG adoption poll for draft-dugeon-pce-stateful-interdomain-04

[[e-mail]]

Hello Adrian,

Thanks a lot for your thorough review and your suggestion.

We'll incorporate all of them. I just have a comment about the text with the proposed figure: as it describe the Backward Recursive method, I think it will preferable inverse order of explanation for point 3 i.e. start by domain C, then domain B and end with domain A.

Regards,

Olivier, on behalf of the authors

PS. Sorry for the late answer, my initial reply got stuck in the outbox.

Le 22/12/2020 à 14:37, Adrian Farrel a écrit :
> Hi,
>
> I've reviewed this draft and I think it is ready for adoption because
> the functionality (i.e., stitching segments without inter-domain
> signaling which means that path-key cannot be used) is valuable.
>
> There are a number of editorial comments below. I think they do not 
> need to be addressed before adoption, but I hope the authors will factor
> them into a new revision after adoption.
>
> Thanks,
> Adrian
>
> ===
>
> Need to update Young Lee's coordinates
>
> ---
>
> Abstract
>
> I think that BRPC or H-PCE are methods to achieve inter-domain paths
> not methods to be combined with inter-domain paths. How about...
> OLD
>    This document specifies how to combine a Backward Recursive or
>    Hierarchical method with inter-domain paths in the context of
>    stateful Path Computation Element (PCE).
> NEW
>    This document specifies how to use a Backward Recursive or
>    Hierarchical method to derive inter-domain paths in the context of
>    stateful Path Computation Element (PCE).
> END
>
> ---
>
> Abstract
>
> "It relies on..." comes in the sentence immediately after "This
> document..."  I think you need to be more precise. Probably
>
> s/It relies on/The mechanism relies on/
>
> ---
>
> Abstract
>
> s/enables to operate them/enables them to be operated/
>
> ---
>
> Abstract
>
>    A new Stitching Label is defined, new Path
>    Setup Types, a new Association Type and a new PCEP communication
>    Protocol (PCEP) Capability are considered for that purpose.
>
> I can't parse this. Possibly...
>
>    For this purpose, this document defines a new Stitching Label, new
>    Path Setup Types, new Association Type, and a new PCEP communication
>    Protocol (PCEP) Capability.
>
> ---
>
> The requirement language should be moved into section 1.2
>
> ---
>
> Introduction
>
> There is a *lot* of text in the Introduction. I wonder whether we need
> so much. Does every PCE document have to start with the whole history of
> PCE?
>
> I tried to boil down what this document is really about:
>
> - PCE is used to compute paths from MPLS-TE, GMPLS, and SR
> - Various mechanisms can be used to enable PCEs to cooperate to compute
>   inter-domain paths including BRPC and H-PCE
> - MPLS-TE and GMPLS depend on signaling using RSVP-TE to set up paths,
>   but it is not common to allow signaling across administrative domain
>   borders.
> - SR depends on a stack of segment identifiers, but in an inter-domain
>   path, this stack may become large, and detailed control of a path
>   within one domain by packets originating in another domain might not 
>   be supported.
> - This document describes a mechanism whereby the paths across each 
>   domain remain under the control of those domains, and the paths are
>   stitched together at domain boundaries to form a single end-to-end
>   path.
> - The mechanism relies on cooperating PCEs to determine the end-to-end
>   path with each PCE responsible for computing and initiating the paths
>   within its domain. The PCEs are assumed to be stateful active PCEs so
>   that they can instruct their networks to set up the paths. 
> - Signaling (for MPLS-TE and GMPLS) is used only within individual
>   domains.
> - Specific labels/SIDs are used to indicate which path segments should
>   be stitched together.
> - To enable this mechanism, this document defines a new Stitching
>   Label, new Path Setup Types, new Association Type, and a new PCEP
>   communication Protocol (PCEP) Capability.
>
> I think that can be converted into text that is a little easier to read
> than the current Introduction.
>
> ---
>
> 1.1
>
> s/end-o-end/end-to-end/
>
> ---
>
> I think it would be helpful to have a figure that shows the solution 
> architecture in more detail than that currently in section 1.1.  Nothing
> wrong with that figure, but we also need to see the LSPs/SR-paths and
> where the signaling stops and how the label/SID on the inter-domain link
> is used. Also, how the PCEs talk to the various nodes.
>                                          
> Something like the figure below would allow the descriptive text that
> follows.
>
>     --------------           --------------           --------------
>    |Domain-A      |         |Domain-B      |         |Domain-C      |
>    |              |         |              |         |              |
>    |     PCE------+--PCEP---+---PCE--------+--PCEP---+---PCE        |
>    |    /         |         |  /           |         |  /           |
>    |   /          |         | /            |         | /            |
>    | Src=========BNA-------BNB1===========BNB2------BNC=========Dst |
>    |              |  Inter- |              |  Inter- |              |
>     --------------   Domain  --------------   Domain  --------------
>                      Link                     Link
>
>
>    1. The PCEs in Domain-A, Domain-B, and Domain-C communicate using
>       PCEP either directly, as shown, using BRPC or with a parent PCE
>       if using BRPC.
>    2. The PCE in Domain-A selects an end-to-end domain path. It tells
>       the PCE in Domain-B that the path will be used, and that PCE
>       passes the information on to the PCE in Domain-C.
>    3. Each of the PCEs use PCEP to instruct the segment head ends.
>       a. In Domain-A, the PCE instructs the Source node with the path
>          to use to reach Border Node, BNA.  The instructions also 
>          include the label or SID to use on the inter-domain link to
>          BNB1.
>       b. In Domain-B, the PCE instructs the ingress Border Node, BNB1,
>          with the path to reach the egress Border Node, BNB2.  The
>          instructions also tell BNB1 the incoming label or SID that
>          will be stitched to the intra-domain path, and the label or
>          SID to use on the inter-domain link to BNC.
>       c. In Domain-C, the PCE instructs the ingress Border Node, BNC,
>          with the path to reach the Destination.  The instructions also
>          tell BNC the incoming label or SID that will be stitched to the
>          intra-domain path.
>
> -----Original Message-----
> From: Pce <[e-mail]> On Behalf Of Dhruv Dhody
> Sent: 18 December 2020 12:52
> To: [e-mail]
> Cc: pce-chairs <[e-mail]>
> Subject: [Pce] WG adoption poll for draft-dugeon-pce-stateful-interdomain-04
>
> Hi WG,
>
> This email begins the WG adoption poll for
> draft-dugeon-pce-stateful-interdomain-04.
>
> https://datatracker.ietf.org/doc/html/draft-dugeon-pce-stateful-interdomain-
> 04
>
> Should this draft be adopted by the PCE WG? Please state your reasons
> - Why / Why not? What needs to be fixed before or after adoption? Are
> you willing to work on this draft? Review comments should be posted to
> the list.
>
> To accommodate for the holiday season, this adoption poll will end on
> 11th Jan 2021 (Monday).
>
> Thanks!
> Dhruv
>
> _______________________________________________
> Pce mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/pce
>
> _______________________________________________
> Pce mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/pce
>
-- 
Orange logo <http://www.orange.com>

 

Olivier Dugeon
Orange Expert, Future Networks
Open Source Referent
Orange/IMT/OLN/WTC/IEE/iTeQ

 

fixe : [phone]
mobile : [phone]
[e-mail] <mailto:[e-mail]>


_________________________________________________________________________________________________________________________

Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.

This message and its attachments may contain confidential or privileged information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.
Thank you.