Subject: Adoption Call for <draft-troan-6man-universal-ra-option>

From: Bob Hinden <[email-masked]>
Date: Mon, 23 Aug 2021 21:28:33 -0700

This message starts a two week 6MAN call on adopting:

  Title:          The Universal IPv6 Configuration Option
  Authors:        T. Winters, O. Troan
  File Name:      draft-troan-6man-universal-ra-option-05
  Document date:  12 July 2021

  https://datatracker.ietf.org/doc/html/draft-troan-6man-universal-ra-option-05

as a working group document. Substantive comments and statements of support for adopting this document should be directed to the mailing list.  Editorial suggestions can be sent to the authors.  This adoption call will end on 6 September 2021.

Further, if you are willing to work on this document, either as contributor, author, or reviewer please notify the list.   That provides indication of the energy level in the working group to work on this.

Bob
6man Chair

---

From: Lorenzo Colitti <[email-masked]>
Date: Tue, 24 Aug 2021 16:02:50 +0900

On Tue, Aug 24, 2021 at 1:29 PM Bob Hinden <[email-masked]> wrote:

> as a working group document.
>

The last(?) time this was discussed, several participants had concerns
about the lack of semantics of this option. See for example +Philip Homburg
<[email-masked]> 's message here
https://mailarchive.ietf.org/arch/msg/ipv6/5VbbzSIMb_fuKfNi3zVoOQSOLzk/ .
The concern (which I share) is that the interesting part of an RA option is
not the syntax, it's the semantics. Making it easier to add options to an
RA is not very useful unless there is a standard that explains what it
means. If that standard is necessary anyway, then that standard can define
the syntax as well.

Have those concerns been addressed? If not, what has changed?

---

From: Nick Hilliard <[email-masked]>
Date: Tue, 24 Aug 2021 10:23:00 +0100

Bob Hinden wrote on 24/08/2021 05:28:
> as a working group document. Substantive comments and statements of
> support for adopting this document should be directed to the mailing
> list.  Editorial suggestions can be sent to the authors.  This
> adoption call willend on 6 September 2021.
The most obvious issue with this draft is xkcd.com/927 and the ensuing 
complexity problem it creates.  For example, implementations may handle 
configuration options differently depending on whether they're 
encapsulated as RA, DHCP or universal.  You can argue that this is an 
implementation mistake or someone-else's-problem, but the operational 
reality is that multiple encapsulation mechanisms for the same 
underlying concepts creates the environment for implementation 
differences and consequently infrastructure fragility.  Lorenzo's (and 
Philip's) point about specification is a subset of this - this situation 
can be helped by having reams of documentation and test suites for each 
option.

Nick

---

From: Michael Richardson <[email-masked]>
Date: Tue, 24 Aug 2021 14:39:58 -0400

> about the lack of semantics of this option.

This new document provides an IANA Registry.

The Registry offers Standards Action, Specification Required, and also Expert
Review.   For the first two, the semantics would be in a specification.
(not necessarily an RFC).

For Expert Review, depends upon the view of the experts.
The document will probably need to provide some advice to the Experts.

The big win, in my opinion, for this option, is that it requires no
incremental effort on the part of router vendors.  This means that if the
Android team thinks that having an RA option to configure the default font
size on a phone is a useful thing [doubtful :-)], then they can experiment
with such a thing without having to spend two years in an RFP with their
router vendors.

I support adoption of the document.
There are a number of editorial tweaks that would make the document a bit
clearer.  The JSON content in section 4 is jarring when you said CBOR.
Then later, the document says that there will be a way to configure the
option via JSON.

I'm not sure I understand why we are using 20 of the super valuable -23->23
options for things that we already have RA options for.   I'm sure that will
come out in discusson once adopted.

--
Michael Richardson <[email-masked]>   . o O ( IPv6 IøT consulting )
           Sandelman Software Works Inc, Ottawa and Worldwide

---

From: Carsten Bormann <[email-masked]>
Date: Tue, 24 Aug 2021 21:06:04 +0200

> options 

(Actually, -24..23 because of the way CBOR encodes negative numbers.
[BTW, the phrasing -23-23 as in the draft is, er, hard to read.])

Grüße, Carsten

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 25 Aug 2021 11:33:07 +1200

I'm replying to Nick's message but I think this also addresses
Lorenzo's point too:
On 24-Aug-21 21:23, Nick Hilliard wrote:
> complexity problem it creates.  

Well, yes and no. As Michael Richardson implies, this could bump
up the semantics from the depths of the stack to what is essentially
app level code, with a requirement for an individual spec of some
kind. So it will only work between consenting hosts and routers, and
it will be a no-op otherwise. Yes, that could lead to a very complex
interoperability scenarios, and help desk calls saying that my
friend's phone does this, and my phone does that, and please fix it.

But didn't we create this situation when we failed to ensure feature
equivalence between RA and DHVPv6 in the first place? As far as I can
tell, if used with care (i.e. Expert Review or more) this proposal
offers a way out of the already bad situation.

