Subject: Re: [Pce] Shepherd's Review of draft-ietf-pce-pce-initiated-lsp-07

From: Jonathan Hardwick <[email-masked]>
Date: Tue, 16 Aug 2016 16:02:37 +0000

Hi Julien

During this email, I'm wearing my "segment routing co-author" hat :-)

I agree that END-POINTS is not necessarily congruent with RSVP signalling addresses, but I don't agree with the part of the proposed amendment that says that this object should not be used for segment-routed LSPs.  As you said, the intent of END-POINTS is to give the two points to be interconnected by the LSP.  In segment routing, where there is no confusion with RSVP signalling addresses, it is useful for the PCC to have this object available.  The PCC needs this information in order to use the LSP, and having to derive it from the ERO would be more difficult for implementers.

I'd prefer not to say anything about the use of END-POINTS in segment routing in this draft.  We can discuss its use in draft-ietf-pce-segment-routing.  Is that OK?

Best regards
Jon

-----Original Message-----
From: Pce [mailto:[email-masked]] On Behalf Of Julien Meuric
Sent: 29 July 2016 10:16
To: [email-masked]
Cc: [email-masked]
Subject: [Pce] Shepherd's Review of draft-ietf-pce-pce-initiated-lsp-07

Dear authors of draft-ietf-pce-pce-initiated-lsp,

Please find below my shepherd's review of the aforementioned I-D.

_Summary_

The document does not need much work to move forward. As discussed with Ina during the IETF week, a few items deserve to be highlighted:
- the choice of zero as wildcard PLSP-ID to remove all LSPs initiated by a PCE is unsafe;
- the use of the END-POINTS object is misaligned with RFC 5440's definition and not suited to SR.

_Detailed Comments_
------
Header
---
- Like with draft-ietf-pce-stateful-pce, adding "Individual Contributor" 
after Ed's name helps getting rid of the odd empty line.
------
Abstract
---
- s/provide stateful control/provide active control/
------
Section 1.
---
- s/Path Computation Element Protocol PCEP/Path Computation Element communication Protocol (PCEP)/
------
Section 3.
---
- s/provides stateful control/provides active control/
- s/is one of a software-driven/is a software-driven/
- s/is one of dynamically/is dynamically/
- s/is that of demand/is demand/
- s/Operation overview/Operation Overview/
- s/PCE provisioned/PCE-provisioned/
- s/it also generates/it MUST also generate/
- s/PCC also sets/PCC MUST also set/
- s/PCE may update/PCE MAY update/
- s/PCC initiated LSPs/PCC-initiated LSPs/
------
Section 4.
---
- s/PCE provisioned/PCE-provisioned/
------
Section 5.
---
- s/LSP instantiation and deletion/LSP Instantiation and Deletion/
- OLD:
A Path Computation LSP Initiate Message (also referred to as PCInitiate
message) is a PCEP message...
   NEW:
A Path Computation LSP Initiate Message is referred to as PCInitiate
message: it is a PCEP message...

