Re: [spring] WG LC for draft-ietf-spring-segment-routing
On Nov 30, 2016, at 2:27 PM, Stewart Bryantwrote: > 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
On 30/11/2016 10:38, Stefano Previdi (sprevidi) wrote: On Nov 29, 2016, at 8:21 PM, Stewart Bryantwrote: 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
> On Nov 29, 2016, at 8:21 PM, Stewart Bryantwrote: > > 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