Re: [Pce] AD review of draft-ietf-pce-local-protection-enforcement-08

[Andrew Stone (Nokia)]

Hi John, PCE WG

New version -09 has been posted [1]. Hopefully this helps clear up the 
discussion comments below.

Summary:

- Reduced the verbosity in the introduction regarding segment routing background
- Added comment regarding control/data plane applicability and prefixed SR 
specific comments
- Moved preferred content from section 5 to section 4 and consolidated the 
wording with 'do not care'
- Various nits that were caught in review

Thanks again for the review! 
Andrew

[1] 
https://author-tools.ietf.org/iddiff?url1=draft-ietf-pce-local-protection-enforcement-08=draft-ietf-pce-local-protection-enforcement-09=--html



On 2023-04-24, 7:13 PM, "Andrew Stone (Nokia)" mailto:andrew.st...@nokia.com>> wrote:


Hi John,


Thank you very much for the review and including the inline diff, made it 
easier to follow. 


Good observation and point about it being technology-agnostic. It was motivated 
by SR, but as you point out the E+F flags descriptions and behavior 
clarifications may be applicable outside of SR in ways I'm unaware of or don't 
exist yet. The introduction was intended to build context in the purpose of the 
draft, not necessarily a tutorial on SR, but I can see how it may be a bit 
heavy for that purpose. Considering these two observations perhaps the SR 
specific discussions from the introduction would be better to move to section 
4.2, and the introduction include statements about technology applicability? 
And where applicable, the use of 'SID' outside of that section can be amended 
where applicable? There are some recommendation text embedded in the document 
that should be kept (ex: 5.2: .It is RECOMMENDED . assume a Node SID is 
protected ...RECOMMENDED ... assume an Adjacency SID is protected if the backup 
flag advertised ). Perhaps those can be pre-ambled with "If the technology 
is SR then ..." ? Do you think this would help clarify what portions are 
agnostic vs SR specific?


Further replies in-line below with >>[Andrew].  blocks. 


Will adopt your editorial changes and address discussions for a new revision 
soon. 


Thanks again,
Andrew










On 2023-04-20, 3:35 PM, "John Scudder" mailto:j...@juniper.net> >> 
wrote:
CAUTION: This is an external email. Please be very careful when clicking links 
or opening attachments. See the URL nok.it/ext for additional information.


Hi Authors, WG,


Thanks for this spec. I can see the need to clear up this ambiguity.




I’ve supplied most of my questions and comments in the form of an edited copy 
of the draft. Minor editorial suggestions I’ve made in place without further 
comment, most of my more substantive questions and comments are done in-line 
and prefixed with “jgs:”. You can use your favorite diff tool to review them; 
I’ve attached the iddiff output for your convenience if you’d like to use it. 
I’ve also pasted a traditional diff below in case you want to use it for 
in-line reply.




In addition to my various inline comments, I have a general question/comment. 
The spec, as far as I can tell, is technology-agnostic: it introduces the E 
flag and codifies the interpretation of the E+L flags. It doesn’t restrict this 
to any particular data plane. That seems like the right choice. But, the draft 
also opens with several paragraphs of discussion of Segment Routing in the 
Introduction, and its normative language is SR-specific (search for “SID” in 
the document to see what I mean, SIDs are an SR construct).




Is the applicability of the document intended to be specific to Segment 
Routing? If so I think this needs to be made clearer. Or, if the document is 
NOT intended to be restricted to SR, then revisions are needed everywhere after 
the Introduction where the string ‘SID’ occurs, to make it technology-agnostic. 
(Less importantly, one might also ask why the Introduction needs to contain a 
tutorial on SR.)




Thanks,


—John




--- draft-ietf-pce-local-protection-enforcement-08.txt 2023-04-20 
14:28:28.0 -0400
+++ draft-ietf-pce-local-protection-enforcement-08-jgs-comments.txt 2023-04-20 
15:25:51.0 -0400
@@ -148,15 +148,21 @@
calculated to include other segment identifiers which are not
applicable to having their protection state advertised, as they may
only be locally significant for each router processing the SID, such
- as Node SIDs, it may not be possible for PCE to include the
+ as Node SIDs, it may not be possible for the PCE to include the
protection constraint as part of the path calculation.




- It is desirable for an operator to define the enforcement, or
+ It is desirable for an operator to be able to define the enforcement, or
strictness of the protection requirement when it can be applied.
+---
+jgs: I don't follow what you mean by "... or strictness of the protection
+requirement when it can be applied." I'm getting hung up on the "when it
+can be applied" part. Would it be correct to just delete those words? 

