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

From: Mark Smith <[email-masked]>
Date: Thu, 28 May 2020 21:23:11 +1000

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.

---

From: Andrew Alston <[email-masked]>
Date: Thu, 28 May 2020 11:41:31 +0000

It will be very interesting to run an analysis on the list of all these people suddnely objecting – to see how many of them have ever posted before – and will ever post again.

But – I trust the chairs to recognize and balance against an external dos of support by what looks like many individuals from the same entity.

Will see if I can get around to scripting an analysis of all the new voices – will make for an interesting read 😊

Andrew

From: ipv6 <[email-masked]> On Behalf Of Mark Smith
Sent: Thursday, 28 May 2020 14:23
To: 6MAN <[email-masked]>
Subject: So where have all these new 6man WG people come from?

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.

---

From: tom petch <[email-masked]>
Date: Thu, 28 May 2020 11:46:38 +0000

From: ipv6 <[email-masked]> on behalf of Mark Smith <[email-masked]>
Sent: 28 May 2020 12:23

<tp>
Mark

Which tells you all you need to know.  Look at the affiliation on the e-mail and you can predict with considerable accuracy the view that is stated below, something that WG Chairs come to know at a very early stage in their position.

Tom Petch
( a name you likely do not recognise, at least on  6man).

Regards,
Mark.

---

From: "Voyer, Daniel" <[email-masked]>
Date: Thu, 28 May 2020 11:57:36 +0000

Hello Mark,

It’s funny you mention that as there is lots of new people joining SPRING working group in the last year as well. At IETF 105 in SPRING. Have a look here: https://www.youtube.com/watch?v=WuoJWecyATQ, long list of people at the mic with questions.

I thought the bright side was that the world is now ready, more than ever, to run IPv6 as underlay in their backbone with great interest and passion 😊

Let’s look at the glass half full, not half empty.

Regards,
dan

From: ipv6 <[email-masked]> on behalf of Mark Smith <[email-masked]>
Date: Thursday, May 28, 2020 at 7:23 AM
To: 6MAN <[email-masked]>
Subject: [EXT]So where have all these new 6man WG people come from?

Regards,
Mark.

---

From: [email-masked]
Date: Thu, 28 May 2020 14:11:50 +0200

Segment Routing (CRH, SRH and friends) isn't something 6man has traditionally dealt with.
We have been more concerned about IPv6 in the open Internet, end to end, and not so much of technologies only applicable within a controlled domain.

From that perspective, it is not surprising that this work attracts a different participant-set than before.

It seems that a proxy war is being fought out in the working group.
With both opponents and proponents of proposals closely aligned along company borders.

Best regards,
Ole, with the dystopian hat on.

> On 28 May 2020, at 13:23, Mark Smith <[email-masked]> wrote:
> 
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> [email-masked]
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------

---

From: Philip Homburg <[email-masked]>
Date: Thu, 28 May 2020 15:06:12 +0200

>6man working group adopting the CRH draft.

Given that adoption is not a voting system, it should not matter if people
are new. What should matter is the arguments they use a against adoption.

I personally have no opinion on the draft. However I do note that,
for example, having a default router in DHCPv6 has been blocked over the
years because that functionality is already provided by RA. Even 
though there is operator demand for the option and it can provide features
that are hard to realize with RAs.

So I can imagine that some people argue against duplicated efforts on a
similar basis.

---

From: Alexandre Petrescu <[email-masked]>
Date: Thu, 28 May 2020 15:39:11 +0200

I am of the group who looked closely at routing header in the times when 
Pascal looked at it.

Now I stay away.  Routing header is a flexibility tool, there waiting to 
be exercised.  Yet its existence at the network layer has a potential to 
threaten the concept of the Internet at large.

It looks to me as something that could be dealt with either in a limited 
domain, or otherwise at the application layer.

I also admit that a WG needs new contributors, otherwise being at risk 
of ossification.

One might wonder why some WGs die while others last forever?

Alex

---

From: "Templin (US), Fred L" <[email-masked]>
Date: Thu, 28 May 2020 13:53:24 +0000

Ole,

> With both opponents and proponents of proposals closely aligned along company borders.

