Re: Insertion of IPv6 Segment Routing Headers in a Controlled Domain

[Dirk Steinberg <[e-mail]>]

> Am 03.04.2017 um 22:34 schrieb Mark Smith <[e-mail]>:
> 
> On 31 Mar. 2017 01:34, "Dirk Steinberg" <[e-mail] <mailto:[e-mail]>> wrote:
> 
> > Am 29.03.2017 um 22:08 schrieb Mark Smith <[e-mail] <mailto:[e-mail]>>:
> >
> > On 30 March 2017 at 06:58, Mark Smith <[e-mail] <mailto:[e-mail]>> wrote:
> >> So having further about this, I have fundamental question that it
> >> isn't answering.
> >>
> >> Why can't IPv6-in-IPv6 encapsulation be used for this? What is missing
> >> from IPv6 that "requires" that EH insertion is used instead of much
> >> simpler, off-the-shelf encapsulation/decapsulation?
> >>
> >>
> >>
> >> For example, using IPv6-in-IPv6 encapsulation, I don't think an SRH is
> >> needed at all in the "2. Source Domain and Packet Journey" example.
> >>
> >> When node 2 realises that the link between itself and 3 has failed, it
> >> encapsulates the original SA=1, DA=9 packet in a new IPv6 header
> >> ("tunnelling" it). The new IPv6 header has an SA=2, DA=5, and is sent
> >> towards node 4.
> >>
> >> Node 4 forwards the packet onto node 5 using conventional destination
> >> address based IPv6 forwarding.
> >>
> >> Node 5 receives the packet, and as it is DA=5, decapsulates the inner
> >> SA=1, DA=9 packet. Node 5 then submits that packet to the standard
> >> IPv6 forwarding table, resulting in it being forwarded to Node 3,
> >> which then forwards it to Node 9. All of this is happening using
> >> conventional IPv6 destination based forwarding.
> >>
> >> Encapsulation is solving this problem by effectively creating a
> >> on-demand virtual link or tunnel between Node 2 and Node 5, getting
> >> the original packet past the failure point to a point along the
> >> original packet's forwarding path. Once there, it pops out of the
> >> virtual link and is sent along its way. I don't think the insertion of
> >> the EH and DA swapping method could be described the same way or could
> >> be described as simply.
> >>
> >> I think this IP-in-IPv6 encapsulation solution to the above example is
> >> better because:
> >>
> >> - there is no need for an additional header of any type - the path
> >> information is inherent in the DA of the outer IPv6 header when sent
> >> to node 5, and in the DA of the inner IPv6 packet (now "the packet")
> >> when being sent by node 5 to node 9.
> >
> > To clarify, what I mean by "no need for an additional header of any
> > type" is no additional header beyond the IPv6 encapsulation header
> > i.e. no SRH EH or similar between the outer and inner IPv6 packets. It
> > is the original IPv6 packet inside a vanilla IPv6 packet with the
> > outer IPv6 packet’s next header field set to 41.
> 
> Following this logic of not using „an additional header of any type“ leads to
> the conclusion that for every entry in an SR policy represented by the
> SID list of an SRH, you would instead use one more nested IPv6
> encapsulation header.
> 
> In the simple example of section 2 the TI-LFA policy only needs to specify
> one additional node, namely 5 (9 being the original destination), but
> conceivably the backup policy could be more complex including 3, 4, 5,
> or more SIDs. Would you really want to propose that the PLR should
> impose, say 4 nested IPv6 encapsulation headers at the same time
> while still claiming this to be simpler and/or more efficient?
> 
> Let’s face the reality: the cost of adding an IPv6 encapsulation header
> is fairly high and while doing this once may be acceptable in certain situations
> doing this N times nested is prohibitive both in terms of the burden on the
> forwarding hardware and in terms of MTU growth. One more entry in
> the SID list is just so much more efficient.
> 
> That is ignoring the complexity and cost of processing introduced at each hop. 
> 
> The current (and decades old) IPv6 forwarding model involves hop-by-hop destination address matching and hop-by-hop link-layer endcap/decap to get the packet to its destination.
> 
> MPLS too follows this model. Labels aren't inserted into the IPv6 packet, they're added to the outside of it.
> 
> EH insertion is fundamentally changing this forwarding model, because forwarding devices have to do more complicated processing of EH chain processing to forward IPv6 packets.

