Re: So where have all these new 6man WG people come from?

["Henderickx, Wim (Nokia - BE/Antwerp)" <[e-mail]>]

Andrew, RFC8663 is doing exactly the same, you route based on destination IP to the other end. Balancing will work the same way as you use the outer ipv6 header.
The tag defines the destination IP to put in the outer header and you get what you want.

It is the same with CRH, you determine the next destination IP based on the lookup of the tag. The operations are the same.

From: Andrew Alston <[e-mail]>
Date: Friday, 29 May 2020 at 07:43
To: "Henderickx, Wim (Nokia - BE/Antwerp)" <[e-mail]>, "Templin (US), Fred L" <[e-mail]>, Brian E Carpenter <[e-mail]>, 6MAN <[e-mail]>
Subject: RE: So where have all these new 6man WG people come from?

Actually – I was expecting this reply.

And no – RFC8663 does NOT accomplish what I want.

With 8663 – tunnels have to be built – normally manually.  With CRH – I have to do precisely nothing, because the routing is done on the DA over the non-MPLS supporting nodes and its stock standard destination routing.
That means – balancing works – no need to build tunnels – no need to construct anything – its simpler, its easier and it saves me one hell of a lot of hassle.

I also point out that – we aren’t talking about one or two rings here – we can be talking about 20 -  30 -  40 rings.  So which one do I build my tunnels over?  With CRH – I don’t have to care.

Thanks

Andrew


From: Henderickx, Wim (Nokia - BE/Antwerp) <[e-mail]>
Sent: Friday, 29 May 2020 07:33
To: Andrew Alston <[e-mail]>; Templin (US), Fred L <[e-mail]>; Brian E Carpenter <[e-mail]>; 6MAN <[e-mail]>
Subject: Re: So where have all these new 6man WG people come from?

Andrew, RFC8663 would do the job in the same way. On top you also will need to interwork with MPLS, so you have to do all kinds of mapping and encap with CRH to interwork with CRH. RFC8663 is a much better alternative for such environment

From: ipv6 <[e-mail]<mailto:[e-mail]>> on behalf of Andrew Alston <[e-mail]<mailto:[e-mail]>>
Date: Friday, 29 May 2020 at 02:41
To: "Templin (US), Fred L" <[e-mail]<mailto:[e-mail]>>, Brian E Carpenter <[e-mail]<mailto:[e-mail]>>, 6MAN <[e-mail]<mailto:[e-mail]>>
Subject: Re: So where have all these new 6man WG people come from?

I want to add another use case to this, and it’s pretty critical to some of my thinking

Imagine this scenario –

P -> PE <ASBR> -> Metro

In the metro – you have a bunch of metro aggregation nodes – imagine them connected something like:

A <----> B <----> C<----> D
|           |           |          |
E <----> F <----> G <---->H

(I’ve included a png in case the formatting of this gets messed up)

Now – say hypothetically there are rings of building handoffs that start and stop at separate metro nodes – so a ring that goes from D through H – say 10 devicse deep.   Those devices are:


a.)     Relatively low end devices – but have sufficient forwarding capacity to carry traffic between the metro nodes

b.)    Support MPLS on V4 – do not support it on V6 (and never will, since there is on LDPv6 on those devices, and well, LDPv6 was pretty much still born anyway imho)

Now lets say I get a dual break – C to D and D to H – the only communication path left – as the path of last resort is one of the metro rings D through H – and yes – that’s a last resort – you don’t wanna be routing through those rings unless you truly have to – but – it is a path of last resort.

In an MPLS world – V4 MPLS traffic will keep flowing – via the rings – using the last resort path. In a V6 world – I have a problem.  In an V4 MPLS world – despite the fact that I do not have support SR-MPLS – I have SRMS which will allow me to actually run effective SR through the ring.  There is no SRMS that I know of for V6 – or if there is – it’s certainly never been implemented by any vendor I have ever seen.  I could static backup tunnels over the metro rings and shove my v6 traffic over those – except – that means retaining V4 on the rings.  Alternatively – I could go either SRv6 (and I’ve stated many times why that doesn’t work for me in any way shape or form) or – I can use CRH – because the intermediary devices do not have to know anything about it.

Bottom line – for those who wish to say “Qu'ils mangent de la MPLS” – guess what – this doesn’t work for us in this scenario.  CRH does.  I point out that replacing the thousands upon thousands of devices in the metro rings – also makes no logical sense whatsoever.

So basically – there are cases where – I need to be able to run functionality over islands – I need to be able to do it without V6 MPLS support – and I need those devices to be able to pass the stuff transparently.  I do not wish to be creating static tunnels – I do not to break loose based steering because it has to flow through the path of last resort – and I have zero interest in running SRv6.  CRH – works in this scenario – it’s been tested – extensively.

Thanks

Andrew



From: ipv6 <[e-mail]<mailto:[e-mail]>> on behalf of "Templin (US), Fred L" <[e-mail]<mailto:[e-mail]>>
Date: Friday, 29 May 2020 at 00:03
To: Brian E Carpenter <[e-mail]<mailto:[e-mail]>>, 6MAN <[e-mail]<mailto:[e-mail]>>
Subject: RE: So where have all these new 6man WG people come from?

Brian, please don't delete the message about a concrete use for CRH in real-world
applications (planes, trains automobiles) with backing documentation:

https://mailarchive.ietf.org/arch/msg/ipv6/g43uTZFNVyLV3y-kvrDn8Qktk1Y/<https://mailarchive.ietf.org/arch/msg/ipv6/g43uTZFNVyLV3y-kvrDn8Qktk1Y>

Thanks - Fred

> -----Original Message-----
> From: ipv6 [mailto:[e-mail]] On Behalf Of Brian E Carpenter
> Sent: Thursday, May 28, 2020 1:40 PM
> To: 6MAN <[e-mail]<mailto:[e-mail]>>
> Subject: Re: So where have all these new 6man WG people come from?
>
> I have concluded two things.
>
> 1. Most people have completely failed to understand the meaning of "adoption" in the IETF WG context. I and at least one co-author
> will be submitting a draft about that to the gendispatch WG soon.
>
> 2. When I hear a choir singing, it is the same as hearing one voice.
>
> My personal decision at this point is to delete all messages about CRH adoption unread, except for the message we will soon receive
> from the WG Chairs stating the rough consensus of the adoption call, which ends on 2020-05-29. I do feel sympathy for the Chairs who
> must read and evaluate everything.
>
> Regards
> Brian Carpenter
>
> On 28-May-20 23:23, Mark Smith wrote:
> > I've been an active participant in the ipng, 6man and v6ops IETF working groups since 2002.
> >
> > While I've only been to one IETF meeting in person since then (106, sponsored by the Internet Society), over that time I've come to
> recognise the names of many of the regular and active participants in these IPv6 working groups.
> >
> > I do not recognise many of the names of people who are objecting to the 6man working group adopting the CRH draft.
> >
> > Those who have been active 6man participants in recent years would know that even an ID adopted by 6man, written by Bob and
> Brian, that had a number of revisions, didn't survive WG last call, and that occurred while Bob was (as he still is) one of the 6man WG
> chairs.
> >
> >
> > Regards,
> > Mark.
> >
> > --------------------------------------------------------------------
> > IETF IPv6 working group mailing list
> > [e-mail]<mailto:[e-mail]>
> > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> > --------------------------------------------------------------------
> >
>
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> [e-mail]<mailto:[e-mail]>
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------
--------------------------------------------------------------------
IETF IPv6 working group mailing list
[e-mail]<mailto:[e-mail]>
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------