Subject: Re: [spring] Ben Campbell's No Objection on draft-ietf-spring-segment-routing-13: (with COMMENT)

From: Ben Campbell <[email-masked]>
Date: Tue, 2 Jan 2018 18:17:28 -0600

Hi, thanks for the response. Comments inline:

> On Dec 20, 2017, at 5:35 PM, Les Ginsberg (ginsberg) <[email-masked]> wrote:
> 
> Ben -
> 
> Thanx for the review.
> V14 has been published and it attempts to address the Security concerns.
> Look forward to your feedback.

It’s not clear to me how the new version addresses Adam’s major comment or Alissa’s second DISCUSS point. But it’s probably best to discuss those points directly with Adam and Alissa.

[…]

>> 
>> 
>> ----------------------------------------------------------------------
>> COMMENT:
>> ----------------------------------------------------------------------
>> 
>> Substantive Comments:
>> 
>> - I support Alissa's discuss and Adam's major comment.
>> 
>> - Requirements Language: There are lower case instances of 2119 keywords.
>> Unless you mean for those to also be normative, please use the boilerplate
>> from RFC 8174.
>> 
>> -3.1.1, last paragraph: Why are the SHOULDs not MUSTs?
>> 
> [Les:] Failure to do the validation will result in the packet being dropped when it reaches a node which does not support the algorithm i.e., the algorithm specific label will not match any installed incoming label. This is sub-optimal but not fatal - hence SHOULD rather than MUST.

Do you think that would ever be a reasonable implementation choice? If so, it would help to add a sentence or two about the consequences into the text.

> 
>> -12.2: The citations to the following references seem to be used normatively:
>> I-D.ietf-6man-segment-routing-header
>> I-D.ietf-isis-segment-routing-extensions
>> I-D.ietf-ospf-ospfv3-segment-routing-extensions
>> I-D.ietf-ospf-segment-routing-extensions
>> 
> [Les:] I respectfully disagree.
> The architecture document is NOT dependent upon the IGP/6man documents - the dependency is the other way around.
> The referenced documents are useful for readers who wish to better understand how the architecture is supported by routing protocols/IPv6 - but there is no dependency that the architecture definition has on the implementation specifics.

A reference is normative if reading it is necessary to understand or implement this draft.  I-D.ietf-6man-segment-routing-header is referenced several times in the security considerations section in a way that seems to make the security considerations incomplete unless you read that. The other 3 seem necessary to implement IGP segment advertising as described in section 3.

[…]

---

From: "Les Ginsberg (ginsberg)" <[email-masked]>
Date: Wed, 3 Jan 2018 01:00:15 +0000

Ben -

Inline.

> -----Original Message-----
> From: Ben Campbell [mailto:[email-masked]]
> Sent: Tuesday, January 02, 2018 4:17 PM
> To: Les Ginsberg (ginsberg) <[email-masked]>
> Cc: The IESG <[email-masked]>; [email-masked]; [email-masked];
> [email-masked]; [email-masked];
> [email-masked]
> Subject: Re: [spring] Ben Campbell's No Objection on draft-ietf-spring-
> segment-routing-13: (with COMMENT)
> 
> It’s not clear to me how the new version addresses Adam’s major comment
> or Alissa’s second DISCUSS point. But it’s probably best to discuss those
> points directly with Adam and Alissa.
> 
[Les:] Adam has already responded positively. He made a suggestion for clarifying text which I agreed to put into the next version.
Will wait to hear from Alissa.

> >> Unless you mean for those to also be normative, please use the
> >> boilerplate from RFC 8174.
> >>
> > [Les:] Failure to do the validation will result in the packet being dropped
> when it reaches a node which does not support the algorithm i.e., the
> algorithm specific label will not match any installed incoming label. This is sub-
> optimal but not fatal - hence SHOULD rather than MUST.
> 
> Do you think that would ever be a reasonable implementation choice? If so,
> it would help to add a sentence or two about the consequences into the
> text.
>
[Les:] I can add some text.
 
> > The architecture document is NOT dependent upon the IGP/6man
> documents - the dependency is the other way around.
> > The referenced documents are useful for readers who wish to better
> understand how the architecture is supported by routing protocols/IPv6 - but
> there is no dependency that the architecture definition has on the
> implementation specifics.
> 
> A reference is normative if reading it is necessary to understand or
> implement this draft.  I-D.ietf-6man-segment-routing-header is referenced
> several times in the security considerations section in a way that seems to
> make the security considerations incomplete unless you read that. The other
> 3 seem necessary to implement IGP segment advertising as described in
> section 3.
> 
[Les:] This is still a point of disagreement. 

This is an architecture document - not an implementation document. Solely using this document it is not possible to implement anything because the document does not specify any implementation. It does provide the framework for all implementation related SR drafts.
The architecture draft stands on its own. We could eliminate all of the SR draft references and the document would still be complete.  But, it is certainly helpful to one's understanding of the architecture to read about how it is implemented - and we therefore have provided informational references for those documents which currently exist(sic) and seem relevant as an aid to the reader. But that does not make the architecture document dependent on these references.

To do what you suggest would create a two way dependency between the architecture document and every other segment routing specification. As per https://www.ietf.org/iesg/statement/normative-informative.html 

" An RFC cannot be published until all of the documents that it lists as normative references have been published."

Given that there are many implementation related SR related drafts which are in various stages of being written - as well as many such drafts which have yet to be written, at what point can we declare the architecture document publishable?

   Les

---

From: Ben Campbell <[email-masked]>
Date: Tue, 2 Jan 2018 20:44:16 -0600

More on the one point:

> On Jan 2, 2018, at 7:00 PM, Les Ginsberg (ginsberg) <[email-masked]> wrote:
> 
>>> 
>>> 

It’s fairly common to have a standard track document that describes things at a high level and normatively depends on other drafts for details. On re-scanning the draft, I don’t see text to indicate that this was not the intent. It’s entirely possible I missed something.

I think the issue is that the draft is not clear about it’s purpose and relation to the extension drafts. As far as I can tell, there is no text in the abstract or introduction that says that this is an architecture draft. Some text in the abstract to say that this is an architecture, and some text in the introduction to expand on that and to talk about it’s relationship to the extension drafts would help.

For example, as the text stands now I have trouble reading section 3 any way except to say “Segment routing requires advertising IGP segments. You can do that using one of these referenced drafts”. That’s why I thought the references should be normative.

Now, if what you mean to say is “Defining segment routing requires defining how you reference IGP segments. That work is ongoing at the time of this writing. See the referenced drafts for the status of that work”, then the references would seem informational.

> " An RFC cannot be published until all of the documents that it lists as normative references have been published.”
> 

As mentioned above, I would not object to calling these informational references with some clarifying text about the purpose of this draft and it’s relationship to the referenced drafts.

Ben.

---

From: "Les Ginsberg (ginsberg)" <[email-masked]>
Date: Wed, 3 Jan 2018 21:28:39 +0000

Ben -

I want to emphasize that we have a common goal - we both want the document to be clear on its scope and relationship to other documents.

I think the document as written is clear (more on that below) - but as I am one of the authors it may be that I do not see omissions as clearly as a reader who comes without the underlying context that document writers develop. Your fresh perspective is a valuable input that I do not want to ignore.

The title of the document is "Segment Routing Architecture".

The phrase "SR Architecture" is used numerous times throughout the document.

I am not sure how we could be more clear about the intent.

Certainly stating that this is an architecture document would be redundant and I am not sure what value that adds.

You are concerned that the relationship between this document and the numerous documents which define how to implement portions of the architecture is not clear - but to me this is implicit in the notion of "architecture" - which defines the structure and design of something. Is it necessary to make it explicit that an architecture document is NOT defining implementation nor does it need to do so? For example, does it make a difference to the architecture in what container a protocol advertises a SID? It certainly could make a significant difference as to the ease of maintaining a database (for example), but redefining a protocol advertisement makes no difference to the architecture definition.

That said, here is some proposed text that could be inserted into the Introduction. I am not fully convinced this is needed and/or is truly helpful, but if it helps you as a reader to have a clearer understanding then that may be sufficient justification. Let me know what you think. If it seems helpful to you then it can be reviewed by the other co-authors.

"This document defines the architecture for Segment Routing, including definitions of basic objects and functions and a description of the overall design.

It does NOT define the means of implementing the architecture - that is contained in numerous referencing documents, some of which are mentioned in this document as a convenience to the reader."

   Les

> Sent: Tuesday, January 02, 2018 6:44 PM

> > On Jan 2, 2018, at 7:00 PM, Les Ginsberg (ginsberg) <[email-masked]<mailto:[email-masked]>>

> wrote:

> >>>> -12.2: The citations to the following references seem to be used

> >> normatively:

> >> understand how the architecture is supported by routing

> >> protocols/IPv6 - but there is no dependency that the architecture

> >> definition has on the implementation specifics.

> >> implement this draft.  I-D.ietf-6man-segment-routing-header is

> >> referenced several times in the security considerations section in a

> >> way that seems to make the security considerations incomplete unless

> >> you read that. The other

> > This is an architecture document - not an implementation document. Solely

> using this document it is not possible to implement anything because the

> document does not specify any implementation. It does provide the

> framework for all implementation related SR drafts.

> > The architecture draft stands on its own. We could eliminate all of the SR

> draft references and the document would still be complete.  But, it is

> certainly helpful to one's understanding of the architecture to read about

> how it is implemented - and we therefore have provided informational

> references for those documents which currently exist(sic) and seem relevant

> as an aid to the reader. But that does not make the architecture document

> dependent on these references.

> It’s fairly common to have a standard track document that describes things at

> a high level and normatively depends on other drafts for details. On re-

> scanning the draft, I don’t see text to indicate that this was not the intent.

> It’s entirely possible I missed something.

> I think the issue is that the draft is not clear about it’s purpose and relation to

> the extension drafts. As far as I can tell, there is no text in the abstract or

> introduction that says that this is an architecture draft. Some text in the

> abstract to say that this is an architecture, and some text in the introduction

> to expand on that and to talk about it’s relationship to the extension drafts

> would help.

> For example, as the text stands now I have trouble reading section 3 any way

> except to say “Segment routing requires advertising IGP segments. You can

> do that using one of these referenced drafts”. That’s why I thought the

> references should be normative.

> Now, if what you mean to say is “Defining segment routing requires defining

> how you reference IGP segments. That work is ongoing at the time of this

> writing. See the referenced drafts for the status of that work”, then the

> references would seem informational.

> > To do what you suggest would create a two way dependency between the

> > architecture document and every other segment routing specification.

> > As per https://www.ietf.org/iesg/statement/normative-informative.html

> > " An RFC cannot be published until all of the documents that it lists as

> normative references have been published.”

> > Given that there are many implementation related SR related drafts which

> are in various stages of being written - as well as many such drafts which

> have yet to be written, at what point can we declare the architecture

> document publishable?

> As mentioned above, I would not object to calling these informational

> references with some clarifying text about the purpose of this draft and it’s

> relationship to the referenced drafts.