Subject: Re: [v6ops] Comments on draft-ali-ipv6rtr-reqs-01

From: Fred Baker <[email-masked]>
Date: Sun, 1 Jan 2017 17:23:53 -0800

> On Dec 30, 2016, at 1:59 PM, Russ White <[email-masked]> wrote:
> 
> 
>> It is indeed an individual draft, and to my knowledge no given working
> group
>> has been asked for opinions. That said, we welcome any and all review.
>> Specifically, I have copied v6ops and 6man on this note.
> 
> We would like to present it to a WG as a work item--which WG would be best
> for this one? There are some sections that need to be filled before we
> present it, I think.
> 
> :-)
> 
> Russ

Personaly opinion: this isn’t about IPv6 per se, it is about the operation of an IPv6 network. I’d suggest v6ops.

---

From: Fred Baker <[email-masked]>
Date: Sun, 1 Jan 2017 17:26:50 -0800

> On Jan 1, 2017, at 5:23 PM, Fred Baker <[email-masked]> wrote:
> 
> 

Note that I’m not precluding 6man input. I’m asking what change or clarification in IPv6 implementations (e.g., IPv6 Maintenance) is called for. I don’t think there are any. I think it comments on how IPv6 is used operationally, and by extension, what an operator might expect to find in IPv6 implementations he deploys.

---

From: Tim Chown <[email-masked]>
Date: Tue, 3 Jan 2017 16:07:07 +0000

Hi,

On 2 Jan 2017, at 01:23, Fred Baker <[email-masked]<mailto:[email-masked]>> wrote:

On Dec 30, 2016, at 1:59 PM, Russ White <[email-masked]<mailto:[email-masked]>> wrote:

:-)

Russ

I looked through this draft quickly as it seemed to be relevant to the ongoing 6man work on updating RFC 6434, IPv6 Node Requirements.

I like the style it’s written in, and the blend of advice being given. It reads nicely.

I think this draft treads more heavily into operational and design requirements, rather than just being a list of protocol requirements, so I’d also say it looks more like a v6ops document, and it could probably be renamed to match that emphasis.

Tim

---

From: Bob Hinden <[email-masked]>
Date: Tue, 3 Jan 2017 12:12:57 -0800

Fred.

> Personaly opinion: this isn’t about IPv6 per se, it is about the operation of an IPv6 network. I’d suggest v6ops.

Probably good to keep both w.g.’s involved.  I was thinking this was similar to IPv6 Node Requirements which in in 6MAN.

Also, 6MAN has started on an Node Requirements bis document, good to keep this coordinated with that.

Bob

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

---

From: Fred Baker <[email-masked]>
Date: Tue, 3 Jan 2017 12:51:43 -0800

No argument, and BTW I tend to think most documents in both working groups benefit from cross-pollination :-)

> On Jan 3, 2017, at 12:12 PM, Bob Hinden <[email-masked]> wrote:
> 
> Fred.
>

---

From: Fernando Gont <[email-masked]>
Date: Tue, 3 Jan 2017 03:07:38 -0300

On 01/01/2017 10:26 PM, Fred Baker wrote:
>>>> has been asked for opinions. That said, we welcome any and all
>>>> review. Specifically, I have copied v6ops and 6man on this
>>>> note.
>>> 
>>> We would like to present it to a WG as a work item--which WG
>>> would be best for this one? There are some sections that need to
>>> be filled before we present it, I think.
>>> 
>>> :-)
>>> 
>>> Russ
>> 
>> Personaly opinion: this isn’t about IPv6 per se, it is about the
>> operation of an IPv6 network. I’d suggest v6ops.
> 
> Note that I’m not precluding 6man input. I’m asking what change or
> clarification in IPv6 implementations (e.g., IPv6 Maintenance) is
> called for. I don’t think there are any. I think it comments on how
> IPv6 is used operationally, and by extension, what an operator might
> expect to find in IPv6 implementations he deploys.

I somewhat agree, but: wasn't the Node Requirements RFC produced by
6man? -- this one should be similar in nature...

Thanks,
-- 
Fernando Gont
SI6 Networks
e-mail: [email-masked]
PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492

