Re: [spring] WG LC for draft-ietf-spring-segment-routing

[Stefano Previdi (sprevidi)]

On Nov 30, 2016, at 2:27 PM, Stewart Bryant  wrote:
> On 30/11/2016 10:38, Stefano Previdi (sprevidi) wrote:
>>> On Nov 29, 2016, at 8:21 PM, Stewart Bryant  
>>> wrote:
>>> 
>>> The following are my comments on this text in response to the WGLC.
>>> A lot of comments are embedded in the draft text below.
>>> 
>>> However I have some major overarching comments. Although this is called
>>> an architecture it seems to be rather more of a description of how
>>> a large number of other documents combine to produce an overall
>>> specification for SR.
>> 
>> the references points to protocol extensions that would allow to implement 
>> the architecture. Then, you have other documents describing the use cases.
>> 
>> We’ve been debating quite a bit at the time of the spring wg forming and we 
>> agreed to separate these topics (i.e.: architecture, protocol extensions and 
>> use cases).
> 
> Separating them is fine, and having a use case dependency i.e. requirements 
> is OK, so long as the IESG agree to publish them (there is a policy decision 
> that makes this less automatic than it used to be).


indeed, things have slightly changed since the time the WG has been 
authoritatively formed...


> However I think the architecture really needs to stand alone and above the 
> implementations.
> 
>> 
>> Now, of course, having these references may impact the publication process 
>> of the architecture draft and maybe we should revisit many of the references.
> 
> That would be wise. Also because you are changing the IPv6 dataplane, I don't 
> think you can assume it is done until it is done and yet you have a lot of 
> detail in the architecture. I don't see why the architecture needs any of 
> that detail. At the arch level you really just have a list of instructions 
> yet to be executed and everything else is implementation of that architecture.
> 
>> 
>> Having said that, having a document with all the pointers to use cases and 
>> protocols helps the reader.
>> 
>> 
>>> Certainly for an architecture the number
>>> of forward references to detailed solutions for a description of the
>>> concept is quite extraordinary.
>>> 
>>> So embedded is the contents of some of these referenced documents
>>> that I do not think that it safe to publish this text other than
>>> synchronously with some of those documents. This is absolutely the case
>>> for the dataplane definitions, especially for IPv6, but seems
>>> likely to apply to other references. The further implication of
>>> the constant dependence on other documents is that many of them
>>> are really normative rather  than informative references, making
>>> this document a hostage to their fate.
>>> 
>>> It is far more conventional in an architecture to set out the general
>>> description and state the invariants, and put the detail into
>>> specific protocol documents, but to have the architecture as a
>>> standalone text. In other words to set things out so that
>>> the reader understands how components fit together, what the subtleties
>>> are and what the constraints on the components are, but leave the
>>> component design decisions to the component designers.
>> 
>> we can easily re-phrase most of the sections and remove some of the 
>> references so to free (or relax) most of the dependencies.
> That would be a good idea.


we’re in sync then.


>>> Clearly I think this draft needs significant work before it is
>>> ready for submission to the IESG for publication.
>> 
>> Well, I think it may require some editorial changes but I think the 
>> architecture structure and component is pretty solid... otherwise we 
>> wouldn’t have multi-vendor implementations and deployments...
> 
> I agree that the MPLS side is likely to be safe.


well, even for SR IPv6 we do have multivendor implementations.

s.


> I don't think IP is as safe and will not do so until I actually see it in the 
> RFC editor's queue. I do worry that the stack/(list+pointer) + address scope 
> differences may lead to design stress going forward.
> 
> I have not looked at the detail of the sub-components yet.
> 
>> 
>> I’ll go through your other comments in a separate email.
>> 
>> Thanks.
>> s.
>> 
> 
> - Stewart
> 
>> 
>>> - Stewart
>>> 
>>> 
>>> 
>>> 
>>> Network Working Group   C. Filsfils, Ed.
>>> Internet-Draft   S. Previdi, Ed.
>>> Intended status: Standards Track Cisco Systems, Inc.
>>> Expires: May 23, 2017B. Decraene
>>>S. Litkowski
>>>  Orange
>>>   R. Shakir
>>>  Google
>>>   November 19, 2016
>>> 
>>> 
>>>

