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

[Alexandre Petrescu <[e-mail]>]

Excuse me for posting in reply interspersed to someone else.  It's
because I did not get the original from R. Raszuk.

Le 17/12/2019 à 11:59, Mark Smith a écrit :
> 
> 
> On Tue, 17 Dec 2019, 21:12 Robert Raszuk, <[e-mail] 
> <mailto:[e-mail]>> wrote:
> 
> Hi Andrew,
> 
> My personal opinion is that with below you are now going way outside
>  of what should be discussed on IETF mailing lists.

I think his post is very valuable.


> Hope SPRING charis will address it.

Please take this more informal.  It is not a big problem.

> IETF is not the right forum for any vendor implementation discussion
> regardless if this is Cisco, Juniper, Arrcus, Nokia etc .... I
> recommend you move it to -nsp lists.

What is -nsp list?

I would like to tell you the following: in many IETF email lists I look 
at the distance between theory and implementation is too high.

And, some people suggest to rather go to other implementation-specific 
lists, like lkml.  But there, the traffic is too high to cope with.  So 
one ends up with not discussing the issue at all.  We dont want that either.

> 
> I think it matters when a draft is reporting deployments, and there 
> are drafts that are justifying decisions based on apparent operator 
> deployment popularity rather than providing objective technical and 
> engineering justification.

I agree.

Alex

> 
> The Internet Engineering Task Force shouldn't fall victim to any 
> logical fallacies.
> 
> https://yourlogicalfallacyis.com
> 
> 
> 
> 
> 
> 
> 
> 
> 
> If standards or drafts are not clear you are welcome to ask
> questions on those. Any implementation is a private choice of given
> vendor and in no way should influence WG decision in regards of the
> choices we make in protocol design.
> 
> If you think that some implementations violate standards or even WG 
> drafts you are more then welcome to propose specific questions to
> the implementation reports which chairs would be normally more than
> happy to include in the process and ask or even enforce all vendors
> to fill the blanks.
> 
> Regards, Robert.
> 
> 
> On Tue, Dec 17, 2019 at 6:58 AM Andrew Alston 
> <Andrew.Alston@liquidtelecom..com 
> <mailto:[e-mail]>> 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 <[e-mail] 
> <mailto:[e-mail]>> *On Behalf Of *Alexandre Petrescu 
> *Sent:* Monday, 16 December 2019 17:34 *To:* SPRING WG email list 
> <[e-mail] <mailto:[e-mail]>> *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 
> [e-mail] <mailto:[e-mail]> 
> https://www.ietf.org/mailman/listinfo/spring____
> 
> _______________________________________________ spring mailing list 
> [e-mail] <mailto:[e-mail]> 
> https://www.ietf.org/mailman/listinfo/spring
> 
> _______________________________________________ spring mailing list 
> [e-mail] <mailto:[e-mail]> 
> https://www.ietf.org/mailman/listinfo/spring
>