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

From: Dhruv Dhody <[email-masked]>
Date: Fri, 18 Dec 2020 18:22:19 +0530

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

---

From: Young Lee <[email-masked]>
Date: Sun, 20 Dec 2020 10:32:39 +0900

Support.

Thanks.
Young

2020년 12월 18일 (금) 오후 9:53, Dhruv Dhody <[email-masked]>님이 작성:

> _______________________________________________
> Pce mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/pce
>

---

From: "Adrian Farrel" <[email-masked]>
Date: Tue, 22 Dec 2020 13:37:07 -0000

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 <[email-masked]> On Behalf Of Dhruv Dhody
Sent: 18 December 2020 12:52
To: [email-masked]
Cc: pce-chairs <[email-masked]>
Subject: [Pce] WG adoption poll for draft-dugeon-pce-stateful-interdomain-04

Hi WG,

https://datatracker.ietf.org/doc/html/draft-dugeon-pce-stateful-interdomain-
04

Thanks!
Dhruv