Subject: Objection to wg adoption call for draft-filsfilscheng-spring-srv6-srh-compression (was: Re: Question from SPRING regarding draft-filsfilscheng-spring-srv6-srh-compression)

From: Nick Hilliard <[email-masked]>
Date: Sat, 23 Oct 2021 10:50:56 +0100

Hi Stefano,

Stefano Salsano wrote on 23/10/2021 01:29:
> if an operator wants to combine CSIDs of different length, building the 
> debug tools becomes more complex, but this actually depends on the 
> specific choices and configurations

Exactly. For example, problems will occur when the operator changes SID 
length inside their domain, or attempts to interoperate with other SRH 
domains (either within the same or with different administrative 
domains), or merges with another network which uses with a different SID 
length.

 From the point of view of operations and management of production 
networks, if a protocol allows for a variable length parameter, but 
doesn't explicitly encode the length of the parameter, then this 
introduces protocol ambiguity.  Protocol ambiguity is toxic on 
production networks because it causes breakage which is difficult to 
diagnose and may be impossible to fix.

If the SRH compression draft proposed to encode the compressed SID 
length for each instance of a C-SID in the header, then this problem 
goes away.

On this basis, I'm objecting to the adoption of 
draft-filsfilscheng-spring-srv6-srh-compression as a WG draft, and 
respectfully suggest that the spring wg does not adopt any draft in 
future which allows for different C-SID lengths but doesn't encode 
C-SIDs as {length,value} tuples.

Nick

---

From: Sander Steffann <[email-masked]>
Date: Sun, 24 Oct 2021 08:31:13 +0200

Hi,

> On this basis, I'm objecting to the adoption of draft-filsfilscheng-spring-srv6-srh-compression as a WG draft, and respectfully suggest that the spring wg does not adopt any draft in future which allows for different C-SID lengths but doesn't encode C-SIDs as {length,value} tuples.

I support this argument, so +1 to the objection.

Cheers,
Sander

---

From: Robert Raszuk <[email-masked]>
Date: Sun, 24 Oct 2021 13:58:05 +0200

Nick & Sander,

Just for my own understanding here.

A)  Are you asking to add new TLV to IPv6 SRH say called "C-SID Length"
(and make SRH mandatory if used with C-SIDs) which would define the C-SID
length ?

or

B) Are you asking to define a completely new data plane for IP networks ?
By new data plane I mean either the format of IP header in the packets.

or

C) What else are you suggesting ?

- -

If this is (A)  I think it could be considered. SRH already supports TLVs.
That way even wireshark could read and parse C-SIDs correctly (if this is
of any value when detached from rest of control plane).

Thx,
Robert.

On Sun, Oct 24, 2021 at 8:33 AM Sander Steffann <[email-masked]> wrote:

> respectfully suggest that the spring wg does not adopt any draft in future
> which allows for different C-SID lengths but doesn't encode C-SIDs as
> {length,value} tuples.
>
> _______________________________________________
> spring mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/spring
>

---

From: Sander Steffann <[email-masked]>
Date: Sun, 24 Oct 2021 17:15:00 +0200

Hi,

> A)  Are you asking to add new TLV to IPv6 SRH say called "C-SID Length" (and make SRH mandatory if used with C-SIDs) which would define the C-SID length ? 

Yes, that would be a step in the right direction. 

> B) Are you asking to define a completely new data plane for IP networks ? By new data plane I mean either the format of IP header in the packets.

With the stuff being stacked on top of the basic SRv6 spec it’s definitely starting to look like one :)

But I also see the benefit of using the existing IPv6 data plane when doing SR between administrative domains. That does require better interop facilities than the current drafts provide though.

> If this is (A)  I think it could be considered. SRH already supports TLVs. That way even wireshark could read and parse C-SIDs correctly (if this is of any value when detached from rest of control plane). 

The tool used doesn’t matter. What matters that an engineer can understand and decode what’s going on on the wire when stuff breaks. And that the headers contain enough information to use for interop between multiple admin domains for example. 

Cheers,
Sander

---

From: Nick Hilliard <[email-masked]>
Date: Sun, 24 Oct 2021 16:36:02 +0100