Re: [spring] WG LC for draft-ietf-spring-segment-routing

[Stewart Bryant]

On 30/11/2016 10:38, Stefano Previdi (sprevidi) wrote:

On Nov 29, 2016, at 8:21 PM, Stewart Bryant  wrote:

The following are my comments on this text in response to the WGLC.
A lot of comments are embedded in the draft text below.

However I have some major overarching comments. Although this is called
an architecture it seems to be rather more of a description of how
a large number of other documents combine to produce an overall
specification for SR.


the references points to protocol extensions that would allow to implement the 
architecture. Then, you have other documents describing the use cases.

We’ve been debating quite a bit at the time of the spring wg forming and we 
agreed to separate these topics (i.e.: architecture, protocol extensions and 
use cases).


Separating them is fine, and having a use case dependency i.e. 
requirements is OK, so long as the IESG agree to publish them (there is 
a policy decision that makes this less automatic than it used to be). 
However I think the architecture really needs to stand alone and above 
the implementations.




Now, of course, having these references may impact the publication process of 
the architecture draft and maybe we should revisit many of the references.


That would be wise. Also because you are changing the IPv6 dataplane, I 
don't think you can assume it is done until it is done and yet you have 
a lot of detail in the architecture. I don't see why the architecture 
needs any of that detail. At the arch level you really just have a list 
of instructions yet to be executed and everything else is implementation 
of that architecture.




Having said that, having a document with all the pointers to use cases and 
protocols helps the reader.



Certainly for an architecture the number
of forward references to detailed solutions for a description of the
concept is quite extraordinary.

So embedded is the contents of some of these referenced documents
that I do not think that it safe to publish this text other than
synchronously with some of those documents. This is absolutely the case
for the dataplane definitions, especially for IPv6, but seems
likely to apply to other references. The further implication of
the constant dependence on other documents is that many of them
are really normative rather  than informative references, making
this document a hostage to their fate.

It is far more conventional in an architecture to set out the general
description and state the invariants, and put the detail into
specific protocol documents, but to have the architecture as a
standalone text. In other words to set things out so that
the reader understands how components fit together, what the subtleties
are and what the constraints on the components are, but leave the
component design decisions to the component designers.


we can easily re-phrase most of the sections and remove some of the references 
so to free (or relax) most of the dependencies.

That would be a good idea.



Clearly I think this draft needs significant work before it is
ready for submission to the IESG for publication.


Well, I think it may require some editorial changes but I think the 
architecture structure and component is pretty solid... otherwise we wouldn’t 
have multi-vendor implementations and deployments...


I agree that the MPLS side is likely to be safe. I don't think IP is as 
safe and will not do so until I actually see it in the RFC editor's 
queue. I do worry that the stack/(list+pointer) + address scope 
differences may lead to design stress going forward.


I have not looked at the detail of the sub-components yet.



I’ll go through your other comments in a separate email.

Thanks.
s.



- Stewart




- Stewart




Network Working Group   C. Filsfils, Ed.
Internet-Draft   S. Previdi, Ed.
Intended status: Standards Track Cisco Systems, Inc.
Expires: May 23, 2017B. Decraene
S. Litkowski
  Orange
   R. Shakir
  Google
   November 19, 2016


  Segment Routing Architecture
  draft-ietf-spring-segment-routing-10

Abstract

   Segment Routing (SR) leverages the source routing paradigm.  A node
   steers a packet through an ordered list of instructions, called
   segments.  A segment can represent any instruction, topological or
   service-based.  A segment can have a local semantic to an SR node or
   global within an SR domain.  SR allows to enforce a flow through any
   topological path and service chain while maintaining per-flow state
   only at the ingress node to the SR 