(I would probably argue for dropping "Expert Review" alone;
"Specification Required" implies Expert Review.)

   Brian

> For example, implementations may handle 
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> [email-masked]
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------
>

---

From: Lorenzo Colitti <[email-masked]>
Date: Wed, 25 Aug 2021 09:05:46 +0900

On Wed, Aug 25, 2021 at 8:33 AM Brian E Carpenter <
[email-masked]> wrote:

> equivalence between RA and DHVPv6 in the first place?
>

Not really. While it's true that the two protocols have different semantics
(e.g., one is push-based and one is polling), you can run both at the same
time. And by and large, with the possible exeption of DNS, there's not a
lot of overlap between the two (e.g., it's not possible to configure
routing via DHCP).

---

From: Erik Kline <[email-masked]>
Date: Tue, 24 Aug 2021 17:31:34 -0700

> with such a thing without having to spend two years in an RFP with their

<no hats>

They could also do that today if they just include the ability for the
operator to specify a byte string in hex, verify the length mod 8 is zero
and that the value in 2nd byte matches the computed length, and probably
also perform some check on the value of the first byte.  Other tools, like
command-line-run python scripts, could handle generating the correct byte
string for an operator's use case for the given ND option type.

This could then be included in all RAs without any additional knowledge on
the part of the router (assuming it's an option that doesn't require
special knowledge on the part of the router).

---

From: Michael Richardson <[email-masked]>
Date: Tue, 24 Aug 2021 21:55:03 -0400

> string for an operator's use case for the given ND option type.

Sure, you can do this after you have spent a few years to get 6man to give
you an option code for your 2-month experiment.

The multi-byte options under Expert Review are very plentiful.

---

From: Jen Linkova <[email-masked]>
Date: Wed, 25 Aug 2021 11:59:04 +1000

> with such a thing without having to spend two years in an RFP with their

That would be very convenient, indeed. So if this is the primary goal
of the proposal, maybe it can be achieved by
- only allowing private (experimental) configuration information
- requiring that the host MUST ignore any configuration provided by
this option if the same configuration is provided by the standard
means?

-- 
SY, Jen Linkova aka Furry

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 25 Aug 2021 14:30:46 +1200

Regards
   Brian Carpenter

> - only allowing private (experimental) configuration information

*initially* (while it's an Experimental RFC?)

> this option if the same configuration is provided by the standard

I don't like that. Suppose I wanted to test out PD via RA, for example?
Or announcing a /48 on-link prefix?

How about SHOULD, unless overriding the standard is the purpose of
the experiment?

    Brian

---

From: Jen Linkova <[email-masked]>
Date: Wed, 25 Aug 2021 13:51:41 +1000

> How about SHOULD, unless overriding the standard is the purpose of

Sorry, I SHOULD NOT have been jumping to normative language right away
w/o clarifying the idea first ;)

So, on one hand it would be cool to experiment with some non-standard
thing w/o jumping through all IETF and IANA hoops.
On another hand there is some risk associated with the proposed
solution. More specifically,
1) new configuration elements might be introduced w/o in-depth specifications.
2) hosts might get conflicting information from various sources.
It would inevitably lead to unpredictable client behaviour,
operational impact and degraded work-life balance for network
administrators..

So maybe what we need is to create a safe, easy to access playground
environment to have operational experience with proposed options and
to provide a clear path for those options to be either standardized or
disappear.

What I'm suggesting is that we do not create any globally unique
IANA-maintained registry but make this option suitable for
private/experimental use only.
For a new config element to be globally deployed/standardized an RFC
would still be required, with an operational experience using the
universal option considered as an implementation evidence.

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Wed, 25 Aug 2021 04:52:31 +0000

Indeed,

Same goes for RS wouldn’t it? 

The option could be stimulated by a request from a host or even a peer router in an RS and the RA could be  returned unicast.

So why limit the new freedom to RA?

Pascal

> Le 25 août 2021 à 03:55, Michael Richardson <[email-masked]> a écrit :
> 
>

---

From: Lorenzo Colitti <[email-masked]>
Date: Wed, 25 Aug 2021 14:04:00 +0900

I don't think it makes sense to add options to RS packets.

IPv6 relies on multicast RAs to maintain connectivity, and those multicast
RAs would need to be converted into unicast RAs. At that point you have
lots of issues: it doesn't scale as well, the network can't know when to
stop sending RAs when hosts disappear, etc.

These limitations can be overcome on particular networks and/or with
layering violations, but not in the general case.

On Wed, 25 Aug 2021, 13:53 Pascal Thubert (pthubert), <pthubert=
[email-masked]> wrote:

> The option could be stimulated by a request from a host or even a peer
> router in an RS and the RA could be  returned unicast.
>

---

From: Fernando Gont <[email-masked]>
Date: Wed, 25 Aug 2021 03:45:41 -0300

Hi, Jen,

> <[email-masked]> wrote:
[....]
> to provide a clear path for those options to be either standardized or