Re: [Pce] AD review of draft-ietf-pce-local-protection-enforcement-08

[Andrew Stone (Nokia)]

Hi John,

Thank you very much for the review and including the inline diff, made it 
easier to follow. 

Good observation and point about it being technology-agnostic. It was motivated 
by SR, but as you point out the E+F flags descriptions and behavior 
clarifications may be applicable outside of SR in ways I'm unaware of or don't 
exist yet. The introduction was intended to build context in the purpose of the 
draft, not necessarily a tutorial on SR, but I can see how it may be a bit 
heavy for that purpose. Considering these two observations perhaps the SR 
specific discussions from the introduction would be better to move to section 
4.2, and the introduction include statements about technology applicability? 
And where applicable, the use of 'SID' outside of that section can be amended 
where applicable? There are some recommendation text embedded in the document 
that should be kept (ex: 5.2: .It is RECOMMENDED . assume a Node SID is 
protected ...RECOMMENDED ... assume an Adjacency SID is protected if the backup 
flag advertised ). Perhaps those can be pre-ambled with "If the technology 
is SR then ..." ? Do you think this would help clarify what portions are 
agnostic vs SR specific?

Further replies in-line below with >>[Andrew].  blocks. 

Will adopt your editorial changes and address discussions for a new revision 
soon. 

Thanks again,
Andrew





On 2023-04-20, 3:35 PM, "John Scudder" mailto:j...@juniper.net>> wrote:
CAUTION: This is an external email. Please be very careful when clicking links 
or opening attachments. See the URL nok.it/ext for additional information.

Hi Authors, WG,

Thanks for this spec. I can see the need to clear up this ambiguity.


I’ve supplied most of my questions and comments in the form of an edited copy 
of the draft. Minor editorial suggestions I’ve made in place without further 
comment, most of my more substantive questions and comments are done in-line 
and prefixed with “jgs:”. You can use your favorite diff tool to review them; 
I’ve attached the iddiff output for your convenience if you’d like to use it. 
I’ve also pasted a traditional diff below in case you want to use it for 
in-line reply.


In addition to my various inline comments, I have a general question/comment. 
The spec, as far as I can tell, is technology-agnostic: it introduces the E 
flag and codifies the interpretation of the E+L flags. It doesn’t restrict this 
to any particular data plane. That seems like the right choice. But, the draft 
also opens with several paragraphs of discussion of Segment Routing in the 
Introduction, and its normative language is SR-specific (search for “SID” in 
the document to see what I mean, SIDs are an SR construct).


Is the applicability of the document intended to be specific to Segment 
Routing? If so I think this needs to be made clearer. Or, if the document is 
NOT intended to be restricted to SR, then revisions are needed everywhere after 
the Introduction where the string ‘SID’ occurs, to make it technology-agnostic. 
(Less importantly, one might also ask why the Introduction needs to contain a 
tutorial on SR.)


Thanks,

—John


--- draft-ietf-pce-local-protection-enforcement-08.txt 2023-04-20 
14:28:28.0 -0400
+++ draft-ietf-pce-local-protection-enforcement-08-jgs-comments.txt 2023-04-20 
15:25:51.0 -0400
@@ -148,15 +148,21 @@
calculated to include other segment identifiers which are not
applicable to having their protection state advertised, as they may
only be locally significant for each router processing the SID, such
- as Node SIDs, it may not be possible for PCE to include the
+ as Node SIDs, it may not be possible for the PCE to include the
protection constraint as part of the path calculation.


- It is desirable for an operator to define the enforcement, or
+ It is desirable for an operator to be able to define the enforcement, or
strictness of the protection requirement when it can be applied.
+---
+jgs: I don't follow what you mean by "... or strictness of the protection
+requirement when it can be applied." I'm getting hung up on the "when it
+can be applied" part. Would it be correct to just delete those words? Or
+if it wouldn't, can you help me understand what work they're doing? Thanks.
+---

 
[Andrew] "When it can be applied" was intended to suggest to a reader that 
there may be scenarios where the PCE is simply unaware whether a given resource 
is protected or not, or may even need to make assumptions on it's protected 
state because the information may not be available (knowledge if Node SID is 
protected by all nodes along the path). It's likely redundant and can be 
removed (PCE can't enforce what it doesn't know). Will adjust.





@@ -286,6 +292,25 @@
the PCE a preference on which SID to select, as the behaviour of the
LSP would differ during a local failure depending on which SID is
selected.
+---
+jgs: I thought this paragraph was going to answer a question I