Hi Alvaro
I'm sorry that it has taken longer than I thought to reply to your comments!
Please find our replies below. I will post an updated version of the document
as soon as I can.
Many thanks
Jon
--
DISCUSS:
--
I am balloting DISCUSS because I think that there are some technical and
clarity issues that makes understanding, and potentially implementing this
document hard. I also want to discuss the "backwards compatibility" and the
use of TLVs as sub-TLVs in PCEP as introduced in this document.
(1) MSD Definition. The MSD may be learned from a variety of sources,
including the SR-PCE-CAPABILITY sub-TLV defined in this document. It is
important then for the MSD to be defined consistently everywhere. Please use
the BMI-MSD definition from rfc8491.
[Jon] Happy to change this. This draft actually pre-dates RFC 8491, but now
the definition has moved there, we can point to it.
(2) Ability to signal the MSD per link, not just per node. Clearly the
calculation of paths through specific links (using an Adjacency SID, for
example) would require that information (if different/lower from what the node
may support).
Note that §6.1 seems to assume that the MSD will normally be advertised through
different mechanisms, and it uses that to work around the fact that there's no
link-specific information: "Furthermore, whenever a PCE learns the MSD for a
link via different means, it MUST use that value for that link regardless of
the MSD value exchanged in the SR-PCE-CAPABILITY sub-TLV." However, the text
doesn't mandate the IGP/BGP-LS information to be available to the PCE. IOW, as
written, the specification can't guarantee the proper calculation of paths that
require the PCE to consider link MSDs.
[Jon] In many deployments we anticipate that link MSDs are homogeneous. In
those cases, link state routing might not distribute per-link MSDs (e.g.
routers might not even support RFC 8491). In such cases, the per-node MSD on
the PCEP session is sufficient. All the draft says is that MSD information
available from link state routing, if any, must take priority over that defined
on the PCEP session. I don't see a problem with that.
(3) Extensibility to advertise other MSD-Types. [This point is not
DISCUSS-worthy, but I'm including it here since I'm already talking about the
MSD.]
rfc8491 (aka I-D.ietf-isis-segment-routing-msd) and
I-D.ietf-ospf-segment-routing-msd encode the MSD advertisement as a pair:
MSD-Type and MSD-Value, with the expectation that "new MSD-Types will be
defined to signal additional capabilities, e.g., entropy labels, SIDs that can
be imposed through recirculation, or SIDs associated with another data plane
such as IPv6." IOW, the encoding is reusable with other dataplanes. I peeked
into draft-negi-pce-segment-routing-ipv6 [*] and i don't see anything in there
that couldn't be signaled using the SR-PCE-CAPABILITY sub-TLV defined here (+
the MSD_Value). I think this is important for consistency.
[*] I realize that draft-negi-pce-segment-routing-ipv6 is not even a WG
document, but it is the only potential reference I found to what a different
dataplane might look line.
[Jon] This document (and the SR-PCE-CAPABILITY) is scoped to MPLS only. I
believe that draft-negi defines its own SRV6-PCE-CAPABILITY TLV and I don't see
any reference to MSD in it, but if a new MSD type is needed for other dataplane
types, I think it's expected that a new SR capability TLV will be defined to
convey it. I don't expect to generalize the SR-PCE-CAPABILITY TLV.
Note that the MSD in the SR-PCE-CAPABILITY is a BMI-MSD. Although RFC 8491
defines a generic MSD container, the MSD in this document is specifically a
BMI-MSD.
(4) §6.2.2 (Interpreting the SR-ERO):
o If the subobjects contain NAI only, then the PCC first converts
each NAI into a SID index value by looking it up in its local
database, and then proceeds as above.
I believe that this step in the interpretation of the SR-ERO is not properly
specified.
Which "local database" are you referring to? §6.2.2.1 mentions the SR-DB (when
talking about errors)...but the specification should be clear about which
database and what the specific procedure is.
[Jon] You are right, this should be more explicit. How about this.
NEW
If the subobjects contain NAI only, the PCC first converts
each NAI into a SID index value and then proceeds as above.
To convert an NAI to a SID index, the PCC looks for a fully-specified
prefix or adjacency matching the fields in the NAI. If the PCC finds
a matching prefix/adjacency, and the matching prefix/adjacency has a SID
associated
with it, then the PCC uses that SID. If the PCC cannot find a
matching prefix/adjacency, or if the matching prefix/adjacency has no SID
associated
with it, the PCC behaves as
