On Mar 6, 2015, at 11:44 AM, "Heatley, Nick" <[email protected]> wrote: > Hi authors, this draft is very interesting, thank you. > > Consider a mobile operator perspective, I was interested in the comment > within the draft regarding making a source path decision without requiring > full DPI. > Could there be such a thing as a border "path-cache-reflector" function? > The egress node, in addition to cleaning up the header, could perform > additional functions: The path is dynamically cached for a short while > (potentially also NSH), and using a more simple SPI, the return traffic could > be reflected down a symmetric path, by reversing the segments?
well, for sure there's nothing that prevents an implementation from doing so. This specific point (reversing the segment list) has ben mentioned already a couple of times. segment routing for v6 dataplane has the nice property of preserving the segment list so it makes you scenario doable. > For me, the goal would be to use SPI for ingress of return traffic and > simpler processes at the border node, rather than resorting to DPI and "full > service awareness" to classify incoming traffic, when creating a symmetric > return path. Could this be achieved? This would be an interesting scenario or > use case; as far as I can tell it is not strictly available in an MPLS > environment. it is possible but it would require some state to be kept if the node reversing the segment list is not the destination of the packet. IOW if the reversing has to happen outside the service/application context. > Perhaps this has already been discussed in say SFC, I don't know. Perhaps > there are issues here? > I am only just discovering these drafts, so please be gentle. too late... you're in the dark side now... ;-) s. > Regards, > Nick > > > -----Original Message----- > From: spring [mailto:[email protected]] On Behalf Of > [email protected] > Sent: 06 March 2015 09:27 > To: [email protected] > Cc: [email protected] > Subject: [spring] I-D Action: draft-ietf-spring-ipv6-use-cases-04.txt > > > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > This draft is a work item of the Source Packet Routing in Networking Working > Group of the IETF. > > Title : IPv6 SPRING Use Cases > Authors : John Brzozowski > John Leddy > Ida Leung > Stefano Previdi > Mark Townsley > Christian Martin > Clarence Filsfils > Roberta Maglione > Filename : draft-ietf-spring-ipv6-use-cases-04.txt > Pages : 13 > Date : 2015-03-06 > > Abstract: > Source Packet Routing in Networking (SPRING) architecture leverages > the source routing paradigm. A node steers a packet through a > controlled set of instructions, called segments, by prepending the > packet with SPRING header. A segment can represent any instruction, > topological or service-based. A segment can have a local semantic to > the SPRING node or global within the SPRING domain. SPRING allows to > enforce a flow through any topological path and service chain while > maintaining per-flow state only at the ingress node to the SPRING > domain. > > The objective of this document is to illustrate some use cases that > need to be taken into account by the Source Packet Routing in > Networking (SPRING) architecture. > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-spring-ipv6-use-cases/ > > There's also a htmlized version available at: > http://tools.ietf.org/html/draft-ietf-spring-ipv6-use-cases-04 > > A diff from the previous version is available at: > http://www.ietf.org/rfcdiff?url2=draft-ietf-spring-ipv6-use-cases-04 > > > Please note that it may take a couple of minutes from the time of submission > until the htmlized version and diff are available at tools.ietf.org. > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > _______________________________________________ > spring mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/spring > > NOTICE AND DISCLAIMER > This e-mail (including any attachments) is intended for the above-named > person(s). If you are not the intended recipient, notify the sender > immediately, delete this email from your system and do not disclose or use > for any purpose. > > We may monitor all incoming and outgoing emails in line with current > legislation. We have taken steps to ensure that this email and attachments > are free from any virus, but it remains your responsibility to ensure that > viruses do not adversely affect you. > > EE Limited > Registered in England and Wales > Company Registered Number: 02382161 > Registered Office Address: Trident Place, Mosquito Way, Hatfield, > Hertfordshire, AL10 9BW. > _______________________________________________ > sfc mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/sfc _______________________________________________ spring mailing list [email protected] https://www.ietf.org/mailman/listinfo/spring
