RE: Question about SRv6 Insert function

[Ron Bonica <[e-mail]>]

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 <[e-mail]> On Behalf Of li zhenqiang
Sent: Friday, August 30, 2019 5:53 AM
To: draft-voyer-6man-extension-header-insertion <[e-mail]>; draft-ietf-spring-srv6-network-programming <[e-mail]>; [e-mail]; [e-mail]
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
________________________________
[e-mail]<mailto:[e-mail]>