Re: [spring] FW: New Version Notification for draft-bonica-spring-srv6-plus-05.txt

Hi Joel,

On Thu, 29 Aug 2019 at 11:50, Joel M. Halpern <jmh@joelhalpern.com> wrote:
>
> Mark, I had missed the earlier email suggesting that the SIDs could be
> address specific rather than just node specific.  That is an interesting
> idea.  At first glance, it appears to work, and warrants further thought.
>

I like the idea of having one-size-fits-most or one-size-fits-all
parameters or rather constants if possible, as it means one less
decision, and one less decision that could be wrong and then costly to
fix.

With per-address SID space, you could then use aggregate prefixes to
give a range of addresses and their SIDs some sort of significance
that may be operationally or business useful.

For example, I think ULAs should be used for the outer SR packet
addressing to help mitigate SR traffic leaking or its effects, and
since you can generate multiple of your own unique ULA /48s, you could
do something like have a SR ULA /48 per country, region etc., or
perhaps a ULA /48 per SR service type or type group.

> As far as I know, routers tend not to use SLAAC for interface address
> generation, and tend not to be worried about the privacy properties of
> their interface addresses, so at least for most use cases I am having
> trouble following your last paragraph.
>

They might not be using the SLAAC "protocol" i.e. RA PIOs, however
they are supposed to be using the SLAAC method to generate their
Link-Local addresses.

RFC 4862, "IPv6 Stateless Address Autoconfiguration":

"The autoconfiguration process specified in this document applies only
   to hosts and not routers.  Since host autoconfiguration uses
   information advertised by routers, routers will need to be configured
   by some other means.  However, it is expected that routers will
   generate link-local addresses using the mechanism described in this
   document.  In addition, routers are expected to successfully pass the
   Duplicate Address Detection procedure described in this document on
   all addresses prior to assigning them to an interface."

RFC 7217 naturally applies to routers too due to their use of SLAAC
above, including their link-local addresses. The specific idea was to
be able to couple a router's interface addresses to something else
independent of interface MAC address, such as module slot, so that
swapping a router interface module didn't cause the IPv6 interface
addresses to change.

Of course you can avoid that problem by configuring static IPv6
addresses on router interfaces, although it's work a computer could do
instead, and I wonder how often people have typed in fe80::1 when they
really meant to type in fe80::2? DAD would catch it, however it's
better to avoid a problem.

I'm pretty sure globally unique Link-Local IIDs weren't a goal of RFC
7217, however I think they're useful because within your network they
can be come a network wide IPv6 interface identifier independent of
GUA/ULA addresses.

Their local network uniqueness also means they could be put in a local
instance of authoritative reverse DNS for fe80::/10 e.g. PTR
<intfname>.<routername>. That could be useful during troubleshooting
e.g. have an end-user read out their default gateway's interface
address name rather than fe80::<blah>. (fe80::1 is good for end-users
to read or type, but tells you nothing link or router specific. )

Regards,
Mark.

> Thank you,
> Joel
>
> On 8/28/2019 7:39 PM, Mark Smith wrote:
> > Hi Ron,
> >
> > In an email a while back I think you mentioned that the SID space is
> > unique in the context of an address, where as this draft is saying
> > that SIDs have node-local significance, which I think means the same
> > single SID space across all the addresses of the node.
> >
> > The reason I'm wondering is that if the SID space is per-address, then
> > I'd think it could be possible to have a single 16 bit SID space,
> > rather than two sizes and needing an operator to make a choice (with
> > the risk of making an incorrect choice, and the consequences of having
> > to migrate a network from one size to another).
> >
> > If 16 bits is enough for TCP/UDP etc. ports in most cases then I'd
> > guess it would probably be enough for SIDs. Of course, as with running
> > out of TCP/UDP port numbers, an operator could give a node or
> > interface another IPv6 address to create another 16 bit SID space if
> > necessary.
> >
> >
> > I also remember from that email you mentioning the idea of unique
> > link-local addresses. If IPv6 implementations follow RFC 8064,
> > "Recommendation on Stable IPv6 Interface Identifiers", which
> > recommends RFC 7217, "A Method for Generating Semantically Opaque
> > Interface Identifiers with IPv6 Stateless Address Autoconfiguration
> > (SLAAC)", then nodes' link-local addresses (specifically the IID part)
> > should not only be network wide unique, but also globally unique.
> >
> > Regards,
> > Mark.
> >
> > On Thu, 29 Aug 2019 at 01:38, Ron Bonica
> > <rbonica=40juniper.net@dmarc.ietf.org> wrote:
> >>
> >> FYI
> >>
> >>
> >> Juniper Public
> >>
> >> -----Original Message-----
> >> From: internet-drafts@ietf.org <internet-drafts@ietf.org>
> >> Sent: Wednesday, August 28, 2019 11:31 AM
> >> To: Ron Bonica <rbonica@juniper.net>; Shraddha Hegde <shraddha@juniper.net>; Andrew Alston <Andrew.Alston@liquidtelecom.com>; Gang Chen <phdgang@gmail.com>; Joel Halpern <joel.halpern@ericsson.com>; Andrew Alston <andrew.alston@liquidtelecom.com>; Daniam Henriques <daniam.henriques@liquidtelecom.com>; Jen Linkova <furry@google.com>; Yuji Kamite <y.kamite@ntt.com>
> >> Subject: New Version Notification for draft-bonica-spring-srv6-plus-05.txt
> >>
> >>
> >> A new version of I-D, draft-bonica-spring-srv6-plus-05.txt
> >> has been successfully submitted by Ron Bonica and posted to the IETF repository.
> >>
> >> Name:           draft-bonica-spring-srv6-plus
> >> Revision:       05
> >> Title:          IPv6 Support for Segment Routing: SRv6+
> >> Document date:  2019-08-28
> >> Group:          Individual Submission
> >> Pages:          23
> >>
> >>
> >> Abstract:
> >>     This document describes SRv6+. SRv6+ is a Segment Routing (SR)
> >>     solution that leverages IPv6.  It supports a wide variety of use-
> >>     cases while remaining in strict compliance with IPv6 specifications.
> >>     SRv6+ is optimized for ASIC-based forwarding devices that operate at
> >>     high data rates.
> >>
> >>
> >>
> >>
> >> Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org.
> >>
> >> The IETF Secretariat
> >> --------------------------------------------------------------------
> >> IETF IPv6 working group mailing list
> >> ipv6@ietf.org
> >> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> >> --------------------------------------------------------------------
> >
> > --------------------------------------------------------------------
> > IETF IPv6 working group mailing list
> > ipv6@ietf.org
> > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> > --------------------------------------------------------------------
> >