Isn't that what experimental RFCs are for?

And, if the goal is simply to experiment, rather than production
deployment, why would you need your router vendor to implement the
option *for that*?

Thanks,
--
Fernando Gont
Director of Information Security
EdgeUno, Inc.
PGP Fingerprint: DFBD 63E3 B248 AE79 C598 AF23 EBAE DA03 0644 1531
“This communication is the property of EdgeUno or one of its group companies and/or affiliates. This electronic message contains information which may be privileged or confidential. The information is intended to be for the exclusive use of the individual(s) named above and if you are not the intended recipient be aware that any non-explicitly authorized disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited, and will be considered a criminal offense. Please notify [email-masked] about the unintended receipt of this electronic message and delete it.”

---

From: Jen Linkova <[email-masked]>
Date: Wed, 25 Aug 2021 17:58:58 +1000

> Isn't that what experimental RFCs are for?

What I meant was 'after the option is standardized, it shouldn't be in
the universal option'.
So imagine I did an experiment of "sending the default font size in
RA" (without updating any IANA registry, just by using a "reserved for
experiment" value),
found that it drastically improved user experience
and everyone wants to be on my IPv6-only network.
Then I came back to the IETF with a proposal to have a standard RA
option for the default font size.

Indeed I could have done it today using RA option types 253 and 254
if, as Erik suggested, router vendors allowed me to include custom
crafted options into RAs.

> deployment, why would you need your router vendor to implement the

I'm not sure I understand the question. Would it be better if we say "
to get some real-life operational experience" rather than "to
experiment"?

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Wed, 25 Aug 2021 12:12:42 +0000

I don’t buy that, Lorenzo;

Even outside of this discussion, we do more an more unicast RAs, in particular in response to RS, and largely because multicast is a practical joke.
And even if RAs were all unicast, which is not the proposal, this would still not be in par with DHCP, which does not appear to be on its knees.
What’s killing us is the excess of broadcast, not unicast.

To my point: the draft could be extended to enable the possibility for an RS to offer or ask something and for the RA to encode a reply.
That’s neat compared to 8 byte alignments that protected RISC architectures of the 1990s but has been largely obsolete for 10-20 years.
That’s neat in this new decade where even IETF protocols start using Thrift for serialization.

Keep safe;

Pascal

From: Lorenzo Colitti <lorenzo=[email-masked]>
Sent: mercredi 25 août 2021 7:04
To: Pascal Thubert (pthubert) <[email-masked]>
Cc: Michael Richardson <[email-masked]>; Erik Kline <[email-masked]>; IPv6 List <[email-masked]>
Subject: Re: Adoption Call for <draft-troan-6man-universal-ra-option>

IPv6 relies on multicast RAs to maintain connectivity, and those multicast RAs would need to be converted into unicast RAs. At that point you have lots of issues: it doesn't scale as well, the network can't know when to stop sending RAs when hosts disappear, etc.

These limitations can be overcome on particular networks and/or with layering violations, but not in the general case.

On Wed, 25 Aug 2021, 13:53 Pascal Thubert (pthubert), <pthubert=[email-masked]<mailto:[email-masked]>> wrote:
Indeed,

Pascal

> Le 25 août 2021 à 03:55, Michael Richardson <[email-masked]<mailto:[email-masked]>> a écrit :
>
> 
> Erik Kline <[email-masked]<mailto:[email-masked]>> wrote:
> Michael Richardson <[email-masked]<mailto:[email-masked]>>   . o O ( IPv6 IøT consulting )
> [email-masked]<mailto:[email-masked]>

---

From: Philip Homburg <[email-masked]>
Date: Wed, 25 Aug 2021 15:29:17 +0200

>    To my point: the draft could be extended to enable the possibility
>    for an RS to offer or ask something and for the RA to encode a
>    reply.

And how is this different from stateless DHCPv6?

---

From: Michael Richardson <[email-masked]>
Date: Wed, 25 Aug 2021 12:12:04 -0400

> this option if the same configuration is provided by the standard

I don't understand why the document repeats the existing RA options.

I don't think that the option has to be purely for experimental use.
I think that it gets the IANA considerations right.

---

From: Vasilenko Eduard <[email-masked]>
Date: Thu, 26 Aug 2021 10:14:57 +0000

A reminder that RS by itself is not very useful
Because it is permitted only during interface initialization (section 6.3.7 of RFC 4861).
Hence, would you add options to RS or not – you could not rely on this mechanism anyway.
Ed/
From: ipv6 [mailto:[email-masked]] On Behalf Of Pascal Thubert (pthubert)
Sent: Wednesday, August 25, 2021 3:13 PM
To: Lorenzo Colitti <lorenzo=[email-masked]>
Cc: Michael Richardson <[email-masked]>; IPv6 List <[email-masked]>
Subject: RE: Adoption Call for <draft-troan-6man-universal-ra-option>

Keep safe;

Pascal

