Hi Mustapha
Yes, I think we can do that. It's a small change and is backwards compatible.
I can update the draft when submissions re-open. Here is my proposal for the
revised section 5.5 text:
5.5. METRIC Object
A PCC MAY specify the MSD for an individual path computation request
using the METRIC object defined in [RFC5440]. This document defines
a new type for the METRIC object to be used for this purpose as
follows:
o T = 11: Maximum SID Depth of the requested path.
The PCC sets the metric-value to the MSD for this path. The PCC MUST
set the B (bound) bit to 1 in the METRIC object, which specifies that
the SID depth for the computed path MUST NOT exceed the metric-value.
If a PCEP session is established with a non-zero default MSD value, then the
PCC MUST NOT send an MSD METRIC object with an MSD greater than
the session's default MSD. If the PCE receives a path computation request
with an MSD METRIC object on a session which is greater than the session's
default MSD, then it MUST consider the request invalid and send
a PCErr with Error-Type = 10 ("Reception of an invalid object") and
Error-Value 9 ("MSD exceeds the default for the PCEP session").
Thanks
Jon
-----Original Message-----
From: Aissaoui, Mustapha (Nokia - CA/Ottawa)
[mailto:[email protected]]
Sent: 29 June 2018 19:19
To: Jonathan Hardwick <[email protected]>; [email protected]
Subject: RE: [Pce] FW: I-D Action: draft-ietf-pce-segment-routing-12.txt
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 protected]] On Behalf Of Jonathan Hardwick
Sent: Friday, June 29, 2018 1:22 PM
To: [email protected]
Subject: [Pce] FW: I-D Action: draft-ietf-pce-segment-routing-12.txt
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 protected]] On Behalf Of [email protected]
Sent: 29 June 2018 18:20
To: [email protected]
Cc: [email protected]
Subject: [Pce] I-D Action: draft-ietf-pce-segment-routing-12.txt
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/
_______________________________________________
Pce mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/pce
_______________________________________________
Pce mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/pce
_______________________________________________
Pce mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/pce
