Li,
In the scenarios that you mention, below, SRv6 nodes have the following options:
1. To prepend and IPv6 header, with its own SRH
2. To insert an SRH, as described below
Option 1 is in keeping with the word and spirit of RFC 8200. As you point out,
Option 2 contradicts RFC 8200.
So, we should probably explore the motivation for Option 2). If the motivation
is not sufficient, we should probably standardize on Option 1.
Ron
Juniper Business Use Only
From: spring <spring-boun...@ietf.org> On Behalf Of li zhenqiang
Sent: Friday, August 30, 2019 5:53 AM
To: draft-voyer-6man-extension-header-insertion
<draft-voyer-6man-extension-header-insert...@ietf.org>;
draft-ietf-spring-srv6-network-programming
<draft-ietf-spring-srv6-network-programm...@ietf.org>; 6...@ietf.org;
spring@ietf.org
Subject: [spring] Question about SRv6 Insert function
Hello all,
End.B6.Insert specified in draft-ietf-spring-srv6-network-programming-01 will
insert a new SRH in the received IPv6 packet, which results in two SRHs in one
IPv6 packet. It is contradict with RFC8200 that says Each extension header
should occur at most once, except for the Destination Options header..
In draft-voyer-6man-extension-header-insertion-06, an intermediate node
executes the insert function to implement a sub-50 milliseconds FRR operation
upon link failure. It is contradict with RFC8200 that says Extension headers
(except for the Hop-by-Hop Options header) are not processed, inserted, or
deleted by any node along a packet's delivery path, until the packet reaches
the node (or each of the set of nodes, in the case of multicast) identified in
the Destination Address field of the IPv6 header.
Best Regards,
Zhenqiang Li
________________________________
li_zhenqi...@hotmail.com<mailto:li_zhenqi...@hotmail.com>
_______________________________________________
spring mailing list
spring@ietf.org
https://www.ietf.org/mailman/listinfo/spring