I am representing real-world use cases (planes, trains and automobiles) with my
aviation hat on. I do not work for a network equipment vendor and do not have
company influences driving my decisions. I think this flood of people coming into
6man many for the first time is bad for the 6man technical process and may
interfere with the timely need for solutions to real world problems. I trust that
the chairs will recognize what is going on and make the right decisions.

Thanks - Fred

> -----Original Message-----
> From: ipv6 [mailto:[email-masked]] On Behalf Of [email-masked]
> Sent: Thursday, May 28, 2020 5:12 AM
> To: Mark Smith <[email-masked]>
> Cc: 6MAN <[email-masked]>
> Subject: Re: So where have all these new 6man WG people come from?
> 
> > 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.
> >
> > 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.

---

From: Ron Bonica <[email-masked]>
Date: Thu, 28 May 2020 16:08:05 +0000

Ole,

Welcome to dystopia!

I am not so worried about new names in the discussion, because we don't vote in the IETF.  I could ask all of my neighbors and distant cousins to register an opinion on the mailing list, but it wouldn't matter unless they brought new content to the discussion.

When you and Bob evaluate the discussion, I am confident that you will enumerate and evaluate the arguments. Your decision will be based on that evaluation, and not influenced by a vote count.

Since this has been an exceptionally active call for adoption, I am confident that the decision making process will be as transparent as possible. You might consider publishing the list of arguments and your evaluation of each.

                                                                                     Ron

Juniper Business Use Only

-----Original Message-----
From: ipv6 <[email-masked]> On Behalf Of [email-masked]
Sent: Thursday, May 28, 2020 8:12 AM
To: Mark Smith <[email-masked]>
Cc: 6MAN <[email-masked]>
Subject: Re: So where have all these new 6man WG people come from?

[External Email. Be cautious of content]

Best regards,

> Administrative Requests: https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/ipv6__;!!NEt6yMaO-gk!SfCXMcTWY0BCJpNIbI-D9f_TH5WLUcJgB7py9FLnRYgaWeoHNIVNonVAyD2Qud2Z$

--------------------------------------------------------------------
IETF IPv6 working group mailing list
[email-masked]
Administrative Requests: https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/ipv6__;!!NEt6yMaO-gk!SfCXMcTWY0BCJpNIbI-D9f_TH5WLUcJgB7py9FLnRYgaWeoHNIVNonVAyD2Qud2Z$
--------------------------------------------------------------------

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 29 May 2020 08:39:48 +1200

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

---

From: "Templin (US), Fred L" <[email-masked]>
Date: Thu, 28 May 2020 21:01:26 +0000

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

> From: ipv6 [mailto:[email-masked]] On Behalf Of Brian E Carpenter
> Sent: Thursday, May 28, 2020 1:40 PM
> To: 6MAN <[email-masked]>
> 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.
> 
> 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
>

---

From: Andrew Alston <[email-masked]>
Date: Fri, 29 May 2020 00:40:56 +0000

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 <[email-masked]> on behalf of "Templin (US), Fred L" <[email-masked]>
Date: Friday, 29 May 2020 at 00:03
To: Brian E Carpenter <[email-masked]>, 6MAN <[email-masked]>
Subject: RE: So where have all these new 6man WG people come from?

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

Thanks - Fred

> > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6<https://www.ietf.org/mailman/listinfo/ipv6>
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6<https://www.ietf.org/mailman/listinfo/ipv6>
--------------------------------------------------------------------
IETF IPv6 working group mailing list
[email-masked]
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6<https://www.ietf.org/mailman/listinfo/ipv6>
--------------------------------------------------------------------

---

From: "Henderickx, Wim (Nokia - BE/Antwerp)" <[email-masked]>
Date: Fri, 29 May 2020 04:33:28 +0000

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 <[email-masked]> on behalf of Andrew Alston <[email-masked]>
Date: Friday, 29 May 2020 at 02:41
To: "Templin (US), Fred L" <[email-masked]>, Brian E Carpenter <[email-masked]>, 6MAN <[email-masked]>
Subject: Re: So where have all these new 6man WG people come from?

Imagine this scenario –

P -> PE <ASBR> -> Metro

A •• B •• C•• D
|           |           |          |
E •• F •• G ••H

Thanks

Andrew

Thanks - Fred

---

