Re: Questions / comments regarding draft-voyer-6man-extension-header-insertion (was: Proposed revised Extension Header text for rfc2460bis)

["C. M. Heard" <[e-mail]>]

On Fri, May 5, 2017 at 2:14 PM, Voyer, Daniel <[e-mail]> wrote:
> Note that draft-voyer-6man-extension-header-insertion has been written
> with the purpose to illustrate _one_ evident use-case where header
> insertion is useful, not harmful and very beneficial. The intent of
> the draft is not to come with a complete set of solutions on how you
> can insert and update a source route path for a given packet.
>
> The first step towards header insertion, is to clearly document the
> practical, operational use-case where it is required (used) and safe.
[ ... ]
> As illustrated in the draft, the statement "Node 1 originates a packet
> P1 destined to 9 (SA=1, DA=9)” refers to the action the ingress node
> of the source domain consisting of encapsulating the incoming packet
> (i.e.: the packet entering in the source domain) into an outer header
> with SA=himself (i.e., node 1) and DA=egress node (i.e., node-9). This
> means that all packet transiting through the source domain are in fact
> encapsulated/tunneled through it.
>
> In this case, the shape of the new packet is:
>         SA=1, DA=9
>         SA=x, DA=y (i.e., the original SA/DA addresses)
>         payload
>
> Now, the packet travels from node-1 to node-9 and arrives in node-2.
> Assume that node-2 activated TI-LFA (IPFRR) where a backup path is
> pre-computed and installed into fib so that in case of interface 2to3
> fails, the traffic follows the 50ms convergence rules or better(SRTE).
> Upon failure of interface 2to3, the packet is rerouted to node-4 with
> the following SRH inserted:
>
>         SA=1, DA=5    (DA is now set as the first segment)
>         SRH=(5, 9)
>         SA=x, DA=y    (i.e., the original SA/DA addresses)
>         payload
> i.e., packet now has an SRH inserted by node-2 (transit node).
> Ref.: few paper about TI-LFA:
>
http://www.tmcnet.com/tmc/whitepapers/documents/whitepapers/2015/11524-fast-reroute-with-segment-routing-extending-fast-reroute.pdf
>
http://www.segment-routing.net/tutorials/2016-09-27-topology-independent-lfa-ti-lfa/
>
> When the packet reaches node-9, it is decapsulated which means both
> outer header and SRH are removed.

Thank you for providing the explanation and the links to the white papers.
That very much helps to understand the use case that is presented, and in
particular how any ICMP error messages related to the SRH can be confined
to the SR domain. You may wish to consider including part or all of that
information in the next version of the draft. That being said, I still have
some comments and questions.

First, it still is not clear to me why it is considered decisively
advantageous to add the outer IPv6 header at the ingress to the SR domain
(node 1) and then insert the SRH at the intermediate that detects the link
failure (node 2) instead of just doing the encapsulation at the
intermediate node itself. An explanation would help. If it requires
consideration of other use cases to make that case, you may want to consider
adding one or more of those use cases to the draft.

Second, suppose that a second link failure is detected at node 4 (see
https://tools.ietf.org/html/draft-voyer-6man-extension-header-insertion-00#section-3
).
If that triggers SRH insertion because of fast reroute, then there will
be two SRH's in the packet, which would make it malformed. To avoid this
problem, it seems to me that node 4 would need to rebuild the existing SRH,
encapsulate the packet in another outer IPv6 header, or else drop the
packet.
By analogy with how fast protection switching works in transport NEs, I
understand that protecting agains multiple link failures may be out of
scope,
but even so, multiple link failures should not result in malformed packets.

Looking forward to further discussion.

Mike Heard