Re: [Pce] Benjamin Kaduk's Discuss on draft-ietf-pce-stateful-path-protection-10: (with DISCUSS and COMMENT)
On Tue, Sep 24, 2019 at 11:38:13AM +0530, Dhruv Dhody wrote: > Hi Ben, > > Apologies for the delay. I am replying this email where we tackle > points that needed some more discussion. > > On Fri, Sep 20, 2019 at 2:32 AM Benjamin Kaduk wrote: > > > > Hi Dhruv, > > > > On Wed, Sep 18, 2019 at 11:45:23AM +0530, Dhruv Dhody wrote: > > > Hi Ben, > > > > > > Thanks for your review, let me start the discussion and the authors > > > can interject as needed. > > > > Thanks; it's a great start. > > > > > On Wed, Sep 18, 2019 at 5:14 AM Benjamin Kaduk via Datatracker > > > wrote: > > > > > > > > Benjamin Kaduk has entered the following ballot position for > > > > draft-ietf-pce-stateful-path-protection-10: Discuss > > > > > > > > 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-stateful-path-protection/ > > > > > > > > > > > > > > > > -- > > > > DISCUSS: > > > > -- > > > > > > > > (1) draft-ietf-pce-association-group notes that "PCEP extensions that > > > > define > > > > a new association type should clarify the relationship between the SVEC > > > > object and the association type, if any". Where do we do so for the > > > > path protection association type? > > > > > > > > > > This is discussed in > > > https://tools.ietf.org/html/draft-ietf-pce-association-diversity-10#section-5.3, > > > where it is more relevant. This draft includes the relationship with > > > diversity association in Section 5. > > > > A naive reading of the linked section would be that it applies only to the > > "Disjointness Association Type" defined in that document. I'm not in a > > position to claim that the reasoning in that document does not apply to > > this one, but I think we should make a more clear link between the Path > > Protection ASsociation Type and the discussion in that document. > > > > The direct relationship is between the 'Disjointness Association Type' > and SVEC. But it is natural to include both Protection association and > disjoint association together. If SVEC is also present the > relationship is as per the Section 5.3 of > [I-D.ietf-pce-association-diversity]. Suppose if only protection > association is present and SVEC object, there is no direct > relationship and both object would be processed. > > I suggest we add this text to make sure reader is aware of SVEC - "The > relationship between the Synchronization VECtor (SVEC) object and the > Disjointness Association is described in section 5.3 of > [I-D.ietf-pce-association-diversity]." Thanks! > > > > > (2) Section 3.2 says: > > > > > > > > Protection Type (PT): 6 bits - This field is as defined in > > > > Section 14.1 of [RFC4872] to indicate the LSP protection type in > > > > use. > > > > > > > > There doesn't seem to be a registry created by RFC 4872 to track these > > > > PT values, so I assume that the way to allocate a new value is > > > > "standards-track RFC that Updates: RFC 4872". Is that also the way to > > > > allocate new PT values for PPAG usage? How would someone updating RFC > > > > 4872 to allocate a new type know to consider/document whether it applies > > > > for PPAG usage? > > > > > > > > > > That's true. Maybe we can add this text - "Any type already defined or > > > that could be defined in the future for use in the RSVP-TE PROTECTION > > > object is acceptable in this TLV unless explicitly stated otherwise." > > > > To be honest, that's probably good enough in practice, since it seems > > somewhat unlikely that the last bit is ever going to get allocated (though, > > I guess technically the field could be converted to an integer instead of > > flags). I do still have to wonder how the reader would know *where* it > > would be stated otherwise, and how the author of a document defining a new > > type would know to consider our use case as well as the RFC 4872 use case. > > > > I guess such an update would happen in TEAS; and historically PCE and > TEAS work very closely, as well as share the same AD. I think we are > quite safe here. > > In case you were wondering why flags - we chose PT as flags as per RFC > 4872 where this is called "LSP (Protection Type) Flags". > > > > > (3) In Section 4.3: > > > > > > > >A PCE can create/update working and protection LSPs independently. > > > >As specified in [I-D.ietf-pce-association-group], Association Groups > > > >can be created by both the PCE and the PCC.
Re: [Pce] Benjamin Kaduk's Discuss on draft-ietf-pce-stateful-path-protection-10: (with DISCUSS and COMMENT)
Hi Ben, Apologies for the delay. I am replying this email where we tackle points that needed some more discussion. On Fri, Sep 20, 2019 at 2:32 AM Benjamin Kaduk wrote: > > Hi Dhruv, > > On Wed, Sep 18, 2019 at 11:45:23AM +0530, Dhruv Dhody wrote: > > Hi Ben, > > > > Thanks for your review, let me start the discussion and the authors > > can interject as needed. > > Thanks; it's a great start. > > > On Wed, Sep 18, 2019 at 5:14 AM Benjamin Kaduk via Datatracker > > wrote: > > > > > > Benjamin Kaduk has entered the following ballot position for > > > draft-ietf-pce-stateful-path-protection-10: Discuss > > > > > > 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-stateful-path-protection/ > > > > > > > > > > > > -- > > > DISCUSS: > > > -- > > > > > > (1) draft-ietf-pce-association-group notes that "PCEP extensions that > > > define > > > a new association type should clarify the relationship between the SVEC > > > object and the association type, if any". Where do we do so for the > > > path protection association type? > > > > > > > This is discussed in > > https://tools.ietf.org/html/draft-ietf-pce-association-diversity-10#section-5.3, > > where it is more relevant. This draft includes the relationship with > > diversity association in Section 5. > > A naive reading of the linked section would be that it applies only to the > "Disjointness Association Type" defined in that document. I'm not in a > position to claim that the reasoning in that document does not apply to > this one, but I think we should make a more clear link between the Path > Protection ASsociation Type and the discussion in that document. > The direct relationship is between the 'Disjointness Association Type' and SVEC. But it is natural to include both Protection association and disjoint association together. If SVEC is also present the relationship is as per the Section 5.3 of [I-D.ietf-pce-association-diversity]. Suppose if only protection association is present and SVEC object, there is no direct relationship and both object would be processed. I suggest we add this text to make sure reader is aware of SVEC - "The relationship between the Synchronization VECtor (SVEC) object and the Disjointness Association is described in section 5.3 of [I-D.ietf-pce-association-diversity]." > > > (2) Section 3.2 says: > > > > > > Protection Type (PT): 6 bits - This field is as defined in > > > Section 14.1 of [RFC4872] to indicate the LSP protection type in > > > use. > > > > > > There doesn't seem to be a registry created by RFC 4872 to track these > > > PT values, so I assume that the way to allocate a new value is > > > "standards-track RFC that Updates: RFC 4872". Is that also the way to > > > allocate new PT values for PPAG usage? How would someone updating RFC > > > 4872 to allocate a new type know to consider/document whether it applies > > > for PPAG usage? > > > > > > > That's true. Maybe we can add this text - "Any type already defined or > > that could be defined in the future for use in the RSVP-TE PROTECTION > > object is acceptable in this TLV unless explicitly stated otherwise." > > To be honest, that's probably good enough in practice, since it seems > somewhat unlikely that the last bit is ever going to get allocated (though, > I guess technically the field could be converted to an integer instead of > flags). I do still have to wonder how the reader would know *where* it > would be stated otherwise, and how the author of a document defining a new > type would know to consider our use case as well as the RFC 4872 use case. > I guess such an update would happen in TEAS; and historically PCE and TEAS work very closely, as well as share the same AD. I think we are quite safe here. In case you were wondering why flags - we chose PT as flags as per RFC 4872 where this is called "LSP (Protection Type) Flags". > > > (3) In Section 4.3: > > > > > >A PCE can create/update working and protection LSPs independently. > > >As specified in [I-D.ietf-pce-association-group], Association Groups > > >can be created by both the PCE and the PCC. Further, a PCE can > > > > > > The requirement that source, destination, and tunnel ID of all LSPs > > > within a PPAG MUST be the same is new to this document, so I think we > > > need to specify error handling for when attempts to update LSPs > > > independently would violate that invariant
Re: [Pce] Benjamin Kaduk's Discuss on draft-ietf-pce-stateful-path-protection-10: (with DISCUSS and COMMENT)
Hi Mahendra, Thanks for the links. What's in the diff generally looks good; I think we may still need to have a bit more discussion here about items (1) and (4) (for the latter, I'm not sure if the plan is still to update the table to list everything or just leave it to the body text). Also, with respect to (7), I think there was at least one place in the text where we mention that the source, destination, and tunnel ID must match where we don't also mention the protection type matching. Maybe it's sufficiently less important that we don't need to mention it everywhere, but I'll mention it just in case. Thanks, Ben On Sun, Sep 22, 2019 at 09:06:24PM +0530, Mahend Negi wrote: > Hi Ben/Dhruv, > > Thanks for the review and clarification. Comments are incorporated in the > working copy (links below). > > Working copy: > https://github.com/mahendnegi/ietf/blob/master/pce/path-protection/iesg/draft-ietf-pce-stateful-path-protection-11.txt > Diff: > https://github.com/mahendnegi/ietf/commit/c51efb2b025d545e066b9b13de6d84de48d1a03c > > Please do share your opinion. > > Thanks, > Mahendra > > > On Fri, Sep 20, 2019 at 2:33 AM Benjamin Kaduk wrote: > > > Hi Dhruv, > > > > On Wed, Sep 18, 2019 at 11:45:23AM +0530, Dhruv Dhody wrote: > > > Hi Ben, > > > > > > Thanks for your review, let me start the discussion and the authors > > > can interject as needed. > > > > Thanks; it's a great start. > > > > > On Wed, Sep 18, 2019 at 5:14 AM Benjamin Kaduk via Datatracker > > > wrote: > > > > > > > > Benjamin Kaduk has entered the following ballot position for > > > > draft-ietf-pce-stateful-path-protection-10: Discuss > > > > > > > > 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-stateful-path-protection/ > > > > > > > > > > > > > > > > -- > > > > DISCUSS: > > > > -- > > > > > > > > (1) draft-ietf-pce-association-group notes that "PCEP extensions that > > define > > > > a new association type should clarify the relationship between the SVEC > > > > object and the association type, if any". Where do we do so for the > > > > path protection association type? > > > > > > > > > > This is discussed in > > > > > https://tools.ietf.org/html/draft-ietf-pce-association-diversity-10#section-5.3 > > , > > > where it is more relevant. This draft includes the relationship with > > > diversity association in Section 5. > > > > A naive reading of the linked section would be that it applies only to the > > "Disjointness Association Type" defined in that document. I'm not in a > > position to claim that the reasoning in that document does not apply to > > this one, but I think we should make a more clear link between the Path > > Protection ASsociation Type and the discussion in that document. > > > > > > (2) Section 3.2 says: > > > > > > > > Protection Type (PT): 6 bits - This field is as defined in > > > > Section 14.1 of [RFC4872] to indicate the LSP protection type in > > > > use. > > > > > > > > There doesn't seem to be a registry created by RFC 4872 to track these > > > > PT values, so I assume that the way to allocate a new value is > > > > "standards-track RFC that Updates: RFC 4872". Is that also the way to > > > > allocate new PT values for PPAG usage? How would someone updating RFC > > > > 4872 to allocate a new type know to consider/document whether it > > applies > > > > for PPAG usage? > > > > > > > > > > That's true. Maybe we can add this text - "Any type already defined or > > > that could be defined in the future for use in the RSVP-TE PROTECTION > > > object is acceptable in this TLV unless explicitly stated otherwise." > > > > To be honest, that's probably good enough in practice, since it seems > > somewhat unlikely that the last bit is ever going to get allocated (though, > > I guess technically the field could be converted to an integer instead of > > flags). I do still have to wonder how the reader would know *where* it > > would be stated otherwise, and how the author of a document defining a new > > type would know to consider our use case as well as the RFC 4872 use case. > > > > > > (3) In Section 4.3: > > > > > > > >A PCE can create/update working and protection LSPs independently. > > > >As specified in [I-D.ietf-pce-association-group], Association Groups > > > >can be created by both the PCE and the PCC. Further, a PCE can > > > > > > > > The requirement that source,
Re: [Pce] Benjamin Kaduk's Discuss on draft-ietf-pce-stateful-path-protection-10: (with DISCUSS and COMMENT)
Hi Ben/Dhruv, Thanks for the review and clarification. Comments are incorporated in the working copy (links below). Working copy: https://github.com/mahendnegi/ietf/blob/master/pce/path-protection/iesg/draft-ietf-pce-stateful-path-protection-11.txt Diff: https://github.com/mahendnegi/ietf/commit/c51efb2b025d545e066b9b13de6d84de48d1a03c Please do share your opinion. Thanks, Mahendra On Fri, Sep 20, 2019 at 2:33 AM Benjamin Kaduk wrote: > Hi Dhruv, > > On Wed, Sep 18, 2019 at 11:45:23AM +0530, Dhruv Dhody wrote: > > Hi Ben, > > > > Thanks for your review, let me start the discussion and the authors > > can interject as needed. > > Thanks; it's a great start. > > > On Wed, Sep 18, 2019 at 5:14 AM Benjamin Kaduk via Datatracker > > wrote: > > > > > > Benjamin Kaduk has entered the following ballot position for > > > draft-ietf-pce-stateful-path-protection-10: Discuss > > > > > > 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-stateful-path-protection/ > > > > > > > > > > > > -- > > > DISCUSS: > > > -- > > > > > > (1) draft-ietf-pce-association-group notes that "PCEP extensions that > define > > > a new association type should clarify the relationship between the SVEC > > > object and the association type, if any". Where do we do so for the > > > path protection association type? > > > > > > > This is discussed in > > > https://tools.ietf.org/html/draft-ietf-pce-association-diversity-10#section-5.3 > , > > where it is more relevant. This draft includes the relationship with > > diversity association in Section 5. > > A naive reading of the linked section would be that it applies only to the > "Disjointness Association Type" defined in that document. I'm not in a > position to claim that the reasoning in that document does not apply to > this one, but I think we should make a more clear link between the Path > Protection ASsociation Type and the discussion in that document. > > > > (2) Section 3.2 says: > > > > > > Protection Type (PT): 6 bits - This field is as defined in > > > Section 14.1 of [RFC4872] to indicate the LSP protection type in > > > use. > > > > > > There doesn't seem to be a registry created by RFC 4872 to track these > > > PT values, so I assume that the way to allocate a new value is > > > "standards-track RFC that Updates: RFC 4872". Is that also the way to > > > allocate new PT values for PPAG usage? How would someone updating RFC > > > 4872 to allocate a new type know to consider/document whether it > applies > > > for PPAG usage? > > > > > > > That's true. Maybe we can add this text - "Any type already defined or > > that could be defined in the future for use in the RSVP-TE PROTECTION > > object is acceptable in this TLV unless explicitly stated otherwise." > > To be honest, that's probably good enough in practice, since it seems > somewhat unlikely that the last bit is ever going to get allocated (though, > I guess technically the field could be converted to an integer instead of > flags). I do still have to wonder how the reader would know *where* it > would be stated otherwise, and how the author of a document defining a new > type would know to consider our use case as well as the RFC 4872 use case. > > > > (3) In Section 4.3: > > > > > >A PCE can create/update working and protection LSPs independently. > > >As specified in [I-D.ietf-pce-association-group], Association Groups > > >can be created by both the PCE and the PCC. Further, a PCE can > > > > > > The requirement that source, destination, and tunnel ID of all LSPs > > > within a PPAG MUST be the same is new to this document, so I think we > > > need to specify error handling for when attempts to update LSPs > > > independently would violate that invariant (presumably in Section 4.5). > > > > > > > In the existing error case in Section 4.5 we could make it "add or > update". > > Wording it right might be a little finicky, but that's fine in general. > > > > (4) In Section 6.3: > > > > > > IANA is requested to allocate new > > >error values within the "PCEP-ERROR Object Error Types and Values" > > >sub-registry of the PCEP Numbers registry, as follows: > > > > > > The following table only lists Error-values. What Error-type(s) should > > > they be associated with? > > > > > > > It is mentioned in the text, but worth making it explicit in the table > as well. > > > > >
Re: [Pce] Benjamin Kaduk's Discuss on draft-ietf-pce-stateful-path-protection-10: (with DISCUSS and COMMENT)
Hi Dhruv, On Wed, Sep 18, 2019 at 11:45:23AM +0530, Dhruv Dhody wrote: > Hi Ben, > > Thanks for your review, let me start the discussion and the authors > can interject as needed. Thanks; it's a great start. > On Wed, Sep 18, 2019 at 5:14 AM Benjamin Kaduk via Datatracker > wrote: > > > > Benjamin Kaduk has entered the following ballot position for > > draft-ietf-pce-stateful-path-protection-10: Discuss > > > > 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-stateful-path-protection/ > > > > > > > > -- > > DISCUSS: > > -- > > > > (1) draft-ietf-pce-association-group notes that "PCEP extensions that define > > a new association type should clarify the relationship between the SVEC > > object and the association type, if any". Where do we do so for the > > path protection association type? > > > > This is discussed in > https://tools.ietf.org/html/draft-ietf-pce-association-diversity-10#section-5.3, > where it is more relevant. This draft includes the relationship with > diversity association in Section 5. A naive reading of the linked section would be that it applies only to the "Disjointness Association Type" defined in that document. I'm not in a position to claim that the reasoning in that document does not apply to this one, but I think we should make a more clear link between the Path Protection ASsociation Type and the discussion in that document. > > (2) Section 3.2 says: > > > > Protection Type (PT): 6 bits - This field is as defined in > > Section 14.1 of [RFC4872] to indicate the LSP protection type in > > use. > > > > There doesn't seem to be a registry created by RFC 4872 to track these > > PT values, so I assume that the way to allocate a new value is > > "standards-track RFC that Updates: RFC 4872". Is that also the way to > > allocate new PT values for PPAG usage? How would someone updating RFC > > 4872 to allocate a new type know to consider/document whether it applies > > for PPAG usage? > > > > That's true. Maybe we can add this text - "Any type already defined or > that could be defined in the future for use in the RSVP-TE PROTECTION > object is acceptable in this TLV unless explicitly stated otherwise." To be honest, that's probably good enough in practice, since it seems somewhat unlikely that the last bit is ever going to get allocated (though, I guess technically the field could be converted to an integer instead of flags). I do still have to wonder how the reader would know *where* it would be stated otherwise, and how the author of a document defining a new type would know to consider our use case as well as the RFC 4872 use case. > > (3) In Section 4.3: > > > >A PCE can create/update working and protection LSPs independently. > >As specified in [I-D.ietf-pce-association-group], Association Groups > >can be created by both the PCE and the PCC. Further, a PCE can > > > > The requirement that source, destination, and tunnel ID of all LSPs > > within a PPAG MUST be the same is new to this document, so I think we > > need to specify error handling for when attempts to update LSPs > > independently would violate that invariant (presumably in Section 4.5). > > > > In the existing error case in Section 4.5 we could make it "add or update". Wording it right might be a little finicky, but that's fine in general. > > (4) In Section 6.3: > > > > IANA is requested to allocate new > >error values within the "PCEP-ERROR Object Error Types and Values" > >sub-registry of the PCEP Numbers registry, as follows: > > > > The following table only lists Error-values. What Error-type(s) should > > they be associated with? > > > > It is mentioned in the text, but worth making it explicit in the table as > well. > > > (5) We don't say which objects the PPAG TLV can appear in. (Section 3.2 > > says "[t]he Path Protection Association TLV is an optional TLV for use > > with the Path Protection Association Type", but it's hard to interpret > > that as meaning "for use [only] with the ASSOCIATION object defined in > > draft-ietf-pce-association-group", especially since there is a "path > > protection association type" already (and it's a codepoint in the > > "ASSOCIATION Type Field" registry). > > > > We can update to - "The Path Protection Association TLV is an optional > TLV for use in the ASSOCIATION Object with the Path Protection > Association Type." Thanks!
Re: [Pce] Benjamin Kaduk's Discuss on draft-ietf-pce-stateful-path-protection-10: (with DISCUSS and COMMENT)
Hi Ben, Thanks for your review, let me start the discussion and the authors can interject as needed. On Wed, Sep 18, 2019 at 5:14 AM Benjamin Kaduk via Datatracker wrote: > > Benjamin Kaduk has entered the following ballot position for > draft-ietf-pce-stateful-path-protection-10: Discuss > > 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-stateful-path-protection/ > > > > -- > DISCUSS: > -- > > (1) draft-ietf-pce-association-group notes that "PCEP extensions that define > a new association type should clarify the relationship between the SVEC > object and the association type, if any". Where do we do so for the > path protection association type? > This is discussed in https://tools.ietf.org/html/draft-ietf-pce-association-diversity-10#section-5.3, where it is more relevant. This draft includes the relationship with diversity association in Section 5. > (2) Section 3.2 says: > > Protection Type (PT): 6 bits - This field is as defined in > Section 14.1 of [RFC4872] to indicate the LSP protection type in > use. > > There doesn't seem to be a registry created by RFC 4872 to track these > PT values, so I assume that the way to allocate a new value is > "standards-track RFC that Updates: RFC 4872". Is that also the way to > allocate new PT values for PPAG usage? How would someone updating RFC > 4872 to allocate a new type know to consider/document whether it applies > for PPAG usage? > That's true. Maybe we can add this text - "Any type already defined or that could be defined in the future for use in the RSVP-TE PROTECTION object is acceptable in this TLV unless explicitly stated otherwise." > (3) In Section 4.3: > >A PCE can create/update working and protection LSPs independently. >As specified in [I-D.ietf-pce-association-group], Association Groups >can be created by both the PCE and the PCC. Further, a PCE can > > The requirement that source, destination, and tunnel ID of all LSPs > within a PPAG MUST be the same is new to this document, so I think we > need to specify error handling for when attempts to update LSPs > independently would violate that invariant (presumably in Section 4.5). > In the existing error case in Section 4.5 we could make it "add or update". > (4) In Section 6.3: > > IANA is requested to allocate new >error values within the "PCEP-ERROR Object Error Types and Values" >sub-registry of the PCEP Numbers registry, as follows: > > The following table only lists Error-values. What Error-type(s) should > they be associated with? > It is mentioned in the text, but worth making it explicit in the table as well. > (5) We don't say which objects the PPAG TLV can appear in. (Section 3.2 > says "[t]he Path Protection Association TLV is an optional TLV for use > with the Path Protection Association Type", but it's hard to interpret > that as meaning "for use [only] with the ASSOCIATION object defined in > draft-ietf-pce-association-group", especially since there is a "path > protection association type" already (and it's a codepoint in the > "ASSOCIATION Type Field" registry). > We can update to - "The Path Protection Association TLV is an optional TLV for use in the ASSOCIATION Object with the Path Protection Association Type." > (6) I'm not sure if a change to the document is needed here, but perhaps > some discussion is in order: we say that a given LSP can belong to more > than one PPAG, but only allow one PPAG TLV per [some context that > remains unclear; see (5)]. I don't have a good handle for whether these > two requirements are potentially in conflict: that is, whether a single > PPAG TLV would have to specify the flags that apply for both PPAGs that > a given LSP is a member of, or if the containing objects serve to scope > the PPAG TLV flags' interpretation. > When a given LSP belong to more than one PPAG, we expect to have multiple ASSOCIATION Object for each PPAG with each of them having a single PPAG TLV. > (7) Do the Protection Type fields of the PPAG TLV in the various LSPs > that are members of the same PPAG need to match, in the same way that > the source/destination/tunnel-ID do? > Yes. Authors should make that explicit. > > -- > COMMENT: > -- > > Section 1 > >This document specifies a stateful PCEP extension to
[Pce] Benjamin Kaduk's Discuss on draft-ietf-pce-stateful-path-protection-10: (with DISCUSS and COMMENT)
Benjamin Kaduk has entered the following ballot position for draft-ietf-pce-stateful-path-protection-10: Discuss 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-stateful-path-protection/ -- DISCUSS: -- (1) draft-ietf-pce-association-group notes that "PCEP extensions that define a new association type should clarify the relationship between the SVEC object and the association type, if any". Where do we do so for the path protection association type? (2) Section 3.2 says: Protection Type (PT): 6 bits - This field is as defined in Section 14.1 of [RFC4872] to indicate the LSP protection type in use. There doesn't seem to be a registry created by RFC 4872 to track these PT values, so I assume that the way to allocate a new value is "standards-track RFC that Updates: RFC 4872". Is that also the way to allocate new PT values for PPAG usage? How would someone updating RFC 4872 to allocate a new type know to consider/document whether it applies for PPAG usage? (3) In Section 4.3: A PCE can create/update working and protection LSPs independently. As specified in [I-D.ietf-pce-association-group], Association Groups can be created by both the PCE and the PCC. Further, a PCE can The requirement that source, destination, and tunnel ID of all LSPs within a PPAG MUST be the same is new to this document, so I think we need to specify error handling for when attempts to update LSPs independently would violate that invariant (presumably in Section 4.5). (4) In Section 6.3: IANA is requested to allocate new error values within the "PCEP-ERROR Object Error Types and Values" sub-registry of the PCEP Numbers registry, as follows: The following table only lists Error-values. What Error-type(s) should they be associated with? (5) We don't say which objects the PPAG TLV can appear in. (Section 3.2 says "[t]he Path Protection Association TLV is an optional TLV for use with the Path Protection Association Type", but it's hard to interpret that as meaning "for use [only] with the ASSOCIATION object defined in draft-ietf-pce-association-group", especially since there is a "path protection association type" already (and it's a codepoint in the "ASSOCIATION Type Field" registry). (6) I'm not sure if a change to the document is needed here, but perhaps some discussion is in order: we say that a given LSP can belong to more than one PPAG, but only allow one PPAG TLV per [some context that remains unclear; see (5)]. I don't have a good handle for whether these two requirements are potentially in conflict: that is, whether a single PPAG TLV would have to specify the flags that apply for both PPAGs that a given LSP is a member of, or if the containing objects serve to scope the PPAG TLV flags' interpretation. (7) Do the Protection Type fields of the PPAG TLV in the various LSPs that are members of the same PPAG need to match, in the same way that the source/destination/tunnel-ID do? -- COMMENT: -- Section 1 This document specifies a stateful PCEP extension to associate two or more LSPs for the purpose of setting up path protection. The proposed extension covers the following scenarios: nit: after publication, it doesn't really seem like a *proposed* extension anymore. Section 3.1 LSPs are not associated by listing the other LSPs with which they interact, but rather by making them belong to an association group referred to as "Path Protection Association Group" (PPAG) in this document. [...] The first 2/3 of this sentence is a (true) generic statement about all association groups, which exist outside of this document in a generic fashion. I strongly suggest rewording this to make clear that the PPAG is the specific association (group) type used for this document's functionality but that other association groups are possible. The current wording implies that the PPAG is the only association possible, and it is just given a special name for this document's purposes. [I-D.ietf-pce-association-group] specifies the mechanism for the capability advertisement of the Association types supported by a PCEP speaker by defining a ASSOC-Type-List TLV to be carried within an OPEN object. This capability exchange for the Association type described in this document (i.e.
