Re: [spring] packet captures for draft-ietf-spring-srv6-network-programming-06?

Hi Darren,

> You state that “code seems to be *way* off the draft”, but there is nothing in your email to support this.

Firstly - this quote leaves out a key statement in my original email - that I may have been reading the document incorrectly.

> You have made claims based on unfortunate misunderstandings of SRv6.

A misunderstanding that quite frankly should concern the authors of this draft, since it has been clearly demonstrated in subsequent emails that I was not alone in this misunderstanding, please see https://mailarchive.ietf.org/arch/msg/spring/d45B3wI5UBliIE0aoJPU-PDNe7w and https://mailarchive.ietf.org/arch/msg/spring/JbL22XULyiNA9HH9LFANZpi4Bbs

> Let’s return focus to discussing technical points and progressing the WG agenda and milestones with diligence and a constructive mindset.

Why do we standardize?  For the purpose of inter-op.  Why is running code central to IETF philosophies?  In my view, its so that people can demonstrate what is in the draft and so that the understanding of what is in the draft can be tested in real code.  Indeed, I point to the introduction of this draft:

This document defines the SRv6 Network Programming concept and aims
at standardizing the main segment routing functions to enable the
creation of interoperable overlays with underlay optimization and
service programming.

Therefore – if the text in the draft is being mis-interpreted – I would say that the questioning of this is both relevant and constructive – because a mis-reading of this by multiple people, both vendors and operators alike it would seem, would result in significant challenges to inter-op implementations of said text. I would also point out that the cornerstone of the IETF is to find consensus,  and a major part of meeting WG milestones revolves around finding of consensus.  I question how we will find consensus if it is demonstrable that the participants in this process have totally different interpretations of what is in the document.  It therefore moves to the authors to clarify in the text so that the meaning becomes clear and present so that a shared understanding can be gained to then gauge the consensus.  As such, I view this not only as constructive, but diligent, and I view this also as a technical point, since the misunderstandings of the text revolve around technical issues in a technical draft.

As such, do you not feel that a more appropriate response to my email would have been, “You seem to have misunderstood, perhaps we can provide some text in order to ensure such misunderstandings are less likely to occur?

Thanks

Andrew

On Dec 17, 2019, at 12:57 AM, Andrew Alston <mailto:Andrew.Alston@liquidtelecom.com> wrote:

Alex,

Will try and get you some captures off the devices I’ve been testing on – in order to make sure I understood this draft properly, and in light of the deployment status draft, I decided to play a lot more deeply and setup a bit of a lab.  I’m still doing tests and soon as I have some other bits completed will send through the packet captures from those against (Since the XR boxes that I have to test on seem to have absolutely no ability to setup traffic steering with SRv6 (and I actually have requested details of how to configure this in the past but gotten no response), I’m just finishing the code to inject packets from outside with a sid stack to test this.  I also acknowledge that I’m running tests against code that is implementing a draft that seems far from final – and so shouldn’t have that many expectations.

That being said, In light of the deployment draft – I do have some concerns that there is a draft that specifies that people have put this stuff into production – yet the implementation in current shipping code seems to be *way* off the draft and contrary to things we have been told in the working group.

Some of the more interesting finds so far:

• In Montreal – I questioned the growth in the IGP tables – since I would have to use a separate locator on each router – I was explicitly told this wasn’t necessary and could use the loopbacks – not so in current code – use of the loopback marks the locator as down.

• Locator size is not configurable as anything other than a /64

• XR 7.0.1 claims a maximum number of SID’s at 8000 – I’m still unclear if this limitation in the code is based on locally configured SID’s or received SID’s – and will run some tests on this in the coming day or two to verify

• There seems to be a limit on a single locator per box – I’m still trying to figure out what impact this will have in a multi-area or multi-level IGP deployment scenario.

• By default when configuring a locator – the device configures a separate End.X (PSP) for each interface – now – this is where things get interesting.  If I am reading the NP text correctly, End.X (PSP) should be locator:0006::  - However, in the shipping code, that is not the case at all – as per the below:

RP/0/RP0/CPU0:SRV6-R2#show segment-routing srv6 locator R2 sid Sun Dec 15 04:56:10.913 UTC

SID                         Behavior     Context                           Owner               State  RW

--------------------------  -----------  ------------------------------    ------------------  -----  --

2001:db8:ee:2:1::           End (PSP)    'default':1                       sidmgr              InUse  Y

2001:db8:ee:2:11::          End.OP       'default'                         sidmgr              InUse  Y

2001:db8:ee:2:40::          End.X (PSP)  [Gi0/0/0/0, Link-Local]           isis-64             InUse  Y

2001:db8:ee:2:41::          End.X (PSP)  [Gi0/0/0/1, Link-Local]           isis-64             InUse  Y

2001:db8:ee:2:42::          End.X (PSP)  [Gi0/0/0/3, Link-Local]           isis-64             InUse  Y

So from my perspective – I have to wonder about the production deployments – because particularly on this last point – if people have been putting this stuff in production, and the implementation is so different from the text, its going to create some rather interesting breakage going forward if my reading of the text is correct.

Anyway – will send some packet captures hopefully in the next 48 hours once I’ve got a more complete set of captures from my lab setup.

Thanks

Andrew

From: spring <mailto:spring-bounces@ietf.org> On Behalf Of Alexandre Petrescu

Sent: Monday, 16 December 2019 17:34

To: SPRING WG email list <mailto:spring@ietf.org>

Subject: [spring] packet captures for draft-ietf-spring-srv6-network-programming-06?

Hi, SPRINGers,

My comments on SRv6 relate to a worry about modifying packets in transit.

In order to better explain myself, or maybe to remove the worry

altogether, I would like to ask for packet dumps of SRv6.

By looking at the packet contents that go into the network it is much

easier to clarify and to avoid misunderstandings.

Alex

_______________________________________________

spring mailing list

mailto:spring@ietf.org

https://www.ietf.org/mailman/listinfo/spring

_______________________________________________

spring mailing list

mailto:spring@ietf.org

https://www.ietf.org/mailman/listinfo/spring