---

From: joel jaeggli <[email-masked]>
Date: Wed, 4 Jan 2017 00:07:11 -0800

> 6man? -- this one should be similar in nature...
and 6204 / 7084 / 7849 were done in v6ops, it's not that unusual a style
of document generally speaking.

---

From: Tim Chown <[email-masked]>
Date: Wed, 4 Jan 2017 08:47:34 +0000

On 4 Jan 2017, at 08:07, joel jaeggli <[email-masked]<mailto:[email-masked]>> wrote:

On 1/2/17 10:07 PM, Fernando Gont wrote:
On 01/01/2017 10:26 PM, Fred Baker wrote:
On Jan 1, 2017, at 5:23 PM, Fred Baker <[email-masked]<mailto:[email-masked]>>
wrote:

It is indeed an individual draft, and to my knowledge no given
working
group

:-)

Russ

This draft is a little different to RFC6434; there’s more operational/design text in there.

The important thing is that, given it looks like really nice work, it gets adopted somewhere :)

Tim

---

From: Lee Howard <[email-masked]>
Date: Sat, 07 Jan 2017 15:50:27 -0500

This is a hat-off document review.

General notes:
I love this document. One of the best operations-related documents I¹ve seen
at the IETF.
The Architecture Review I think should be a separate document. It¹s
excellent, but I can imagine many other documents wanting to refer just to
that portion. It may be appropriate in rtgwg, too.

If you¹re going to say ³routers,² use that word throughout; to me, a
³network device² is a device on a network, not necessarily one that forwards
at layer 3.

Specific notes:
Are there really six authors? Sure some of them contributed text, while just
a few are document authors.

Don¹t forget the Abstract.

Section 1.
Are there references for the definitions of ³routers² and ³middleboxes² you
could reference (e.g., rfc7663 ³Report from the IAB Workshop on Stack
Evolution in a Middlebox Internet (SEMI)²)?

Paragraph ³Readers should recognize² is great. Replace ³This memo will only
interact² with ³This memo will only discuss².

Is there an IPv4 router requirements doc, foc citation/comparison?

2.1 The first paragraph is excellent. Additional note, though: different
implemtnations may increase robustness in the face of a weakness or
vulnerability that only affects one.

First bulleted paragraph:
Should it be ³applications² instead of ³software² in the first bulleted
paragraph? For instead, I¹d rather say, ³Applications should deal with error
states gracefully² than ³Software should be written to deal with error
states gracefully.² And, ³it should do so in a way that does not spread
false reachability information, or allow false information to remain.² Then,
as a separate sentence, ³It should also not fail in a way overloadsŠ²

Second bulleted paragraph is a great point.

Third bullet should reference rfc5218 ³What Makes for a Successful
Protocol?²

Fourth bullet should, too, plus reference draft-iab-protocol-transitions.

The last bullet needs more detail. Should you ignore bits that are not in
wide use, or handle them a specific way? IN any case, have to handle errors
gracefully (as you said above).

2.2
s/impese/impede ?

³as simple as possible² is often appended, ³and no simpler.² That gets at
your point: if it¹s too simple, it may not solve your problem.
However, a counterpoint: Some problems turn out not to be worth solving due
to the complexity introduced. See IRTF¹s ncrg.

I¹d add a sentence or clause to the ³Elegance is the goal² paragraph to
include clarifying the problem (some solutions solve what you think the
problem is, but often the problem is ³net expense is too high² or ³latency
is too high for X applications² rather than ³our MEDs need tuning²).

Totally agree about tradeoffs. I want to add that competing optimizations
can¹t optimize for everything, but sometimes it¹s obvious what to optimize
for. For instance, adding a bit of state on a device that is loaded with
unused resources is fine.

Again, in ³The amount of state² I¹d refer to ncrg; I think
it¹shttps://tools.ietf.org/html/draft-irtf-ncrg-complexity-framework-01
Also, this paper using state as a metric for
complexity:https://people.eecs.berkeley.edu/~sylvia/papers/netcomp.pdf

[citation needed] for ³All nontrivial abstractions leak.²