From: Lorenzo Colitti <lorenzo=[email-masked]<mailto:lorenzo=[email-masked]>>
Sent: mercredi 25 août 2021 7:04
To: Pascal Thubert (pthubert) <[email-masked]<mailto:[email-masked]>>
Cc: Michael Richardson <[email-masked]<mailto:[email-masked]>>; Erik Kline <[email-masked]<mailto:[email-masked]>>; IPv6 List <[email-masked]<mailto:[email-masked]>>
Subject: Re: Adoption Call for <draft-troan-6man-universal-ra-option>

Pascal

---

From: Vasilenko Eduard <[email-masked]>
Date: Thu, 26 Aug 2021 10:17:50 +0000

I like Jen's proposal
that something that is standardized (and has better chances for interoperability)
SHOULD be prioritized
against something that is not formally specified.
Ed/
-----Original Message-----
From: ipv6 [mailto:[email-masked]] On Behalf Of Jen Linkova
Sent: Wednesday, August 25, 2021 6:52 AM
To: Brian E Carpenter <[email-masked]>
Cc: Michael Richardson <[email-masked]>; Lorenzo Colitti <lorenzo=[email-masked]>; IPv6 List <[email-masked]>
Subject: Re: Adoption Call for <draft-troan-6man-universal-ra-option>

On Wed, Aug 25, 2021 at 12:30 PM Brian E Carpenter <[email-masked]> wrote:
> >> incremental effort on the part of router vendors.  This means that 
> >> if the Android team thinks that having an RA option to configure 
> >> the default font size on a phone is a useful thing [doubtful :-)], 
> >> then they can experiment with such a thing without having to spend 
> >> two years in an RFP with their router vendors.
> >
> > That would be very convenient, indeed. So if this is the primary 
> > goal of the proposal, maybe it can be achieved by
> How about SHOULD, unless overriding the standard is the purpose of the 
> experiment?

Sorry, I SHOULD NOT have been jumping to normative language right away w/o clarifying the idea first ;)

So, on one hand it would be cool to experiment with some non-standard thing w/o jumping through all IETF and IANA hoops.
On another hand there is some risk associated with the proposed solution. More specifically,
1) new configuration elements might be introduced w/o in-depth specifications.
2) hosts might get conflicting information from various sources.
It would inevitably lead to unpredictable client behaviour, operational impact and degraded work-life balance for network administrators..

So maybe what we need is to create a safe, easy to access playground environment to have operational experience with proposed options and to provide a clear path for those options to be either standardized or disappear.

What I'm suggesting is that we do not create any globally unique IANA-maintained registry but make this option suitable for private/experimental use only.
For a new config element to be globally deployed/standardized an RFC would still be required, with an operational experience using the universal option considered as an implementation evidence.

---

From: Jen Linkova <[email-masked]>
Date: Thu, 26 Aug 2021 20:57:43 +1000

> I don't think that the option has to be purely for experimental use.

Because the main concern expressed in this thread is: "the proposed
approach allows creating standard SLAAC configuration parameters
without specifying hosts or routers behaviour and/or getting the
proposed behaviour reviewed by the IETF".
IMHO any standard configuration provided by SLAAC must be published as an RFC.

> I think that it gets the IANA considerations right.

It would be great if we can lower the barrier of running experiments
with SLAAC options and getting operational experience before the I-D
is written and a new standard is proposed. However there should be a
safety net to prevent "nothing is more permanent than a temporary
solution" situation.

---

From: Nick Hilliard <[email-masked]>
Date: Thu, 26 Aug 2021 12:05:19 +0100

> safety net to prevent "nothing is more permanent than a temporary

one of the difficulties in this specific situation is that chipsets 
needs to be designed and built to support new encapsulation formats at 
this layer, e.g. first-hop security.  This draft isn't, and shouldn't 
be, considered a temporary solution to anything.  Either it needs to be 
made Experimental track or else it needs serious commitment in terms of 
careful specification / interoperability.

Nick

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Thu, 26 Aug 2021 13:28:27 +0000

Hello Eduard:

As you know, an RFC says is true until another RFC changes it. It might be that we’re wasting the little resources we have by keeping constraints that used to but do not make sense anymore. RS is such mostly wasted land. It could be used for a lot more thing, see the corresponding DIS in RPL.

The list in the may is clearly an incomplete set of examples, e.g., what if the current router sent a final RA and this node has no more default gw, what if the wireless node roamed and it wishes to assess whether it has the same connectivity using RS to the link local of its router, etc…

This particular suggestion (a lowercase may) dates from the time where the suggested behaviour upon RS was (little wait and) multicast RA, though unicast was always a MAY.  In the face of harmful broadcast, we are reversing that line of thought, see for instance https://datatracker.ietf.org/doc/html/rfc7772#section-5.1. Now, unicast response has more favour.

Here the proposal is to trigger a response that has to be specific and thus unicast. Yes, this can be seen as stepping on DHCP’s feet. It could also be seen as a basic router to router media. It’s mostly a door opener to enable new router to router capabilities in ND, independent of the other IGPs they might run.

