• Those who avoid strictly-routed segments
• Those who rely heavily on strictly-routed segments
Those who avoid strictly-routed segments rarely generate SID Lists that contain
more than 8 entries. So, they are generally OK with 32-bit encoding. This is
because with 32-bit encoding, the total SR overhead is exactly 80 bytes (i.e.,
40 bytes for the IPv6 header and 40 bytes for the CRH).
By contrast, those who rely on strictly-routed segments regularly generate SID
Lists that contain more than 8 entries. So, they are generally required 16-bit
encoding.
IMHO, the operator understands its needs better than we do. We should support
both. Let the operator decide at run time.
Ron
From: Mark Smith <[email protected]>
Sent: Wednesday, July 3, 2019 9:08 PM
To: Tom Herbert <[email protected]>
Cc: Ron Bonica <[email protected]>; SPRING WG <[email protected]>;
6man WG <[email protected]>
Subject: Re: Comments on draft-bonica-spring-srv6-plus
On Thu., 4 Jul. 2019, 06:06 Tom Herbert, <[email protected]> wrote:
On Wed, Jul 3, 2019 at 12:44 PM Ron Bonica <[email protected]> wrote:
Hi Tom,
Thanks for the review.
On Friday, I will update draft-bonica-6man-comp-rtg-hdr. It will contain a
section on mutability. It will say:
- the Segments Left field is mutable
- every other field in the CRH is immutable
I will also update draft-bonica-6man-vpn-dest-opt and
draft-bonica-6man-seg-end-opt. Both of those request an IANA option type with
the CHG bit equal to 0. So they are both immutable.
SID encoding isn't entirely opportunistic. Since the last IETF, we realized
that it would be burdensome for every vendor to support all three SID lengths.
So, we said that implementations MUST support 32-bit encoding and MAY support
16 bit encoding. (We dropped 8-bit encoding entirely).
This sounds dicey from an interoperability and flexibility point of
view. Supposed I've deployed a network where everyone is using 16 bits
SIDs. But, then for some reason I need to switch vendors for a small
part of the network and their implementation doesn't support 16 bits.
Do I need to up the MSV and make all SIDs to be 32 bits just on the
off chance that one of the new nodes might be in some SID list?
A side effect of this decision is that a node should only send CRH's with
16-bit encoding every other node in the domain supports 16-bit encoding.. So,
network operators will need to configure the SID length on each node, with the
default being 32.
Well, in light the above problem, I have to wonder if it's better to
only support 32 bits. The leap from 128 bits to 32 bits is much more
consequential than going from 32 to 16 bits. Other than that, it
simplifies the protocol, reduces support and test matrix, ensures
interoperability, etc.
One single size is much better.
I think most people will pick the larger size, regardless of their functional
SID space need, to avoid the possibility of getting it wrong and then having to
do a lot of after hours and possibly service impacting work in the future to
expand from the smaller to larger size.
Implementations would also be simpler, so less opportunities for implementation
bugs.
It also means no possibility of configuration errors because the size is a
constant rather than a settable parameter.
A lot of the principles in RFC 5505 - "Principles of Internet Host
Configuration" - seem to me to be equally applicable to network interior protocols.
For example, I think the whole of "2.1. Minimize Configuration" fully applies
here.
Regards,
Mark.
Tom
Ron
Juniper Business Use Only
-----Original Message-----
From: Tom Herbert <[email protected]>
Sent: Wednesday, July 3, 2019 2:48 PM
To: Ron Bonica <[email protected]>
Cc: SPRING WG <[email protected]>; 6man WG <[email protected]>
Subject: Comments on draft-bonica-spring-srv6-plus
Hi Ron,
Thanks for the draft.
I think the name SRV6+ might be a little misleading in that it could
be misinterpreted as SRV6+ being a superset of SRV6. Specifically,
SRV6+ doesn't allow 128 bit SIDs which seems inherent in SRV6 and so
the primary function (and implementation) of SRV6 isn't compatible. It doesn't
seem like it would be that much effort to allow a 128 bit SID size to be
compatible.
I don't understand the rationale for needing a MSV to be explictly configured
throughout the domain. Couldn't the appropriate SID size be chosen by the
sender at run time. For instance, if all the SIDs in a list are less than
65,536 then 16 bit SIDs can be used, else 32 bit SIDs are used (I assume 16 and
32 bit SIDs are in same number space).
Since CRH has the bits stating the SID length there is no ambiguity at the
receiver. SID compression is opportunistic and it's always good practice to
avoid situations that require wide scale renumbering.
Please add a section on mutability requirements of protocol fields so that
there is no ambiguity.
Tom
--------------------------------------------------------------------
IETF IPv6 working group mailing list
[email protected]
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------
Juniper Business Use Only
--------------------------------------------------------------------
IETF IPv6 working group mailing list
[email protected]
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------
