Dear Linda, Thank you for your email.
Please see inline. Thanks, Francois From: Linda Dunbar <linda.dun...@futurewei.com> Date: Friday 17 January 2020 at 01:31 To: "draft-ietf-spring-sr-service-programm...@ietf.org" <draft-ietf-spring-sr-service-programm...@ietf.org> Cc: SPRING WG <spring@ietf.org> Subject: Can features described by draft-ietf-spring-sr-service-programming-01 be supported by draft-ietf-spring-srv6-network-programming-08? Authors of draft-ietf-spring-sr-service-programming-01: “draft-ietf-spring-sr-service-programming” specifies Service SIDs to be embedded into the SID list. Does it make the SID list even longer? For example, if a packet needs to be steered through the network by 3 SIDs (S1, S2, S3), Service SIDs will be the additional SIDs to be added to the packet header? It is by including a service SID in the SID-list that you can steer packets through the network function associated with this service SID. Regarding your specific example, if you add service SIDs in a SID-list that already contains other types of SIDs (e.g., topological ones), then it will indeed make your SID-list longer. It seems straight forward for draft-ietf-spring-srv6-network-programming to add an instruction to forward the packet to a specific service Function. Why not using draft-ietf-spring-srv6-network-programming to steer packets to specific service functions? What features specified by draft-ietf-spring-sr-service-programming that can’t be achieved by draft-ietf-spring-srv6-network-programming? While you may be able to perform some basic service chaining with the functionalities defined in other drafts, many service chaining use-cases require more than that. For example, some service chaining use-cases involve legacy network functions (SR-unaware) that are not able to process an SR packet (SR-MPLS or SRv6) or the usage of metadata. draft-ietf-spring-sr-service-programming defines the additional data plane procedures and protocol extensions to support these use cases for both SR-MPLS and SRv6. Some minor questions: What is the ENH in Section 6.1.2? You have ENH = 59, ENH = 4, Are you talking the Ethernet frames being encapsulated by SRH header? The inner payload are IP frames, aren’t they? Depending on the use-case and the behavior, the inner payload can be Ethernet, IPv4, IPv6, or a transport layer header. ENH is an old terminology that is really the Upper-layer header type (inner payload type). The same applies to value 59, which should be changed to “TBD1” from draft-ietf-spring-srv6-network-programming until the appropriate value is assigned by IANA. Thank you for raising that point. We will correct that in the next revision of the draft. Thank you very much, Linda Dunbar
_______________________________________________ spring mailing list spring@ietf.org https://www.ietf.org/mailman/listinfo/spring