From: "Henderickx, Wim (Nokia - BE/Antwerp)" <[email-masked]>
Date: Fri, 29 May 2020 04:42:09 +0000

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)" <[email-masked]>
Date: Friday, 29 May 2020 at 06:33
To: Andrew Alston <[email-masked]>, "Templin (US), Fred L" <[email-masked]>, Brian E Carpenter <[email-masked]>, 6MAN <[email-masked]>
Subject: Re: So where have all these new 6man WG people come from?

Imagine this scenario –

P -> PE <ASBR> -> Metro

A •• B •• C•• D
|           |           |          |
E •• F •• G ••H

Thanks

Andrew

Thanks - Fred

---

From: Carsten Bormann <[email-masked]>
Date: Fri, 29 May 2020 06:55:23 +0200

> With both opponents and proponents of proposals closely aligned along company borders.

I’m coming late to the party (had to make popcorn first).
Is there a summary somewhere that explains the positions, who holds them, and possibly why?
A blog-post, an article, any other opinion piece?

(WG-chairs, this is not a question for you; Adrian had some wise words on this.)
I’d still like to understand what’s going on without investing hours into sorting messages and guessing company agenda.
(Normally, I’d have asked this question on the hallway and would have got a good summary in two minutes, but no hallways in 2020.)

Grüße, Carsten

---

From: Ca By <[email-masked]>
Date: Thu, 28 May 2020 22:28:54 -0700

On Thu, May 28, 2020 at 9:55 PM Carsten Bormann <[email-masked]> wrote:

> I’d still like to understand what’s going on without investing hours into
> sorting messages and guessing company agenda.
> (Normally, I’d have asked this question on the hallway and would have got
> a good summary in two minutes, but no hallways in 2020.)
>
> Grüße, Carsten
>

I would start here, consider it ground truth

https://www.iab.org/wp-content/IAB-uploads/2010/11/hourglass-london-ietf.pdf

I deleted my drafted diatribe about complexity and about how and where the
ietf went wrong, but the first page of this i-d has a clue about what
SPRING is really about

https://tools.ietf.org/html/draft-filsfils-spring-net-pgm-extension-srv6-usid-00

I am with others, who delete these threads unread in 6man. I am hoping
cooler heads will prevail, and SPRING will leave the Internet standard ipv6
alone, and create their own protocol, the protocol they want. They can take
the ground up experimental status like LISP did.  Just get it all out there
with minimal blockers.

Meanwhile, i will be quietly serving 100M+ users with the original ipv6
that “just works”

> Administrative Requests: nhttps://www.ietf.org/mailman/listinfo/ipv6

---

From: Andrew Alston <[email-masked]>
Date: Fri, 29 May 2020 05:43:21 +0000

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) <[email-masked]>
Sent: Friday, 29 May 2020 07:33
To: Andrew Alston <[email-masked]>; Templin (US), Fred L <[email-masked]>; Brian E Carpenter <[email-masked]>; 6MAN <[email-masked]>
Subject: Re: So where have all these new 6man WG people come from?

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

Imagine this scenario –

P -> PE <ASBR> -> Metro

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

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)

Thanks

Andrew

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

Thanks - Fred

> To: 6MAN <[email-masked]<mailto:[email-masked]>>
> > [email-masked]<mailto:[email-masked]>
> [email-masked]<mailto:[email-masked]>
--------------------------------------------------------------------
IETF IPv6 working group mailing list
[email-masked]<mailto:[email-masked]>
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6<https://www.ietf.org/mailman/listinfo/ipv6>
--------------------------------------------------------------------

---

From: "Henderickx, Wim (Nokia - BE/Antwerp)" <[email-masked]>
Date: Fri, 29 May 2020 07:31:58 +0000

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

Thanks

Andrew

Imagine this scenario –

P -> PE <ASBR> -> Metro

Thanks

Andrew

Thanks - Fred

---

From: Robert Raszuk <[email-masked]>
Date: Fri, 29 May 2020 09:55:13 +0200

>  – 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 <
[email-masked]> wrote:

> A  B  C D
> E  F  G H
> 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 <[email-masked]> on behalf of "Templin (US), Fred L" <
> [email-masked]>
> *Date: *Friday, 29 May 2020 at 00:03
> *To: *Brian E Carpenter <[email-masked]>, 6MAN <[email-masked]
> >
> *Subject: *RE: So where have all these new 6man WG people come from?
>
>
>
> > 1. Most people have completely failed to understand the meaning of
> "adoption" in the IETF WG context. I and at least one co-author
> > 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
> sponsored by the Internet Society), over that time I've come to
> > > 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.
> > >

