Subject: Comments on < draft-filsfils-spring-net-pgm-extension-srv6-usid-00>

From: Bob Hinden <[email-masked]>
Date: Tue, 16 Jul 2019 23:00:23 -0400

Hi,

I was looking at < draft-filsfils-spring-net-pgm-extension-srv6-usid-00> and have a few comments.  I am copying the 6MAN list because of its use of IPv6 addresses.

The draft says:

   uSID block: A block of uSID's

      It can be any IPv6 prefix allocated to the provider (e.g. /40 or
      /48), or it can be any block generally available for private use.
      An SR domain may have multiple uSID blocks.

      In this document we leverage FC00::/8 block reserved for private
      use as ULA space (RFC4193).  Throughout this document we use
      FC00::/16 as the illustrated uSID block.  ULA space allows for up
      to 256 uSID blocks in FC00::/8.

The first sentence in the first paragraph is fine, as it is proposing using prefixes assigned to the provider.   The rest is not fine.

ULA space as defined in RFC4193 is not for use like this.   RFC4193 specifies:

   The Local IPv6 addresses are created using a pseudo-randomly
   allocated global ID.  They have the following format:

      | 7 bits |1|  40 bits   |  16 bits  |          64 bits           |
      +--------+-+------------+-----------+----------------------------+
      | Prefix |L| Global ID  | Subnet ID |        Interface ID        |
      +--------+-+------------+-----------+----------------------------+

It is inappropriate to use the a large portion of ULA space (aka FC00::/16) in the manner proposed by this draft.   A better alternative for a provider using SRH is to generate an /48 ULA prefix as defined in RFC4193 and use it for this purpose.  What is proposed in this document will break ULAs for everyone else.

This draft (nor any future drafts in Spring) should not be redefining the IPv6 address space.   It is also very excessive to use this much address space to identify segments in a SRH network.   How many segments are needed to be identified?  Surely not 2^^112.

Regards,
Bob

---

From: Robert Raszuk <[email-masked]>
Date: Wed, 17 Jul 2019 08:42:10 +0200

HI Bob,

The way I read this document is that FC00::/8 is just an example. If IETF
decided to allocate a new prefix I think no one will object that.

> How many segments are needed to be identified?  Surely not 2^^112.

The crux of the proposal is in embedding multiple microSIDs in the *single*
IPv6 address. So if we consume say 16 bits for prefix we are left with 112
bits for SIDs.

Say SID would be of 16 bits so we can at most in dst address of single
encapsulated packet impose 7 SIDs. Not sure where you 2 to the power of 112
comes from - there is no "SID stacking" here any more :).

Cheers,
R.

On Wed, Jul 17, 2019 at 5:01 AM Bob Hinden <[email-masked]> wrote:

> Hi,
>
> I was looking at < draft-filsfils-spring-net-pgm-extension-srv6-usid-00>
> and have a few comments.  I am copying the 6MAN list because of its use of
> IPv6 addresses.
>
> The draft says:
>
> The first sentence in the first paragraph is fine, as it is proposing
> using prefixes assigned to the provider.   The rest is not fine.
>
> It is inappropriate to use the a large portion of ULA space (aka
> FC00::/16) in the manner proposed by this draft.   A better alternative for
> a provider using SRH is to generate an /48 ULA prefix as defined in RFC4193
> and use it for this purpose.  What is proposed in this document will break
> ULAs for everyone else.
>
> This draft (nor any future drafts in Spring) should not be redefining the
> IPv6 address space.   It is also very excessive to use this much address
> space to identify segments in a SRH network.   How many segments are needed
> to be identified?  Surely not 2^^112.
>
> Regards,
> Bob
>
>
>
>
>
> _______________________________________________
> spring mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/spring
>

---

From: "Pablo Camarillo (pcamaril)" <[email-masked]>
Date: Wed, 17 Jul 2019 08:49:36 +0000

Hi Bob,

Let's indeed simplify the discussion and use a prefix assigned to the provider.
We will submit a rev1 accordingly on Monday.

Thanks,
Pablo

-----Original Message-----
From: spring <[email-masked]> on behalf of Bob Hinden <[email-masked]>
Date: Wednesday, 17 July 2019 at 05:01
To: SPRING WG <[email-masked]>
Cc: IPv6 List <[email-masked]>, Bob Hinden <[email-masked]>
Subject: [spring] Comments on < draft-filsfils-spring-net-pgm-extension-srv6-usid-00>

    The first sentence in the first paragraph is fine, as it is proposing using prefixes assigned to the provider.

---

From: Bob Hinden <[email-masked]>
Date: Wed, 17 Jul 2019 08:27:09 -0400

Robert,

> On Jul 17, 2019, at 2:42 AM, Robert Raszuk <[email-masked]> wrote:
> 
> HI Bob,
> 
> The way I read this document is that FC00::/8 is just an example. If IETF decided to allocate a new prefix I think no one will object that.

I don’t think IETF specs should cite examples that are not consistent with other standards, in this case RFC4193.   But it’s more than a suggestion, it says:

      In this document we leverage FC00::/8 block reserved for private
      use as ULA space (RFC4193)

> The crux of the proposal is in embedding multiple microSIDs in the *single* IPv6 address. So if we consume say 16 bits for prefix we are left with 112 bits for SIDs.
> 
> Say SID would be of 16 bits so we can at most in dst address of single encapsulated packet impose 7 SIDs. Not sure where you 2 to the power of 112 comes from - there is no "SID stacking" here any more :).

I got 2^^112 by the spec was proposing a /16 prefix, that leaves 112 bits for addresses in that prefix.   Hence 2^^112.

I wouldn’t consider these to be an IPv6 address.   RFC4291 says:

   Except for the knowledge of the subnet boundary discussed in the
   previous paragraphs, nodes should not make any assumptions about the
   structure of an IPv6 address.

This appears to go well beyond that.

Bob

---

From: Bob Hinden <[email-masked]>
Date: Wed, 17 Jul 2019 08:27:52 -0400

Pablo,

> On Jul 17, 2019, at 4:49 AM, Pablo Camarillo (pcamaril) <[email-masked]> wrote:
> 
> Hi Bob,
> 

I think that would be better.

Thanks,
Bob