Hi Adrian
Sorry for the delay. Thanks again for the carefully considered feedback. I've
trimmed out points below where I agreed and no comment was necessary. Please
find answers and clarifications below.
---
Section 3
o An ordered set of IP address(es) representing network nodes/links:
In this case, the PCC needs to convert the IP address(es) into the
corresponding MPLS labels by consulting its Traffic Engineering
Database (TED).
But I am surprised that this work is offloaded to the PCC since the PCE has all
the information to do this task. Why did the WG want to add this option?
And then...
o An ordered set of SID(s)
s/SID(s)/SIDs/
This list of SIDs would need to be converted to labels by the PCC by applying
the SRGB offsets. Again, why make the PCC do this?
And finally...
o An ordered set of both MPLS label(s) and IP address(es): In this
case, the PCC needs to convert the IP address(es) into the
corresponding SID(s) by consulting its TED.
This mixture of the previous two cases seems to compound the level of
complexity. Can't the PCE just know it is making an SR path and supply a list
of MPLS labels corresponding to the SIDs?
[Jon] Having consulted the authors, the reason is that different PCE
implementations have different approaches, which can all be accommodated fairly
straightforwardly in the draft's format. Having said that, it seems harsh to
force the PCC into having to provide an NAI-resolution service for the PCE.
Therefore, I have added a capability flag so that the PCC can indicate that it
cannot / will not do NAI resolution. [/Jon]
---
5.1.2 ----> 6
If a PCEP speaker receives a PATH-SETUP-TYPE-CAPABILITY TLV with a
PST list containing PST=1, but the SR-PCE-CAPABILITY sub-TLV is
absent, then the PCEP speaker MUST send a PCErr message with Error-
Type 10 (Reception of an invalid object) and Error-Value TBD1 (to be
assigned by IANA) (Missing PCE-SR-CAPABILITY sub-TLV) and MUST then
close the PCEP session.
Suppose an implementation receives an Open with PST=1 but doesn't understand
(or doesn't support) that value. Is it still required to perform this check?
Hopefully not.
[Jon] Nope. Have changed to
If a PCEP speaker receives a PATH-SETUP-TYPE-CAPABILITY TLV with a
PST list containing PST=1, and supports that path setup type, then it
checks for the presence of the SR-PCE-CAPABILITY sub-TLV. If that sub-TLV is
absent, then the PCEP speaker MUST send a PCErr message with Error-
Type 10 (Reception of an invalid object) and Error-Value TBD1 (to be
assigned by IANA) (Missing PCE-SR-CAPABILITY sub-TLV) and MUST then
close the PCEP session.
[/Jon]
---
5.3.1 (under Length) has
As mentioned earlier, an SR-ERO
subobject MUST have at least SID or NAI.
This is good and does tie in with what is written in earlier sections.
However, 5.3.1 starts with
An SR-ERO subobject consists of a 32-bit header followed by the SID
and the NAI associated with the SID. The SID is a 32-bit number.
The size of the NAI depends on its respective type, as described in
the following sections.
That makes it sound like they are both mandatory, and the figure doesn't help.
A little rewording would go a long way, and you could add "(optional)"
to the figure.
[Jon] I have modified the preamble to the following, and have added the word
"optional" to the diagram.
An SR-ERO subobject consists of a 32-bit header followed by the SID
and/or the NAI associated with the SID. The SID is a 32-bit number.
The size of the NAI depends on its respective type, as described in
the following sections. At least one of the SID and the NAI MUST be
included in the SR-ERO subobject, and both MAY be included.
[/Jon]
---
5.3.1
SID Type (ST) indicates the type of information associated with the
SID contained in the object body. When ST value is 0, SID MUST
NOT be null and NAI MUST be null.
Does "null" mean "all zeros" or "absent"?
See also the definition of the S and F flags.
[Jon] It means "absent" (see definition of Length field). But this is not
particularly clear, so I have changed all instances of "null" to "absent".
[/Jon]
---
5.3.1
Other ST values are described
later in this document.
It would be friendly to provide a list somewhere.
Do you need a registry?
[Jon] I have added a list and created a registry. [/Jon]
---
5.3.1
Flags is used to carry any additional information pertaining to SID.
You need to say how to set the unused bits.
Do you need a registry?
[Jon] I have created a registry. [/Jon]
---
5.3.3
If a PCC receives a stack of SR-ERO subobjects, and the number of
stack exceeds the maximum number of SIDs that the PCC can impose on
the packet, it MAY send a PCErr message with Error-Type = 10
("Reception of an invalid object") and Error-Value = 3 ("Unsupported
number of Segment ERO subobjects").
And if it doesn't send the PCErr, what should it do?
[Jon] I think this has to be a MUST, not a MAY. [/Jon]
---
5.3.3
When a PCEP speaker detects that all subobjects of ERO are not
identical, and if it does not handle such ERO, it MUST send a PCErr
message with Error-Type = 10 ("Reception of an invalid object") and
Error-Value = 5 ("Non-identical ERO subobjects").
"Not identical" could have so many meanings here!
- Presumably you don't mean that all SIDs have the same value
- You might be referring to all flags
- You might be referring to just the M and C flags
- You might mean that the ERO must contain all SR-ERO subobjects or
no SR-ERO subobjects
Please clarify and possibly rename the error value.
[Jon] It means the last of those. Renamed the error to "ERO mixes SR-ERO
subobjects with other subobject types".
It also means you can't mix labels, SID index values and pure NAI. I've added
that check too.[/Jon]
(See also 5.4.1).
[Jon] "RRO mixes SR-RRO subobjects with other subobject types" [/Jon]
---
5.3.3
When a PCEP speaker receives an SR-ERO subobject in which ST is 0,
SID MUST be present and NAI MUST NOT be present(i.e., S-flag MUST be
0, F-flag MUST be 1, and the Length MUST be 8). Otherwise, it MUST
consider the entire ERO object invalid and send a PCErr message with
Error-Type = 10 ("Reception of an invalid object") and Error-Value =
11 ("Malformed object"). The PCEP speaker MAY include the malformed
SR-ERO object in the PCErr message as well.
This text is good.
But it makes me think: what about the ST values 1 through 5 if the NAI is
absent?
[Jon] I've generally tightened this area up and have hopefully covered all
invalid cases! [/Jon]
> -----Original Message-----
> From: Pce [mailto:[email protected]] On Behalf Of Julien Meuric
> Sent: 15 January 2018 09:38
> To: [email protected]
> Subject: [Pce] WG Last Call for draft-ietf-pce-segment-routing-11
>
> Dear PCE WG,
>
> Best wishes for this new year, full of interoperable specifications.
> Let us begin by resuming our work in progress.
>
> This message starts a 2-week WG last call for
> draft-ietf-pce-segment-routing-11. Please send your feedback on the
> I-D to the PCE mailing list by Monday January 29.
_______________________________________________
Pce mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/pce
_______________________________________________
Pce mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/pce
