Hi all,
Overall Support WGLC. It's an important document in the world of SRTE, and the
document goes to good lengths to describe the various scenarios and
combinations.
Only one question I have for the authors and WG, for any further clarification
on the following text (section 4):
The absence of TE-PATH-BINDING TLV in PCUpd message
means that the PCE does not specify a binding value in which case the
binding value allocation is governed by the PCC's local policy.
I find the "governed by PCC local policy" a bit too vague and could lead to
implementation interop differences. Assuming a PCInitiated LSP that been
established with a BSID: If the PCE wants to withdraw the binding SID , I
interpret the document as the PCE would send a PCUpdate without the TLV, but
the behaviour is now up to PCC as per that text. if the PCC local
policy/implementation is to do nothing, how can the PCE explicitly force-remove
the BSID with a PCUpdate? In a similar manner, If the PCE does not want to
change the value but PCC local policy is to treat missing TLV as remove, then
PCE should always send the TLV in every PCUpdate (which I'm okay with) which is
not stated, otherwise the local policy/implementation may interpret it as a
removal compared to an implementation which may interpret it as being okay to
not send the TLV on every PCUpdate since there was "no change".
In summary: might need a bit of a wording to further detail "PCE wishes to
withdraw" case.
Thanks!
Andrew
On 2021-03-18, 7:09 AM, "Pce on behalf of julien.meu...@orange.com"
<pce-boun...@ietf.org on behalf of julien.meu...@orange.com> wrote:
Hi all,
This message initiates a 2-week PCE WG Last Call for
draft-ietf-pce-binding-label-sid-07. Please review and share your
feedback, whatever it is, using the PCE mailing list. This WGLC will end
on Thursday April 1st (no kidding).
Moreover, we have received a request from the authors for a code point
allocation to support interoperability testing.
RFC 7120 requires to meet the following criteria to proceed:
b. The format, semantics, processing, and other rules related to
handling the protocol entities defined by the code points
(henceforth called "specifications") must be adequately described
in an Internet-Draft.
c. The specifications of these code points must be stable; i.e., if
there is a change, implementations based on the earlier and later
specifications must be seamlessly interoperable.
If anyone believes that the draft does not meet these criteria, or
believes that early allocation is not appropriate for any other
reason, please send an email to the PCE mailing list explaining why. If
the chairs hear no objections by Thursday, March 25th, we will kick off
the "early" allocation request.
Thanks,
Dhruv & Julien
_________________________________________________________________________________________________________________________
Ce message et ses pieces jointes peuvent contenir des informations
confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu
ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages
electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou
falsifie. Merci.
This message and its attachments may contain confidential or privileged
information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and
delete this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been
modified, changed or falsified.
Thank you.
_______________________________________________
Pce mailing list
Pce@ietf.org
https://www.ietf.org/mailman/listinfo/pce
_______________________________________________
Pce mailing list
Pce@ietf.org
https://www.ietf.org/mailman/listinfo/pce
