Subject: Re: [spring] I-D Action: draft-ietf-spring-ipv6-use-cases-04.txt - path-cache-reflector?

From: "Heatley, Nick" <[email-masked]>
Date: Fri, 6 Mar 2015 10:44:05 +0000

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?
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.

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.
Regards,
Nick 

-----Original Message-----
From: spring [mailto:[email-masked]] On Behalf Of [email-masked]
Sent: 06 March 2015 09:27
To: [email-masked]
Cc: [email-masked]
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-masked]
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.

---

From: "Stefano Previdi (sprevidi)" <[email-masked]>
Date: Fri, 6 Mar 2015 11:45:41 +0000

> 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…

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,…

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. 

> I am only just discovering these drafts, so please be gentle.

too late... you're in the dark side now... ;-)

s.

> sfc mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/sfc