The bullet ³The desired optimization² isn¹t clear to me. Do you mean
efficiency? Something else?

I¹d like to see the triangle problem reworked into easily stated points.
state/interactions/optimization isn¹t quite there, but the idea of what I
mean.

2.3
Hourglass [citation needed?]
You include MPLS, which is confusing later. MPLS router or MPLS switch? You
see the problem with including it in the document, without explicit and
constant sidebars about L2/L3?

In the paragraph ³These protocols² you should refer back to your statement
that all abstractions leak (2.2)

2.4 3rd bullet is hand-waving. What information must be handled locally?
Does local mean ³on this router² or ³on this card² or ³in this AS²? HBH
headers? ³etc.² is really vague.

Also, the paragraph ³When consulting² is explicitly about IP routers: MPLS
doesn¹t do a longest prefix match.

3.1 
citations needed for SNMP and MIB definitions.

³Network devices should place a priority on supporting machine readable
APIs.² Do you mean device maufacturers should focus on writing code to do
that, or do you mean the devices should prioritize API config bits somehow?
I think you mean ³Router manufacturers should focus on developing
machine-readable APIs.² But I¹m not sure I agree, since to prioritize
something means to implicitly deprioritize something else (if everything¹s a
priority, nothing is), and I don¹t want to encourage vendors to prioritize
APIs over CLI.

3.2 SHould mention AAA.

3.3
³To reach this goal, IPv6 network devices shouldŠ²
SHOULD?  You mean routers, not devices connected to a network?

btw, we¹re more than half way through the document, and this is the first
mention of anything specific to IPv6. That¹s why I think the first half
should be a separate doc.

This section should make reference to ANIMA and SUPA WG efforts, even if
just for awareness. Maybe HNCP (Homenet), too. All of those efforts could
make a difference in this area.

3.4 ³The network control plane² needs a verb.

"DoS and DDoS attacks directly on network devices² should be ³DoS and DDoS
attacks directly against routers.²

Typo: authentication
³These techniques² should start a new sentence.

4.
Second bullet: not just lots of information, but lots of queries (overhead
in packet size and processing)

³There are three broad² is a great breakdown of what you¹re describing.

4.1 after ³human readability² I¹d highlight that software can translate for
humans.

Again in the NETCONF/RESTCONF paragraph, ³current focus² could mean
³prioritize this and let other relevant efforts slide.² But I basically
agree with the point you¹re making about a single modeling language.

4.2 First paragraph could use more detail. Why is this important?

s/Traffic Engineer/Traffic Engineering

Yes, please add the missing sections, but make sure titles agree with your
outline (e.g., top of p. 12 says ³device state, topology state, and flow
state,² but the headings don¹t match, especially at ³4.3 Traffic Flow and
Traceability.²

5. SHOULD?

5.1 Yes, address != host identifier, but why?

5.2 2nd bullet, is there a reference to cite for this?

The bullet ³Configuring an prefix length longer than a /64Šshould require
additional configuration stepsŠ²  Hmm. I¹m not sure about this one. More
discussion required.
The following paragraph is good.

5.3
³(History of MTU is not a happy one)² made me smile

The bullet on ineffectiveness of pMTUd should refer to something. . .  maybe
the recommendations on ICMP filtering?

Where¹d the numbers come from for delaying serialized packets? It¹s useful;
is it just math, or is there a reference? I hadn¹t thought about this
before.

5.4. You don¹t mention ping.
ICMP is blocked to prevent reconn attacks.

5.6 I wish you luck!

In all of these sections, should there be a statement that none of {IPv4,
IPv6, MPLS} can require any of the others?  i.e., ³IPv6 MUST NOT require
IPv4 in order to work.² (rfc6540)

The Security Considerations section is weak. There¹s a lot to consider, and
a document detailing router requirements really ought to discuss security
pretty thoroughly.

Keep at it: this could be great.

Lee

---

From: Fred Baker <[email-masked]>
Date: Sun, 8 Jan 2017 21:56:59 -0800

> On Jan 7, 2017, at 12:50 PM, Lee Howard <[email-masked]> wrote:
> 

It's dated, but one could mention RFC 1812.