---

From: Andrew Alston <[email-masked]>
Date: Fri, 29 May 2020 07:58:36 +0000

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 <[email-masked]>
Sent: Friday, 29 May 2020 10:55
To: Andrew Alston <[email-masked]>
Cc: Templin (US), Fred L <[email-masked]>; Brian E Carpenter <[email-masked]>; 6MAN <[email-masked]>
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 <[email-masked]<mailto:[email-masked]>> 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

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)

Thanks

Andrew

Thanks - Fred

> From: ipv6 [mailto:[email-masked]<mailto:[email-masked]>] On Behalf Of Brian E Carpenter

---

From: Robert Raszuk <[email-masked]>
Date: Fri, 29 May 2020 10:03:24 +0200

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 <
[email-masked]> wrote:

> *From:* Robert Raszuk <[email-masked]>
> *Sent:* Friday, 29 May 2020 10:55
> *To:* Andrew Alston <[email-masked]>
> *Cc:* Templin (US), Fred L <[email-masked]>; Brian E Carpenter
> <[email-masked]>; 6MAN <[email-masked]>
> *Subject:* Re: So where have all these new 6man WG people come from?
>
>
>
>
>
> Normally that requirement can be satisfied in any network by proper
> setting of link metrics in IGP or proper route preference in BGP.
>
>
>
> A ßà B ßà Cßà D
> E ßà F ßà G ßàH
> a.      Relatively low end devices – but have sufficient forwarding
> 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)
>
>
>

---

From: Andrew Alston <[email-masked]>
Date: Fri, 29 May 2020 08:31:28 +0000

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

Sent: Friday, 29 May 2020 11:03

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

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

Andrew

From: Robert Raszuk <[email-masked]<mailto:[email-masked]>>
Sent: Friday, 29 May 2020 10:55
To: Andrew Alston <[email-masked]<mailto:[email-masked]>>
Cc: Templin (US), Fred L <[email-masked]<mailto:[email-masked]>>; Brian E Carpenter <[email-masked]<mailto:[email-masked]>>; 6MAN <[email-masked]<mailto:[email-masked]>>
Subject: Re: So where have all these new 6man WG people come from?

Thx,
R.

Imagine this scenario –

P -> PE <ASBR> -> Metro

Thanks

Andrew

Thanks - Fred

---

From: Robert Raszuk <[email-masked]>
Date: Fri, 29 May 2020 10:35:33 +0200

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 <
[email-masked]> 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.
>
>
>
> *Sent:* Friday, 29 May 2020 11:03

---

From: Stewart Bryant <[email-masked]>
Date: Fri, 29 May 2020 14:22:07 +0100

In the past when such issues have arisen a special session has been called at IETF to work out a way forward.

I am not sure how well this would work in a virtual meeting, but it would seem to be an appropriate solution here.

Normal outcomes are pick A, pick B or let both go forward and let the market decide. Although the IETF generally dislikes it, sometimes the later is the only way to get out of the corner.

There are various ways of adopting the third option such as setting one text as informational.

- Stewart

> On 28 May 2020, at 13:11, [email-masked] wrote:
>

---

From: Ron Bonica <[email-masked]>
Date: Fri, 29 May 2020 13:58:37 +0000

Stewart,

Generally speaking, the market understands its requirement better than the IETF. Why not let both proceed? 

The market understands its requirements and it will choose wisely.

                                                                               Ron

-----Original Message-----
From: ipv6 <[email-masked]> On Behalf Of Stewart Bryant
Sent: Friday, May 29, 2020 9:22 AM
To: Ole Troan <[email-masked]>
Cc: 6MAN <[email-masked]>
Subject: Re: So where have all these new 6man WG people come from?

- Stewart

>> Administrative Requests: https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/ipv6__;!!NEt6yMaO-gk!V1-LQ6p9QKqjeldG4s-lSwAr7iyRJN13wDX9K_q5nuOotWe2pPMTG87pandUTgzj$
> Administrative Requests: https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/ipv6__;!!NEt6yMaO-gk!V1-LQ6p9QKqjeldG4s-lSwAr7iyRJN13wDX9K_q5nuOotWe2pPMTG87pandUTgzj$

