Re: I-D Action: draft-voyer-6man-extension-header-insertion-02.txt

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

On Sat, 2 Dec 2017 08:15:04 +0100, Stefano Salsano wrote:
> with the first tunneling operation you create a new packet that originates
> in your SR domain.
>
> We definitely want it, so the further SR insertion will only be applied to
> such packets (and hosts outside the domain will not receive unexpected
> ICMP...) and we believe that it is worth paying the tunneling overhead
here.
>
> We think that for further operations that require adding of SRH
information
> to such packets originating in your SR domain, the SR insertion is more
> efficient than tunnelling into a new packet.
>
> This is both from the point of view of the packet size (and increase of
> packet headers size) and from the point of view of the cost of packet
> manipulation operations.


Thank you for a direct and clear explanation of why SR header insertion is
seen to be advantageous, and when. Performing encapsulation at domain
boundaries should ensure that ICMP messages caused by SR headers don't go
to nodes that are not part of the domain.


> There can be scenarios in which you have more than one such operation to
be
> applied to the packet, let us assume two. If you go for tunnelling you
have
> the first encapsulation, then two more IPv6-in-IPv6 encapsulation in the
> same packet, for a total of 3 encapsulations. If you go for tunneling + SR
> insertion you only have the first encapsulation and then "simple" mangling
> of SRH header.


One of the questions that occurs to me is what happens if conditions arise
at a node within the SR domain that mandate the insertion of an SR header
when one is already present. This could occur in the fast reroute scenario
of
https://tools.ietf.org/html/draft-voyer-6man-extension-header-insertion-02
- section-3
<https://tools.ietf.org/html/draft-voyer-6man-extension-header-insertion-02#section-3>
where node 2 has inserted a SR header owing to loss of the link 2-to-3,
assuming that we have a somewhat richer topology such as the one shown bel
ow:


        (--- Source Domain ---)
        (                     )
    A---( 1-----2-----3-----9 )---B
        (       |     |       )
        (       4-----5       )

        (       |     |       )

        (       6-----7       )

(---------------------)


If node 4 detects failure of link 4-to-5, would that trigger insertion
of a second SRH? If so, that would violate the recommendations in
https://tools.ietf.org/html/draft-ietf-6man-segment-routing-header-07 -
section-3.2
<https://tools.ietf.org/html/draft-ietf-6man-segment-routing-header-07#section-3.2>
.
This situation would not arise if encapsulation were used instead of header
insertion.

One possible answer for this scenario might simply be that it is OK to have
multiple SR headers within one packet. RFC 8200 mandates strictly sequential
processing of extension headers and also mandates that if a routing header
is
expired (i.e., has Segments Left equal to zero) then the receiving node must
proceed to the next header. So if the SRH inserted by node 4 appears before
the one inserted by node 2, then everything should work, assuming that if a
node processes an unexpired routing header it just forwards the packet and
does not proceed to the next header. RFC 8200 does not say this explicitly,
but it is implied by the header ordering recommendations in Section 4.1.
Note that this answer would require a change to the SRH draft.

What I am really trying to get at is not to advocate for one position or
another, but rather to encourage the proponents of header insertion to
consider, and document, corner cases such as these. That will help assure
everyone on both sides of the debate that things have been thought through.

Mike Heard