[Pce] I-D Action: draft-ietf-pce-pcep-extension-native-ip-06.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 Chun Zhu Filename: draft-ietf-pce-pcep-extension-native-ip-06.txt Pages : 10 Date: 2020-08-18 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-06 https://datatracker.ietf.org/doc/html/draft-ietf-pce-pcep-extension-native-ip-06 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-pce-pcep-extension-native-ip-06 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
[Pce] Fwd: IPR Poll on draft-ietf-pce-pcep-extension-for-pce-controller
Sending to the list... -- Forwarded message - From: Chao Zhou Date: Tue, 18 Aug 2020 at 22:39 Subject: Re: [Pce] IPR Poll on draft-ietf-pce-pcep-extension-for-pce-controller To: Dhruv Dhody Cc: pce-chairs , lizhen...@huawei.com < lizhen...@huawei.com>, Quintin Zhao Hi Dhruv, Thanks for the email. Sorry for the delay of response. My response regarding to this draft is below: I am not aware of any IPR applicable to this draft that should be disclosed in accordance with IETF IPR rules. Thanks, -Chao On Monday, August 17, 2020, 11:18:26 PM EDT, Dhruv Dhody wrote: Hi Chao, Forwarding to your updated email address. Please respond to the below IPR poll by including the PCE WG List ( pce@ietf.org ) in your reply. Thanks! Dhruv -- Forwarded message - From: *Hariharan Ananthakrishnan* Date: Fri, Aug 7, 2020 at 9:32 AM Subject: [Pce] IPR Poll on draft-ietf-pce-pcep-extension-for-pce-controller To: , , Mahend Negi < mahend.i...@gmail.com>, , Cc: Hi Authors, In preparation for WG LC 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 mailing list Pce@ietf.org https://www.ietf.org/mailman/listinfo/pce
Re: [Pce] IPR Poll on draft-ietf-pce-pcep-extension-for-pce-controller
Hi Hari, I am not aware of any IPR applicable to this draft that should be disclosed in accordance with IETF IPR rules. Regards, Mahendra On Fri, Aug 7, 2020 at 9:32 AM Hariharan Ananthakrishnan wrote: > Hi Authors, > > In preparation for WG LC 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] PCE WG LC for draft-ietf-pce-pcep-extension-for-pce-controller
Hi Aijun, As a contributor to this I-D and a WG participant, let me jump in and snip to ... > 2. This draft states it focuses on LSP Path central control, but I think the > procedures described in this draft is common to other CCI object(which may be > defined in other documents). So would it be better to generalize the > procedures? The specific part for other path type may be only the CCI > objects. This can facilitate the extension of PCECC procedure in other > scenario. > > > > > > [Shuping] Yes, you are right. We can add some text in the introduction to > make it clear that though this document focuses on the basic PCECC LSP mode > for the static LSPs, the procedures defined are generic enough to be used by > other PCECC extensions. > > [WAJ] Not only the introduction part, but also the following procedures. It > is better to generalize the (section 5), not strictly limit within the LSP > path. > > [DD] I see that this has been updated based on Adrian's comment, this now reads - While this document is focused on the procedures for the static LSPs (referred to as basic PCECC mode in Section 3), the mechanism and protocol encoding are specified in such a way that, extensions for other use cases is easy to achieve. For example, the extensions for PCECC for Segment Routing (SR) are specified in [I-D.zhao-pce-pcep-extension-pce-controller-sr] and [I-D.dhody-pce-pcep-extension-pce-controller-srv6]. I disagree regarding the need to change section 5. In this I-D, we don't generalize but allow for an easy extension for new use cases. This document defines what needs to be done for CCI Object-Type=1, and allows other CCI Object-Types to be defined in other I-Ds later. There are cases where we can generalize when the extension can stand on its own, for example, a generic ASSOCIATION object, and have different association types. But we do not have a generic CCI object, we have CCI Object-Type=1 that needs to be specified in this context. This is similar to how PCEP for SR-MPLS exists on its own in RFC 8664 and later extended for SRv6 without a generic SR text. > > > > 3. Section-5.5.1of this draft describes the “Basic PCECC LSP Setup”, which is > based on the LSP delegation mode. But for LSP delegate mode, the LSP must > exist beforehand, which is constructed via the distributed protocol(RSVP > etc.). In such scenario, is it necessary to allocate the Label via the PCE? > > > > > > [Shuping] This is similar to the case for RFC 8664 where a PCC-initiated SR > path is delegated to the PCE. It is not mandatory for the path (label-stack) > to be "constructed" beforehand. > > [WAJ] For the PCC-initiated SR path, only the headend need to be touched. It > is different from the scenario described in Figure 2. > > > [DD] It is different, but Shuping's response was based on your comment "But for LSP delegate mode, the LSP must exist beforehand..." and to highlight that the requirement for the LSP to exist beforehand is incorrect! One can send a PCReq message first to get the path and then delegate it. It is also allowed to delegate an LSP that has an empty ERO (down LSP). But in either case, there is no requirement for the LSP to be established in the data plane before the delegation. > 5. Similar consideration is for the “PCC allocation label”. What the reason > to let the PCC allocate such label? Why can’t PCE allocate such information > for each PCC from its appointed label space? > > > > > > [Shuping] It was suggested to be added because in some cases PCC may not be > able to allocate a part of its label space for PCE to control and it would > want to control the full label-space allocation. > > [WAJ] In such situation, we think the distributed only label allocation is > fine. The PCE should not intervene this process. Adding PCE in the network > should simplify the procedures, not make it complex. > > [DD] The capability of the PCC to allocate labels is something that already exists and by adding one flag in the protocol exchange one is able to allow both modes. This is not particularly complex IMHO :) Also, you should note that this is quite common in SR use cases such as binding and path segments where PCC allocated binding segment and path segment is supported. > > > > 6. For definition of CCI object, will it simplify the overall procedures if > the CCI object for MPLS label includes both the IN and OUT label together? > > > > > > [Shuping] At the ingress, we would only have out-label, and at the egress, we > would only have an in-label. > > In case of P2MP branch nodes, we would have one in-label and many out-labels > as described in another I-D. > > For these reasons, we decided to have them as separate CCI instances. > > [WAJ] Separate CCI instances requires the binding function on the devices. > How to avoid the problem when the CCI instances can’t be bound together? For > example, the PCE download two out label, no in label, or vice versa? > > [D
Re: [Pce] Éric Vyncke's No Objection on draft-ietf-pce-pcep-flowspec-10: (with COMMENT)
Thanks Eric, Yes, that's a good catch. Embarrassed that is sneaked through. I now have The Value field MUST be set to 0 and MUST be ignored on receipt. in my working copy. Best, Adrian -Original Message- From: Éric Vyncke via Datatracker Sent: 18 August 2020 11:14 To: The IESG Cc: draft-ietf-pce-pcep-flows...@ietf.org; pce-cha...@ietf.org; pce@ietf.org; Julien Meuric ; julien.meu...@orange.com Subject: Éric Vyncke's No Objection on draft-ietf-pce-pcep-flowspec-10: (with COMMENT) Éric Vyncke has entered the following ballot position for draft-ietf-pce-pcep-flowspec-10: No Objection 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/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-pce-pcep-flowspec/ -- COMMENT: -- Thank you for the work put into this document. I found the text easy to read albeit sometimes it could be shortened (section 1 for example). But, I prefer clarity and ease of read to concise text. I have only one non-blocking comment in section 4: documenting what is the expected behavior when receiving a "Value" != 0 could be helpful (probably the usual 'ignored'). I hope that this helps to improve the document, Regards, -éric ___ Pce mailing list Pce@ietf.org https://www.ietf.org/mailman/listinfo/pce
Re: [Pce] PCE WG LC for draft-ietf-pce-pcep-extension-for-pce-controller
Bravo! :) Thank you, Adrian! Best regards, Shuping 发件人：Adrian Farrel 收件人：Pengshuping (Peng Shuping) ;julien.meuric ;pce 抄 送：draft-ietf-pce-pcep-extension-for-pce-controller 时 间：2020-08-18 19:25:23 主 题：RE: [Pce] PCE WG LC for draft-ietf-pce-pcep-extension-for-pce-controller That's super-fast work, Shuping. Thanks. I skimmed through the changes and checked the ones where I had asked questions. Everything looks good. I can now fully support the last call. Best, Adrian -Original Message- From: Pengshuping (Peng Shuping) Sent: 18 August 2020 12:08 To: adr...@olddog.co.uk; julien.meu...@orange.com; pce@ietf.org Cc: draft-ietf-pce-pcep-extension-for-pce-control...@ietf.org Subject: RE: [Pce] PCE WG LC for draft-ietf-pce-pcep-extension-for-pce-controller Dear Adrian, Many thanks for your detailed review and comments. Please find the diff with our updates to the draft according to your comments. Hope we have addressed them properly. https://tools.ietf.org/tools/rfcdiff/rfcdiff.pyht?url1=draft-ietf-pce-pcep-e xtension-for-pce-controller-06&url2=https://raw.githubusercontent.com/dhruvd hody/ietf/master/draft-ietf-pce-pcep-extension-for-pce-controller-07.txt We have also updated Chao Zhou's email address in the draft. Thank you! Best regards, Shuping > -Original Message- > From: Adrian Farrel [mailto:adr...@olddog.co.uk] > Sent: Monday, August 17, 2020 12:15 AM > To: julien.meu...@orange.com; pce@ietf.org > Cc: draft-ietf-pce-pcep-extension-for-pce-control...@ietf.org > Subject: RE: [Pce] PCE WG LC for > draft-ietf-pce-pcep-extension-for-pce-controller > > Hi Julien, WG, authors, > > I'm listed as one of the eight Contributors to this document, although my > affiliation should read "Old Dog Consulting". > > I was a co-author of RFC 8283, so I am generally glad to see protocol work > addressing this space. > > This document is almost ready to progress, but there are quite a few nits > that we should take care of before asking to advance the document. > After that's done, I support this document being published as an RFC. > > Thanks, > Adrian > > === > > Figures > > If you make the table in Section 5.2 into "Figure 1" then you will not need to > renumber Figure 2. > > All figures should have a caption such as you have for Figure 2. > > All figures should be mentioned explicitly in the text. Thus, instead of saying > "as shown below" you should say "as shown in Figure 2". This is important > because: > - it helps the RFC Editor check that you are using all of the figures > - it protects the text from edits that might move it around in relation > to the figure. > > --- > > Abstract > > s/(G)MPLS/MPLS and GMPLS/ > s/PCEP protocol extensions/PCEP extensions/ > > --- > > Introduction > > s/draft specify/document specifies/ > > --- > > Introduction > >The extension for PCECC in Segment Routing (SR) is specified in a >separate draft [I-D.zhao-pce-pcep-extension-pce-controller-sr]. > > This paragraph is, of course, completely true. But it is absolutely unclear > what it is doing here. There has been no previous discussion of SR in the > document, and the only other mention of SR is in 5.5.9. I think we can > probably do without this paragraph. > > --- > > 2. > > OLD >Terminologies used in this document is same as described in the draft >[RFC8283]. > NEW >Terminology used in this document is that same as that described in >[RFC8283]. > END > > --- > > 3. > > OLD >it is assumed that label range to be used NEW >it is assumed that the label range to be used END > > OLD >A future extension could add this capability NEW >A future extension could add the capability END > > OLD >This document also allow a case where the label space is maintained >by PCC itself > NEW >This document also allows a case where the label space is maintained >by the PCC itself > END > > --- > > 4. > > OLD >Following key requirements associated PCECC should be considered > when >designing the PCECC based solution: > NEW >The following key requirements should be considered when >designing the PCECC based solution: > END > > --- > > 5.3 > s/This document specify/This document specifies/ s//new CCI > object-type/new CCI object-types/ > > --- > > 5.4 > s/During PCEP Initialization Phase/During the PCEP Initialization Phase/ > s/Path is setup/Path is set up/ s/sub-TLV in PCC's/sub-TLV in a PCC's/ s/PCE's > OPEN message/a PCE's OPEN message/ > > --- > > 5.4 > >If the PCEP >Speakers support the extensions of this draft but did not advertise >this capability attempts a PCECC operation then a PCErr message with >Error-Type=19(Invalid Operation) and Error-Value=TBD3 (Attempted >PCECC operations when PCECC capability was not advertised) will be >generated and the PCEP session will be terminated. > > This is good. But you also need to include what happens if an > implementation that does not understand these extensions receives one.
Re: [Pce] PCE WG LC for draft-ietf-pce-pcep-extension-for-pce-controller
That's super-fast work, Shuping. Thanks. I skimmed through the changes and checked the ones where I had asked questions. Everything looks good. I can now fully support the last call. Best, Adrian -Original Message- From: Pengshuping (Peng Shuping) Sent: 18 August 2020 12:08 To: adr...@olddog.co.uk; julien.meu...@orange.com; pce@ietf.org Cc: draft-ietf-pce-pcep-extension-for-pce-control...@ietf.org Subject: RE: [Pce] PCE WG LC for draft-ietf-pce-pcep-extension-for-pce-controller Dear Adrian, Many thanks for your detailed review and comments. Please find the diff with our updates to the draft according to your comments. Hope we have addressed them properly. https://tools.ietf.org/tools/rfcdiff/rfcdiff.pyht?url1=draft-ietf-pce-pcep-e xtension-for-pce-controller-06&url2=https://raw.githubusercontent.com/dhruvd hody/ietf/master/draft-ietf-pce-pcep-extension-for-pce-controller-07.txt We have also updated Chao Zhou's email address in the draft. Thank you! Best regards, Shuping > -Original Message- > From: Adrian Farrel [mailto:adr...@olddog.co.uk] > Sent: Monday, August 17, 2020 12:15 AM > To: julien.meu...@orange.com; pce@ietf.org > Cc: draft-ietf-pce-pcep-extension-for-pce-control...@ietf.org > Subject: RE: [Pce] PCE WG LC for > draft-ietf-pce-pcep-extension-for-pce-controller > > Hi Julien, WG, authors, > > I'm listed as one of the eight Contributors to this document, although my > affiliation should read "Old Dog Consulting". > > I was a co-author of RFC 8283, so I am generally glad to see protocol work > addressing this space. > > This document is almost ready to progress, but there are quite a few nits > that we should take care of before asking to advance the document. > After that's done, I support this document being published as an RFC. > > Thanks, > Adrian > > === > > Figures > > If you make the table in Section 5.2 into "Figure 1" then you will not need to > renumber Figure 2. > > All figures should have a caption such as you have for Figure 2. > > All figures should be mentioned explicitly in the text. Thus, instead of saying > "as shown below" you should say "as shown in Figure 2". This is important > because: > - it helps the RFC Editor check that you are using all of the figures > - it protects the text from edits that might move it around in relation > to the figure. > > --- > > Abstract > > s/(G)MPLS/MPLS and GMPLS/ > s/PCEP protocol extensions/PCEP extensions/ > > --- > > Introduction > > s/draft specify/document specifies/ > > --- > > Introduction > >The extension for PCECC in Segment Routing (SR) is specified in a >separate draft [I-D.zhao-pce-pcep-extension-pce-controller-sr]. > > This paragraph is, of course, completely true. But it is absolutely unclear > what it is doing here. There has been no previous discussion of SR in the > document, and the only other mention of SR is in 5.5.9. I think we can > probably do without this paragraph. > > --- > > 2. > > OLD >Terminologies used in this document is same as described in the draft >[RFC8283]. > NEW >Terminology used in this document is that same as that described in >[RFC8283]. > END > > --- > > 3. > > OLD >it is assumed that label range to be used NEW >it is assumed that the label range to be used END > > OLD >A future extension could add this capability NEW >A future extension could add the capability END > > OLD >This document also allow a case where the label space is maintained >by PCC itself > NEW >This document also allows a case where the label space is maintained >by the PCC itself > END > > --- > > 4. > > OLD >Following key requirements associated PCECC should be considered > when >designing the PCECC based solution: > NEW >The following key requirements should be considered when >designing the PCECC based solution: > END > > --- > > 5.3 > s/This document specify/This document specifies/ s//new CCI > object-type/new CCI object-types/ > > --- > > 5.4 > s/During PCEP Initialization Phase/During the PCEP Initialization Phase/ > s/Path is setup/Path is set up/ s/sub-TLV in PCC's/sub-TLV in a PCC's/ s/PCE's > OPEN message/a PCE's OPEN message/ > > --- > > 5.4 > >If the PCEP >Speakers support the extensions of this draft but did not advertise >this capability attempts a PCECC operation then a PCErr message with >Error-Type=19(Invalid Operation) and Error-Value=TBD3 (Attempted >PCECC operations when PCECC capability was not advertised) will be >generated and the PCEP session will be terminated. > > This is good. But you also need to include what happens if an > implementation that does not understand these extensions receives one. > I suspect you can do this with a reference to another document. > > --- > > There are a couple of cases of s/a LSP/an LSP/ > > --- > > 5.5.1 > > s/based on PCECC mechanism/based on the PCECC mechanism/ > s/LSP-IDENTIFIER TLV MUST/An
Re: [Pce] PCE WG LC for draft-ietf-pce-pcep-extension-for-pce-controller
Dear Adrian, Many thanks for your detailed review and comments. Please find the diff with our updates to the draft according to your comments. Hope we have addressed them properly. https://tools.ietf.org/tools/rfcdiff/rfcdiff.pyht?url1=draft-ietf-pce-pcep-extension-for-pce-controller-06&url2=https://raw.githubusercontent.com/dhruvdhody/ietf/master/draft-ietf-pce-pcep-extension-for-pce-controller-07.txt We have also updated Chao Zhou's email address in the draft. Thank you! Best regards, Shuping > -Original Message- > From: Adrian Farrel [mailto:adr...@olddog.co.uk] > Sent: Monday, August 17, 2020 12:15 AM > To: julien.meu...@orange.com; pce@ietf.org > Cc: draft-ietf-pce-pcep-extension-for-pce-control...@ietf.org > Subject: RE: [Pce] PCE WG LC for > draft-ietf-pce-pcep-extension-for-pce-controller > > Hi Julien, WG, authors, > > I'm listed as one of the eight Contributors to this document, although my > affiliation should read "Old Dog Consulting". > > I was a co-author of RFC 8283, so I am generally glad to see protocol work > addressing this space. > > This document is almost ready to progress, but there are quite a few nits > that we should take care of before asking to advance the document. > After that's done, I support this document being published as an RFC. > > Thanks, > Adrian > > === > > Figures > > If you make the table in Section 5.2 into "Figure 1" then you will not need to > renumber Figure 2. > > All figures should have a caption such as you have for Figure 2. > > All figures should be mentioned explicitly in the text. Thus, instead of > saying > "as shown below" you should say "as shown in Figure 2". This is important > because: > - it helps the RFC Editor check that you are using all of the figures > - it protects the text from edits that might move it around in relation > to the figure. > > --- > > Abstract > > s/(G)MPLS/MPLS and GMPLS/ > s/PCEP protocol extensions/PCEP extensions/ > > --- > > Introduction > > s/draft specify/document specifies/ > > --- > > Introduction > >The extension for PCECC in Segment Routing (SR) is specified in a >separate draft [I-D.zhao-pce-pcep-extension-pce-controller-sr]. > > This paragraph is, of course, completely true. But it is absolutely unclear > what it is doing here. There has been no previous discussion of SR in the > document, and the only other mention of SR is in 5.5.9. I think we can > probably do without this paragraph. > > --- > > 2. > > OLD >Terminologies used in this document is same as described in the draft >[RFC8283]. > NEW >Terminology used in this document is that same as that described in >[RFC8283]. > END > > --- > > 3. > > OLD >it is assumed that label range to be used NEW >it is assumed that the label range to be used END > > OLD >A future extension could add this capability NEW >A future extension could add the capability END > > OLD >This document also allow a case where the label space is maintained >by PCC itself > NEW >This document also allows a case where the label space is maintained >by the PCC itself > END > > --- > > 4. > > OLD >Following key requirements associated PCECC should be considered > when >designing the PCECC based solution: > NEW >The following key requirements should be considered when >designing the PCECC based solution: > END > > --- > > 5.3 > s/This document specify/This document specifies/ s//new CCI > object-type/new CCI object-types/ > > --- > > 5.4 > s/During PCEP Initialization Phase/During the PCEP Initialization Phase/ > s/Path is setup/Path is set up/ s/sub-TLV in PCC's/sub-TLV in a PCC's/ s/PCE's > OPEN message/a PCE's OPEN message/ > > --- > > 5.4 > >If the PCEP >Speakers support the extensions of this draft but did not advertise >this capability attempts a PCECC operation then a PCErr message with >Error-Type=19(Invalid Operation) and Error-Value=TBD3 (Attempted >PCECC operations when PCECC capability was not advertised) will be >generated and the PCEP session will be terminated. > > This is good. But you also need to include what happens if an > implementation that does not understand these extensions receives one. > I suspect you can do this with a reference to another document. > > --- > > There are a couple of cases of s/a LSP/an LSP/ > > --- > > 5.5.1 > > s/based on PCECC mechanism/based on the PCECC mechanism/ > s/LSP-IDENTIFIER TLV MUST/An LSP-IDENTIFIER TLV MUST/ s/with D > flags/with D flag/ s/and set up the/and sets up the/ s/include the > central/includes the central/ s/The CC-ID is uniquely identify/The CC-ID > uniquely identifies/ s/two CCI object/two CCI objects/ s/PCECC LSP is same > as/PCECC LSP is the same as/ > s/receives PCRpt message/receives a PCRpt message/ (twice) > s/The PCECC LSP are/The PCECC LSPs are/ > s/In case where/In the case where/ > s/label allocation are/label allocations are/ s/Similarly C bit/Sim
[Pce] Éric Vyncke's No Objection on draft-ietf-pce-pcep-flowspec-10: (with COMMENT)
Éric Vyncke has entered the following ballot position for draft-ietf-pce-pcep-flowspec-10: No Objection 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/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-pce-pcep-flowspec/ -- COMMENT: -- Thank you for the work put into this document. I found the text easy to read albeit sometimes it could be shortened (section 1 for example). But, I prefer clarity and ease of read to concise text. I have only one non-blocking comment in section 4: documenting what is the expected behavior when receiving a "Value" != 0 could be helpful (probably the usual 'ignored'). I hope that this helps to improve the document, Regards, -éric ___ Pce mailing list Pce@ietf.org https://www.ietf.org/mailman/listinfo/pce