--------------------------------------------------------------------
IETF IPv6 working group mailing list
[email-masked]
Administrative Requests: https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/ipv6__;!!NEt6yMaO-gk!V1-LQ6p9QKqjeldG4s-lSwAr7iyRJN13wDX9K_q5nuOotWe2pPMTG87pandUTgzj$
--------------------------------------------------------------------

---

From: "Templin (US), Fred L" <[email-masked]>
Date: Fri, 29 May 2020 14:13:30 +0000

Ron, yes and there are considerable new markets developing. Communications
service for worldwide air and ground transportation will be an enormous area
for new growth in this decade. And, conservation of scarce bandwidth at end
systems with low-end and/or congested wireless media will be a pivotal factor.

Fred

> From: ipv6 [mailto:[email-masked]] On Behalf Of Ron Bonica
> Sent: Friday, May 29, 2020 6:59 AM
> To: Stewart Bryant <[email-masked]>; Ole Troan <[email-masked]>
> Cc: 6MAN <[email-masked]>
> Normal outcomes are pick A, pick B or let both go forward and let the market decide. Although the IETF generally dislikes it,
> sometimes the later is the only way to get out of the corner.
> 
> >> Administrative Requests: https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/ipv6__;!!NEt6yMaO-gk!V1-
> LQ6p9QKqjeldG4s-lSwAr7iyRJN13wDX9K_q5nuOotWe2pPMTG87pandUTgzj$
> > Administrative Requests: https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/ipv6__;!!NEt6yMaO-gk!V1-
> LQ6p9QKqjeldG4s-lSwAr7iyRJN13wDX9K_q5nuOotWe2pPMTG87pandUTgzj$
> Administrative Requests: https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/ipv6__;!!NEt6yMaO-gk!V1-
> LQ6p9QKqjeldG4s-lSwAr7iyRJN13wDX9K_q5nuOotWe2pPMTG87pandUTgzj$

---

From: Stewart Bryant <[email-masked]>
Date: Fri, 29 May 2020 15:17:37 +0100

Ron,

That is clearly a possible outcome that the IETF could choose, and I would not disagree if that was the consensus position.

My main point was that a list discussion of this type rarely reaches an acceptable outcome, and that an objective discussion at IETF is normally a better approach. Indeed resolving issues like this is exactly why we meet F2F at IETF.

- Stewart

> On 29 May 2020, at 14:58, Ron Bonica <[email-masked]> wrote:
> 
> Stewart,
>

---

From: Fred Baker <[email-masked]>
Date: Fri, 29 May 2020 07:20:32 -0700

> On May 29, 2020, at 7:17 AM, Stewart Bryant <[email-masked]> wrote:
> 

So your point is that this entire discussion needs to wait until we meet f2f?

I think, in fairness, we have done quite a bit on email, and check things discussed f2f on email.

---

From: "Voyer, Daniel" <[email-masked]>
Date: Fri, 29 May 2020 14:26:54 +0000

I agree with Stewart. Addressing these outstanding issues by email only is a challenge. 

When people make the effort to meet in person means they are truly determine solve it and also agree they might put a bit of water in their wine

We could also have virtual room/webex.

dan

---

From: Ted Lemon <[email-masked]>
Date: Fri, 29 May 2020 10:30:01 -0400

> My main point was that a list discussion of this type rarely reaches an acceptable outcome, and that an objective discussion at IETF is normally a better approach. Indeed resolving issues like this…

My experience with this is more that working group chairs are quite active in moderating discussions during in-person meetings, and really tend not to take responsibility for doing that on the mailing list. This produces the effect you’ve observed, that it’s easier to get consensus in-person than on the list.

This is unfortunate; if the chairs took a more active role on the list, considering the cost of the time it takes for participants with coding jobs to follow multi-hundred-post repetitive arguments, we would probably do a better job of reaching consensus on-list.

Of course, this is a lot of work, and it’s sort of understandable that it doesn’t happen; my point is simply that if we want to be an effective _online_ organization, maybe we need to start doing things a bit differently.

---

From: Ron Bonica <[email-masked]>
Date: Fri, 29 May 2020 15:27:33 +0000

