Subject: Re: [spring] draft-filsfils-spring-net-pgm-extension-srv6-usid-01

From: "Pablo Camarillo (pcamaril)" <[email-masked]>
Date: Tue, 10 Sep 2019 14:11:31 +0000

Ron,

SRv6 is based on IPv6 longest prefix match forwarding. You can shoot yourself in the foot by adding bad routes.

Cheers,
Pablo.

From: spring <[email-masked]> on behalf of Ron Bonica <rbonica=[email-masked]>
Date: Tuesday, 6 August 2019 at 22:46
To: SPRING WG <[email-masked]>
Subject: [spring] draft-filsfils-spring-net-pgm-extension-srv6-usid-01

Authors,

Referring to the example in Section 5.2 of draft-filsfils-spring-net-pgm-extension-srv6-usid-01, what would happen if Node 7 instantiated the following:

-          A uSID  identified by 2001:db8:0700/48

-          A more specific route (e.g., 2001:db8:0700::/49)

Would the more specific route be ignored by the longest path lookup on Node 7? If not, would the more specific route cause all SR Paths whose penultimate segment is 2001:db8:0700/48 to black hole?

                                                                                                               Ron

Juniper Business Use Only

---

From: Ron Bonica <[email-masked]>
Date: Wed, 11 Sep 2019 14:56:17 +0000

Pablo,

So, to make uSID work:

  *   You have to get a large block (e.g., /32) from your RIR
  *   You have to allocate a smaller block (e.g., /48)  to each router for uSIDs
  *   You can't use more specifics from that block for anything else (e.g., numbering interfaces)
  *   If you do, you may cause multiple SR paths to black hole

Do I have this right?

                                       Ron

Juniper Business Use Only
From: Pablo Camarillo (pcamaril) <[email-masked]>
Sent: Tuesday, September 10, 2019 10:12 AM
To: Ron Bonica <[email-masked]>; SPRING WG <[email-masked]>
Subject: Re: [spring] draft-filsfils-spring-net-pgm-extension-srv6-usid-01

Ron,

Cheers,
Pablo.

From: spring <[email-masked]<mailto:[email-masked]>> on behalf of Ron Bonica <rbonica=[email-masked]<mailto:rbonica=[email-masked]>>
Date: Tuesday, 6 August 2019 at 22:46
To: SPRING WG <[email-masked]<mailto:[email-masked]>>
Subject: [spring] draft-filsfils-spring-net-pgm-extension-srv6-usid-01

Authors,

                                                                                                               Ron

---

From: Mark Smith <[email-masked]>
Date: Thu, 12 Sep 2019 09:03:44 +1000

On Thu, 12 Sep 2019, 00:56 Ron Bonica, <rbonica=[email-masked]>
wrote:

> Pablo,
>
>
>
> So, to make uSID work:
>
>
>
>    - You have to get a large block (e.g., /32) from your RIR
>    - You have to allocate a smaller block (e.g., /48)  to each router for
>    uSIDs
>    - You can’t use more specifics from that block for anything else
>    (e.g., numbering interfaces)
>    - If you do, you may cause multiple SR paths to black hole
>
>
+ Ignore the subnet ID field definition - RFC 3587.

+ Ignore the IID field definition - RFC 4291.

+ Ensure your combined set of uSID values in the IID field don't end up
being any of the reserved IID values - RFC 5453.

I realised quite a while ago to overcome some early Ethernet MTU issues
with MPLS, by, on a point to point Ethernet link, switching each end into
promiscuous mode and then putting MPLS labels in the 12 octets of the now
unused address fields. It should work although it is being non-obvious, and
may cause unexpected problems. For example, switching on the "multicast
bit" in the source address field actually says there is a Token Ring Route
Information Field after the Ethernet header.

Possibly useful hack, but not something I'd do by choice. Encoding uSIDs in
IPv6 addresses is similar and could possibly cause more problems, because
the domain or scope of transmission is much greater than a single
point-to-point link.

Regards,
Mark.

>    -
> *From:* Pablo Camarillo (pcamaril) <[email-masked]>
> *Sent:* Tuesday, September 10, 2019 10:12 AM
> *To:* Ron Bonica <[email-masked]>; SPRING WG <[email-masked]>
> *Subject:* Re: [spring]
> draft-filsfils-spring-net-pgm-extension-srv6-usid-01
>
>
>
> Ron,
>
>
>
> SRv6 is based on IPv6 longest prefix match forwarding. You can shoot
> yourself in the foot by adding bad routes.
>
>
>
> Cheers,
>
> Pablo.
>
>
>
> *From: *spring <[email-masked]> on behalf of Ron Bonica <
> rbonica=[email-masked]>
> *Date: *Tuesday, 6 August 2019 at 22:46
> *To: *SPRING WG <[email-masked]>
> *Subject: *[spring] draft-filsfils-spring-net-pgm-extension-srv6-usid-01
>
>
>
> Authors,
>
>
>
> Referring to the example in Section 5.2 of
> draft-filsfils-spring-net-pgm-extension-srv6-usid-01, what would happen if
> Node 7 instantiated the following:
>
>
>
> -          A more specific route (e.g.., 2001:db8:0700::/49)
>
>
>
> Would the more specific route be ignored by the longest path lookup on
> Node 7? If not, would the more specific route cause all SR Paths whose
> penultimate segment is 2001:db8:0700/48 to black hole?
>
>
>
>
> Ron
>
>
>
>
>
>
>
>
>
> _______________________________________________
> spring mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/spring
>