Re: [Pce] WGLC for draft-ietf-pce-association-policy
Hi, I have read this draft, and I support this document being published as an RFC. Just a few nits are found and listed as below. 1. "may instantiate LSPs and specifies" -> "...specify" 2. "[RFC8697] specify" -> "... specifies" 3. "Error- Value 4" -> "Error-Value 4" 4. " In some cases to apply a PCE policy successfully, it is required to also associate some policy parameters that needs to be evaluated, to successfully apply the said policy. " -> " In some cases to apply a PCE policy successfully, it is required to also associate some policy parameters that need to be evaluated. " 5. "The TLV could include one or more policy related parameter" -> "... parameters" 6. "a 4-bytes alignment" -> "4-byte" 7. "The PCEP peer implementation need to be aware" ->" The PCEP peer implementation needs to be aware" 8. "Further, if one or more parameters received in the POLICY-PARAMETERS-TLV received by the PCEP speaker " -> "Further, if one or more parameters in the POLICY-PARAMETERS-TLV received by the PCEP speaker " 9. " IANA is requested to confirm the early-allocated codepoints " -> " IANA is requested to confirm the early-allocated code point" 10. "in which case the an operator MUST " -> " in which case the operator MUST " 11. "This module supports associations as defined in [RFC8697] and thus support the Policy Association groups " -> "This module supports associations as defined in [RFC8697] and thus supports the Policy Association groups " 12. " this document borrow some of " -> " this document borrowed some of " Best regards, Shuping > -Original Message- > From: Pce [mailto:pce-boun...@ietf.org] On Behalf Of Dhruv Dhody > Sent: Friday, September 4, 2020 1:13 PM > To: pce@ietf.org > Cc: draft-ietf-pce-association-pol...@ietf.org; pce-chairs > > Subject: [Pce] WGLC for draft-ietf-pce-association-policy > > Hi WG, > > This email starts a working group last call for > draft-ietf-pce-association-policy [1]. Please indicate your support or > concern for this draft. If you are opposed to the progression of the draft to > RFC, please articulate your concern. If you support it, please indicate that > you have read the latest version and it is ready for publication in your > opinion. As always, review comments and nits are most welcome. > > The WG LC will end on 21st September 2020. > > Thanks, > Dhruv & Julien > [1] https://datatracker.ietf.org/doc/draft-ietf-pce-association-policy/ > > ___ > 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] WGLC for draft-ietf-pce-association-policy
Hi Aijun, See inline... On Mon, Sep 21, 2020 at 7:46 AM Aijun Wang wrote: > > HI, Dhruv and the authors this draft: > > How to ensure the interoperability? The document just says: > "Further, if one or more parameters received in the POLICY-PARAMETERS-TLV > received by the PCEP speaker are considered as unacceptable in the context of > the >associated policy (e.g. out of range value, badly encoded value...), the > PCEP speaker MUST NOT apply the received policy and SHOULD log this event." > There will be no more detail error information can be reported via such > opaque policy. How to debug the policy deployment then? > I agree, it would be wise to generate an error, we could reuse the error from RFC 8697. How about -> Further, if one or more parameters received in the POLICY-PARAMETERS-TLV received by the PCEP speaker are considered as unacceptable in the context of the associated policy (e.g. out of range value, badly encoded value...), the PCEP speaker MUST reject the PCEP message and send a PCErr message with Error-Type 26 "Association Error" and Error-Value 5 "Operator-configured association information mismatch" [RFC8697]. PCEP speaker SHOULD log this event. > And, if there are some examples to show what association requirements can't > be accomplished by the SVEC object, and can only be done via PAG, the > document may be more convincible. > SVEC object has an impact only on the diversity association and it was covered in https://www.rfc-editor.org/rfc/rfc8800.html#name-relationship-to-svec. Your suggestion to add an example is a good idea. Can the authors consider adding something in the appendix? Thanks! Dhruv [ still without hats :) ] > > Best Regards > > Aijun Wang > China Telecom > > -Original Message- > From: Dhruv Dhody [mailto:d...@dhruvdhody.com] > Sent: Friday, September 18, 2020 12:40 PM > To: Aijun Wang > Cc: pce@ietf.org; draft-ietf-pce-association-pol...@ietf.org; pce-chairs > > Subject: Re: [Pce] WGLC for draft-ietf-pce-association-policy > > Hi Aijun, > > Thank you for your comments. > > I wanted to focus on the 3rd point. I remember this being discussed perhaps > in the previous incarnation of the draft. The main motivation in PCEP is to > provide a "standard" container and mechanism to associate (and encode the > policy) and leave the actual policy standardization out of the scope of PCEP. > > Another way to look at this would be, when a policy is well-known and needs > to be standardized (some may consider diversity or SR-Policy as those > policies), we define a new standard association-type for it with a standard > TLV. This I-D is used when we do not have a standard policy defined in PCEP > but would like to use the protocol as an opaque container to associate > policies to the path. What does that policy mean and how to encode/decode the > policy parameters are expected to be done out-of-band via other mechanisms > which are better suited for policy definitions and configurations at the PCEP > speakers. Hope this helps! > > Thanks! > Dhruv (hat-less!) > > On Fri, Sep 18, 2020 at 6:43 AM Aijun Wang wrote: > > > > Hi, Authors: > > > > I Just have a quick view of this draft, and has some points wanted to > > be > > clarified: > > 1. This draft defines one new association type (policy association > > type) that follows the procedures described in RFC8697 and attached > > TLV? Is it right? > > 2. According to the text described in > > https://tools.ietf.org/html/rfc8697#section-3.2, to define one new > > association type, the related draft should clarify its relationship > > between the SVEC object, if any. > > Should this draft to add such part? > > 3. For the definition of "Policy-Parameters-TLV", the "Policy > > Parameters" is opaque value to the PCEP peers. The draft describes > > the PCEP peers should know how to the encoding format of such policy > > in advance. But from my POV, the encoding format is the main content > > needs to be standardized. If such contents can't be standardized, what > > benefit can we get from this standardization work? What's the reason not to > > standardize this? > > > > > > Best Regards > > > > Aijun Wang > > China Telecom > > > > > > -Original Message- > > From: pce-boun...@ietf.org [mailto:pce-boun...@ietf.org] On Behalf Of > > Dhruv Dhody > > Sent: Thursday, September 17, 2020 5:42 PM > > To: pce@ietf.org > > Cc: draft-ietf-pce-association-pol...@ietf.org; pce-chairs > > > > Subject: Re: [Pce] WGLC for draft-ietf-pce-association-policy > > > > Hi WG, > > > > A reminder to the WG to be more vocal. I am copying this slide from > > the chair's WG status slide > > [https://www.ietf.org/proceedings/108/slides/slides-108-pce-1-introduc > > tion-0 > > 1] > > > > > Please be Vocal > > > > > > o During WG Adoption and WG LC calls, the response is less. > > > > > > o Please be vocal on the list to help us gauge the consensus better. > > > > > > o The working group mailing
Re: [Pce] WGLC for draft-ietf-pce-association-policy
Hi, I've read the latest version of this document, and think it is ready for publication. Best regards, Jie > -Original Message- > From: Pce [mailto:pce-boun...@ietf.org] On Behalf Of Dhruv Dhody > Sent: Friday, September 4, 2020 1:13 PM > To: pce@ietf.org > Cc: draft-ietf-pce-association-pol...@ietf.org; pce-chairs > > Subject: [Pce] WGLC for draft-ietf-pce-association-policy > > Hi WG, > > This email starts a working group last call for > draft-ietf-pce-association-policy > [1]. Please indicate your support or concern for this draft. If you are > opposed > to the progression of the draft to RFC, please articulate your concern. If you > support it, please indicate that you have read the latest version and it is > ready > for publication in your opinion. As always, review comments and nits are most > welcome. > > The WG LC will end on 21st September 2020. > > Thanks, > Dhruv & Julien > [1] https://datatracker.ietf.org/doc/draft-ietf-pce-association-policy/ > > ___ > 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] WGLC for draft-ietf-pce-association-policy
Hi, Dhruv: Reusing "Association Error/Operator-configured association information mismatch" can give some clues, but it does not yet hit the crucial point. The content of this draft has illustrated some possible reasons ---(e.g. out of range value, badly encoded value...), but the returned error information blends them together again. Can we define some new error-value to reflect them more clearly? I think the parser of the association policy can give the detail information. And, seems no authors of this draft to response these questions? Best Regards Aijun Wang China Telecom -Original Message- From: Dhruv Dhody [mailto:d...@dhruvdhody.com] Sent: Monday, September 21, 2020 7:04 PM To: Aijun Wang Cc: pce@ietf.org; draft-ietf-pce-association-pol...@ietf.org; pce-chairs Subject: Re: [Pce] WGLC for draft-ietf-pce-association-policy Hi Aijun, See inline... On Mon, Sep 21, 2020 at 7:46 AM Aijun Wang wrote: > > HI, Dhruv and the authors this draft: > > How to ensure the interoperability? The document just says: > "Further, if one or more parameters received in the POLICY-PARAMETERS-TLV > received by the PCEP speaker are considered as unacceptable in the context of > the >associated policy (e.g. out of range value, badly encoded value...), the > PCEP speaker MUST NOT apply the received policy and SHOULD log this event." > There will be no more detail error information can be reported via such > opaque policy. How to debug the policy deployment then? > I agree, it would be wise to generate an error, we could reuse the error from RFC 8697. How about -> Further, if one or more parameters received in the POLICY-PARAMETERS-TLV received by the PCEP speaker are considered as unacceptable in the context of the associated policy (e.g. out of range value, badly encoded value...), the PCEP speaker MUST reject the PCEP message and send a PCErr message with Error-Type 26 "Association Error" and Error-Value 5 "Operator-configured association information mismatch" [RFC8697]. PCEP speaker SHOULD log this event. > And, if there are some examples to show what association requirements can't > be accomplished by the SVEC object, and can only be done via PAG, the > document may be more convincible. > SVEC object has an impact only on the diversity association and it was covered in https://www.rfc-editor.org/rfc/rfc8800.html#name-relationship-to-svec. Your suggestion to add an example is a good idea. Can the authors consider adding something in the appendix? Thanks! Dhruv [ still without hats :) ] > > Best Regards > > Aijun Wang > China Telecom > > -Original Message- > From: Dhruv Dhody [mailto:d...@dhruvdhody.com] > Sent: Friday, September 18, 2020 12:40 PM > To: Aijun Wang > Cc: pce@ietf.org; draft-ietf-pce-association-pol...@ietf.org; > pce-chairs > Subject: Re: [Pce] WGLC for draft-ietf-pce-association-policy > > Hi Aijun, > > Thank you for your comments. > > I wanted to focus on the 3rd point. I remember this being discussed perhaps > in the previous incarnation of the draft. The main motivation in PCEP is to > provide a "standard" container and mechanism to associate (and encode the > policy) and leave the actual policy standardization out of the scope of PCEP. > > Another way to look at this would be, when a policy is well-known and needs > to be standardized (some may consider diversity or SR-Policy as those > policies), we define a new standard association-type for it with a standard > TLV. This I-D is used when we do not have a standard policy defined in PCEP > but would like to use the protocol as an opaque container to associate > policies to the path. What does that policy mean and how to encode/decode the > policy parameters are expected to be done out-of-band via other mechanisms > which are better suited for policy definitions and configurations at the PCEP > speakers. Hope this helps! > > Thanks! > Dhruv (hat-less!) > > On Fri, Sep 18, 2020 at 6:43 AM Aijun Wang wrote: > > > > Hi, Authors: > > > > I Just have a quick view of this draft, and has some points wanted > > to be > > clarified: > > 1. This draft defines one new association type (policy association > > type) that follows the procedures described in RFC8697 and attached > > TLV? Is it right? > > 2. According to the text described in > > https://tools.ietf.org/html/rfc8697#section-3.2, to define one new > > association type, the related draft should clarify its relationship > > between the SVEC object, if any. > > Should this draft to add such part? > > 3. For the definition of "Policy-Parameters-TLV", the "Policy > > Parameters" is opaque value to the PCEP peers. The draft describes > > the PCEP peers should know how to the encoding format of such policy > > in advance. But from my POV, the encoding format is the main content > > needs to be standardized. If such contents can't be standardized, > > what benefit can we get from this standardization work?
Re: [Pce] WGLC for draft-ietf-pce-association-policy
I support advancement of this critical draft. This draft provides a extensibility of existing generic mechanism of creating a groupings of LSPs to define associations between a set of LSPs and configuration attributes with stateful and stateless PCE described in RFC 8697 by mapping one or more LSPs with policy. Thanks Gyan On Mon, Sep 21, 2020 at 9:37 PM Aijun Wang wrote: > Hi, Dhruv: > > > > Reusing "Association Error/Operator-configured association information > mismatch" can give some clues, but it does not yet hit the crucial point. > > The content of this draft has illustrated some possible reasons ---(e.g. > out of range value, badly encoded value...), but the returned error > information blends them together again. > > Can we define some new error-value to reflect them more clearly? I think > the parser of the association policy can give the detail information. > > > > And, seems no authors of this draft to response these questions? > > > > Best Regards > > > > Aijun Wang > > China Telecom > > > > -Original Message- > > From: Dhruv Dhody [mailto:d...@dhruvdhody.com] > > Sent: Monday, September 21, 2020 7:04 PM > > To: Aijun Wang > > Cc: pce@ietf.org; draft-ietf-pce-association-pol...@ietf.org; pce-chairs < > pce-cha...@ietf.org> > > Subject: Re: [Pce] WGLC for draft-ietf-pce-association-policy > > > > Hi Aijun, > > > > See inline... > > > > On Mon, Sep 21, 2020 at 7:46 AM Aijun Wang > wrote: > > > > > > HI, Dhruv and the authors this draft: > > > > > > How to ensure the interoperability? The document just says: > > > "Further, if one or more parameters received in the > POLICY-PARAMETERS-TLV received by the PCEP speaker are considered as > unacceptable in the context of the > > >associated policy (e.g. out of range value, badly encoded value...), > the PCEP speaker MUST NOT apply the received policy and SHOULD log this > event." > > > There will be no more detail error information can be reported via such > opaque policy. How to debug the policy deployment then? > > > > > > > I agree, it would be wise to generate an error, we could reuse the error > from RFC 8697. How about -> > > > >Further, if one or more > >parameters received in the POLICY-PARAMETERS-TLV received by the PCEP > >speaker are considered as unacceptable in the context of the > >associated policy (e.g. out of range value, badly encoded value...), > >the PCEP speaker MUST reject the PCEP > >message and send a PCErr message with Error-Type 26 "Association > >Error" and Error-Value 5 "Operator-configured association information > >mismatch" [RFC8697]. PCEP speaker SHOULD log this event. > > > > > > > And, if there are some examples to show what association requirements > can't be accomplished by the SVEC object, and can only be done via PAG, the > document may be more convincible. > > > > > > > SVEC object has an impact only on the diversity association and it was > covered in > https://www.rfc-editor.org/rfc/rfc8800.html#name-relationship-to-svec. > > Your suggestion to add an example is a good idea. Can the authors consider > adding something in the appendix? > > > > Thanks! > > Dhruv [ still without hats :) ] > > > > > > > > > > Best Regards > > > > > > Aijun Wang > > > China Telecom > > > > > > -Original Message- > > > From: Dhruv Dhody [mailto:d...@dhruvdhody.com] > > > Sent: Friday, September 18, 2020 12:40 PM > > > To: Aijun Wang > > > Cc: pce@ietf.org; draft-ietf-pce-association-pol...@ietf.org; > > > pce-chairs > > > Subject: Re: [Pce] WGLC for draft-ietf-pce-association-policy > > > > > > Hi Aijun, > > > > > > Thank you for your comments. > > > > > > I wanted to focus on the 3rd point. I remember this being discussed > perhaps in the previous incarnation of the draft. The main motivation in > PCEP is to provide a "standard" container and mechanism to associate (and > encode the policy) and leave the actual policy standardization out of the > scope of PCEP. > > > > > > Another way to look at this would be, when a policy is well-known and > needs to be standardized (some may consider diversity or SR-Policy as those > policies), we define a new standard association-type for it with a standard > TLV. This I-D is used when we do not have a standard policy defined in PCEP > but would like to use the protocol as an opaque container to associate > policies to the path. What does that policy mean and how to encode/decode > the policy parameters are expected to be done out-of-band via other > mechanisms which are better suited for policy definitions and > configurations at the PCEP speakers. Hope this helps! > > > > > > Thanks! > > > Dhruv (hat-less!) > > > > > > On Fri, Sep 18, 2020 at 6:43 AM Aijun Wang > wrote: > > > > > > > > Hi, Authors: > > > > > > > > I Just have a quick view of this draft, and has some points wanted > > > > to be > > > > clarified: > > > > 1. This draft defines one new association type (policy association > > > > type) that follows the procedures
