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

[Andrew Alston <[e-mail]>]

Drop MPLS all together…

Errr Robert – I would respond to this with more detail – but – I’ve seen some pretty bizarre and out there comments that show a total fundamental lack of knowledge of what’s on the ground or what providers like ourselves do – and this one truly takes the cake.

No value?  That’s why using the technology generates us billions of dollars of revenue every single year?

Sorry – this is beyond hilarious

Andrew


From: Robert Raszuk <[e-mail]>
Sent: Friday, 29 May 2020 11:03
To: Andrew Alston <[e-mail]>
Cc: 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?

I say drop MPLS all together ... no need ... no value.

For application which require encap use IP encap IPv4 or IPv6.  Hint: RFC7510

Simplify rather then keep patching and complicate further.

On Fri, May 29, 2020 at 9:58 AM Andrew Alston <[e-mail]<mailto:[e-mail]>> wrote:
Robert,

What part of – dual break – only path left is through the rings was not clear here?

In the scenario that I mentioned – my path of last resort goes through a non-MPLS capable ring.

There are no other paths left in the case of dual breaks at that point

Andrew

From: Robert Raszuk <[e-mail]<mailto:[e-mail]>>
Sent: Friday, 29 May 2020 10:55
To: Andrew Alston <[e-mail]<mailto:[e-mail]>>
Cc: 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?


>  – you don’t wanna be routing through those rings unless you truly have to – but – it is a path of last resort.

Normally that requirement can be satisfied in any network by proper setting of link metrics in IGP or proper route preference in BGP.

There is no need to roll TE of any sort there. It will just complicate the network - regardless of TE flavor.

Thx,
R.






On Fri, May 29, 2020 at 2:41 AM Andrew Alston <[e-mail]<mailto:[e-mail]>> wrote:
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]<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<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<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<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<https://www.ietf.org/mailman/listinfo/ipv6>
--------------------------------------------------------------------