Subject: [Pce] I-D Action: draft-ietf-pce-segment-routing-12.txt

From: [email-masked]
Date: Fri, 29 Jun 2018 10:19:44 -0700

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Path Computation Element WG of the IETF.

        Title           : PCEP Extensions for Segment Routing
        Authors         : Siva Sivabalan
                          Clarence Filsfils
                          Jeff Tantsura
                          Wim Henderickx
                          Jon Hardwick
	Filename        : draft-ietf-pce-segment-routing-12.txt
	Pages           : 32
	Date            : 2018-06-29

Abstract:
   Segment Routing (SR) enables any head-end node to select any path
   without relying on a hop-by-hop signaling technique (e.g., LDP or
   RSVP-TE).  It depends only on "segments" that are advertised by Link-
   State Interior Gateway Protocols (IGPs).  A Segment Routed Path can
   be derived from a variety of mechanisms, including an IGP Shortest
   Path Tree (SPT), explicit configuration, or a Path Computation
   Element (PCE).  This document specifies extensions to the Path
   Computation Element Protocol (PCEP) that allow a stateful PCE to
   compute and initiate Traffic Engineering (TE) paths, as well as a PCC
   to request a path subject to certain constraints and optimization
   criteria in SR networks.

The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-pce-segment-routing/

There are also htmlized versions available at:
https://tools.ietf.org/html/draft-ietf-pce-segment-routing-12
https://datatracker.ietf.org/doc/html/draft-ietf-pce-segment-routing-12

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-pce-segment-routing-12

Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

---

From: Jonathan Hardwick <[email-masked]>
Date: Fri, 29 Jun 2018 17:22:08 +0000

This new version addresses the feedback received during working group last call.  My apologies for the long delay.
Many thanks to those who took the time to review and comment on this.  The result is that the draft has been substantially tightened and many ambiguities resolved.
I will be replying to the individual commenters today.

Best regards
Jon

-----Original Message-----
From: Pce [mailto:[email-masked]] On Behalf Of [email-masked]
Sent: 29 June 2018 18:20
To: [email-masked]
Cc: [email-masked]
Subject: [Pce] I-D Action: draft-ietf-pce-segment-routing-12.txt

Abstract:

Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org.

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

---

From: "Aissaoui, Mustapha (Nokia - CA/Ottawa)" <[email-masked]>
Date: Fri, 29 Jun 2018 18:18:35 +0000

Hi Jon,
There is one issue which I would like to discuss and it came up during the EANTC multi-vendor interop in March 2018.

The rule for handling MSD in Section 5.5 seems to be overly restrictive. The MSD value advertised in the Open message is useful as an upper bound for both pce-initiated LSP and pcc-initiated LSP. However, PCC may want to set a MSD value for a specific pcc-initiated LSP which is lower than that in the Open Object. The rules in Section 5.5 do not allow that as the presence of the MSD Metric object in the path request message is errored if a non-zero MSD was included in the Open message. If on the other hand you set the MSD in the Open message to zero, PCE will not discover the MSD to enforce for pce-initiated LSP.

What I would like to propose is to relax the rule such that a path request is only errored when the MSD Metric value is higher than that in the Open message. That way we can achieve the desired behavior for both pce-initiated and pcc-initiated LSP.

Here is the relevant paragraph in Section 5.5:
"
   If a PCEP session is established with a non-zero MSD value, then the
   PCC MUST NOT send an MSD METRIC object.  If the PCE receives a path
   computation request with an MSD METRIC object on a session with a
   non-zero MSD value then it MUST consider the request invalid and send
   a PCErr with Error-Type = 10 ("Reception of an invalid object") and
   Error-Value 9 ("Default MSD is specified for the PCEP session").
"

Mustapha.

-----Original Message-----
From: Pce [mailto:[email-masked]] On Behalf Of Jonathan Hardwick
Sent: Friday, June 29, 2018 1:22 PM
To: [email-masked]
Subject: [Pce] FW: I-D Action: draft-ietf-pce-segment-routing-12.txt

Best regards
Jon

-----Original Message-----
From: Pce [mailto:[email-masked]] On Behalf Of [email-masked]
Sent: 29 June 2018 18:20
To: [email-masked]
Cc: [email-masked]
Subject: [Pce] I-D Action: draft-ietf-pce-segment-routing-12.txt

Abstract: