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

From: Alexandre Petrescu <[email-masked]>
Date: Mon, 16 Dec 2019 15:34:23 +0100

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

---

From: Andrew Alston <[email-masked]>
Date: Tue, 17 Dec 2019 05:57:47 +0000

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 <[email-masked]> On Behalf Of Alexandre Petrescu
Sent: Monday, 16 December 2019 17:34
To: SPRING WG email list <[email-masked]>
Subject: [spring] packet captures for draft-ietf-spring-srv6-network-programming-06?

Hi, SPRINGers,

Alex

_______________________________________________
spring mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/spring<https://www.ietf.org/mailman/listinfo/spring>

---

From: Robert Raszuk <[email-masked]>
Date: Tue, 17 Dec 2019 11:12:25 +0100

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.

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 <
[email-masked]> 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.
>
>
>
>    - 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 <[email-masked]> *On Behalf Of *Alexandre Petrescu
> *Sent:* Monday, 16 December 2019 17:34
> *To:* SPRING WG email list <[email-masked]>
> *Subject:* [spring] packet captures for
> draft-ietf-spring-srv6-network-programming-06?
>
>
>
> Hi, SPRINGers,
>
> [email-masked]
> https://www.ietf.org/mailman/listinfo/spring
> [email-masked]
> https://www.ietf.org/mailman/listinfo/spring
>

---

From: Mark Smith <[email-masked]>
Date: Tue, 17 Dec 2019 21:59:38 +1100

> 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

> Andrew.Alston@liquidtelecom..com <[email-masked]>> wrote:
>
>> Alex,
>>
>>
>>
>> *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*
>>
>> 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.
>>
>>
>>

---

From: Robert Raszuk <[email-masked]>
Date: Tue, 17 Dec 2019 12:03:41 +0100

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

Cheers
R.

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

>> If you think that some implementations violate standards or even WG
>> drafts you are more then welcome to propose specific questions to
>>> 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

---

From: Mark Smith <[email-masked]>
Date: Tue, 17 Dec 2019 22:21:36 +1100

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

Hopefully it shouldn't be all that amazing, I try hard to be logical and
not fall victim to all the biases we humans have.

(I'm planning to release a line of digital hifi cables for audiophiles
under the brand "Confirmation Bias". I figure I should get in on the $2900 USD
Ethernet cables market. Those 1s and 0s know which direction they're going,
and really care if it's the wrong way!)

---

From: Andrew Alston <[email-masked]>
Date: Tue, 17 Dec 2019 16:18:43 +0000

Echoing what Mark said in later emails.  A deployment draft was published – it made claims about peoples production deployments – and it is my belief that any draft that is put forward into the IETF is open to testing and verification.  Furthermore – I would strongly argue there is a reason that the IETF calls for running code, running code lets us test the premise behind the drafts – and if the running code presents – and further pushed through deployment drafts – is not in line with the drafts themselves – we need to understand why not.

To find inter-operable approaches – which is kinda the point of standards I believe – it is very critical that we understand what is actually being put out there as being deployed – vs what is in the drafts – and critical to understand if we are miss understanding something in the draft that is causing such wide disparities – anything else will lead to a huge amount of inter-op issues later down the line.

Hence – I think an analysis of what is being claimed by the deployment draft is indeed very relevant.

Thanks

Andrew

From: Robert Raszuk <[email-masked]>
Date: Tuesday, 17 December 2019 at 13:12
To: Andrew Alston <[email-masked]>
Cc: Alexandre Petrescu <[email-masked]>, SPRING WG email list <[email-masked]>
Subject: Re: [spring] packet captures for draft-ietf-spring-srv6-network-programming-06?

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.

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 <[email-masked]<mailto:[email-masked]>> 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.

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

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

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 <[email-masked]<mailto:[email-masked]>> On Behalf Of Alexandre Petrescu
Sent: Monday, 16 December 2019 17:34
To: SPRING WG email list <[email-masked]<mailto:[email-masked]>>
Subject: [spring] packet captures for draft-ietf-spring-srv6-network-programming-06?

Hi, SPRINGers,

Alex

---

From: Alexandre Petrescu <[email-masked]>
Date: Wed, 18 Dec 2019 17:10:39 +0100

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, <[email-masked] 
> <mailto:[email-masked]>> 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

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.
> 
> 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.
> 
> 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:[email-masked]>> 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.____
> 
> __ __
> 
> 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 
> 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____/
> 
> /__ __/
> 
> 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 <[email-masked] 
> <mailto:[email-masked]>> *On Behalf Of *Alexandre Petrescu 
> *Sent:* Monday, 16 December 2019 17:34 *To:* SPRING WG email list 
> <[email-masked] <mailto:[email-masked]>> *Subject:* [spring]
> packet captures for
> draft-ietf-spring-srv6-network-programming-06?____
> 
> __ __
> 
> Hi, SPRINGers,
> 
> _______________________________________________ spring mailing list 
> [email-masked] <mailto:[email-masked]> 
> https://www.ietf.org/mailman/listinfo/spring____
> 
> _______________________________________________ spring mailing list 
> [email-masked] <mailto:[email-masked]> 
> _______________________________________________ spring mailing list 
> [email-masked] <mailto:[email-masked]>

---

From: Alexandre Petrescu <[email-masked]>
Date: Wed, 18 Dec 2019 17:12:19 +0100

Andrew,

Le 17/12/2019 à 06:57, Andrew Alston a écrit :
> – 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.
> 
>     not so in current code – use of the loopback marks the locator as down.
> 
>     in the coming day or two to verify
> 
>     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/

I would like to ask you whether that
2001:db8:ee:2:1::
could rather be
2001:db8:ee:ff:2:1::?

It is important for the 64 limit.

Alex
[...]

---

From: Andrew Alston <[email-masked]>
Date: Wed, 18 Dec 2019 20:53:56 +0000

>   I would like to ask you whether that
    
  No - the locator has to be on a 64bit boundary - it refuses configuration for anything else in the code bases I have tested on.

Thanks

Andrew

---

From: Andrew Alston <[email-masked]>
Date: Wed, 18 Dec 2019 20:59:39 +0000

>    I would like to ask you whether that
    
 Just to clarify to y last email - in the above - 2001:db8:ee:2 is the locator - 1 seems to be a function - which I also realize does not align at all with section 9.2 of the draft - but am I correct in understanding you are asking if the locator could be 2001:db8:ee:ff:2:: - with 1 being the function - in which case the answer, as per my previous email, is no - not in the code bases I am testing on.

Thanks

Andrew

---

From: Alexandre Petrescu <[email-masked]>
Date: Wed, 18 Dec 2019 22:17:48 +0100

>    No - the locator has to be on a 64bit boundary - it refuses configuration for anything else in the code bases I have tested on.

Are the fixed-length locators aware of a similar distinction in IPv4 
before CIDR existed?

Does SRv6 appreciate class existence in IPv6?

Alex

---

From: Alexandre Petrescu <[email-masked]>
Date: Wed, 18 Dec 2019 22:27:47 +0100

Le 18/12/2019 à 21:59, Andrew Alston a écrit :
> Just to clarify to y last email - in the above - 2001:db8:ee:2 is the
> locator - 1 seems to be a function - which I also realize does not
> align at all with section 9.2 of the draft - but am I correct in
> understanding you are asking if the locator could be
> 2001:db8:ee:ff:2:: - with 1 being the function - in which case the
> answer, as per my previous email, is no - not in the code bases I am
> testing on.

Thank you for the reply.

If the locator can only be 64bit in length then I think it is wrong.

But I am aware the more I say that the stronger and more numerous the 
RFCs using a fixed 64 are published :-)  It is not what I want.  So I 
stop saying it.

Alex

---

From: "Darren Dukes (ddukes)" <[email-masked]>
Date: Thu, 19 Dec 2019 18:44:18 +0000

Hi Andrew,

You state that “code seems to be *way* off the draft”, but there is nothing in your email to support this.
You have made claims based on unfortunate misunderstandings of SRv6.

For example, your understanding of End.X SID is not correct.
You appear to be confusing SRv6 SID Function and an SRv6 Segment Behavior.
These are clearly defined in section 2 of draft-ietf-spring-srv6-network-programming and described in detail later in the draft.
Allow me to explain:
- Several End.X SIDs are instantiated in the same router, one “adjacency SID” per adjacency seems about right.
- Each SID will be unique, i.e. a unique IPv6 address.
- The address does not encode the SRv6 Segment Behavior codepoint (e.g. 0x0006). These Behavior codepoints (as captured in “Table 4: IETF - SRv6 Endpoint Behaviors)  are for control plane use.

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

Thanks
  Darren

On Dec 17, 2019, at 12:57 AM, Andrew Alston <[email-masked]<mailto:[email-masked]>> wrote:

Alex,

Thanks

Andrew

Hi, SPRINGers,

Alex

---

From: Andrew Alston <[email-masked]>
Date: Fri, 20 Dec 2019 05:10:18 +0000

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:[email-masked]> wrote:

Alex,

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

Thanks

Andrew

From: spring <mailto:[email-masked]> On Behalf Of Alexandre Petrescu

To: SPRING WG email list <mailto:[email-masked]>

Hi, SPRINGers,

Alex

spring mailing list

mailto:[email-masked]

spring mailing list

mailto:[email-masked]

---

From: "Darren Dukes (ddukes)" <[email-masked]>
Date: Fri, 20 Dec 2019 11:12:48 +0000

Hello Andrew.

Perhaps brevity can help here.  I’m only replying to the last sentence of your email.

Were you to have initiated this thread with “This implementation allocated multiple END.X SIDs, is that in opposition to section... of draft...? I interpret section ... to mean ....”

My reply could have been “You seem to have misunderstood, allow me to explain... ” then we could have had a good conversation and arrived at the clarifying text.

I hope this helps.

Thanks!
  Darren

________________________________
From: Andrew Alston <[email-masked]>
Sent: Friday, December 20, 2019 12:10:18 AM
To: Darren Dukes (ddukes) <[email-masked]>
Cc: Alexandre Petrescu <[email-masked]>; SPRING WG email list <[email-masked]>
Subject: RE: [spring] packet captures for draft-ietf-spring-srv6-network-programming-06?

Hi Darren,

> 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 seehttps://mailarchive.ietf.org/arch/msg/spring/d45B3wI5UBliIE0aoJPU-PDNe7w and https://mailarchive.ietf.org/arch/msg/spring/JbL22XULyiNA9HH9LFANZpi4Bbs

at standardizing the main segment routing functionsto enable the

service programming.

Thanks

Andrew

Alex,

Thanks

Andrew

Hi, SPRINGers,

Alex

spring mailing list

mailto:[email-masked]

spring mailing list

mailto:[email-masked]