Daniel,

Under any other circumstance, I would also ask for a face-to-face meeting. But given the current situation, a virtual meeting is much more prudent.

                                                                                                                       Ron

-----Original Message-----
From: ipv6 <[email-masked]> On Behalf Of Voyer, Daniel
Sent: Friday, May 29, 2020 10:27 AM
To: Fred Baker <[email-masked]>; Stewart Bryant <[email-masked]>
Cc: 6MAN <[email-masked]>
Subject: RE: So where have all these new 6man WG people come from?

dan

--------------------------------------------------------------------
IETF IPv6 working group mailing list
[email-masked]
Administrative Requests: https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/ipv6__;!!NEt6yMaO-gk!QndTkl0C5M0cx5siV_6qk7WdkkB3j5zWysil4DO87Gikloy6tsxQ6xY_5jWLr-ZG$
--------------------------------------------------------------------

---

From: Toerless Eckert <[email-masked]>
Date: Fri, 29 May 2020 19:12:34 +0200

To me the main issue is that all the discussions about possible
improvements of IPv6 steering headers (all the options out there)
do nothing but monopolize precious industry cycles into tactical 
issues instead of also addressing the strategic problems with IPv6
that go way beyond optimizing steering header encoding.

IMHO, it is a misguided dogma to think that RFC8200 128 bit
addresses IPv6 is a one-size-fits-all solution not only for
what it was built for, the Internet, but also all arbitrary controlled
networks - for the infinite future!

IoT with IPv6 is an extreme pain (header compression, MTU).
Most controlled networks do not even want global addresses (security, 
segment based app-gateway architectures, ...).
16-bit/32-bit/48-bit address sizes would be highly desirable.
Even the 1980'th CLNP network protocol had variable sized addresses.
IPv6 has not solved core problems to be even equal to L2 switching:
plug routers together, get automatic connectivity, no bother about addresses.
CLNP was a lot closer to that goal too.

We have no "maintenance-only" constraint in IETF multicast,
yet for unicast network layer we only permit maintenance or
else you need to create another WG for just a sub-problem.
How silly of a structure is that ?  And please do not create
an IPv6.00001 working group, but think really about another
instance of IPv6-NG, but this time backward compatible.

And do not let a vendor force the hand of the IETF by developing
and deploying proprietary solutions first. We know how bad that works from
ongoing work in other layers, as well as historic examples.

If we continue to proliferate this "one-size-fits-all" myth,
then we are just continuing to extend our own version of
a winchester mystery house and kill our industry.

On Fri, May 29, 2020 at 10:30:01AM -0400, Ted Lemon wrote:
> My experience with this is more that working group chairs are quite active in moderating discussions during in-person meetings, and really tend not to take responsibility for doing that on the mailing list. This produces the effect you???ve observed, that it???s easier to get consensus in-person than on the list.
> 
> Of course, this is a lot of work, and it???s sort of understandable that it doesn???t happen; my point is simply that if we want to be an effective _online_ organization, maybe we need to start doing things a bit differently.
> 

-- 
---
[email-masked]

---

From: "Templin (US), Fred L" <[email-masked]>
Date: Fri, 29 May 2020 17:36:11 +0000

Sounds like another call for IPv8 - we had that same discussion back around
Y2K. It seems in keeping with networking technologies in general that it takes
about two decades for history to repeat itself.

> From: ipv6 [mailto:[email-masked]] On Behalf Of Toerless Eckert
> Sent: Friday, May 29, 2020 10:13 AM
> To: Ted Lemon <[email-masked]>
> Cc: 6MAN <[email-masked]>
> Subject: One size fits all !?! (was: Re: So where have all these new 6man WG people come from?)
> 
> > > My main point was that a list discussion of this type rarely reaches an acceptable outcome, and that an objective discussion at IETF
> is normally a better approach. Indeed resolving issues like this is exactly why we meet F2F at IETF.
> >
> > My experience with this is more that working group chairs are quite active in moderating discussions during in-person meetings, and
> really tend not to take responsibility for doing that on the mailing list. This produces the effect you???ve observed, that it???s easier
> to get consensus in-person than on the list.
> >
> > This is unfortunate; if the chairs took a more active role on the list, considering the cost of the time it takes for participants with
> coding jobs to follow multi-hundred-post repetitive arguments, we would probably do a better job of reaching consensus on-list.
> >
> > Of course, this is a lot of work, and it???s sort of understandable that it doesn???t happen; my point is simply that if we want to be
> an effective _online_ organization, maybe we need to start doing things a bit differently.
> >
>