Keep safe;

Pascal

From: ipv6 <[email-masked]> On Behalf Of Vasilenko Eduard
Sent: jeudi 26 août 2021 12:15
To: Pascal Thubert (pthubert) <pthubert=[email-masked]>; Lorenzo Colitti <lorenzo=[email-masked]>
Cc: Michael Richardson <[email-masked]>; IPv6 List <[email-masked]>
Subject: RE: Adoption Call for <draft-troan-6man-universal-ra-option>

A reminder that RS by itself is not very useful
Because it is permitted only during interface initialization (section 6.3.7 of RFC 4861).
Hence, would you add options to RS or not – you could not rely on this mechanism anyway.
Ed/
From: ipv6 [mailto:[email-masked]] On Behalf Of Pascal Thubert (pthubert)
Sent: Wednesday, August 25, 2021 3:13 PM
To: Lorenzo Colitti <lorenzo=[email-masked]<mailto:lorenzo=[email-masked]>>
Cc: Michael Richardson <[email-masked]<mailto:[email-masked]>>; IPv6 List <[email-masked]<mailto:[email-masked]>>
Subject: RE: Adoption Call for <draft-troan-6man-universal-ra-option>

Keep safe;

Pascal

Pascal

---

From: Vasilenko Eduard <[email-masked]>
Date: Thu, 26 Aug 2021 13:37:25 +0000

Hi Pascal,
Then I agree with you that RS/RA flexibility is better to have in both directions
In hope that RS would be permitted in the future for other situations.
Ed/
From: Pascal Thubert (pthubert) [mailto:[email-masked]]
Sent: Thursday, August 26, 2021 4:28 PM
To: Vasilenko Eduard <[email-masked]>; Pascal Thubert (pthubert) <pthubert=[email-masked]>; Lorenzo Colitti <lorenzo=[email-masked]>
Cc: Michael Richardson <[email-masked]>; IPv6 List <[email-masked]>
Subject: RE: Adoption Call for <draft-troan-6man-universal-ra-option>

Hello Eduard:

Keep safe;

Pascal

From: ipv6 <[email-masked]<mailto:[email-masked]>> On Behalf Of Vasilenko Eduard
Sent: jeudi 26 août 2021 12:15
To: Pascal Thubert (pthubert) <pthubert=[email-masked]<mailto:pthubert=[email-masked]>>; Lorenzo Colitti <lorenzo=[email-masked]<mailto:lorenzo=[email-masked]>>
Cc: Michael Richardson <[email-masked]<mailto:[email-masked]>>; IPv6 List <[email-masked]<mailto:[email-masked]>>
Subject: RE: Adoption Call for <draft-troan-6man-universal-ra-option>

Keep safe;

Pascal

Pascal

---

From: Bob Hinden <[email-masked]>
Date: Thu, 26 Aug 2021 10:49:34 -0700

Jen,

> On Aug 26, 2021, at 3:57 AM, Jen Linkova <[email-masked]> wrote:
> 
> …….

> safety net to prevent "nothing is more permanent than a temporary

As has been pointed out, we do have two experimental code points that are available for experimentation.

From https://www.iana.org/assignments/icmpv6-parameters/icmpv6-parameters.xhtml

   253	RFC3692-style Experiment 1 [1]	[RFC4727]
   254	RFC3692-style Experiment 2 [1]	[RFC4727]

Given that RAs are limited to a single link the likelihood of a collision seems very low.  Do we need something else for experiments to gain operational experience?

The benefit, of course, of having a document (likely an ID) is to verify that it is specified well enough to enable interoperable implementations.

Bob

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 27 Aug 2021 08:34:06 +1200

On 25-Aug-21 12:05, Lorenzo Colitti wrote:
> On Wed, Aug 25, 2021 at 8:33 AM Brian E Carpenter <[email-masked] <mailto:[email-masked]>> wrote:
> 
> Not really. While it's true that the two protocols have different semantics (e.g., one is push-based and one is polling), you can run both at the same time. And by and large, with the possible exeption of DNS, there's not a lot of overlap between the two (e.g., it's not possible to configure routing via DHCP).

That's exactly what I mean: we don't have feature equivalence, which means there is zero hope of paring back to a single solution. The universal option is a possible path to a single solution in the long term.

   Brian

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 27 Aug 2021 08:48:23 +1200

> private/experimental use only.

There's a trick we used in GRASP for named objectives, which
allows both registered and unregistered names for this exact reason:
https://www.rfc-editor.org/rfc/rfc8990.html#section-2.10.1-4

Regards
   Brian Carpenter

---

From: Lorenzo Colitti <[email-masked]>
Date: Tue, 31 Aug 2021 11:07:34 +0900

On Thu, Aug 26, 2021 at 10:28 PM Pascal Thubert (pthubert) <pthubert=
[email-masked]> wrote:

> Here the proposal is to trigger a response that has to be specific and
> thus unicast. Yes, this can be seen as stepping on DHCP’s feet. It could
> also be seen as a basic router to router media. It’s mostly a door opener
> to enable new router to router capabilities in ND, independent of the other
> IGPs they might run.
>

I think that's a problem because it becomes impossible to refresh those
parameters via multicast RA. In order to refresh those parameters, you have
to either require the host to send periodic RSes (but when? How does the
host know when to re-send the RS? How will it know if something has
changed?) or require the network to send periodic unicast RA to all hosts
(but to which hosts? how does it know which hosts are even still on the
network?).

---

From: Lorenzo Colitti <[email-masked]>
Date: Tue, 31 Aug 2021 11:16:32 +0900

> careful specification / interoperability.

That's a great point. Writing a generic JSON parser in an ASIC (or, in
general, in anything that needs to operate at line rate) seems difficult to
impossible.

