Hi Dhruv
Thanks – I’ve applied these markups. See comments below (trimming all closed
issues).
I’ll post a new revision forthwith.
Cheers
Jon
[[Dhruv Dhody]] Thanks, regarding MSD something like –
The MSD (in OPEN message) discloses capabilities of the PCC (how many SIDs it
supports), which could provide an indication of the abilities of the PCC. This
information could be used to gain intelligence about devices in the network.
[Jon2] Thanks for the text – I have added something similar.
NEWER
o An ordered set of IP addresses representing network nodes/links.
o An ordered set of SID index values, with or without the corresponding IP
addresses.
o An ordered set of MPLS labels, with or without corresponding IP
address.
The PCC converts these into an MPLS label stack and next hop, as described
in section 6.2.2.
END NEWER
[[Dhruv Dhody]] In the WIP you sent you have - “An ordered set of MPLS labels
and IP addresses”. Let’s update it to what you have above!
[Jon2] Oops! Fixed it.
Suggestions:
**************
(1) In section 3, it says -
An PCE can update an LSP that is initially established via RSVP-TE
signaling to use an SR-TE path, by sending a PCUpd to the PCC that
delegated the LSP to it ([RFC8231]). Similarly, an LSP initially
created with an SR-TE path can be updated to use RSVP-TE signaling,
if necessary. This capability is useful when a network is migrated
from RSVP-TE to SR-TE technology.
We should also add text for LSPs that are not delegated and in control with
PCC, where PCC will trigger the migration and this should be reported to the
PCE via the PCRpt message.
[Jon] Not sure I understand… Are you saying that the PCC delegates the LSP and,
at the same time, requests the PCC to migrate the LSP? What should the PCC set
on the PCRpt to request a migration? I’m not sure if it makes sense, I would
expect migrations to be driven from the controller downwards, not individually
requested by the head-ends.
[[Dhruv Dhody]] Consider a LSP that was not delegated and control is at the
PCC. Via configuration the PCC is asked to migrate this to SR, the PCC could
via PCReq/PCRep gets a new path based on SR and installs it in the forwarding
and migrate to it. We would want a make-before-break like operations where via
PCRpt message(s) the new LSP (with PST=SR) is reported and the old LSP is
reported to be deleted.
Thus IMHO the migration could be triggered at the PCC via configuration too. In
section 8.2 we state that this is out of scope, but in section 3 it was
mentioned only in scope of PCUpd message, thus making me wonder if we should
also include the PCC triggered migration of LSP.
[Jon2] OK – got it. I have added “A PCC can update an undelegated LSP that is
initially established via RSVP-TE signaling to use an SR-TE path as follows.
First, it requests an SR-TE Path from a PCE by sending a PCReq message. If it
receives a suitable path, it establishes the path in the data plane, and then
tears down the original RSVP-TE path. If the PCE is stateful, then the PCC
sends PCRpt messages indicating that the new path is set up and the old path is
torn down, per [RFC8231].”
Another query NAI only SR-RRO is of no use. I think we should not allow that!!
[Jon] I think it could make sense e.g. as a list of router IDs that the LSP
visits. Personally, I think NAI-only overcomplicates the protocol in both ERO
and RRO, but given that we allow it in ERO, I don’t see a reason to ban it from
RRO.
[[Dhruv Dhody]] My point of view was that when NAI-only ERO is sent by the PCE,
the PCC needs to convert that into a viable SID-list based on its database. It
would make sense for the PCC to report this to the PCE in form of SR-RRO. Thus
it must contain the SID-index or label. Just returning the NAI-only to the PCE
may not be that useful. The PCC always needs SID to install in the data plane
and it is useful to report that to the PCE, thus I still feel we should not
allow NAI-only in SR-RRO!
But I can live with it if you do not wish to make this change.
[Jon2] I worry the change is destabilizing because it begs further (sensible)
questions like “do any fielded implementations do it?”, “is there any purpose
to having NAI in the RRO at all?” or “should we define a new format for SR-RRO
without the F and S bits?” Nobody has objected to the RRO format up to this
point. So I’m going to leave it in there for now unless I get more pushback
from the RTGDIR / ADs!
(7) Section 5.5, is METRIC object without bound allowed? I.e. a path
computation request to optimize MSD valid?
[Jon] Agree this would make sense if the PCC does not impose an MSD. Changed
the text to:
NEW
A PCC MAY request that PCE optimizes an individual path computation
request to minimize the SID depth of the computed path by 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.
If the PCC includes a METRIC object of this type on a path
computation request, then the PCE MUST minimize the SID depth of the
computed path. If the B (bound) bit is set to to 1 in the METRIC
object, then the PCE MUST NOT return a path whose SID depth exceeds
the given metric-value. If the PCC did not set the L bit in its SR-
PCE-CAPABILITY TLV, then it MUST set the B bit to 1. If the PCC set
the L bit in its SR-PCE-CAPABILITY TLV, then it MAY set the B bit to
zero, which indicates that the PCE should minimize the SID depth
without imposing an absolute maximum value.
END NEW
[[Dhruv Dhody]] This is good. But I am not sure about the relationship between
L bit (in TLV) and B bit (in METRIC). Though a PCC did not impose any limit on
MSD, it could still ask for a smaller SID stack (optimization)?
[Jon2] I have changed it to make it clearer, hopefully:
OLD
If the PCC set
the L bit in its SR-PCE-CAPABILITY TLV, then it MAY set the B bit to
zero, which indicates that the PCE should minimize the SID depth
without imposing an absolute maximum value.
NEW
If the PCC set
the L bit in its SR-PCE-CAPABILITY TLV, then it MAY set the B bit to
1 or zero.
END
(8) Section 6.2.1, it says -
If a PCC receives an SR-ERO subobject in which the S bit is set to
zero and the M bit is set to zero (that is, it represents an index
value), then the SID MUST be a node-SID, an adjacency-SID or a
binding-SID. If the SID is not one of these types, the PCC MUST send
a PCErr message with Error-Type = 10 ("Reception of an invalid
object") and Error Value = TBD10 ("Bad SID type in SR-ERO"). If the
SID is an Adjacency-SID then the L flag MUST NOT be set. If the L
flag is set for an Adjacency-SID then the PCC MUST send a PCErr
message with Error-Type = 10 ("Reception of an invalid object") and
Error-Value = 11 ("Malformed object").
Shouldn’t we just say that PCC should support the SID type and leave the door
open for any other SID type use for ex anycast SID or any other future SID type?
[Jon] What I was really thinking here was that it would be invalid to have a
prefix-SID in the list (unless it’s a node SID). I’ve reworded as follows:
NEW
If a PCC receives an SR-ERO subobject in which the S bit is set to
zero and the M bit is set to zero, then the subobject contains a SID
index value. If the SID is a prefix-SID but not a node-SID, then the
PCC MUST send a PCErr message with Error-Type = 10 ("Reception of an
invalid object") and Error Value = TBD9 ("Bad SID type in SR-ERO").
If the SID is an Adjacency-SID then the L flag MUST NOT be set. If
the L flag is set for an Adjacency-SID then the PCC MUST send a PCErr
message with Error-Type = 10 ("Reception of an invalid object") and
Error-Value = 11 ("Malformed object").
END NEW
[[Dhruv Dhody]] This is better but I feel we should not include the prefix SID
check. There are use-cases to include prefix SID as the bottom SID (Refer SR
policy draft)!
[Jon2] OK – I have retired the following text (and error code TBD9):
“If the SID is a prefix-SID but not a node-SID, then the
PCC MUST send a PCErr message with Error-Type = 10 ("Reception of an
invalid object") and Error Value = TBD9 ("Bad SID type in SR-ERO").
“
_______________________________________________
Pce mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/pce