---

From: Greg Mirsky <[email-masked]>
Date: Fri, 29 May 2020 11:41:54 -0700

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) <
[email-masked]> 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)" <[email-masked]>
> *Date: *Friday, 29 May 2020 at 06:33
> *To: *Andrew Alston <[email-masked]>, "Templin (US),
> Fred L" <[email-masked]>, Brian E Carpenter <
> [email-masked]>, 6MAN <[email-masked]>
> *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 <[email-masked]> on behalf of Andrew Alston <
> [email-masked]>
> *Date: *Friday, 29 May 2020 at 02:41
> *To: *"Templin (US), Fred L" <[email-masked]>, Brian E
> Carpenter <[email-masked]>, 6MAN <[email-masked]>
> *Subject: *Re: So where have all these new 6man WG people come from?
>
>
>

---

From: Toerless Eckert <[email-masked]>
Date: Fri, 29 May 2020 20:50:53 +0200

> about two decades for history to repeat itself.

IMHO Not quite. IPv4 in the mid-90th was like a global pandemic that triggered
a mass extinction event for almost all other network layers. AppleTalk, DecNET,
CLNP, X.25/CONP, XNS, SNA, ...  ("IPv4, the best pandemic ever" ;-)

IPv6 was designed to kill & replace IPv4, and even tried to enforce
it with sunsetv4 later on, aka: follow your "history repeats itself" model.
That was well intentioned but in hindsight unrealistic. I think we learned
that what happened with IPv4 will never repeat itself and can not be engineered
by standards decree. 

Therefore, I don't think we could be successfull with periodic "kill & replace"
IMHO we should have a strategy for evolution more like how e.g.: window 10 is
managed, instead of repeating microsofts experience with the failing
kill&replace through win7 and win8. Maybe first think about expansion
through market segment profiles.

I for once wouldn't bother changing the Internet profile (RFC8200)
right now, but just think what the best incremental additional profile
for e.g.: controlled inter-networks would be that could be added incrementally
to networks where Internet profile is already running. This friendly
co-existance is already standard practice for hundreds of millions
of users anyhow for the parts of network technology where we do not
 need new standards.

Cheers
    Toerless

-- 
---
[email-masked]

---

From: Greg Mirsky <[email-masked]>
Date: Fri, 29 May 2020 11:55:49 -0700

Dear Daniel and Stewart,
what, in your opinion, is missing when using virtual meetings or e-mail to
resolve differences in opinion? Seeing emotions, facial expressions? With
some effort, I can imagine them, add them to the picture. I believe that
the differences can be resolved if there's a will to do that. If there's
none, then even f2f meeting would not help us to arrive to a mutually
acceptable resolution, someone may still feel as he/she lost the argument.

>From the desk of Captain Obvious (with my apologies).

Regards,
Greg

On Fri, May 29, 2020 at 7:27 AM Voyer, Daniel <[email-masked]> wrote:

> When people make the effort to meet in person means they are truly
> determine solve it and also agree they might put a bit of water in their
> wine
>
> On 2020-05-29, 10:20 AM, "ipv6 on behalf of Fred Baker" <
> [email-masked] on behalf of [email-masked]> wrote:
>
>
>
>     > My main point was that a list discussion of this type rarely reaches
> an acceptable outcome, and that an objective discussion at IETF is normally
> a better approach. Indeed resolving issues like this is exactly why we meet
> F2F at IETF.
>

---

From: "Templin (US), Fred L" <[email-masked]>
Date: Fri, 29 May 2020 19:04:03 +0000

Seems like a well-balanced consideration Toerless, which is definitely not
what was attempted with IPv8.

Thanks - Fred

> From: Toerless Eckert [mailto:[email-masked]]
> Sent: Friday, May 29, 2020 11:51 AM
> To: Templin (US), Fred L <[email-masked]>
> Cc: Ted Lemon <[email-masked]>; 6MAN <[email-masked]>
> Subject: Re: One size fits all !?! (was: Re: So where have all these new 6man WG people come from?)
>