Re: [Pce] WG Last Call for draft-ietf-pce-binding-label-sid-07 (and Code Point Allocation)
Many thanks Dhruv and Julien! I support the adoption and early allocation as a co-author. Luckily, before April 1st. Thank you for your work! Respect! Cheng -Original Message- From: julien.meu...@orange.com [mailto: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: 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 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
Re: [Pce] IPR Poll on draft-ietf-pce-binding-label-sid-07
Hi, I am not aware of any IPR applicable to this draft that should be disclosed in accordance with IETF IPR rules. Thanks. s. On Thu, Mar 18, 2021, 18:10 Hariharan Ananthakrishnan wrote: > Hi Authors, > > In preparation for WG Last Call on this draft, I'd like all > authors and contributors to confirm on the list that they are in compliance > with IETF IPR rules. > > Please respond (copying the mailing list) to say one of: > > I am not aware of any IPR applicable to this draft that should be disclosed > in accordance with IETF IPR rules. > > I am aware of the IPR applicable to this draft, and it has already been > disclosed to the IETF. > > I am aware of IPR applicable to this draft, but that has not yet been > disclosed to the IETF. I will work to ensure that it will be disclosed in a > timely manner. > > Thanks, > - Hari > > ___ Pce mailing list Pce@ietf.org https://www.ietf.org/mailman/listinfo/pce
[Pce] IPR Poll on draft-ietf-pce-binding-label-sid-07
Hi Authors, In preparation for WG Last Call on this draft, I'd like all authors and contributors to confirm on the list that they are in compliance with IETF IPR rules. Please respond (copying the mailing list) to say one of: I am not aware of any IPR applicable to this draft that should be disclosed in accordance with IETF IPR rules. I am aware of the IPR applicable to this draft, and it has already been disclosed to the IETF. I am aware of IPR applicable to this draft, but that has not yet been disclosed to the IETF. I will work to ensure that it will be disclosed in a timely manner. Thanks, - Hari ___ 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 Dhruv I am very confused by your messaging. Originally it was pointed out that the draft should follow PCECC/CCI. The authors explained why they feel that is not a good fit. Now you are mentioning get in part with RFC 8231, 8281 etc... which is a new input. Thank you. The authors/co-authors have tried to keep the draft in par with all the RFCs that you mentioned as much as possible. As it is mentioned in the draft clearly. That said this is new concept and there is a need for a new PCE concept and deviation, hence the draft and the purpose of IETF. RSVP-TE P2MP is built via S2Ls. Replication segment is nothing like S2L, replication segment can be connected via unicast SR. Again we are open for any constructive feedback on how this draft can be improved, in the boundary of https://datatracker.ietf.org/doc/draft-ietf-spring-sr-replication-segment/ https://datatracker.ietf.org/doc/draft-ietf-pim-sr-p2mp-policy/ Regards Hooman -Original Message- From: Pce On Behalf Of Dhruv Dhody Sent: Thursday, March 18, 2021 8:01 AM To: pce@ietf.org Subject: Re: [Pce] draft-hsd-pce-sr-p2mp-policy wiki comments and action. Hi, Speaking as a WG member... Let's continue the discussion on considering the replication segment as an LSP v/s PCECC operation. I just wanted to quickly recap - - We have stateful operations for RSVP-TE: RFC 8231, RFC 8281 - We then introduced SR with a minimal extension of new PST and a new SR-ERO subobject: RFC 8664 - We supported P2MP stateful operations for RSVP-TE with RBNF change in PCEP messages: RFC 8623 We have always tried our best to maintain consistency between RSVP-TE and SR in PCEP. Now, if one considers the Replication segment as an LSP operation, IMHO it needs to be built on RFC 8623 P2MP LSP operations. The current approach does not build on RFC 8623 instead uses the multi-path technique (related to ECMP in P2P [1]). This would deviate from RFC 8623 significantly. On the other hand, considering the replication segment as a PCECC/CCI operation gives you more leeway to choose an encoding with a new CCI Object type for the replication segment and it could be independent of RFC 8623. I *still* feel PCECC makes more sense at the higher level too (because of the additional instruction to the leaves and coordination required). Even if one disagrees with that and considers it an LSP operation, it then needs to build on RFC 8623. The current "mashup" approach (i.e. it is an LSP operation but does not follow P2MP LSP encoding) does not work well in maintaining consistency within our extensions. Thanks! Dhruv (as a WG member) [1] https://datatracker.ietf.org/doc/draft-koldychev-pce-multipath/ ___ 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
Re: [Pce] [Editorial Errata Reported] RFC5088 (6459)
Hi John, This errata should be accepted. Please handle it at your convenience. Thanks! Dhruv & Julien On Mon, Mar 8, 2021 at 4:08 PM RFC Errata System wrote: > The following errata report has been submitted for RFC5088, > "OSPF Protocol Extensions for Path Computation Element (PCE) Discovery". > > -- > You may review the report below and at: > https://www.rfc-editor.org/errata/eid6459 > > -- > Type: Editorial > Reported by: tom petch > > Section: 7.2 > > Original Text > - >This document provides new capability bit flags, which are present in >the PCE-CAP-FLAGS TLV referenced in Section 4.1.5. > > > Corrected Text > -- >This document provides new capability bit flags, which are present in >the PCE-CAP-FLAGS TLV referenced in Section 4.5. > > > Notes > - > There is no Section 4.1.5. > > Instructions: > - > This erratum is currently posted as "Reported". If necessary, please > use "Reply All" to discuss whether it should be verified or > rejected. When a decision is reached, the verifying party > can log in to change the status and edit the report, if necessary. > > -- > RFC5088 (draft-ietf-pce-disco-proto-ospf-08) > -- > Title : OSPF Protocol Extensions for Path Computation > Element (PCE) Discovery > Publication Date: January 2008 > Author(s) : JL. Le Roux, Ed., JP. Vasseur, Ed., Y. Ikejiri, R. > Zhang > Category: PROPOSED STANDARD > Source : Path Computation Element > Area: Routing > Stream : IETF > Verifying Party : IESG > ___ 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, Speaking as a WG member... Let's continue the discussion on considering the replication segment as an LSP v/s PCECC operation. I just wanted to quickly recap - - We have stateful operations for RSVP-TE: RFC 8231, RFC 8281 - We then introduced SR with a minimal extension of new PST and a new SR-ERO subobject: RFC 8664 - We supported P2MP stateful operations for RSVP-TE with RBNF change in PCEP messages: RFC 8623 We have always tried our best to maintain consistency between RSVP-TE and SR in PCEP. Now, if one considers the Replication segment as an LSP operation, IMHO it needs to be built on RFC 8623 P2MP LSP operations. The current approach does not build on RFC 8623 instead uses the multi-path technique (related to ECMP in P2P [1]). This would deviate from RFC 8623 significantly. On the other hand, considering the replication segment as a PCECC/CCI operation gives you more leeway to choose an encoding with a new CCI Object type for the replication segment and it could be independent of RFC 8623. I *still* feel PCECC makes more sense at the higher level too (because of the additional instruction to the leaves and coordination required). Even if one disagrees with that and considers it an LSP operation, it then needs to build on RFC 8623. The current "mashup" approach (i.e. it is an LSP operation but does not follow P2MP LSP encoding) does not work well in maintaining consistency within our extensions. Thanks! Dhruv (as a WG member) [1] https://datatracker.ietf.org/doc/draft-koldychev-pce-multipath/ ___ 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, To respond to your comment, we usually follow the list below: 1- Gauge interest on the mailing list about an I-D, 2- Gauge interest when the I-D is presented to the WG, 3- If enough of 1 and 2, do a 1st poll in the room during WG meetings, 4- If enough of 3, add the I-D to the adoption queue. Without face-to-face meeting, we sometimes skip 3. Considering its depth, we often revise the order in the adoption queue with respect to consensus and document maturity (consider thanking Dhruv for that). As a result, your effort should focus on progressing technical discussions rather than process requests: I believe the discussion in progress will end up in improving your I-D, which will be valuable whatever the further steps. Contrary to what I've read, please note PCE-CC isn't a prerequisite and there's no such statement like "the working group is only dictating PCECC and is not open to any other option but PCECC for the purpose of programming the PCC and multicast". Thanks, Julien On 10/03/2021 04:39, Bidgoli, Hooman (Nokia - CA/Ottawa) wrote: > HB> Dear chairs I am not sure if I understand the criteria of how > drafts move from “Individual documents that authors consider ready for > WG adoption” to “WG Adoptoin call queue”. I am guessing it is chairs > consent that moves the draft between the 2 queues, not the adaptation > request? smime.p7s Description: S/MIME Cryptographic Signature ___ Pce mailing list Pce@ietf.org https://www.ietf.org/mailman/listinfo/pce
[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 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
