Hi Martin and Dhruv,
Sorry for my delay due to the Lunar tiger new year, and many thanks to Dhruv
for your help!
I have updated the draft according to the recent discussion in the mailing list.
Hope it can address your comments:
Respect,
Cheng
There is also an htmlized version available at:
https://datatracker.ietf.org/doc/html/draft-ietf-pce-binding-label-sid-13
A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-pce-binding-label-sid-13
-----邮件原件-----
发件人: Dhruv Dhody [mailto:[email protected]]
发送时间: 2022年2月1日 21:09
收件人: Martin Vigoureux <[email protected]>
抄送: The IESG <[email protected]>; [email protected]; pce-chairs
<[email protected]>; [email protected]; Julien Meuric <[email protected]>
主题: Re: Martin Vigoureux's Discuss on draft-ietf-pce-binding-label-sid-12:
(with DISCUSS and COMMENT)
Hi Martin,
Considering Cheng would be busy celebrating the Lunar new year (and the year of
the tiger), let me take a stab at your comments.
On Tue, Feb 1, 2022 at 4:06 PM Martin Vigoureux via Datatracker
<[email protected]> wrote:
Martin Vigoureux has entered the following ballot position for
draft-ietf-pce-binding-label-sid-12: Discuss
When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut
this introductory paragraph, however.)
Please refer to
https://www.ietf.org/blog/handling-iesg-ballot-positions/
for more information about how to handle DISCUSS and COMMENT positions.
The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-pce-binding-label-sid/
----------------------------------------------------------------------
DISCUSS:
----------------------------------------------------------------------
Hi,
thank you for this document.
I have few points I'd like to discuss. Some might simply arise from my
limited knowledge/expertise in pce. Thank you for your understanding.
Section 5 is confusing to me. In my understanding, from a PCE
perspective, an LSP can be in three different situations: state
synched with PCE, delegated to PCE, or initiated by PCE. However,
maybe not all the text applies to the three cases. So, I wonder
whether organizing this section along the lines of what can be done
and not done depending on the situations would help. At least, one key
aspect which is not clear to me is whether the binding value is an attribute
over which control (change/remove) is given to pce in case of delegation.
Dhruv: Regarding the formating of section 5, it is common practice in PCE documents to list text
based on PCEP messages. The use of messages is dependent on the "situation" i.e. PCRpt
for passive; PCRpt & PCUpd for active; PCRpt, PCUpd, & PCInitiate for PCE-initiated.
Since the same message can be used for all, it makes sense to list the operations in terms of
messages.
Regarding delegation - Yes, if the LSP is delegated to PCE, PCE can
change/remove the binding using the PCUpd message. Note that as described in
RFC 8231, PCUpd is still a request from PCE to update and the PCC can always
reject it. The same holds true for binding value.
Also, I have the impression that there are "error" conditions which
are not
described:
* how should PCC react (regardless of whether it already has a binding
value) if it receives from PCE an empty TLV with R=1?
* how should PCC react if it receives from PCE a TLV with a binding
value (different from the one it has) with R=1?
Dhruv: Thanks for noticing these, I suggest adding -
If a PCC receives a PCUpd message with TE-PATH-BINDING TLV where the R flag is set to 1, but either
the binding value is missing (empty TE-PATH-BINDING TLV) or the binding value is incorrect, it MUST
send a PCErr message with Error-Type = TBD2 ("Binding label/SID failure") and Error Value
= TBD6 ("Unable to remove the binding value").
* how should PCC react if it receives from PCE a single TLV with a
binding value different from the one it has and with R=0?
Dhruv: The existing binding values which remain unchanged are optional to be
included. The text uses MAY for them. So in this case, the PCC would try to
allocate an additional binding value.
The draft seems silent about how to deal with multiple identical
TE-PATH-BINDING TLVs. Use any? Throw an error?
Dhruv: I guess use any. Do you suggest adding text for this? I am not sure if I
have seen such text in similar cases.
The draft allows multiple TE-PATH-BINDING TLVs to be sent but in my
view falls short to describe the associated expectations. Ultimately
the binding value is something that will end-up programmed in the
data-plane (or at least reserved in the control plane) but maybe not
all systems have the same capabilities in these domains. Since PCE
doesn't know these capabilities, I think, how should be handled the
situation where PCE requests N values but the node wants to -or
can- only use M (where M < N). Should an error be thrown back, or only
M values chosen and reported back?
Dhruv: In case the PCE sends N TE-PATH-BINDING TLVs in the message and the PCC
cannot allocate them all, the whole message is rejected with an error message.
Is the selection of the M values function of a local policy or should
they be the M first or last, or any other specific rule? These two
paragraphs could be viewed as giving elements of response to these
questions but it's not fully clear:
If a PCE requires a PCC to allocate a (or several) specific binding
value(s), it may do so by sending a PCUpd or PCInitiate message
containing a TE-PATH-BINDING TLV(s). If the value(s) can be
successfully allocated, the PCC reports the binding value(s) to the
PCE. If the PCC considers the binding value specified by the PCE
invalid, it MUST send a PCErr message with Error-Type = TBD2
("Binding label/SID failure") and Error Value = TBD3 ("Invalid SID").
If the binding value is valid, but the PCC is unable to allocate the
binding value, it MUST send a PCErr message with Error-Type = TBD2
("Binding label/SID failure") and Error Value = TBD4 ("Unable to
allocate the specified binding value"). Note that, in case of an
error, the PCC rejects the PCUpd or PCInitiate message in its
entirety and can include the offending TE-PATH-BINDING TLV in the
PCEP-ERROR object.
Dhruv: Since the whole message is rejected, we don't need to select the 'M'
values.
Is some text required here?
----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------
To implement the needed changes to PCEP, in this document, we
introduce a new OPTIONAL TLV that a PCC can use in order to report
the binding label/SID associated with a TE LSP, or a PCE to request a
PCC to allocate a specific binding label/SID value.
It can also request PCC to allocate a value of its own choosing (with
an empty TLV), correct?
Dhruv: Yes! s/a specific binding/any or a specific binding/
As another way to use the extension specified in this document, to
support the PCE-based central controller [RFC8283] operation where
the PCE would take responsibility for managing some part of the MPLS
label space for each of the routers that it controls, the PCE could
directly make the binding label/SID allocation and inform the PCC.
See Section 8 for details.
I am a bit sceptical about this and Section 8. This requires a
mechanism which is, as the draft says, specified nowhere.
Dhruv: RFC 9050 says this -
For the purpose of this document,
it is assumed that the exclusive label range to be used by a PCE is
known and set on both PCEP peers. A future extension could add the
capability to advertise this range via a possible PCEP extension as
well (see [PCE-ID]).
Maybe authors could repeat this in section 8.
If a PCE recognizes the TLV but does not support the TLV, it MUST
send a PCErr with Error-Type = 2 (Capability not supported).
Could you elaborate on what you mean by "does not support the TLV"?
For example the BT value? Also, could the following situation exist: a
node with some LSPs which can support a binding value and other which
can't. How is PCC supposed to react to a PCE request to allocate a
binding value on an LSP from the latter set?
Dhruv: Yes BT value can play a role. In general, in PCEP there is a distinction
made between unknown and (known but not supported). The reason for not being
supported could be many (including the feature is not enabled).
Regarding the situation you mention, PCC would send the error saying unable to
allocate using the existing error codes.
Multiple TE-PATH-BINDING TLVs are allowed to be present in the same
LSP object. This signifies the presence of multiple binding SIDs for
the given LSP. In the case of multiple TE-PATH-BINDING TLVs, the
existing instances of TE-PATH-BINDING TLVs MAY be included in the LSP
object.
Not sure what that last sentence means or adds compared to the previous ones.
Dhruv: The second sentence focus on the existing instances of TE-PATH-BINDING
which remains unchanged.
Thanks for a comprehensive review! Much appreciated.
Regards,
Dhruv
s/associted/associated/