---

From: Fernando Gont <[email-masked]>
Date: Tue, 31 Aug 2021 00:01:58 -0300

Hi, Brian,

> That's exactly what I mean: we don't have feature equivalence, which means there is zero hope of paring back to a single solution. The universal option is a possible path to a single solution in th…

Unfortunately, it would seem to me that the lack of feature equivalence
has more to do with religious debates than with the inability to find a
way to convey the associated information in one protocol or the other.

e.g., quite likely you won't get DHCPv6 to support default routes simply
by standardizing a universal option....

Thanks,

---

From: Tommy Pauly <[email-masked]>
Date: Mon, 30 Aug 2021 21:38:30 -0700

I’m a bit skeptical of the approach put forth in this draft being the right solution. I appreciate the desire to have options that are more easily extensible without router changes, particularly for limited or experimental deployments, but putting the JSON data within the RA does not seem to be necessary. 

Particularly, PvDs already defines containers of RA options in RFC 8801 that can reference a JSON API that’s accessed out of band for extended configuration. If you want the “default font size” option, as humorous as that proposal may be, we already have a mechanism that would allow for that kind of experimentation.

It’s also unclear to me if the nuances of the PvD option are being maintained in the CBOR encoding proposed here, since the PvD option itself can contain other nested options. 

Thanks,
Tommy

> On Aug 24, 2021, at 8:52 PM, Jen Linkova <[email-masked]> wrote:
>

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Tue, 31 Aug 2021 07:00:30 +0000

Hello Lorenzo

If the use case is router to router, routers could use RS + RA just like host to router uses NS + NA. In RFC 8505, a router can sent an async unicast NA to the host, e.g., to indicate that the routing service is down as used by RFC 9010, RIFT, and an eVPN draft. The parallel would be true here.

Keep safe;

Pascal

From: Lorenzo Colitti <lorenzo=[email-masked]>
Sent: mardi 31 août 2021 4:08
To: Pascal Thubert (pthubert) <[email-masked]>
Cc: Vasilenko Eduard <[email-masked]>; Pascal Thubert (pthubert) <[email-masked]>; Michael Richardson <[email-masked]>; IPv6 List <[email-masked]>
Subject: Re: Adoption Call for <draft-troan-6man-universal-ra-option>

On Thu, Aug 26, 2021 at 10:28 PM Pascal Thubert (pthubert) <pthubert=[email-masked]<mailto:[email-masked]>> wrote:
Here the proposal is to trigger a response that has to be specific and thus unicast. Yes, this can be seen as stepping on DHCP’s feet. It could also be seen as a basic router to router media. It’s mostly a door opener to enable new router to router capabilities in ND, independent of the other IGPs they might run.

I think that's a problem because it becomes impossible to refresh those parameters via multicast RA. In order to refresh those parameters, you have to either require the host to send periodic RSes (but when? How does the host know when to re-send the RS? How will it know if something has changed?) or require the network to send periodic unicast RA to all hosts (but to which hosts? how does it know which hosts are even still on the network?).

---

From: Lorenzo Colitti <[email-masked]>
Date: Tue, 31 Aug 2021 17:12:13 +0900

The use case is router to host (i.e., the classic RA model). Scenario:

   1. Host sends RS with special option A.
   2. Router sends unicast RA with response to special option A with a
   lifetime of X.
   3. Time passes. The router sends a multicast RA. If special option A is
   only for this host, then it cannot include special option A.
   4. How does option A get refreshed?

On Tue, Aug 31, 2021 at 4:01 PM Pascal Thubert (pthubert) <pthubert=
[email-masked]> wrote:

