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

[Robert Raszuk <[e-mail]>]

Andrew,

You need to understand the difference between service and transport.

Removing MPLS from transport is happening left and right - and this is what
I said. It brings no value. It only brings problems.

No one states to remove MPLS from services - and this is what generates
revenue.

Kind regards,
R.

On Fri, May 29, 2020 at 10:31 AM Andrew Alston <
[e-mail]> wrote:

> 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]> 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]>
> *Sent:* Friday, 29 May 2020 10:55
> *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?
>
>
>
>
>
> >  – 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]> 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]> on behalf of "Templin (US), Fred L" <
> [e-mail]>
> *Date: *Friday, 29 May 2020 at 00:03
> *To: *Brian E Carpenter <[e-mail]>, 6MAN <[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/
>
> 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]>
> > 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]
> > > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> > > --------------------------------------------------------------------
> > >
> >
> > --------------------------------------------------------------------
> > IETF IPv6 working group mailing list
> > [e-mail]
> > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> > --------------------------------------------------------------------
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> [e-mail]
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------
>
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> [e-mail]
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------
>
>