Re: [spring] WG LC for draft-ietf-spring-segment-routing

[Stefano Previdi (sprevidi)]

> On Nov 29, 2016, at 8:21 PM, Stewart Bryant  wrote:
> 
> The following are my comments on this text in response to the WGLC.
> A lot of comments are embedded in the draft text below.
> 
> However I have some major overarching comments. Although this is called
> an architecture it seems to be rather more of a description of how
> a large number of other documents combine to produce an overall
> specification for SR.


the references points to protocol extensions that would allow to implement the 
architecture. Then, you have other documents describing the use cases.

We’ve been debating quite a bit at the time of the spring wg forming and we 
agreed to separate these topics (i.e.: architecture, protocol extensions and 
use cases).

Now, of course, having these references may impact the publication process of 
the architecture draft and maybe we should revisit many of the references.

Having said that, having a document with all the pointers to use cases and 
protocols helps the reader.


> Certainly for an architecture the number
> of forward references to detailed solutions for a description of the
> concept is quite extraordinary.
> 
> So embedded is the contents of some of these referenced documents
> that I do not think that it safe to publish this text other than
> synchronously with some of those documents. This is absolutely the case
> for the dataplane definitions, especially for IPv6, but seems
> likely to apply to other references. The further implication of
> the constant dependence on other documents is that many of them
> are really normative rather  than informative references, making
> this document a hostage to their fate.
> 
> It is far more conventional in an architecture to set out the general
> description and state the invariants, and put the detail into
> specific protocol documents, but to have the architecture as a
> standalone text. In other words to set things out so that
> the reader understands how components fit together, what the subtleties
> are and what the constraints on the components are, but leave the
> component design decisions to the component designers.


we can easily re-phrase most of the sections and remove some of the references 
so to free (or relax) most of the dependencies.


> Clearly I think this draft needs significant work before it is
> ready for submission to the IESG for publication.


Well, I think it may require some editorial changes but I think the 
architecture structure and component is pretty solid... otherwise we wouldn’t 
have multi-vendor implementations and deployments... 

I’ll go through your other comments in a separate email.

Thanks.
s.



> 
> - Stewart
> 
> 
> 
> 
> Network Working Group   C. Filsfils, Ed.
> Internet-Draft   S. Previdi, Ed.
> Intended status: Standards Track Cisco Systems, Inc.
> Expires: May 23, 2017B. Decraene
>S. Litkowski
>  Orange
>   R. Shakir
>  Google
>   November 19, 2016
> 
> 
>  Segment Routing Architecture
>  draft-ietf-spring-segment-routing-10
> 
> Abstract
> 
>   Segment Routing (SR) leverages the source routing paradigm.  A node
>   steers a packet through an ordered list of instructions, called
>   segments.  A segment can represent any instruction, topological or
>   service-based.  A segment can have a local semantic to an SR node or
>   global within an SR domain.  SR allows to enforce a flow through any
>   topological path and service chain while maintaining per-flow state
>   only at the ingress node to the SR domain.
> 
> SB> Since you mention service chains here, we really should be having
> SB> a wider discussion about whether SR and SFC are really the same
> SB> technology.
> 
>   Segment Routing can be directly applied to the MPLS architecture with
>   no change on the forwarding plane.
> 
> SB> Applied to or implemented using MPLS?
> 
>   A segment is encoded as an MPLS
>   label.  An ordered list of segments is encoded as a stack of labels.
>   The segment to process is on the top of the stack.  Upon completion
>   of a segment, the related label is popped from the stack.
> 
>   Segment Routing can be applied to the IPv6 architecture, with a new
>   type of routing header.  A segment is encoded as an IPv6 address.  An
>   ordered list of segments is encoded as an ordered list of IPv6
>   addresses in the routing header.  The active segment is indicated by
>   the Destination Address of the packet.  The next active segment is
>   indicated by a pointer in the new routing header.
> 
> SB> You really