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

[Robert Raszuk <[e-mail]>]

Amazing .. but I agree with you again ! ;)

Cheers
R.

On Tue, Dec 17, 2019, 11:59 Mark Smith <[e-mail]> wrote:

>
>
> 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
>>
>