[Pce] 2 flags in draft-ietf-pce-binding-label-sid
Hi WG, draft-ietf-pce-binding-label-sid defines 2 flags in TE-PATH-BINDING TLV - o S-Flag: This flag encodes the "Specified-BSID-only" behavior. It is used as described in Section 6.2.3 of [I-D.ietf-spring-segment-routing-policy]. o I-Flag: This flag encodes the "Drop Upon Invalid" behavior. It is used as described in Section 8.2 of [I-D.ietf-spring-segment-routing-policy]. Adrian pointed out that this would make draft-ietf-spring-segment-routing-policy a normative reference. Also that the handling of these flags is not discussed further in this I-D and seems to be applicable only with respect to the SR policy. The change suggested is to have no flags defined in this I-D and a code point registry created for the future. Cheng suggested moving these flags to the SR Policy I-D draft-ietf-pce-segment-routing-policy-cp. This would simply move the content from one WG I-D to another and should not have any technical issue. Are there any concerns with this approach? Thanks! Dhruv ___ Pce mailing list Pce@ietf.org https://www.ietf.org/mailman/listinfo/pce
Re: [Pce] WG Last Call for draft-ietf-pce-binding-label-sid-07 (and Code Point Allocation)
Thanks again for your help! Cheng -Original Message- From: Stone, Andrew (Nokia - CA/Ottawa) [mailto:andrew.st...@nokia.com] Sent: Saturday, March 27, 2021 2:42 AM To: Chengli (Cheng Li) ; julien.meu...@orange.com; pce@ietf.org Cc: draft-ietf-pce-binding-label-...@ietf.org Subject: Re: [Pce] WG Last Call for draft-ietf-pce-binding-label-sid-07 (and Code Point Allocation) Hi Cheng, Thanks for clarifying the text in the document. Diff content looks good to me, much clearer. Consider my comments resolved. Thanks! Andrew On 2021-03-25, 10:49 PM, "Pce on behalf of Chengli (Cheng Li)" wrote: Hi Andrew, Thanks for your comments, please see my reply inline. Also, the diff is attached. Respect, Cheng -Original Message- From: Stone, Andrew (Nokia - CA/Ottawa) [mailto:andrew.st...@nokia.com] Sent: Saturday, March 20, 2021 4:21 AM To: julien.meu...@orange.com; pce@ietf.org Cc: draft-ietf-pce-binding-label-...@ietf.org Subject: Re: [Pce] WG Last Call for draft-ietf-pce-binding-label-sid-07 (and Code Point Allocation) 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. [Cheng] You are correct, there was some issues with multiple TE-PATH-BINDING TLV. This has been updated. See the diff. The above text has been updated to - The absence of TE-PATH-BINDING TLV in PCUpd message means that the PCE does not specify a binding value in which case any previous allocated binding values are withdraw. Further, the PCC's local policy aspect has been seperated out as - In the absence of any instruction from the PCE, the PCC's local policy dictates how the binding allocations are made for a given LSP. Thanks! Thanks! Andrew On 2021-03-18, 7:09 AM, "Pce 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 re
Re: [Pce] WG Last Call for draft-ietf-pce-binding-label-sid-07 (and Code Point Allocation)
Hi Cheng, Thanks for clarifying the text in the document. Diff content looks good to me, much clearer. Consider my comments resolved. Thanks! Andrew On 2021-03-25, 10:49 PM, "Pce on behalf of Chengli (Cheng Li)" wrote: Hi Andrew, Thanks for your comments, please see my reply inline. Also, the diff is attached. Respect, Cheng -Original Message- From: Stone, Andrew (Nokia - CA/Ottawa) [mailto:andrew.st...@nokia.com] Sent: Saturday, March 20, 2021 4:21 AM To: julien.meu...@orange.com; pce@ietf.org Cc: draft-ietf-pce-binding-label-...@ietf.org Subject: Re: [Pce] WG Last Call for draft-ietf-pce-binding-label-sid-07 (and Code Point Allocation) 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. [Cheng] You are correct, there was some issues with multiple TE-PATH-BINDING TLV. This has been updated. See the diff. The above text has been updated to - The absence of TE-PATH-BINDING TLV in PCUpd message means that the PCE does not specify a binding value in which case any previous allocated binding values are withdraw. Further, the PCC's local policy aspect has been seperated out as - In the absence of any instruction from the PCE, the PCC's local policy dictates how the binding allocations are made for a given LSP. Thanks! Thanks! Andrew On 2021-03-18, 7:09 AM, "Pce 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 protec
Re: [Pce] Early code point allocation for draft-ietf-pce-segment-routing-policy-cp
Hi all, After discussing with Tom and the authors, we believe that a reasonable way to progress this early allocation is to postpone the allocation of the error codes. We'll proceed accordingly. Enjoy the week-end, Dhruv & Julien On 01/02/2021 11:54, julien.meu...@orange.com wrote: > Hi WG, > > We have received a request from the authors of > draft-ietf-pce-segment-routing-policy-cp for an early code point allocation. > > 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 Monday, February 15th, we will kick off > the early allocation request. > > Thanks! > > Dhruv & Julien > > > > ___ > Pce mailing list > Pce@ietf.org > https://www.ietf.org/mailman/listinfo/pce smime.p7s Description: S/MIME Cryptographic Signature ___ Pce mailing list Pce@ietf.org https://www.ietf.org/mailman/listinfo/pce
Re: [Pce] WG Last Call for draft-ietf-pce-binding-label-sid-07 (and Code Point Allocation)
Hi Tom, As agreed with the authors, we'll proceed with the early allocation request by leaving the error codes pending upcoming updates (i.e. request allocation for PCEP TLV and LSP object flags). This will leave you some time to find an agreement on the final wording of the error messages. Thank you for your careful review, Dhruv & Julien On 22/03/2021 13:14, tom petch wrote: > > I am unclear how much is being requested of IANA here but .. > > s.11.1.1 starts the registry at zero which is consistent with the rest of the > I-D. Is there any need to reserve the value of zero as something special? > Probably not but something to consider > > TBD4 and TBD5 have almost identical Error-value which I think unhelpful. The > wording should be more distinctive IMHO. If this is part of the Early > Allocation request, then it is better to fix it now rather than getting into > IANA in this form. Perhaps > 'Unable to amend the.. > 'Unable to allocate a.. > And along with TBD2 and TBD6, as in my separate e-mail, I find 'Binding > label/SID' clumsy and would prefer a replacement such as 'Binding value' > > Tom Petch smime.p7s Description: S/MIME Cryptographic Signature ___ Pce mailing list Pce@ietf.org https://www.ietf.org/mailman/listinfo/pce
Re: [Pce] WG Last Call for draft-ietf-pce-binding-label-sid-07 (and Code Point Allocation)
Hi Cheng! This is good progress, thanks. I have cut down to the points that are still open. Nothing we need to fight about 😊 Best, Adrian >> == Questions / Issues == >> >> 3. >> >> o BT = 0: The binding value is an MPLS label carried in the format >> specified in [RFC5462] where only the label value is valid, and >> other fields MUST be considered invalid. The Length MUST be set >> to 7. >> >> I don't think that RFC 5462 is the right reference. That document simply >> renames a field in the MPLS label stack entry. >> >> So, are you carrying an MPLS label or an MPLS label stack entry? Either >> is possible, although since you're only interested in the label, it might be >> more normal to carry just the label value in the least significant 20 bits >> of the binding value field. That would be consistent with a Length of 7. >> >> But, if you want to carry the full label stack entry (with the other fields >> ignored) then perhaps... >> o BT = 0: The binding value is an MPLS label carried in an MPLS >> label stack entry format as specified in [RFC3032] where only the >> label value is valid, and other fields MUST be ignored. The >> Length MUST be set to 8. >> >> This would be more consistent with: >> o BT = 1: Similar to the case where BT is 0 except that all the >> fields on the MPLS label entry are set on transmission. However, >> the receiver MAY choose to override TC, S, and TTL values >> according its local policy. The Length MUST be set to 8. >> But here you may want a little more clarity as: >> o BT = 1: Similar to the case where BT is 0 except that all the >> fields of the MPLS label stack entry are set on transmission of >> the PCEP message containing the TLV. A PCC receiver of this TLV >> in a PCEP message MAY choose to override TC, S, and TTL values >> according its local policy. The Length MUST be set to 8. >> >> But, at the bottom of the section... >> For the BT as 0, the 20 bits represent the MPLS >> label. For the BT as 1, the 32-bits represent the label stack entry >> as per [RFC5462]. >> Which is going back on itself (and using the wrong reference). >> >> Just make a decision on the meaning of BT=0 and make the text clean. > > [Cheng] How about this - > > o BT = 0: The binding value is a 20-bit MPLS label value. The TLV > is padded to 4-bytes alignment. The Length MUST be set to 7 and > first 20 bits are used to encode the MPLS label value. > > o BT = 1: The binding value is a 32-bit MPLS label stack entry as > per [RFC3032] with Label, TC [RFC5462], S, and TTL values encoded. > Note that the receiver MAY choose to override TC, S, and TTL > values according to its local policy. The Length MUST be set to 8. OK. This is clear. I think you just need to look through the other mentions of BT=0 and BT=1 to make sure they match with this. >> 3. >> >> I'm a bit puzzled as to why this document defines two flags for the Path >> Binding TLV >> Flags field, when this document clearly doesn't use or depend on them. >> >> In order to not make [I-D.ietf-spring-segment-routing-policy] a normative >> reference, perhaps >> you should not mention the specific bits, create the registry (in 11.1.1) as >> empty, and simply >> not that [I-D.ietf-spring-segment-routing-policy] defines some flags. >> >> (Obviously, [I-D.ietf-spring-segment-routing-policy] will need to make >> assignments from >> the registry.) > > [Cheng] The idea was to make it consistent with IDR WG I-D > [draft-ietf-idr-segment-routing- > te-policy]. > One option could be to move this to the SR-policy-related PCE WG I-D > [draft-ietf-pce-segment- > routing-policy-cp]. > I have kept this open for now for further discussion. To be clear, I was suggesting: - this document creates and defines the registry - the documents that need codepoints are responsible for requesting allocation of codepoints >> 4. >> >> 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. >> >> If one of these contains a bad value, and a PCErr is sent according to the >> previous >> paragraph, what happens to all the other Binding Values? >> Are they used or discarded? > > [Cheng] They should not be impacted. I have added this - > > In case of multiple TE-PATH-BINDING TLVs, all > instances of TE-PATH-BINDING TLVs MUST always be included in the LSP > object. In case of an error, a PCErr message MAY include the > offending TE-PATH-BINDING TLV in the PCEP-ERROR object. I think maybe I wasn't clear. Suppose the LSP object contains three TE-PATH-BINDING TLVs (TLV1, TLV2, and TLV3) Suppose that TLV3 contains a bad value. That means a PCErr will be sent with PCEP-ERROR and that MAY contain the offending TLV3. OK so far. Now, what happens to TLV1 and TLV2? Are they processed and used by the receiver? Or Are
[Pce] I-D Action: draft-ietf-pce-pcep-extension-native-ip-13.txt
A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Path Computation Element WG of the IETF. Title : PCEP Extension for Native IP Network Authors : Aijun Wang Boris Khasanov Sheng Fang Ren Tan Chun Zhu Filename: draft-ietf-pce-pcep-extension-native-ip-13.txt Pages : 29 Date: 2021-03-26 Abstract: This document defines the Path Computation Element Communication Protocol (PCEP) extension for Central Control Dynamic Routing (CCDR) based application in Native IP network. The scenario and framework of CCDR in native IP is described in [RFC8735] and [I-D.ietf-teas-pce-native-ip]. This draft describes the key information that is transferred between Path Computation Element (PCE) and Path Computation Clients (PCC) to accomplish the End to End (E2E) traffic assurance in Native IP network under central control mode. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-pce-pcep-extension-native-ip/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-pce-pcep-extension-native-ip-13 https://datatracker.ietf.org/doc/html/draft-ietf-pce-pcep-extension-native-ip-13 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-pce-pcep-extension-native-ip-13 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ ___ Pce mailing list Pce@ietf.org https://www.ietf.org/mailman/listinfo/pce
Re: [Pce] draft-hsd-pce-sr-p2mp-policy wiki comments and action.
Hi Hooman, With my chair hat off and speaking as a WG participant. Thanks for explaining your point of view and the history. The PCEP stateful messages are currently being used for - - LSP operations (LSP instruction/reports to/from head end i.e. stateful PCE) - PCECC operations (generic instructions/reports to/from any node) You say- In addition the replication segment is in “NO WAY” part of an LSP or a P2MP > LSP or a static P2MP LSP, it is an individual segment (like a binding SID) > programed at a strategic node for sole purpose of replication. You agree that it is not an LSP operation but you don't consider it PCECC either! You would like to use the encoding that matches with the P2P LSP operations for the replication segment. Since you mentioned binding SID, in PCEP, it is a property of the LSP. It is encoded in a TLV inside the LSP Object. Even when the binding segment is used on a strategic internal node it is for an LSP with the strategic node as the head-end from PCEP's point of view. Regarding the question of why CCI Object, as I mentioned earlier, we could have instantiated a static PCECC LSP as a one-hop LSP along the path without a new object. The approach that the WG took was to define a new CCI Object instead, as the scope of PCECC was bigger and we wanted to have the freedom to encode various types of instructions (which can be unrelated to LSP operations). For example SR/SRv6 SID programming, Native-IP, etc. This has been helpful IMHO. And replication segment fits here well. You say - Consistency is great as long as the solution and the implementation does > not get complicated and there are obvious benefits to it. The solution is > achievable without CCI object, the CCI object and encoding will be there > wrapping ERO for no purpose at all. I agree that your solution is achievable without using a CCI object but disagree that adding a CCI object Type would make it complicated. Moreover to me, it is a PCECC operation (but I-D does not refer to it in any way and that is confusing). Coming back to the question to the WG -- Is the act of programming replication segment to a replication node and the leaves, a PCECC operation (we seem to agree that it is not an LSP operation)? And should we use a new CCI Object type to encode it or not? Thanks! Dhruv (as a WG participant/still chair hat off) On Wed, Mar 24, 2021 at 8:49 AM Bidgoli, Hooman (Nokia - CA/Ottawa) < hooman.bidg...@nokia.com> wrote: > Hi Aijun > > > > Thanks you for your comments. > > > > Inline > > > > Regards > > Hooman > > > > *From:* Aijun Wang > *Sent:* Tuesday, March 23, 2021 3:01 AM > *To:* 'Dhruv Dhody' ; Bidgoli, Hooman (Nokia - > CA/Ottawa) > *Cc:* pce@ietf.org > *Subject:* RE: [Pce] draft-hsd-pce-sr-p2mp-policy wiki comments and > action. > > > > Hi, > > > > My consideration is that if the solution depends on the distribution > protocol among the underlay nodes to accomplish the task, then PCE should > follow the procedures described in RFC8231, RFC8281 etc. That is to say, in > such situation, the instruction from the PCE needs only to be sent to the > headend of the path. > > HB> no underlay distribution for replication SID, as it is not a P2MP LSP. > Replication SID is an individual resource, that can be programmed at > strategical node for sole purpose of replication. It can be stitched > together via unicast SR. Traffic can be steered out of each OIF via unicast > Node/Adjacency SID. > > And, if the solution depends solely on the computation of the PCE, and PCE > should interact not only the headend node, but also the transit node, > tail-end node, follow the PCECC approach is more clear. > > Mixed of these two solutions should be avoided. > > HB> Agreed that the 2 concept can’t be mixed. A bit of history, my > apologies for repetition here: > > 1.We did look at PCECC and our first implementation and first > draft was based on PCECC and CCI object. We found CCI object for > replication SID to be cumbersome, it made the solution much more > complicated then what it needed to be. The perfect examples are: the FRR > protection path, with CCI the protection path had to be downloaded with > every single OIF making the message much larger. In addition for an > incoming label and set of outgoing OIF, the CCI solution forced the > download of the incoming label and the outgoing OIFs/Labels in order with > in a message, making the ordering of the labels and the OIFs very > complicated. In short we tried to use the CCI object and it did not fit > nicely. Hence why we looked at the ERO object with multipath backup TLV for > protection. In addition the replication segment is in “NO WAY” part of an > LSP or a P2MP LSP or a static P2MP LSP, it is an individual segment (like a > binding SID) programed at a strategic node for sole purpose of replication. > > 2.I think above point is driven home. The next suggestion was > why not wrap the ERO in CCI object. This is where the authors/co-authors
Re: [Pce] WG Last Call for draft-ietf-pce-binding-label-sid-07 (and Code Point Allocation)
To all, The latest diff of BSID draft is https://tools.ietf.org/rfcdiff?url1=https://www.ietf.org/archive/id/draft-ietf-pce-binding-label-sid-07.txt&url2=https://raw.githubusercontent.com/dhruvdhody/ietf/master/draft-ietf-pce-binding-label-sid-08.txt Sorry for using the wrong diff file. Thanks, Cheng -Original Message- From: Pce [mailto:pce-boun...@ietf.org] On Behalf Of Chengli (Cheng Li) Sent: Friday, March 26, 2021 10:46 AM To: Aijun Wang ; julien.meu...@orange.com; pce@ietf.org Cc: draft-ietf-pce-binding-label-...@ietf.org Subject: Re: [Pce] WG Last Call for draft-ietf-pce-binding-label-sid-07 (and Code Point Allocation) Hi Aijun, Many thanks for your comments! Please see my reply inline. The diff is attached. Respect, Cheng -Original Message- From: Aijun Wang [mailto:wangai...@tsinghua.org.cn] Sent: Monday, March 22, 2021 11:57 AM To: julien.meu...@orange.com; pce@ietf.org Cc: draft-ietf-pce-binding-label-...@ietf.org Subject: RE: [Pce] WG Last Call for draft-ietf-pce-binding-label-sid-07 (and Code Point Allocation) Hi, 1. The concept of PCC requests the allocating of BSID for a LSP is clear, but the scenario that PCE allocate the BSID is not convincible. PCE can request the PCC to allocate the BSID for one LSP. It should not allocate the value directly. [Cheng]Section 8 is optionally used when PCE is in control of label space (PCECC) and would not be used for vanilla stateful PCE. 2. What's the reason to include the BT=3, that is "SRv6 Endpoint Behavior and SID Structure"? It is one general information and not close connection to the normal usage of BSID. [Cheng] This is an alignment with other SIDs. In order to support backward compatibility, we want to remain BT2, and introduce a new BT for support SID structure. It can be used for future use case. 3. Will it be more clear to define one new bit(R bit) within the Flag field of "TE-PATH-BINDING TLV" to indicate clearly the remove of BSID allocation to a LSP? Instead of the implicit method that depending on the presence of TE-PATH-BINDING TLV as described in current draft? [Cheng] It is possible. But there are existing implementations that would get impacted. 4. For BT=0, the length is set to 7. How to skip the padding trailing zeros to a 4-octet boundary when parsing? [Cheng] We have updated the description of BT=0 as per Adrian's comment. Length=7 and handling of padding is as per RFC5440: The Length field defines the length of the value portion in bytes. The TLV is padded to 4-bytes alignment; padding is not included in the Length field (so a 3-byte value would have a length of 3, but the total size of the TLV would be 8 bytes). Best Regards Aijun Wang China Telecom -Original Message- From: pce-boun...@ietf.org On Behalf Of julien.meu...@orange.com Sent: Thursday, March 18, 2021 7:09 PM To: pce@ietf.org Cc: draft-ietf-pce-binding-label-...@ietf.org Subject: [Pce] WG Last Call for draft-ietf-pce-binding-label-sid-07 (and Code Point Allocation) 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 em