> Hello Lorenzo
>
>
>
> If the use case is router to router, routers could use RS + RA just like
> host to router uses NS + NA. In RFC 8505, a router can sent an async
> unicast NA to the host, e.g., to indicate that the routing service is down
> as used by RFC 9010, RIFT, and an eVPN draft. The parallel would be true
> here.
>
>
>
> Keep safe;
>
>
>
> Pascal
>
>
>
> *From:* Lorenzo Colitti <lorenzo=[email-masked]>
> *Sent:* mardi 31 août 2021 4:08
> *To:* Pascal Thubert (pthubert) <[email-masked]>
> *Cc:* Vasilenko Eduard <[email-masked]>; Pascal Thubert
> (pthubert) <[email-masked]>; Michael Richardson <[email-masked]>;
> IPv6 List <[email-masked]>
> *Subject:* Re: Adoption Call for <draft-troan-6man-universal-ra-option>
>
>
>

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Tue, 31 Aug 2021 09:57:40 +0000

Clearly something like this has to be stateful. The short answer is router maintains a state. How that is done for NS/NA is illustrated in RFC 9010.
I see value doing it for RS RA as well mostly for (virtual) router to router interaction. Meaning that routers would now listen to RAs, at least unicast ones, abd possibly final RAs.
E.g., long answer:

  1.  Host sends RS with special option A, e.g., Calico asking a ToR to inject a route in the fabric for a prefix configured by the devops
  2.  Router sends unicast RA with response to special option A with a lifetime of X and creates a state (that’s not a cache, e.g. RFC 9010)
  3.  Time passes. The router sends a multicast RA. If special option A is only for this host, then it cannot include special option A.
  4.  Something changes like the routing capability expressed in RFC 9010 by a R flag
  5.  Router sends Calico an async unicast RA to indicate that the routing contract is broken, based on the state that it maintains for that calico for a contractual lifetime
Works?

From: Lorenzo Colitti <lorenzo=[email-masked]>
Sent: mardi 31 août 2021 10:12
To: Pascal Thubert (pthubert) <[email-masked]>
Cc: Vasilenko Eduard <[email-masked]>; Michael Richardson <[email-masked]>; IPv6 List <[email-masked]>
Subject: Re: Adoption Call for <draft-troan-6man-universal-ra-option>

  1.  Host sends RS with special option A.
  2.  Router sends unicast RA with response to special option A with a lifetime of X.
  3.  Time passes. The router sends a multicast RA. If special option A is only for this host, then it cannot include special option A.
  4.  How does option A get refreshed?

On Tue, Aug 31, 2021 at 4:01 PM Pascal Thubert (pthubert) <pthubert=[email-masked]<mailto:[email-masked]>> wrote:
Hello Lorenzo

Keep safe;

Pascal

From: Lorenzo Colitti <lorenzo=[email-masked]<mailto:[email-masked]>>
Sent: mardi 31 août 2021 4:08
To: Pascal Thubert (pthubert) <[email-masked]<mailto:[email-masked]>>
Cc: Vasilenko Eduard <[email-masked]<mailto:[email-masked]>>; Pascal Thubert (pthubert) <[email-masked]<mailto:[email-masked]>>; Michael Richardson <[email-masked]<mailto:[email-masked]>>; IPv6 List <[email-masked]<mailto:[email-masked]>>
Subject: Re: Adoption Call for <draft-troan-6man-universal-ra-option>

---

From: Lorenzo Colitti <[email-masked]>
Date: Tue, 31 Aug 2021 19:30:25 +0900

It works if you're willing for routers to keep a lot of state and you have
a reliable way to detect hosts that are no longer on link. Many links are
not like that, and certainly none are like that without layering violations.

On Tue, 31 Aug 2021, 18:59 Pascal Thubert (pthubert), <pthubert=
[email-masked]> wrote:

> Clearly something like this has to be stateful. The short answer is router
> maintains a state. How that is done for NS/NA is illustrated in RFC 9010.
>
> I see value doing it for RS RA as well mostly for (virtual) router to
> router interaction. Meaning that routers would now listen to RAs, at least
> unicast ones, abd possibly final RAs.
>
> E.g., long answer:
>
>    1. Host sends RS with special option A, e.g., Calico asking a ToR to
>    inject a route in the fabric for a prefix configured by the devops
>    lifetime of X and creates a state (that’s not a cache, e.g. RFC 9010)
>    3. Time passes. The router sends a multicast RA. If special option A
>    is only for this host, then it cannot include special option A.
>    5. Router sends Calico an async unicast RA to indicate that the
>    routing contract is broken, based on the state that it maintains for that
>    calico for a contractual lifetime
>
> Works?
>
>
>
> *Sent:* mardi 31 août 2021 10:12
> *Cc:* Vasilenko Eduard <[email-masked]>; Michael Richardson <
> [email-masked]>; IPv6 List <[email-masked]>
>    3. Time passes. The router sends a multicast RA. If special option A
>    is only for this host, then it cannot include special option A.

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Tue, 31 Aug 2021 12:33:22 +0000

We are already maintaining a lot of state. Just look at eVPN or LISP, and there’s more for SAVI and stuff. But snooping has many drawbacks vs. registration.
When a node moves, the infra detects it and cleans the stale states. All proven and deployed.
For what I’m discussing below, it would be useful as an extension of fig 18 of https://datatracker.ietf.org/doc/html/draft-thubert-bess-secure-evpn-mac-signaling-00.