- s/and may contain/and MAY contain/
- OLD :
If the SRP object is missing, the PCC MUST send a PCErr with error-type
6 (Mandatory Object missing) and error-value=10 (SRP Object missing) (per [I-D.ietf-pce-stateful-pce]. If the LSP object is missing, the PCC MUST send a PCErr with error-type 6 (Mandatory Object missing) and
error-value=8 (LSP Object missing) (per [I-D.ietf-pce-stateful-pce]).
   NEW:
Missing SRP and LSP objects in PCInitiate MUST trigger the same PCErr procedures as specified in [I-D.ietf-pce-stateful-pce] for PCUpd.

- s/<END-POINTS>/[<END-POINTS>]/  (see discussion below)
- s/5.3. LSP instantiation/5.3. LSP Instantiation/
- s/LSP Initiate Message/PCInitiate message/
- s/results in a PCErr/MUST result in a PCErr/

- The use of the END-POINTS objects has puzzled me for multiple reasons:
  * RFC 5440 defines the object as a pair of IDs allowing to identify the two points to be interconnected by the ERO to be filled in, whereas the draft uses it to push the IDs of the signaling ends;
  * The signaling source ID to be used should rather be up to the PCC, the requirement on pushing it from the PCE is not obvious;
  * The ERO may include some IDs that could be used as default source/destination IDs, which also makes the need for a destination ID less obvious;
  * To address these, I see 3 options:
   1- Giving up the use of a specific object and fully rely on the ERO;
   2- Defining new "SignalingRemoteID" types (possibly within the END-POINTS object class) to (optionally) convey the info;
   3- Rephrase the text to turn the unwanted "redefinition" of the END-POINTS object into a wording more consistent with RFC 5440, e.g.:
OLD:
    The END-POINTS Object is mandatory for an instantiation request of an
    RSVP-signaled LSP.  It contains the source and destination addresses
    for provisioning the LSP.  If the END-POINTS Object is missing, the
    PCC MUST send a PCErr message with Error-type=6 (Mandatory Object
    missing) and Error-value=3 (END-POINTS Object missing).
NEW:
    For an instantiation request of an RSVP-signaled LSP, the destination
    address may be needed. The PCC may determine it from a provided object
    (e.g., ERO) or a local decision. Alternatively, the END-POINTS object
    MAY be included to explicitly convey the destination addresses to be
    used in the RSVP-TE signaling. The source address may be either
    specified or left up to the PCC decision using the 0.0.0.0 value. For
    LSPs to be setup by other means (e.g., Segment Routing), the END-POINTS
    object SHOULD be omitted.

  * In case you go for option 2, you still need to be more explicit on the non-RSVP case; i.e., the new text should say: "The <OBJECT_NAME> MAY be included for instantiation request of an RSVP-TE-signaled LSP, and SHOULD be omitted otherwise."

- s/echo the SRP-id-number/echo the SRP-ID-number/
- The 2nd paragraph on page 11 ("On succesful completion...") duplicates the 2nd one on page 10 ("The PCE MAY include...") and should be dropped (or at least the 2nd half of it).
- s/succesful completion/successful completion/
- s/5.3.1. The Create flag/5.3.1. The Create Flag/
- On Figure 3, the "O" would be better in the middle of the 3-bit field.
- Once defined, the phrases "Create flag"/"C Flag"/"C-flag" are alternatively used, please pick one and use it everywhere (I personally like "C-flag" but "R flag" seems common in the I-D). Note that flag-phrases should be consistent beyond C.
- s/the PCE who initiated/the PCE which initiated/
- s/5.4. LSP deletion/5.4. LSP Deletion/
- "A PLSP-ID of zero removes all LSPs...": a broken implementation is very likely to use 0 as a default, any value but 0 would be safer; please pick another one.
- s/value 1 ([I-D.ietf-pce-stateful-pce <https://tools.ietf.org/html/draft-ietf-pce-pce-initiated-lsp-07#ref-I-D.ietf-pce-stateful-pce>])/value
1 as per [I-D.ietf-pce-stateful-pce
<https://tools.ietf.org/html/draft-ietf-pce-pce-initiated-lsp-07#ref-I-D.ietf-pce-stateful-pce>])/
- s/The R flag [...] SHOULD be set./The R flag [...] MUST be set./ [or with "R-flag" ?]
------
Section 6.
---
- s/LSP delegation and cleanup/LSP Delegation and Cleanup/
- s/must have the delegation bit/MUST have the delegation bit/
- OLD:
    Receipt of a
    PCInitiate message with a non-zero PLSP-ID normally results in the
    generation of a PCErr.  If the LSP is an orphan, the PCC MUST NOT
    generate an error and MUST redelegate the LSP to the PCE.
   NEW:
    On receipt of PCInitiate message with a PLSP-ID pointing to  an
    orphan LSP, the PCC MUST redelegate that LSP to the PCE. Any
    other non-zero PLSP-ID MUST result in the generation of a PCErr.
------
Section 7.
---
- s/7. Implementation status/7. Implementation Status/
------
Section 8.
---
- s/8. IANA considerations/8. IANA Considerations/
------
Section 11.
---
- The reference to draft-ietf-pce-stateful-sync-optimizations is not required to understand this document and should thus be moved to the informative section.
- Ditto for RFC 5226 (guidelines for authors, not mandatory to readers).
------

Cheers,

Julien

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

---

From: Julien Meuric <[email-masked]>
Date: Thu, 18 Aug 2016 10:59:37 +0200

Hi Jon,

Thank you for this "segment routing"-focused feedback.

I fully agree with deferring detailed specification for segment routing 
to another document. The discussed I-D should just:
- be clear on the RSVP-TE case,
- cover a default case (i.e. non-RSVP), with a flexible definition.

This would turn the latest sentence of my proposed paragraph below into:
"For LSPs to be setup by other means, the END-POINTS object SHOULD/MAY 
be omitted; the exact behavior for other types of LSPs will be specified 
in further documents."

Would that address your concern?

Cheers,

Julien

---

From: Jonathan Hardwick <[email-masked]>
Date: Thu, 18 Aug 2016 09:01:44 +0000

Hi Julien,

That would be great, thanks.

Cheers
Jon

-----Original Message-----
From: Julien Meuric [mailto:[email-masked]] 
Sent: 18 August 2016 10:00
To: Jonathan Hardwick <[email-masked]>
Cc: [email-masked]; [email-masked]
Subject: Re: [Pce] Shepherd's Review of draft-ietf-pce-pce-initiated-lsp-07

Hi Jon,

I fully agree with deferring detailed specification for segment routing to another document. The discussed I-D should just:
- be clear on the RSVP-TE case,
- cover a default case (i.e. non-RSVP), with a flexible definition.

This would turn the latest sentence of my proposed paragraph below into:
"For LSPs to be setup by other means, the END-POINTS object SHOULD/MAY be omitted; the exact behavior for other types of LSPs will be specified in further documents."

Cheers,

Julien

Aug. 16, 2016 - [email-masked]:
> 6 (Mandatory Object missing) and error-value=10 (SRP Object missing) 
> (per [I-D.ietf-pce-stateful-pce]. If the LSP object is missing, the 
> PCC MUST send a PCErr with error-type 6 (Mandatory Object missing) and
> - s/value 1 ([I-D.ietf-pce-stateful-pce 
> <https://tools.ietf.org/html/draft-ietf-pce-pce-initiated-lsp-07#ref-I
> -D.ietf-pce-stateful-pce>])/value