Sander Steffann wrote on 24/10/2021 16:15:
> The tool used doesn’t matter. What matters that an engineer can
> understand and decode what’s going on on the wire when stuff breaks.
> And that the headers contain enough information to use for interop
> between multiple admin domains for example.
The issue is a good deal deeper than just debugging.  As long as there's 
an option to specify a variable length parameter without being able to 
specify the length in the protocol, then the protocol is fundamentally 
ambiguous and its interpretation is entirely context dependent.  I.e. 
one router might interpret a c-sid sequence completely differently to 
another.

The fact that debugging becomes arbitrary and dependent on context is a 
second order issue.

It doesn't matter how the length is specified: it could be a tuple; it 
could be a set of codepoints.  What's important is that it's specified 
unambiguously in the protocol structure on a per-SID basis.

Nick

---

From: Eliot Lear <[email-masked]>
Date: Sun, 24 Oct 2021 19:17:26 +0200

On 24.10.21 17:36, Nick Hilliard wrote:
> The issue is a good deal deeper than just debugging.  As long as 
> there's an option to specify a variable length parameter without being 
> able to specify the length in the protocol, then the protocol is 
> fundamentally ambiguous and its interpretation is entirely context 
> dependent.

You mean, like a subnet mask?

---

From: Sander Steffann <[email-masked]>
Date: Sun, 24 Oct 2021 20:01:46 +0200

>> The issue is a good deal deeper than just debugging.  As long as there's an option to specify a variable length parameter without being able to specify the length in the protocol, then the protocol is fundamentally ambiguous and its interpretation is entirely context dependent.
> 

No, you can parse the addresses in a packet perfectly without knowing the subnet mask. More like variable length addresses without encoding what the length actually is…

Cheers,
Sander

---

From: Nick Hilliard <[email-masked]>
Date: Sun, 24 Oct 2021 20:59:52 +0100

> You mean, like a subnet mask?

There's no direct analog here.  Subnet masks have both local and global 
significance, which is why we use a combination of EGPs and IGPs.  The 
critical thing is that all these routing protocols encode subnet masks 
and the protocol signaling ensures that there's no ambiguity.  This 
doesn't appear to be the case in the SRH compression draft.

As you mention it, I'd love to see the head-scratching that would ensue 
if someone proposed a new routing protocol which didn't encode the 
subnet mask :-)

Nick

---

From: Eliot Lear <[email-masked]>
Date: Sun, 24 Oct 2021 22:23:19 +0200

On 24.10.21 21:59, Nick Hilliard wrote:
>>> there's an option to specify a variable length parameter without 
>>> being able to specify the length in the protocol, then the protocol 
>>> is fundamentally ambiguous and its interpretation is entirely 
>>> context dependent.
>>
> There's no direct analog here.

Of course there is.  You cannot distinguish routing from host without 
looking at external control channels, such as a routing or configuration 
protocol; and you certainly cannot determine the subnet mask of a 
network without that external information, since it's not in the 
packet.  And it's not even in the control plane if the route has been 
aggregated.  Does that make the information "ambiguous"?  The point is 
that the subnet mask of a network is part of a context that you 
discussed, and you might not have it.

Note- I am not taking a position about CSIDs, but I think this line of 
argument is on the wrong track.

Eliot

---

From: Brian E Carpenter <[email-masked]>
Date: Mon, 25 Oct 2021 10:20:17 +1300

> argument is on the wrong track.

