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

[Mark Smith <[e-mail]>]

On Tue, 17 Dec 2019, 21:12 Robert Raszuk, <[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. Hope SPRING charis will
> address it. 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.
>

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.

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 <[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]> *On Behalf Of *Alexandre
>> Petrescu
>> *Sent:* Monday, 16 December 2019 17:34
>> *To:* SPRING WG email list <[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]
>> https://www.ietf.org/mailman/listinfo/spring
>> _______________________________________________
>> spring mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/spring
>>
> _______________________________________________
> spring mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/spring
>