Sent: mardi 31 août 2021 12:30

It works if you're willing for routers to keep a lot of state and you have a reliable way to detect hosts that are no longer on link. Many links are not like that, and certainly none are like that without layering violations.

On Tue, 31 Aug 2021, 18:59 Pascal Thubert (pthubert), <pthubert=[email-masked]<mailto:[email-masked]>> wrote:
Clearly something like this has to be stateful. The short answer is router maintains a state. How that is done for NS/NA is illustrated in RFC 9010.
I see value doing it for RS RA as well mostly for (virtual) router to router interaction. Meaning that routers would now listen to RAs, at least unicast ones, abd possibly final RAs.
E.g., long answer:

Cc: Vasilenko Eduard <[email-masked]<mailto:[email-masked]>>; Michael Richardson <[email-masked]<mailto:[email-masked]>>; IPv6 List <[email-masked]<mailto:[email-masked]>>

Keep safe;

Pascal

---

From: Michael Richardson <[email-masked]>
Date: Tue, 31 Aug 2021 12:10:46 -0400

Tommy Pauly <[email-masked]> wrote:
    > I’m a bit skeptical of the approach put forth in this draft being the
    > right solution. I appreciate the desire to have options that are more
    > easily extensible without router changes, particularly for limited or
    > experimental deployments, but putting the JSON data within the RA does
    > not seem to be necessary.

Just a nit: on the wire, it is CBOR, not JSON.
The JSON transliteration of CBOR is suggested as a UI for the router only.

Other threads suggested that people think that it's on the wire, and that
ASICs would need to parse JSON, which is simply not true.

---

From: Michael Richardson <[email-masked]>
Date: Tue, 31 Aug 2021 12:13:43 -0400

Lorenzo Colitti <[email-masked]> wrote:
    > a reliable way to detect hosts that are no longer on link.

Neighbor Cache Entries already exist, and are already indexed by node.
You don't need more state than that.

    > Many links are

It's true.  Many links maintain even more state.
Please tell me which links have less state?

---

From: Nick Hilliard <[email-masked]>
Date: Tue, 31 Aug 2021 17:22:05 +0100

> ASICs would need to parse JSON, which is simply not true.

this doesn't change the fact that physical hardware will need to be spun 
to parse this data.  And CBOR is still significantly more complex than a 
tlv.

Nick

---

From: [email-masked]
Date: Tue, 31 Aug 2021 18:47:11 +0200

> this doesn't change the fact that physical hardware will need to be spun to parse this data.  And CBOR is still significantly more complex than a tlv.

RA parsers in ASICs might not be the main target for this work.
Do you have any real examples or are there implementors of RA parsers in ASICs on the list?

Cheers,
Ole

---

From: Bob Hinden <[email-masked]>
Date: Tue, 31 Aug 2021 11:44:41 -0700

> On Aug 31, 2021, at 9:47 AM, [email-masked] wrote:
> 
> Signed PGP part

I had the same question.   I would have thought that the vast majority of RA processing would be in hosts, all the router has to do is send the data.

Bob

---

From: Michael Richardson <[email-masked]>
Date: Tue, 31 Aug 2021 14:59:23 -0400

> this doesn't change the fact that physical hardware will need to be spun to
    > parse this data.  And CBOR is still significantly more complex than a tlv.

I also don't know why this option it needs to be parsed in hardware.

---

From: Fernando Gont <[email-masked]>
Date: Tue, 31 Aug 2021 17:16:26 -0300

> I also don't know why this option it needs to be parsed in hardware.

First hop security?

---

From: Carsten Bormann <[email-masked]>
Date: Tue, 31 Aug 2021 22:35:18 +0200

>> I also don't know why this option it needs to be parsed in hardware.

Please explain.

The TLV carrying this option looks like other TLVs, so you already can “parse” that.
Looking into the option is a bit weird because that is meant to carry data items that vary a lot between applications.
(Besides, CBOR encoding *is* a form of TLV, so if you want to build hardware for that, you can do that, too; Appendix C of RFC 8949 tells you what to do.)

Grüße, Carsten

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Tue, 31 Aug 2021 21:13:21 +0000

Typically the hardware intercepts all the RAs and punts to software which does all the policing, eg RA guard, RA throttling etc… so no, no hardware here.

Regards,

Pascal

> Le 31 août 2021 à 22:36, Carsten Bormann <[email-masked]> a écrit :
>

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 1 Sep 2021 10:25:53 +1200

> (Besides, CBOR encoding *is* a form of TLV, so if you want to build hardware for that, you can do that, too; Appendix C of RFC 8949 tells you what to do.)

Yes, but CBOR is flexibly extensible, so there must be a limit to what can be burned into hardware.

On the other hand, I did at one point write a tlv.loads() and tlv.dumps() 
package in Python, and couldn't discern any gross performance difference compared to cbor.loads() and cbor.dumps(). I didn't do extensive performance testing, however.

    Brian