Re: SRH insertion vs SRH insertion + encapsulation

[Robert Raszuk <[e-mail]>]

> > 6man "is not chartered to develop major changes or additions
> > to the IPv6 specifications." Of course it's a matter of judgment,
> > but I agree that changing this is "major".
>
> I cannot think of many other changes that could be considered major as
> this. It even changes the end-to-endness of IPv6.
>


Please observe that today packets are already transported encapsulated in
L2VPN/VPWS transport within number of domains using IPv4 or MPLS. If such
encapsulated packet in say IPv4 domain would "leaked" or "escape" outside
the domain without proper decapsulation it would naturally die as no other
AS would be able to neither route nor properly decapsulate them.

Important: It is in the deepest interest of the carrier to deliver packets.
If they would be dropping packets for whatever reason their business would
be at deep risk.

/* Side comment: Reading a lot of emails I see that some folks treat
network operators like either vacuum or completely unresponsible group of
gangsters just waiting around the corner when 6man will allow them to break
their customer's services or worse as too damn to decide for themselves
what and when to enable a feature in their network. I can rest assure that
carriers are very conservative and would never to anything which would put
at risk even single customer's packet. */

25 years ago frame relay and ATM where connection oriented to offer such
transport for any IP service .. now it is all connection less. Till we get
back to connect oriented transport paradigm using this time optical
switched paths via transit domains we need to at least try do out best in
connection less fashion.

Same for L3VPN/EVPN transports - they also use various encapsulations - and
what goes there IPv6 packets sitting happy as a payload never see.

And all of this is happening today and 6man simply does not know about it.

So here the effort is not to break the end-to-endness of IPv6 nor violate
any dogmas.

*The effort here is to allow IPv6 transport to get the same level of
functionality in the native way in order to deliver IPv6 end-to-end
services with all applications which otherwise require additional
encapsulation layers, various control plane extensions etc ...*

Encapsulated packets will be delivered as the sender intended to the final
receiver and no one is talking about changing a bit in the original
packets.

It is just like you would put cars on the modern tracks to improve time and
quality how they will get through across the mountains.

I tend to think about IPv6 in two planes: IPv6 transport and IPv6 services.
Yes I know you will tell me such division does not exist - true - but this
is the problem not a feature. The sooner community accepts that both can
safely coexist the better for the protocol itself as well as services using
this protocol.

And here interestingly enough we are only talking about enhancement to IPv6
transport without breaking or changing anything to IPv6 services.

Thx,
R.