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

[Mark Smith <[e-mail]>]

On 1 December 2017 at 09:07, Robert Raszuk <[e-mail]> wrote:
> Tom,
>
> The biggest advantage of SRv6 in contrast to SR-MPLS is that the SRH (one or
> more) are not modified through the SR applicability of the packets.
>

I'd have thought the biggest advantage and actual motivation for using
IPv6 for this was to leverage IPv6's near and definite future
commodity. MPLS required forklift upgrades to networks, if you use
IPv6 per RFC8200 (and its predecessors), the majority of existing IPv6
networking devices will work and can continue to be used without
change. and only those that are doing something special need to be
changed.

> So node which understands SRv6 can generate ICMP to both src of the packet
> (poor host) as well as ingress node in SR domain (as it is explicitly listed
> in Ingress Node TLV of first SRH). Node which does not understand SRv6 will
> likely only send it to original src .. but this is a feature not a bug. This
> is how traceroute works.

No, it is not the same as traceroute operation.

Traceroute works on the assumption that the packet headers in the ICMP
response payload match those of the packet that triggered the ICMP
message. That is how the host running traceroute knows which
traceroute process to send the API error message to that then
generates the traceroute hop output.

If the traceroute source host sends IP/UDP or IP/ICMP to trigger the
ICMP messages for tracerouting, yet receives in the ICMP payload
"IP/SRH/UDP" or "IP/SRH/ICMP", and doesn't understand the SRH header
or isn't enabled to understand the SRH header and read past it (which
is probably going to be all end-user hosts), how can the receiving
host know which traceroute process to send the API error to?
Traceroute won't report the hop because it won't receive the sockets
API error message that reports it.

It isn't just traceroute that relies on this, it is all of ICMP. EH
insertion violates that assumption, which is why EH insertion can or
may cause many unexpected ICMP protocol and operational failures.
PMTUD is one of the main examples.

>
> If you do encap how will host now see all the nodes on the way traceroute or
> tracepath ?

They don't see link-layer hops today. An IPv6-in-IPv6 tunnel is using
IPv6 as a link-layer. That's the point of an IPv6-in-IPv6 tunnel - to
make an IPv6 network appear as a single link-layer hop.

> Do you think that hosts admins will be happy to be blinded by
> 6man ?
>

Host admins aren't the actual audience for traceroute, network
operators troubleshooting networks are. We're well familiar with
troubleshooting virtual links that may or may not hide the actual
physical topology and infrastructure, because we configure and operate
it. Ideally host admins should never need to run traceroute because
the network is designed and being operated well enough that paths that
hosts use over it are predictable and testable within the network.

> Btw I am not the one who ever claimed applicability to "controlled networks"
> or "wall gardens" so don't try to use that one with me :)). For me the much
> bigger question is what should go into data plane and what is better to go
> in control plane. We may end up with both and let customers/operators
> choose. But hand waving that doing innovation in data plane is scary is not
> the approach I would endorse.
>

I'll ignore the further logical fallacy appeals. However, I'll address
a point about innovation.

Innovation commonly occurs within existing constraints, to avoid
needing to "boil the ocean". All those innovative electric and self
driving cars and trucks we're hearing about daily? They don't require
that we rip up and replace all the roads, the street signs or traffic
lights, or widen the lanes. They're compatible with our existing road
infrastructure, which is one of the significant values of them as an
innovation. The required costs and resources to adopt them are far
lower because of the compatibility with the existing infrastructure.

If they required changing both the vehicle and the infrastructure they
ride on or in, they wouldn't be called cars, and would cost far more
money to develop and deploy (and would be called "Hyperloop" for
example), and need to carry far greater numbers of people at once to
justify the expense. They wouldn't be individual or small group
transport vehicles, and wouldn't be within financial reach of most
individuals.

Compatibility is one of the 5 factors that influence the adoption of
an innovation. There's a summary of all 5 in this presentation
starting at slide 8 -
http://www.users.on.net/~markachy/The_Rapid_Rise_of_the_MMHH.pdf


> We would be still doing token ring or FDDI ....
>

Another attempt to use emotional appeal rather than technical
argument. Please stop trying to use that method to argue your point,
it doesn't work.

Regards,
Mark.


> Cheers,
> R.
>
>
> On Thu, Nov 30, 2017 at 10:54 PM, Tom Herbert <[e-mail]> wrote:
>>
>> On Thu, Nov 30, 2017 at 1:25 PM, Robert Raszuk <[e-mail]> wrote:
>> > Tom,
>> >
>> > Imagine the case where packets are subject to go via service chains. I
>> > can
>> > steer the packet to the router which has service nodes connected to it
>> > but
>> > original src address may be used to decide which service given packet is
>> > subject to take.
>> >
>> > Sure I can impose an SR function and map it up front such that the
>> > router
>> > above would never need to inspect src address, but why to construct such
>> > architecture which only allows limited set of network programming as
>> > opposed
>> > to offer the choice on how to setup things by network operators ?
>> >
>> Robert,
>>
>> Because the architecture, or at least protocol, is not correct.
>>
>> Suppose a device inserts an EH into a packet that downstream causes
>> the packet to be dropped and generates an ICMP error which goes back
>> to the source. What is a source host supposed do with this? It might
>> be able to determine that it didn't send the EH, and if it's lucky it
>> might even be able to parse the offending EH and maybe even sees the
>> problem that caused the error. But then what? How does the host tell
>> the network to stop mucking with its packets so that they no longer
>> get dropped and the source host doesn't get blamed?
>>
>> ICMP handling is just one of several issues that needs to be
>> addressed. If the only answer is that these aren't concerns because
>> the protocol is only deployed in controlled networks, then I claim
>> that's nothing more than hand waving which is not robust and doesn't
>> scale.
>>
>> Tom
>
>
>
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> [e-mail]
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------
>