Re: What is necessity for SRH, and other EH, insertion/removal?

[Tom Herbert <[e-mail]>]

On Fri, Dec 20, 2019 at 7:00 AM Alexandre Petrescu
<[e-mail]> wrote:
>
>
>
> Le 19/12/2019 à 19:55, Tom Herbert a écrit :
> > On Thu, Dec 19, 2019 at 5:05 AM Alexandre Petrescu
> > <[e-mail]> wrote:
> >>
> >>
> >>
> >> Le 18/12/2019 à 23:07, Tom Herbert a écrit :
> >>> On Sat, Dec 7, 2019 at 9:17 AM Tom Herbert <[e-mail]>
> >>> wrote:
> >>>>
> >>>> Pulling this out into a separate thread. Pertinent questions are:
> >>>>
> >>>> Why is extension header insertion and removal at necessary?
> >>>>
> >>>> Why isn't the proposed alternative of IPIP encapsulation
> >>>> sufficient? (where the encapsulating headers contain the extension
> >>>> headers that would otherwise be inserted)
> >>>>
> >>> I believe that inband network telemetry (INT and IOAM ) might
> >>> provide the best motivation for extension header insertion. One of
> >>> the goals is to allow network operators to perform telemetry on
> >>> packets as they traverse their network. A telemetry header, INT or
> >>> IOAM, is put into packets on ingress to the domain and removed at
> >>> egress, and intermediate nodes modify the packet with measurement
> >>> data.
> >>>
> >>> Key requirements are that not all packets for a flow need to be
> >>> measured, and measured packets need to follow the same path as those
> >>> not measured  in order for the measurements to reflect what is
> >>> happening for the flow. IPIP encapsulation would change the hash
> >>> that ECMP uses so encapsulated packets might traverse a different
> >>> path-- therefore it's not sufficient in this case.
> >>
> >> Why would ECMP (Equal-cost multi-path routing) be influenced by an
> >> addition of an IP header (IPIP encapsulation) but not influenced by the
> >> insertion of an extension header?
> >>
> > Alexandre,
> >
> > When IP encapsulation is performed, unless the outer destination
> > happens to be the same as the inner destination, the destination
> > address will be different and hence packet can be routed over a
> > different path even with just simple destination based routing. The
> > outer source address will also presumably be different, so even if the
> > destination address were the same, the ECMP hash computed as routers
> > would still be different so packets could take a different path.
> >
> > With extension header insertion, the IP addresses are not changed.
> > Neither is the flow label, nor any transport ports. So the network
> > still routes to the same destination address, and if ECMP is in use
> > the same hash is always produced since the inputs to the hash remain
> > the same after the header insertion.
>
> But in that case (dont change src and dst addresses, just insert
> headers) then the packet would not pass through other enforced
> intermediary destinations before reaching the final destination.
>
> In such a case, there could be headers inserted but the contents in
> these headers would not be IP addresses of intermediaries, but some
> other applicatioin-layer data.
>
> If so, why would not be these data added as a payload, and not as an IP
> extension header?  I.e... encapsulate?
>
> >>> Extension header insertion would maintain the routing in ECMP
> >>> (although the fact that extension headers aren't supported in IPv4
> >>> creates another problem).
> >>
> >> ECMP distinguishes between IP headers being extension headers vs base
> >> headers?  IF yes, it should be modified to work with base headers
> >> addition as well (encapsulation IPIP).
> >
> > Some implementations might do that, but not all. In IPv6 this is
> > unnecessary since the flow label contains per flow information so
> > routers don't need to parse beyond the IPv6 header to do EMCP. Also,
> > packets must be routed based on (outer) destination address, ECMP is
> > only used to pick amongst possible paths to a destination. Even if the
> > EMCP hash computation is the same, the packets might still follow
> > different paths when destination address is different.
> >
> >>
> >>> Some of the inband telemetry implementations are already addressing
> >>> this by inserting the inband telemetry headers directly into the UDP
> >>> or TCP payload of existing packets and removing the inserted payload
> >>> bytes at the egress point. Since only transport payload is being
> >>> modified, the packets will be routed the same way as other modified
> >>> packets for a flow. The obvious problem with this approach is that
> >>> payload is being changed by intermediate nodes such that if the end
> >>> host were to ever receive the modified packet this could result in
> >>> silent data corruption of users' data. So this protocol mechanism is
> >>> fundamentally not robust and probably dangerous. I think this
> >>> actually makes extension header insertion, where the worst case
> >>> scenario is probably unexplained packet loss, look palatable!
> >>
> >> Inserting data in the packets and then measuring them - isn't it an
> >> interference with the phenomenon to be measured?
> >>
> > Yes, there certainly is some uncertainty principle effects, however I
> > imagine  not measuring the "actual" path for a flow would probably be
> > considered as invalid results.
>
> I agree.  It depends what is measured, and how the routing is realized.
>
> Some routing might put bigger packets on a different path, just because
> of their size.  This mechanism would be fooled by someone inserting
> headers because it created bigger packets.
>
> Other routing might work hand-in-hand with the header insertion
> mechanism (in same computer the process deciding a path be same process
> inserting headers).
>
> To my mind it comes down again to the concept of a limited domain: if in
> a limited domain the routing and header inserters are bound closely, and
> ends of the comm are both there, then it migh work.
>
> It might be that measurement mechanisms you mentioned, and ECMP
> (multi-path routing), and header insertion, might be appropriate in a
> limited domain.

Alexandre,

I think there's two questions that need to be answered: Is extension
header insertion needed? If it is needed, how can we make work as
robustly as possible?

For the first question, so far it seems like there's three
possibilities why header insertion is better than encapsulation:
1) The alternate routing path problem (talking about here)
2) The right address of the domain egress to set as the destination
address of encapsulation might not be known to the ingress node (i.e.,
not all networks are going to be doing source routing)
3) Header insertion might be less overhead

For segment routing I don't believe #1 or #2 apply, and the overhead
savings of #3 don't seem like a big win relative to overhead of SRH
itself which can be substantial; also the potential overhead savings
for SRH insertion is probably more like twenty-four bytes or less
since encapsulation destination address should save one address one
address routing list. Nevertheless, it's plausible there are use cases
that show a valid need for header insertion (IOAM as one example).

For the second question, IMO, if extension header insertion is needed
then it's essential that the attribution problem is addressed. It must
be clearly indicated in a packet which extension headers have been
inserted and by whom. draft-herbert-6man-eh-attrib-00 proposes an the
Attribution Option for this purpose. Please take a look.

Tom

>
> Alex
>
> >
> > Tom
> >
> >> Alex
> >>
> >>>
> >>> Tom
> >>>
> >>>> Please note, I'm asking for the technical justification of the
> >>>> protocol design, saying that it's necessary because it's already
> >>>> being deployed isn't useful in this regard.
> >>>>
> >>>> Tom
> >>>
> >>> --------------------------------------------------------------------
> >>> IETF IPv6 working group mailing list [e-mail] Administrative
> >>> Requests: https://www.ietf.org/mailman/listinfo/ipv6
> >>> --------------------------------------------------------------------
> >>>
> >>
> >> --------------------------------------------------------------------
> >> IETF IPv6 working group mailing list
> >> [e-mail]
> >> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> >> --------------------------------------------------------------------