There seems to be a fundamental misunderstanding: The normal forwarding of 
SRv6 packets still happens based on the dest address field in the IPv6 header.
The forwarding lookup (for intermediate nodes) does not involve looking at the SRH 
at all, if fact, such nodes do not need to support or know anything about SRv6 at all.

Only segment endpoint nodes, the nodes performing SR-specific functions may have
to look at the SRH and even then, for the common operation that is analogous to 
the POP operation in MPLS, only a new dest address needs to be copied from the 
SRH  and a single counter needs to be decremented. Never is the forwarding based
directly on the SRH.

A node that wants to do SRH insertion of course has to do some heavy lifting, 
that is understood. A 5 year old hardware engine may not be able to do this.
But then we are talking about highly sophisticated and desirable functionality 
(e.g. TI-LFA) and there is always a price: there is no such thing as a free lunch.

> SR will be a compelling replacement for MPLS if it leverages existing commodity IPv6 methods and hardware. If it requires a fork lift upgrade of all devices in the network, then it’s much less attractive compared to MPLS.

Again, no forklift upgrade, but where you want significant new functionality,
there you may have to pay a price, maybe a hardware upgrade of a line card.

And, BTW, when MPLS was introduced, it was not that any IP router could be
made to do MPLS by a simple software upgrade. On the contrary, the situation
was quite similar: where you wanted to deploy new capabilities such as MPLS
FRR, you most likely needed a hardware upgrade.

So I do not see how MPLS is (has been) any better in this respect. Especially 
for the operation that is analogous to SRH insertion, namely MPLS PUSH,
I vividly remember early hw platforms only being able to push 2 or 3 labels
at a time, limiting what you could do with MPLS. Only today, after more than 
15 years of MPLS have we come to a point where we can safely assume that 
new hardware will be able to push „enough“ MPLS labels.

/Dirk

> This is why in general the recurring argument to just use IPv6 encaps
> whenever all you really need is one more entry in the SRH SID list
> is completely missing the point.
> 
> I haven't gone through all examples to determine what the implications of IPv6-in-IPv6 encapsulation are, and I acknowledge that the per-packet overheard is high.
> 
> What I have done though is proven that EH insertion is not required or essential to solve the problem presented in the example. That is the claim that is being made in this draft.
> 
> So please do not make that claim, please do not use giant lists of authors that could not have contributed enough to the document to have earned it, effectively making an appeal to authority, and please look to leverage existing IPv6 processing models and methods to avoid invalidating existing, well known and widely deployed and used IPv6 devices and techniques.
> 
> The bigger and more different the claim from the norm, the more effort you have to put into proving it.
> 
> Regards,
> Mark.
> 
> 
> /Dirk
> 
> >> - Encapsulation/Decapsulation performed by nodes 2 and nodes 5 is
> >> conventional IPv6-in-IPv6 encapsulation, specified in RFC2473, now
> >> nearly 20 years old.
> >>
> >> - In this example, nodes 4, 5 and 3 could be off-the-shelf IPv6
> >> devices that support conventional IPv6 forwarding and conventional
> >> IPv6-in-IPv6 encapsulation/decapsulation (i.e., "tunnelling").
> >>
> >> - Encapsulation/decapsulation is a simpler, universal and proven
> >> operation (literally being done every time an IPv6 packet is being
> >> sent and received over any and all layer 2 links)  compared to the DA
> >> address swapping that occurs at Nodes 2 and Nodes 5 in the described
> >> method.
> >>
> >> More complicated examples would may require more information to be
> >> carried about the path between the inner and outer IPv6 headers
> >> (although encapsulation inside encapsulation/tunnelling inside
> >> tunnelling probably be used at a greater packet overhead host, with
> >> simpler per-hop processing), however I don't think this example
> >> demonstrates why EH insertion is required.
> >>
> >>
> >> Regards,
> >> Mark.
> >
> > --------------------------------------------------------------------
> > IETF IPv6 working group mailing list
> > [e-mail] <mailto:[e-mail]>
> > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 <https://www.ietf.org/mailman/listinfo/ipv6>
> > --------------------------------------------------------------------