My assumption has been that within the SRv6 domain, some routing protocol
will be in use (e.g. OSPF) and that (by some magic that I don't understand)
it will be announcing the subnets currently in use, so that bog-standard
routing will occur, including the final hop, because "hosts" supporting
SRv6 will have to function as routers for the final hop. After all, SRv6
is an overlay, a form of VRF.

Quite what the magic is that configures OSPF accordingly, I do not know.

Regards
    Brian
    Thinking of the IETF standards process: https://xkcd.com/2530/

---

From: Mark Smith <[email-masked]>
Date: Mon, 25 Oct 2021 08:48:13 +1100

> You mean, like a subnet mask?

Subnet masks weren't a good idea either. They, like classes and CIDR, are
hacks to squeeze more addresses out of the 32 bit IPv4 address space.

Have a look at the IPv4 address structure in RFC760. Couldn't be simpler.

---

From: Robert Raszuk <[email-masked]>
Date: Mon, 25 Oct 2021 00:18:03 +0200

> Have a look at the IPv4 address structure in RFC760. Couldn't be simpler.

Simplicity often goes against scalability.

I am afraid CIDR and VLSM is not about squeezing anything. Thay are all
about improving scaling of both data plane and control plane in IP routing
architecture.

But if you claim that subnet masks were not a "good idea either" then are
you suggesting we should propagate reachability globally using host routes
and exact match at each transit hop ?

Thx,
R.

---

From: Greg Mirsky <[email-masked]>
Date: Sun, 24 Oct 2021 15:25:04 -0700

Hi Brian,
so far I haven't noticed a proposal to support C-SID in IGP. I think that
it brings up a legitimate question: How is it going to work? Would it C-SID
be used in combination with dynamic routing protocols or only from a
centralized controller?

Regards,
Greg

On Sun, Oct 24, 2021 at 2:20 PM Brian E Carpenter <
[email-masked]> wrote:

> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> [email-masked]
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------
>

---

From: Andrew Alston <[email-masked]>
Date: Mon, 25 Oct 2021 08:46:29 +0000

> Of course there is.  You cannot distinguish routing from host without looking at external control channels, such as a routing or configuration protocol; and you certainly cannot determine the subnet mask of a network without that external information, since it's not in the ?> packet.  And it's not even in the control plane if the route has been aggregated.  Does that make the information "ambiguous"?  The point is that the subnet mask of a network is part of a context that you discussed, and you might not have it.

This analogy doesn't really work for me.  In the case of an SRH - the router acts on the packet based on local configuration - how it gets that config doesn't really matter.  The SID size in use by each router may or may not be exposed by an IGP for reading - and could differ at each node.  In the case of standard forwarding you have a FIB entry - inserted from the RIB - that goes a certain place.  In the case of this - a router could be using either 16bit SID or 32bit SID - entirely configured locally - and dependent on the configuration - will determine if the node in question shifts the information by 16 or 32 bits - before the FIB lookup.  

Therefore - in a standard scenario - you know that packet X is going to be forwarded using a FIB entry lookup of Y - in the case of this - you have no idea what the router is actually going to be looking up - because you don't know if its going to be doing a 16 or 32 bit sid without knowing the specific local configuration on the router.  That’s a very different level of complexity in terms of operations and debugging on a large network

Andrew

---

From: Ted Hardie <[email-masked]>
Date: Mon, 25 Oct 2021 11:37:21 +0100

On Mon, Oct 25, 2021 at 9:47 AM Andrew Alston <Andrew.Alston=
[email-masked]> wrote:

> protocol; and you certainly cannot determine the subnet mask of a network
> without that external information, since it's not in the ?> packet.  And
> it's not even in the control plane if the route has been aggregated.  Does
> that make the information "ambiguous"?  The point is that the subnet mask
> of a network is part of a context that you discussed, and you might not
> have it.
>
> This analogy doesn't really work for me.  In the case of an SRH - the
> router acts on the packet based on local configuration - how it gets that
> config doesn't really matter.  The SID size in use by each router may or
> may not be exposed by an IGP for reading - and could differ at each node.

I think Eliot's main point is that there are aspects of a flow's routing
through a network which are observable in a packet and there are aspects
which are not.  Think about a network which implements a flow-based
equal-cost multipath; the determination of which flows take which path uses
information in the packet but the algorithm that hashes it together and
chooses a next hop is not.  The practices about what to choose can vary
significantly and to debug (or plan), you have to know a lot more about the
network than what's in the packet itself.

regards,

Ted Hardie

> In the case of standard forwarding you have a FIB entry - inserted from
> the RIB - that goes a certain place.  In the case of this - a router could
> be using either 16bit SID or 32bit SID - entirely configured locally - and
> dependent on the configuration - will determine if the node in question
> shifts the information by 16 or 32 bits - before the FIB lookup.
>
> Therefore - in a standard scenario - you know that packet X is going to be
> forwarded using a FIB entry lookup of Y - in the case of this - you have no
> idea what the router is actually going to be looking up - because you don't
> know if its going to be doing a 16 or 32 bit sid without knowing the
> specific local configuration on the router.  That’s a very different level
> of complexity in terms of operations and debugging on a large network
>
> Andrew
>
>

---

From: Andrew Alston <[email-masked]>
Date: Mon, 25 Oct 2021 12:14:14 +0000

Ted,

I don’t think anyone would dispute that supplementary information is necessary for various purposes.  The question becomes – how much supplementary information – where that supplementary information is coming from – and how much correlation you need to do to get to meaningful information.

Each time you add a step in this process and force an additional piece of information into the chain to make something more useful, you increase complexity and you create a situation where debugging and tracing and other such things become more and more reliant on external software and routines.  This in turn increases cost and decreases the ability of operators to handle this in the absence of complex tools.  So sure, for the vendors, it may be in their advantage to introduce more and more complexity to force more and more software, but this is very much not in the interests of the operators.

It's here where I think we often end up in a divergence between practical operation and fancy ideas – and between vendors and operators.  From the operator perspective, that which is simpler and makes it easier to have their own engineers operate it, debug it and run it, without spending millions on tools, makes a lot of sense.  The reverse in true in the vendor world – where complexity serves to increase revenues (though often ends up in operators having to choose between investment in network hardware vs investment in vendor tools to run said network)

Now, is this an argument that is “technically relevant” in terms of an IETF standard – many would argue no – but there are very practical considerations here when considering how a standard will be used and deployed.  The level of complexity and lack of debuggability and the obfuscation that I see in all of this, is the same concern that I am seeing echoed in every NOG meeting I am in – and while it may not be directly relevant to the text in a document, it does carry relevance to the end users of the protocol – the operators.

There is in essence – a commercial conflict between these two things – which is outside of the realm of the IETF – but – unless we can find harmonization between the operators and the vendors on such things, we will end up in deeper and deeper stalemates that are not in anyones interests.  Therefore, reducing the complexity involved in debugging and operating something, will decrease resistance during the standardization process.  Furthermore, the more obfuscated things get, and the deeper the complexity, the more chance of pitfalls that are not seen until it is to late – and the growing risk of security problems that could not be foreseen until we have pushed something widely into the field.

Andrew

From: Ted Hardie <[email-masked]>
Sent: Monday, October 25, 2021 1:37 PM
To: Andrew Alston <[email-masked]>
Cc: Eliot Lear <[email-masked]>; Nick Hilliard <[email-masked]>; SPRING WG List <[email-masked]>; 6man WG <[email-masked]>
Subject: Re: [spring] Objection to wg adoption call for draft-filsfilscheng-spring-srv6-srh-compression (was: Re: Question from SPRING regarding draft-filsfilscheng-spring-srv6-srh-compression)

> Of course there is.  You cannot distinguish routing from host without looking at external control channels, such as a routing or configuration protocol; and you certainly cannot determine the subne…

This analogy doesn't really work for me.  In the case of an SRH - the router acts on the packet based on local configuration - how it gets that config doesn't really matter.  The SID size in use by each router may or may not be exposed by an IGP for reading - and could differ at each node.

I think Eliot's main point is that there are aspects of a flow's routing through a network which are observable in a packet and there are aspects which are not.  Think about a network which implements a flow-based equal-cost multipath; the determination of which flows take which path uses information in the packet but the algorithm that hashes it together and chooses a next hop is not.  The practices about what to choose can vary significantly and to debug (or plan), you have to know a lot more about the network than what's in the packet itself.

regards,

Ted Hardie

In the case of standard forwarding you have a FIB entry - inserted from the RIB - that goes a certain place.  In the case of this - a router could be using either 16bit SID or 32bit SID - entirely configured locally - and dependent on the configuration - will determine if the node in question shifts the information by 16 or 32 bits - before the FIB lookup.

Andrew

--------------------------------------------------------------------
IETF IPv6 working group mailing list
[email-masked]<mailto:[email-masked]>
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6<https://www.ietf.org/mailman/listinfo/ipv6>
--------------------------------------------------------------------

---

From: Eliot Lear <[email-masked]>
Date: Mon, 25 Oct 2021 14:35:23 +0200

Hi Andrew,

I don't disagree with your point that operational complexity hinders 
adoption.  However...

On 25.10.21 14:14, Andrew Alston wrote:
>
> It's here where I think we often end up in a divergence between 
> practical operation and fancy ideas
>
The problem is that one often can't tell the difference between the two 
without the benefit of hindsight, and perhaps several revs of the spec.  
IPv6 itself is a perfect example of that truth (cf, MIPv6, site-local, 
IPsec requirements, and geographic routing). But I write that with the 
benefit of hindsight in which we did find use for other v6 features, 
like flow labels.

Right now we have a lot of speculation about how tools won't evolve to 
assist operators, and I'm sympathetic to that to a point: tools develop 
best out of operational experience.

Eliot

---

From: Andrew Alston <[email-masked]>
Date: Mon, 25 Oct 2021 12:44:32 +0000

See, I disagree with this Elliot,

What you have is several operators who are clearly stating – there are issues with this.  And tool evolution is exactly what I am referring to – the tools may exist – but what will they cost? For myself, I’m in the lucky position that I have a team that can go out and write tooling if we need it – that will scrape configs for SID lists – that will integrate with our IGP – will take feeds from BMP – whatever – we do that all the time on internal tooling.  The question here is – what impact will this have on the smaller guys who cannot afford to either build or buy such tooling.

This has a knock on effect – the smaller operators are restricted in what they can deploy – the inter-op starts getting restricted – the potential breakage due to available skills in the networks increases – the potential for leakage of who knows what also goes up – and we end up with something that runs contrary to the IETF statement – that is “To make the internet work better”.

Adding complexity where it can be avoided using TLV’s – which are supported in the SRH – does not assist anyone.  Modifying a spec by minor degrees such that the lives of the spec’s consumers are made easier, increases likelihood of adoption and decreases resistance – to me that just makes perfect sense.

Andrew

From: Eliot Lear <[email-masked]>
Sent: Monday, October 25, 2021 3:35 PM
To: Andrew Alston <[email-masked]>; Ted Hardie <[email-masked]>
Cc: Nick Hilliard <[email-masked]>; SPRING WG List <[email-masked]>; 6man WG <[email-masked]>
Subject: Re: [spring] Objection to wg adoption call for draft-filsfilscheng-spring-srv6-srh-compression (was: Re: Question from SPRING regarding draft-filsfilscheng-spring-srv6-srh-compression)

Hi Andrew,

I don't disagree with your point that operational complexity hinders adoption.  However...
On 25.10.21 14:14, Andrew Alston wrote:
It's here where I think we often end up in a divergence between practical operation and fancy ideas

The problem is that one often can't tell the difference between the two without the benefit of hindsight, and perhaps several revs of the spec.  IPv6 itself is a perfect example of that truth (cf, MIPv6, site-local, IPsec requirements, and geographic routing).  But I write that with the benefit of hindsight in which we did find use for other v6 features, like flow labels.

Right now we have a lot of speculation about how tools won't evolve to assist operators, and I'm sympathetic to that to a point: tools develop best out of operational experience.

Eliot

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 28 Oct 2021 14:59:30 +1300

Greg,

Those are exactly my questions too.

Regards
    Brian

On 25-Oct-21 11:25, Greg Mirsky wrote:
> Hi Brian,
> so far I haven't noticed a proposal to support C-SID in IGP. I think that it brings up a legitimate question: How is it going to work? Would it C-SID be used in combination with dynamic routing protocols or only from a centralized controller?
> 
> Regards,
> Greg
> 
> On Sun, Oct 24, 2021 at 2:20 PM Brian E Carpenter <[email-masked] <mailto:[email-masked]>> wrote:
> 
>          Thinking of the IETF standards process: https://xkcd.com/2530/ <https://xkcd.com/2530/>
> 
>     [email-masked] <mailto:[email-masked]>
<https://www.ietf.org/mailman/listinfo/ipv6>