Re: [v6ops] I-D Action: draft-horley-v6ops-lab-00.txt

[David Farmer <[e-mail]>]

On Sat, Jun 12, 2021 at 17:43 Mark Smith <[e-mail]> wrote:

> On Sat, 12 Jun 2021 at 16:28, David Farmer <[e-mail]> wrote:
> >
> >
> >
> > On Fri, Jun 11, 2021 at 21:58 Mark Smith <[e-mail]> wrote:
> >>
> >> If the 2001:db8::/32 prefix is not big enough to usefully teach the
> >> techniques of address space planning and route aggregation, how big
> >> does it need to be?
> >
> >
> > I don’t think it is unreasonable for there to be a larger documentation
> prefix, or even multiple documentation prefixes. There should be enough
> documentation IPv6 address space to provide a number of /32 ISP allocations
> for an example. Even with ASCII art, examples with 3 to 5 ISPs are
> relatively common.
> >
> > Allocating something like a total of a /24, or even /20 for
> documentation purposes isn’t going create any kind issues for IPv6, and
> would allow for much more realistic examples in documentation and for
> training labs.
> >
>
> I don't agree it would be realistic.
>
> People who are dealing with IPv6 prefixes that are shorter than /48,
> such as people at ISPs dealing with RIR /32s or shorter should be able
> to work with prefix lengths that don't fall on nibble or octet
> boundaries.
>
> If they've been taught those techniques on a ULA /48 or the existing
> 2001:db8::/32 prefix, they should also have been taught well enough to
> understand how to apply them to other prefix lengths without having to
> do examples with those other prefix lengths. Doing so starts to imply
> that these techniques are specific to certain prefix lengths.
>
> >> How many aggregation boundaries does there need to
> >> be in a fictitious network and its address space to effectively teach
> >> address space planning and route aggregation?
> >>
> >> The bits available for aggregation in in either 2001:db8::/32 or a ULA
> >> /48 can easily support 4 levels or more of 4 bit aggregation
> >> boundaries at nibble boundaries. When wouldn't that be enough to teach
> >> the technique?
> >
> >
> > I’m sorry you are suggesting for examples to be complicated and
> difficult to understand.
> >
> > To the contrary, examples should be simple, suggestive of what will be
> seen in real operational networks, and easily understood even by IPv6
> novices.
> >
>
> Novices aren't experts and shouldn't be expected to easily understand
> what IPv6 experts do.


Why should you have to be an expert to understand a simple diagram with the
addressing for 3 typical ISPs on it? The lack of sufficient documentation
address space is what makes the diagram complicated. In reality 3 ISPs will
have 3 /32 prefixes or shorter, why can’t we create that simple example in
documentation?

How are novices to ever become experts if they can’t be thought about the
simple stuff first?

The trouble with making hard things too simple and easy when teaching
> them is that you don't end up teaching people how to do the hard
> things. The continued teaching of IPv4 Classful addressing many years
> past the development and deployment of CIDR would be a canonical
> example.


You seem to forget to we want to make IPv6 simple. Isn’t that why we have a
/64 boundary?

> The real Internet has many ISPs, allowing for multiple /32 ISPs in an
> example that is supposed to represent multiple ISPs seems necessary to meet
> the above criteria, at least in my opinion.
> >
>
> Those learning inter-ISP routing aren't going to be novices, they're
> already well along the path of being IPv6 experts. The reality is that
> ISPs don't all only get a /32 - the one I work for just received a /28
> from our RIR.


There are plenty of novices trying to connect to an Internet exchanges.
Furthermore, you make my point for me, we should be able to represent
reality in diagrams some ISP have have prefixes shorter than /32.

Regards,
> Mark.
>
>
>
> > Thanks.
> >
> > --
> > ===============================================
> > David Farmer               Email:[e-mail]
> > Networking & Telecommunication Services
> > Office of Information Techn
> <https://www.google.com/maps/search/e+of+Information+Techn?entry=gmail&source=g>
> ology
> > University of Minnesota
> > 2218 University Ave SE        Phone: [phone]
> > Minneapolis, MN 55414-3029   Cell: 612-812-9952
> > ===============================================
>
-- 
===============================================
David Farmer               Email:[e-mail]
Networking & Telecommunication Services
Office of Information Technology
University of Minnesota
2218 University Ave SE        Phone: [phone]
Minneapolis, MN 55414-3029   Cell: 612-812-9952
===============================================