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

[Greg Mirsky <[e-mail]>]

Hi Wim,
I would probably be troubled if IETF will start "choosing a champion" in
the technology field (not that I haven't noticed that being tried). I think
I'm more comfortable with "There're many ways to slice a bread" view and
IETF ensuring that it can be done in an interoperable way without breaking
other things around.

Regards,
Greg

On Thu, May 28, 2020 at 9:42 PM Henderickx, Wim (Nokia - BE/Antwerp) <
[e-mail]> wrote:

> On top it would be a good signal from IETF to state this as it will help
> you get support for some vendors who don’t want to implement things. Trying
> to come up with a new protocol for the fact a vendor doesn’t support
> something I not good if there is a solution available. As such I believe it
> would be good that IETF brings this signal and does not adopt CRH for such
> scenario.
>
>
>
> My 2 cents.
>
>
>
> *From: *"Henderickx, Wim (Nokia - BE/Antwerp)" <[e-mail]>
> *Date: *Friday, 29 May 2020 at 06: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]> on behalf of Andrew Alston <
> [e-mail]>
> *Date: *Friday, 29 May 2020 at 02:41
> *To: *"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 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:
>
>
>
>    1. Relatively low end devices – but have sufficient forwarding
>    capacity to carry traffic between the metro nodes
>    2. 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
> --------------------------------------------------------------------
>