Subject: RE: Routing Header Insertion

From: "Voyer, Daniel" <[email-masked]>
Date: Wed, 6 May 2020 12:09:21 +0000

Ron, yes – I echo Eric – all my respect.

Ron, I for one, would jump to conclusion for that specific use case where insertion is performed, and have the expected behaviour. This is the exact use case that was described over the years in this mailing list,

Now, obviously, this use case is contain within the operator domain. I don’t expect an operator to have “TI-LFA” on their peering links with other transit/operator.

For people references, page 15 “TI-LFA over SRv6”:
http://www.eantc.de/fileadmin/eantc/downloads/events/MPLS2020/EANTC-MPLSSDNNFV2020-WhitePaper.pdf

Thanks,
dan

From: ipv6 <[email-masked]> on behalf of "Eric Vyncke (evyncke)" <evyncke=[email-masked]>
Date: Wednesday, May 6, 2020 at 7:08 AM
To: Ron Bonica <rbonica=[email-masked]>, 6man <[email-masked]>
Subject: [EXT]Re: Routing Header Insertion

Ron,

All my respect to you for this correction of yours.

Regards

-éric

PS: I was about to reply unicast to Ron but decided that Ron deserves some public appreciation for his email.

From: ipv6 <[email-masked]> on behalf of Ron Bonica <rbonica=[email-masked]>
Date: Wednesday, 6 May 2020 at 02:52
To: 6man <[email-masked]>
Subject: Routing Header Insertion

Folks,

My apologies to Zafar Ali. Reading through the EANTC report, it appears the Juniper demonstration SRv6 Routing Header insertion to support TI-LFA. In that respect, Zafar is correct.

However, we should not jump to the conclusion that such behavior is desirable.

                                                                       Ron

Juniper Business Use Only

Juniper Business Use Only

---

From: Krzysztof Szarkowicz <[email-masked]>
Date: Wed, 6 May 2020 14:36:28 +0200

Also,

There is short video discussing SRv6 TI-LFA EANTC test:

https://youtu.be/v9woK-7AiyA <https://youtu.be/v9woK-7AiyA>

Thanks,
Krzysztof

> On 2020 -May-06, at 14:09, Voyer, Daniel <[email-masked]> wrote:
> 
> http://www.eantc.de/fileadmin/eantc/downloads/events/MPLS2020/EANTC-MPLSSDNNFV2020-WhitePaper.pdf <http://www.eantc.de/fileadmin/eantc/downloads/events/MPLS2020/EANTC-MPLSSDNNFV2020-WhitePaper.pdf>
>  
> Thanks,
> dan
>  
> From: ipv6 <[email-masked] <mailto:[email-masked]>> on behalf of "Eric Vyncke (evyncke)" <evyncke=[email-masked] <mailto:evyncke=[email-masked]>>
> To: Ron Bonica <rbonica=[email-masked] <mailto:rbonica=[email-masked]>>, 6man <[email-masked] <mailto:[email-masked]>>
> From: ipv6 <[email-masked] <mailto:[email-masked]>> on behalf of Ron Bonica <rbonica=[email-masked] <mailto:rbonica=[email-masked]>>
> To: 6man <[email-masked] <mailto:[email-masked]>>
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> [email-masked] <mailto:[email-masked]>
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 <https://www.ietf.org/mailman/listinfo/ipv6>
> --------------------------------------------------------------------

---

From: "Darren Dukes (ddukes)" <[email-masked]>
Date: Thu, 7 May 2020 16:44:26 +0000

Krzysztof thanks for the link, to me it does seem that Juniper sees SRH insertion for TILFA as desirable, as documented in draft-voyer-6man-extension-header-insertion.

So Dan, I think we can jump to that conclusion supported by 19 implementations and 5 deployments as captured in draft-matsushima-spring-srv6-deployment-status, including Juniper's.

Darren

On May 6, 2020, at 8:36 AM, Krzysztof Szarkowicz <[email-masked]<mailto:[email-masked]>> wrote:

Also,

https://youtu.be/v9woK-7AiyA

Thanks,
Krzysztof

On 2020 -May-06, at 14:09, Voyer, Daniel <[email-masked]<mailto:[email-masked]>> wrote:

Thanks,
dan

From: ipv6 <[email-masked]<mailto:[email-masked]>> on behalf of "Eric Vyncke (evyncke)" <evyncke=[email-masked]<mailto:evyncke=[email-masked]>>
Date: Wednesday, May 6, 2020 at 7:08 AM
To: Ron Bonica <rbonica=[email-masked]<mailto:rbonica=[email-masked]>>, 6man <[email-masked]<mailto:[email-masked]>>
Subject: [EXT]Re: Routing Header Insertion

Ron,

Regards

-éric

From: ipv6 <[email-masked]<mailto:[email-masked]>> on behalf of Ron Bonica <rbonica=[email-masked]<mailto:rbonica=[email-masked]>>
Date: Wednesday, 6 May 2020 at 02:52
To: 6man <[email-masked]<mailto:[email-masked]>>
Subject: Routing Header Insertion

Folks,

                                                                       Ron

--------------------------------------------------------------------
IETF IPv6 working group mailing list
[email-masked]<mailto:[email-masked]>
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------

--------------------------------------------------------------------
IETF IPv6 working group mailing list
[email-masked]<mailto:[email-masked]>
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------

---

From: Ron Bonica <[email-masked]>
Date: Thu, 7 May 2020 17:03:11 +0000

Hi Daniel,

TI-LFA with SRH insertion poses problems in the following cases:

  *   When the packet already contains an SRH
  *   When the IPv6 Destination Address contains uSIDs

In the first case, when the packet already contains an SRH, TI-LFA with SRH insertion results in a single packet that contains two SRH's. No reading of RFC 8200 allows this.

The second case is more complex. Assume that in your uSID strategy:

  *   The uSID block identifier is 32 bits long
  *   Each uSID is 16 bits long
  *   The end-of-carrier marker is also 16 bits long

In this case, you can fit 5 uSIDs in the IPv6 address.

On the first segment, when the destination address still contains 5 uSIDs, a PLR detects link failure and invokes TI-LFA procedures. The repair tunnel contains 3 segments. If the PLR executes TI-LFA with insertion procedures, what does the resulting IPv6 Destination address look like? What does the SRH look like?

Yes, the problem can be solved, but not without deep though and vigorous head scratching. When a solution is that complex, it is probably beyond the capability of any operations staff.

The above-mentioned problems could have been avoided if TI-LFA created its repair tunnel by prepending an IPv6 header with its own SRH.

                                                                                                 Ron

Juniper Business Use Only
From: Voyer, Daniel <[email-masked]>
Sent: Wednesday, May 6, 2020 8:09 AM
To: Eric Vyncke (evyncke) <[email-masked]>; Ron Bonica <[email-masked]>; 6man <[email-masked]>
Subject: RE: Routing Header Insertion

[External Email. Be cautious of content]

Ron, yes - I echo Eric - all my respect.

Now, obviously, this use case is contain within the operator domain. I don't expect an operator to have "TI-LFA" on their peering links with other transit/operator.

For people references, page 15 "TI-LFA over SRv6":
http://www.eantc.de/fileadmin/eantc/downloads/events/MPLS2020/EANTC-MPLSSDNNFV2020-WhitePaper.pdf<https://urldefense.com/v3/__http:/www.eantc.de/fileadmin/eantc/downloads/events/MPLS2020/EANTC-MPLSSDNNFV2020-WhitePaper.pdf__;!!NEt6yMaO-gk!XDGamOoAcO3D80GGXssnLzgpdzH91ZYkBz2xO8XOh9drDGTuqVluAINFDOoChS_4$>

Thanks,
dan

Ron,

Regards

-éric

Folks,

                                                                       Ron

---

From: Ron Bonica <[email-masked]>
Date: Thu, 7 May 2020 17:26:12 +0000

Darren,

I would not infer that Juniper sees SRH insertion as desirable.

                                                                    Ron

Juniper Business Use Only
From: Darren Dukes (ddukes) <ddukes=[email-masked]>
Sent: Thursday, May 7, 2020 12:44 PM
To: Krzysztof Szarkowicz <[email-masked]>
Cc: Voyer, Daniel <[email-masked]>; Ron Bonica <[email-masked]>; Eric Vyncke (evyncke) <[email-masked]>; 6man <[email-masked]>
Subject: Re: Routing Header Insertion

Darren

Also,

https://youtu.be/v9woK-7AiyA<https://urldefense.com/v3/__https:/youtu.be/v9woK-7AiyA__;!!NEt6yMaO-gk!TaDJL7YNeeQ7k_C0AX1_QHZk9QBMPGB_gcrjT6UGAdlpCkJ2gRyHQAxM4VlrWMYF$>

Thanks,
Krzysztof

For people references, page 15 "TI-LFA over SRv6":
http://www.eantc.de/fileadmin/eantc/downloads/events/MPLS2020/EANTC-MPLSSDNNFV2020-WhitePaper.pdf<https://urldefense.com/v3/__http:/www.eantc.de/fileadmin/eantc/downloads/events/MPLS2020/EANTC-MPLSSDNNFV2020-WhitePaper.pdf__;!!NEt6yMaO-gk!TaDJL7YNeeQ7k_C0AX1_QHZk9QBMPGB_gcrjT6UGAdlpCkJ2gRyHQAxM4XlMWSUv$>

Thanks,
dan

Ron,

Regards

-éric

Folks,

                                                                       Ron

Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6<https://urldefense.com/v3/__https:/www.ietf.org/mailman/listinfo/ipv6__;!!NEt6yMaO-gk!TaDJL7YNeeQ7k_C0AX1_QHZk9QBMPGB_gcrjT6UGAdlpCkJ2gRyHQAxM4Wt18ps-$>

---

From: Robert Raszuk <[email-masked]>
Date: Thu, 7 May 2020 19:27:39 +0200

Hi Ron,

>  Yes, the problem can be solved, but not without deep though and vigorous
head scratching.

Well don't we still have the indicators of Active, Next and Last uSIDs in
SRH ? If so what is so difficult if you keep your original SRH as is and
provide FRR using new SRH ? Moreover if you POP the additional SRH @
ptotectied path PHP FRR endpoint may not even noticed he is acting as such
endpoint and that is very cool thing.

The problem perhaps becomes a nice exercise to solve how to handle TI-LFA
when you have uSID list in DA address of the packets and where there is no
SRH at all :) Clearly a valid deployment scenario. But since you are
already deep into it I will let you figure it out :)

> When a solution is that complex, it is probably beyond the capability of
any operations staff.

Well it would be a mistake to count on all operators doing this handling in
P4 code on their own custom platforms. For rest of them a simple knob would
be sufficient to enable it and enjoy.

Thx,
R.

On Thu, May 7, 2020 at 7:03 PM Ron Bonica <rbonica=
[email-masked]> wrote:

>    - When the packet already contains an SRH
>    - When the IPv6 Destination Address contains uSIDs
>
>
>
> In the first case, when the packet already contains an SRH, TI-LFA with
> SRH insertion results in a single packet that contains two SRH’s. No
> reading of RFC 8200 allows this.
>
>
>
>    - The uSID block identifier is 32 bits long
>    - Each uSID is 16 bits long
>    - The end-of-carrier marker is also 16 bits long
>
>
>
> On the first segment, when the destination address still contains 5 uSIDs,
> a PLR detects link failure and invokes TI-LFA procedures. The repair tunnel
> contains 3 segments. If the PLR executes TI-LFA with insertion procedures,
> what does the resulting IPv6 Destination address look like? What does the
> SRH look like?
>
>
>
> Yes, the problem can be solved, but not without deep though and vigorous
> head scratching. When a solution is that complex, it is probably beyond the
> capability of any operations staff.
>
>
>
> The above-mentioned problems could have been avoided if TI-LFA created its
> repair tunnel by prepending an IPv6 header with its own SRH.
>
>
>
>
>                                                                                       Ron
>

---

From: Ron Bonica <[email-masked]>
Date: Thu, 7 May 2020 17:46:30 +0000

Robert,

The problem is that the IPv6 destination address contains 5 uSID that represent 5 nodes yet to be visited. Those need to be put at the end of the line, so that they are visited *after* the nodes in the repair path.

Yes, there are some very clever solutions that you and I understand. But will the guy in the NOC who doesn't live and breath SR be able to figure it out the first time he sees it.

                                                                             Ron

Juniper Business Use Only
From: Robert Raszuk <[email-masked]>
Sent: Thursday, May 7, 2020 1:28 PM
To: Ron Bonica <[email-masked]>
Cc: Voyer, Daniel <[email-masked]>; Eric Vyncke (evyncke) <[email-masked]>; 6man <[email-masked]>
Subject: Re: Routing Header Insertion

Hi Ron,

>  Yes, the problem can be solved, but not without deep though and vigorous head scratching.

Well don't we still have the indicators of Active, Next and Last uSIDs in SRH ? If so what is so difficult if you keep your original SRH as is and provide FRR using new SRH ? Moreover if you POP the additional SRH @ ptotectied path PHP FRR endpoint may not even noticed he is acting as such endpoint and that is very cool thing.

The problem perhaps becomes a nice exercise to solve how to handle TI-LFA when you have uSID list in DA address of the packets and where there is no SRH at all :) Clearly a valid deployment scenario. But since you are already deep into it I will let you figure it out :)

> When a solution is that complex, it is probably beyond the capability of any operations staff.

Well it would be a mistake to count on all operators doing this handling in P4 code on their own custom platforms. For rest of them a simple knob would be sufficient to enable it and enjoy.

Thx,
R.

On Thu, May 7, 2020 at 7:03 PM Ron Bonica <rbonica=[email-masked]<mailto:[email-masked]>> wrote:
Hi Daniel,

                                                                                                 Ron

---

From: Sander Steffann <[email-masked]>
Date: Fri, 8 May 2020 00:57:16 +0200

Hi,

> Yes, there are some very clever solutions that you and I understand. But will the guy in the NOC who doesn’t live and breath SR be able to figure it out the first time he sees it.

We are not the only audience of our drafts. We design protocols to be used on networks run by operators. Operators who will encounter bugs, misconfigurations and unexpected behaviour. Yes, there is a level of abstraction beyond which the operator shouldn't need to understand the exact implementation. But IPv6 addresses and extension headers are absolutely within the domain that the operator does need to understand...

If the people in this group (who are far above the expertise level of the average NOC) sometimes have difficulty understanding the dynamics, we are writing documents which are of very bad quality because they are unreadable to most of our target audience...

Cheers,
Sander

---

From: Andrew Alston <[email-masked]>
Date: Fri, 8 May 2020 10:15:30 +0000

I do find it kinda bizarre that one vendor or an individual would jump to a conclusion and make statements about what another one desires - surely it is up to the vendor that desires something to publicly state so and not for someone else to make statements on their behalf?

I mean - let's be clear - I have written a partial SRv6 / SRv6-NP implementation into our DPDK lab testing stack - I did it to verify certain things - the only thing it further convinced me  of is that I will never run this in production - in a million years - and I'd be rather concerned if someone went out there and said on the basis of the fact that I chose to test something - I suddenly supported or liked it.  What that's effectively saying is - to test something is to support it - that's not the case.  It's similar to the line that I was given that because I signed a blue sheet in Singapore and didn't stand up at the microphone and publically object to something at the time - some how my signature on the blue sheet indicated my acceptance and support of the issue in question.

(To quote that)

PC2: The comment started because in the draft we had an example that was assigning A:1::/32 as loopback interface for a router. This is wrong (prefix length, documentation prefix,).
This was fixed in revision 2 of the WG draft, published in September 19th 2019. The closure of this comment was presented by me personally in IETF Singapore. Please refer to the slides. In Singapore you were present (signed blue sheet) and did not had any comment about such closure.

This is interesting - so firstly - let me state that because I was present in a meeting and signed a blue sheet to say I was there - in no way indicates that I forgo the right to object after the meeting - and last I checked, signatures on a blue sheet are there to track attendance, not to track consensus.

So - can I make a humble request that we let people speak for themselves about what they actively support and want rather than trying to speak for others to bolster our case?  Because if the case is so weak that we need to make claims on behalf of others - then there is no case at all.

Thanks

Andrew

From: ipv6 <[email-masked]> On Behalf Of Ron Bonica
Sent: Thursday, 7 May 2020 20:26
To: Darren Dukes (ddukes) <ddukes=[email-masked]>; Krzysztof Szarkowicz <[email-masked]>
Cc: 6man <[email-masked]>
Subject: RE: Routing Header Insertion

Darren,

                                                                    Ron

Juniper Business Use Only
From: Darren Dukes (ddukes) <ddukes=[email-masked]<mailto:ddukes=[email-masked]>>
Sent: Thursday, May 7, 2020 12:44 PM
To: Krzysztof Szarkowicz <[email-masked]<mailto:[email-masked]>>
Cc: Voyer, Daniel <[email-masked]<mailto:[email-masked]>>; Ron Bonica <[email-masked]<mailto:[email-masked]>>; Eric Vyncke (evyncke) <[email-masked]<mailto:[email-masked]>>; 6man <[email-masked]<mailto:[email-masked]>>
Subject: Re: Routing Header Insertion

Darren

Also,

Thanks,
Krzysztof

Thanks,
dan

From: ipv6 <[email-masked]<mailto:[email-masked]>> on behalf of "Eric Vyncke (evyncke)" <evyncke=[email-masked]<mailto:evyncke=[email-masked]>>
Date: Wednesday, May 6, 2020 at 7:08 AM
To: Ron Bonica <rbonica=[email-masked]<mailto:rbonica=[email-masked]>>, 6man <6man@ietf..org<mailto:[email-masked]>>
Subject: [EXT]Re: Routing Header Insertion

Ron,

Regards

-éric

Folks,

                                                                       Ron

--------------------------------------------------------------------
IETF IPv6 working group mailing list
[email-masked]<mailto:[email-masked]>
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6<https://www.ietf.org/mailman/listinfo/ipv6>
--------------------------------------------------------------------

---

From: Robert Raszuk <[email-masked]>
Date: Fri, 8 May 2020 12:33:22 +0200

Hey Andrew,

I don't think the point is on what one vendor desires or likes. The point
is that they internally committed development resources to deliver this
functionality. They also asked one of their top talented TME Krzysiek to go
and demo it. It carries a message. And all Zafar and others did was just
sharing that message.

It really does not matter that much Ron himself or on behalf of his company
can jump on the lists stating that he does not like it. Even if Juniper
marketing will not push it - even if they develop next cartoon mocking it -
they will still likely check mark support tag on the RFPs.

*All that proves that SRH insertion is a useful feature to customers.* And
that's all what matters to some IETF decisions as part of that is community
needs and support for extensions under standardization.

Best,
Robert.

On Fri, May 8, 2020 at 12:16 PM Andrew Alston <
[email-masked]> wrote:

> I do find it kinda bizarre that one vendor or an individual would jump to
> a conclusion and make statements about what another one desires – surely it
> is up to the vendor that desires something to publicly state so and not for
> someone else to make statements on their behalf?
>
>
>
> I mean – let’s be clear – I have written a partial SRv6 / SRv6-NP
> implementation into our DPDK lab testing stack – I did it to verify certain
> things – the only thing it further convinced me  of is that I will never
> run this in production – in a million years – and I’d be rather concerned
> if someone went out there and said on the basis of the fact that I chose to
> test something – I suddenly supported or liked it.  What that’s effectively
> saying is – to test something is to support it – that’s not the case.  It’s
> similar to the line that I was given that because I signed a blue sheet in
> Singapore and didn’t stand up at the microphone and publically object to
> something at the time – some how my signature on the blue sheet indicated
> my acceptance and support of the issue in question.
>
>
>
> (To quote that)
>
>
>
> *PC2: The comment started because in the draft we had an example that was
> assigning A:1::/32 as loopback interface for a router. This is wrong
> (prefix length, documentation prefix,).*
>
> *This was fixed in revision 2 of the WG draft, published in September 19th
> 2019. The closure of this comment was presented by me personally in IETF
> Singapore. Please refer to the slides. In Singapore you were present
> (signed blue sheet) and did not had any comment about such closure.*
>
>
>
>
>
> *This is interesting – so firstly – let me state that because I was
> present in a meeting and signed a blue sheet to say I was there – in no way
> indicates that I forgo the right to object after the meeting – and last I
> checked, signatures on a blue sheet are there to track attendance, not to
> track consensus.*
>
>
>
>
>
> So – can I make a humble request that we let people speak for themselves
> about what they actively support and want rather than trying to speak for
> others to bolster our case?  Because if the case is so weak that we need to
> make claims on behalf of others – then there is no case at all.
>
>
>
> Thanks
>
>
>
> Andrew
>

---

From: Andrew Alston <[email-masked]>
Date: Fri, 8 May 2020 10:56:25 +0000

Robert,

Actually – it proves precisely nothing until they state their motivations – and we have no right to read motivations into it.  We can ask them why they did it – we cannot assume and nor does anyone have the right to make statements about why they chose to do something outside of someone else.

The twisting of words that I have seen of late has really disturbed me.  Another classic case in point was where it was claimed by another opponent of a draft stated the need for architectural documents.  In fact what had been stated was very clear that the applications USING the protocol needed architectural drafts and this was merely a building block (and before I write this, I verified very clear that was what was originally said, with the individual stating it).  My point here is – the IETF says – every person who steps us is representing themselves as an individual.  It is not for us to ascribe motivations to others and then go forward and make claims about other peoples motivations.  Let us make our case on our own technical grounds.

I point out that within the IETF – each person is meant to represent themselves – and statements that imply motivations of others to bolster a case in my view, do nothing more than weaken the argument of those making them – because if the argument is strong – then let it be made on technical grounds – not on the actions of others who have not made statements about their own motivations.

Andrew

From: Robert Raszuk <[email-masked]>
Sent: Friday, 8 May 2020 13:33
To: Andrew Alston <[email-masked]>
Cc: Ron Bonica <rbonica=[email-masked]>; Darren Dukes (ddukes) <ddukes=[email-masked]>; Krzysztof Szarkowicz <[email-masked]>; 6man <[email-masked]>
Subject: Re: Routing Header Insertion

Hey Andrew,

I don't think the point is on what one vendor desires or likes. The point is that they internally committed development resources to deliver this functionality. They also asked one of their top talented TME Krzysiek to go and demo it. It carries a message. And all Zafar and others did was just sharing that message.

It really does not matter that much Ron himself or on behalf of his company can jump on the lists stating that he does not like it. Even if Juniper marketing will not push it - even if they develop next cartoon mocking it - they will still likely check mark support tag on the RFPs.

All that proves that SRH insertion is a useful feature to customers. And that's all what matters to some IETF decisions as part of that is community needs and support for extensions under standardization.

Best,
Robert.

On Fri, May 8, 2020 at 12:16 PM Andrew Alston <[email-masked]<mailto:[email-masked]>> wrote:
I do find it kinda bizarre that one vendor or an individual would jump to a conclusion and make statements about what another one desires – surely it is up to the vendor that desires something to publicly state so and not for someone else to make statements on their behalf?

I mean – let’s be clear – I have written a partial SRv6 / SRv6-NP implementation into our DPDK lab testing stack – I did it to verify certain things – the only thing it further convinced me  of is that I will never run this in production – in a million years – and I’d be rather concerned if someone went out there and said on the basis of the fact that I chose to test something – I suddenly supported or liked it.  What that’s effectively saying is – to test something is to support it – that’s not the case.  It’s similar to the line that I was given that because I signed a blue sheet in Singapore and didn’t stand up at the microphone and publically object to something at the time – some how my signature on the blue sheet indicated my acceptance and support of the issue in question.

(To quote that)

This is interesting – so firstly – let me state that because I was present in a meeting and signed a blue sheet to say I was there – in no way indicates that I forgo the right to object after the meeting – and last I checked, signatures on a blue sheet are there to track attendance, not to track consensus.

So – can I make a humble request that we let people speak for themselves about what they actively support and want rather than trying to speak for others to bolster our case?  Because if the case is so weak that we need to make claims on behalf of others – then there is no case at all.

Thanks

Andrew

---

From: Ron Bonica <[email-masked]>
Date: Fri, 8 May 2020 13:27:42 +0000

Folks,

Because my name and my company have been mentioned so many times in this thread, I feel obliged to respond. Yet, I have no interest in mud-slinging. So, I will mention a few principles that guide Juniper employees when participating in the IETF:

  *   IETF mailing lists are for technical discussion
     *   Demonstrate factual and intellectual honesty
     *   Treat all participants with respect
  *   IETF mailing list are not for marketing
     *   Never make a marketing or positioning statement on an IETF mailing list
     *   Never infer the intention or positioning of a competitor on an IETF mailing list

I consider all of the participants in this discussion to be good friends and I invite them to affirm these principles.

And then, my friends, let us return to technical discussion.

                                                                                             Ron

Juniper Business Use Only
From: Andrew Alston <[email-masked]>
Sent: Friday, May 8, 2020 6:56 AM
To: Robert Raszuk <[email-masked]>
Cc: Ron Bonica <[email-masked]>; Darren Dukes (ddukes) <[email-masked]>; Krzysztof Szarkowicz <[email-masked]>; 6man <[email-masked]>
Subject: RE: Routing Header Insertion

Robert,

Actually - it proves precisely nothing until they state their motivations - and we have no right to read motivations into it.  We can ask them why they did it - we cannot assume and nor does anyone have the right to make statements about why they chose to do something outside of someone else.

The twisting of words that I have seen of late has really disturbed me.  Another classic case in point was where it was claimed by another opponent of a draft stated the need for architectural documents.  In fact what had been stated was very clear that the applications USING the protocol needed architectural drafts and this was merely a building block (and before I write this, I verified very clear that was what was originally said, with the individual stating it).  My point here is - the IETF says - every person who steps us is representing themselves as an individual.  It is not for us to ascribe motivations to others and then go forward and make claims about other peoples motivations.  Let us make our case on our own technical grounds.

I point out that within the IETF - each person is meant to represent themselves - and statements that imply motivations of others to bolster a case in my view, do nothing more than weaken the argument of those making them - because if the argument is strong - then let it be made on technical grounds - not on the actions of others who have not made statements about their own motivations.

Andrew

From: Robert Raszuk <[email-masked]<mailto:[email-masked]>>
Sent: Friday, 8 May 2020 13:33
To: Andrew Alston <[email-masked]<mailto:[email-masked]>>
Cc: Ron Bonica <rbonica=[email-masked]<mailto:rbonica=[email-masked]>>; Darren Dukes (ddukes) <ddukes=[email-masked]<mailto:ddukes=[email-masked]>>; Krzysztof Szarkowicz <[email-masked]<mailto:[email-masked]>>; 6man <[email-masked]<mailto:[email-masked]>>
Subject: Re: Routing Header Insertion

Hey Andrew,

Best,
Robert.

(To quote that)

Thanks

Andrew

---

From: "Joel M. Halpern" <[email-masked]>
Date: Fri, 8 May 2020 10:13:39 -0400

No Robert, a vendor sending something to an interoperability test does 
not prove that the feature is useful to anyone.  There are many possible 
interpretations / reasons / motivations.  And for Darren, from Cisco, to 
assert an interpretation for Juniper and its customers seems wrong to 
me.  If he did that to Ericsson, I would have reacted much more sharply 
than Ron did.

Yours,
Joel

On 5/8/2020 6:33 AM, Robert Raszuk wrote:
> 
> Hey Andrew,
> 
> I don't think the point is on what one vendor desires or likes. The 
> point is that they internally committed development resources to deliver 
> this functionality. They also asked one of their top talented 
> TME Krzysiek to go and demo it. It carries a message. And all Zafar and 
> others did was just sharing that message.
> 
> It really does not matter that much Ron himself or on behalf of his 
> company can jump on the lists stating that he does not like it. Even if 
> Juniper marketing will not push it - even if they develop next cartoon 
> mocking it - they will still likely check mark support tag on the RFPs.
> 
> *All that proves that SRH insertion is a useful feature to customers.* 
> And that's all what matters to some IETF decisions as part of that is 
> community needs and support for extensions under standardization.
> 
> Best,
> Robert.
> 
> 
> On Fri, May 8, 2020 at 12:16 PM Andrew Alston 
> <[email-masked] 
> <mailto:[email-masked]>> wrote:
> 
>     I do find it kinda bizarre that one vendor or an individual would
>     jump to a conclusion and make statements about what another one
>     desires – surely it is up to the vendor that desires something to
>     publicly state so and not for someone else to make statements on
>     their behalf?____
> 
>     __ __
> 
>     implementation into our DPDK lab testing stack – I did it to verify
>     certain things – the only thing it further convinced me  of is that
>     I will never run this in production – in a million years – and I’d
>     be rather concerned if someone went out there and said on the basis
>     of the fact that I chose to test something – I suddenly supported or
>     liked it.  What that’s effectively saying is – to test something is
>     to support it – that’s not the case.  It’s similar to the line that
>     I was given that because I signed a blue sheet in Singapore and
>     didn’t stand up at the microphone and publically object to something
>     at the time – some how my signature on the blue sheet indicated my
>     acceptance and support of the issue in question. ____
> 
>     __ __
> 
>     (To quote that)____
> 
>     __ __
> 
>     /PC2: The comment started because in the draft we had an example
>     that was assigning A:1::/32 as loopback interface for a router. This
>     is wrong (prefix length, documentation prefix,).//____/
> 
>     /This was fixed in revision 2 of the WG draft, published in
>     September 19^th 2019. The closure of this comment was presented by
>     me personally in IETF Singapore. Please refer to the slides. In
>     Singapore you were present (signed blue sheet) and did not had any
>     comment about such closure.//____/
> 
>     ///____/
> 
>     ///____/
> 
>     /This is interesting – so firstly – let me state that because I was
>     present in a meeting and signed a blue sheet to say I was there – in
>     no way indicates that I forgo the right to object after the meeting
>     – and last I checked, signatures on a blue sheet are there to track
>     attendance, not to track consensus.____/
> 
>     /__ __/
> 
>     __ __
> 
>     So – can I make a humble request that we let people speak for
>     themselves about what they actively support and want rather than
>     trying to speak for others to bolster our case?  Because if the case
>     is so weak that we need to make claims on behalf of others – then
>     there is no case at all.____
> 
>     __ __
> 
>     Thanks____
> 
>     __ __
> 
>     Andrew
> 
> 
> [email-masked]

---

From: "Voyer, Daniel" <[email-masked]>
Date: Fri, 8 May 2020 15:35:10 +0000

Hi Ron,

> Those need to be put at the end of the line, so that they are visited *after* the nodes in the repair path.

Exactly as defined in the pseudocode. https://tools.ietf.org/html/draft-filsfils-spring-srv6-net-pgm-insertion-00#section-3.2

Just to also remind you the context of this email is SRH insertion for TI-LFA as demonstrated by Juniper and other vendors in the EANTA report. Nothing to do with uSID solution.

It’s also nice to know, from the report - obviously, that it interop with the other vendor’s platform.

Thanks
dan

From: ipv6 <[email-masked]> on behalf of Ron Bonica <rbonica=[email-masked]>
Date: Thursday, May 7, 2020 at 1:46 PM
To: Robert Raszuk <[email-masked]>
Cc: 6man <[email-masked]>
Subject: RE: Routing Header Insertion

Robert,

                                                                             Ron

Hi Ron,

Thx,
R.

In the first case, when the packet already contains an SRH, TI-LFA with SRH insertion results in a single packet that contains two SRH’s. No reading of RFC 8200 allows this.

                                                                                                 Ron

---

From: Andrew Alston <[email-masked]>
Date: Fri, 8 May 2020 15:35:42 +0000

Hi Ron,

Thanks for your very magnanimous reply, and I think that the principles outlined below by yourself are solid.  I think if we can get back to discussing drafts purely on their technical merits - rather than the statements about what others want - it would certainly serve both the working group and the community at large better than the current situation.

Thanks

Andrew

From: Ron Bonica <[email-masked]>
Sent: Friday, 8 May 2020 16:28
To: Andrew Alston <[email-masked]>; Robert Raszuk <[email-masked]>
Cc: Darren Dukes (ddukes) <[email-masked]>; Krzysztof Szarkowicz <[email-masked]>; 6man <[email-masked]>
Subject: RE: Routing Header Insertion

Folks,

-        IETF mailing lists are for technical discussion

o   Demonstrate factual and intellectual honesty

o   Treat all participants with respect

-        IETF mailing list are not for marketing

o   Never make a marketing or positioning statement on an IETF mailing list

o   Never infer the intention or positioning of a competitor on an IETF mailing list

                                                                                             Ron

Robert,

Andrew

Hey Andrew,

Best,
Robert.

(To quote that)

Thanks

Andrew

---

From: Tony Przygienda <[email-masked]>
Date: Fri, 8 May 2020 08:36:59 -0700

I'm mildly surprised the adult supervision didn't stop in here yet and put
a tamper on the hot air blowing that seem to struggle with basic IETF
principles before the WG complete deteriorates into an extension of a
marketing organization ... RFC 1925 corollary 1) & 12)

-- tony

---

From: "Voyer, Daniel" <[email-masked]>
Date: Fri, 8 May 2020 15:46:21 +0000

On 2020-05-08, 10:13 AM, "ipv6 on behalf of Joel M. Halpern" <[email-masked] on behalf of [email-masked]> wrote:

    No Robert, a vendor sending something to an interoperability test does 
    not prove that the feature is useful to anyone.  

DV:As if vendors will take time & resources ($$$) to develop features that might not be useful to anyone and then go to the trouble of making public interop paper ??!!

Dan

    --------------------------------------------------------------------
    IETF IPv6 working group mailing list
    [email-masked]
    Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
    --------------------------------------------------------------------
    ------------------------------------------------------------------------------
    External Email: Please use caution when opening links and attachments / Courriel externe: Soyez prudent avec les liens et documents joints

---

From: Philip Homburg <[email-masked]>
Date: Fri, 08 May 2020 18:16:16 +0200

> DV:As if vendors will take time & resources ($$$) to develop features
> that might not be useful to anyone and then go to the trouble of
> making public interop paper ??!!

Maybe people can keep these kinds of discussions out 6man. This is a 
complete waste of my time and, I'm sure, many others.

---

From: "Voyer, Daniel" <[email-masked]>
Date: Fri, 8 May 2020 16:47:00 +0000

If it's a waste of your time ... just don't process it - why do we even need to know that ?!

The conversation started to side-track long ago

---

From: Erik Kline <[email-masked]>
Date: Fri, 8 May 2020 13:33:08 -0700

(Sometimes it's a bit hard to keep up with some of the faster-moving
threads, especially when the day job demands more focus.)

[ picking a random message in the stream to reply-all ]

I agree that we should conclude this particular thread.

Please, let us all take a breather and try to reset.  I wish everyone a
pleasant, restorative weekend.

I also apologise it took me this long to catch up.
-ek

---

From: Mark Smith <[email-masked]>
Date: Sat, 9 May 2020 09:34:31 +1000

> Yes, there are some very clever solutions that you and I understand. But will the guy in the NOC who doesn’t live and breath SR be able to figure it out the first time he sees it.

In some of these proposals, there doesn't seem to be any appreciation
of the operational importance of predictable, simple and obvious
operation (the principle of least surprise), compliance and
compatibility with existing and already widely deployed standards
compliant implementations, robustness against predictable faults like
partial hardware failures, operator misconfiguration or vendor
implementation bugs, nor the importance of being able to identifying
the cause of a fault as soon as possible and being able to rectify it
as quickly as possible once identified.

A mechanism being able to work in a test lab, or being interoperable
with another implementation in a test environment, doesn't provide any
evidence that it will be easy and simple to operate in a production
network with paying customers, nor quick to troubleshoot and fix when
it breaks.

Being able to be made to work and being interoperable with another
implementation are relatively low bars if the goal is production
network deployment. It works, but it may not work well.

Regards,
Mark.

> On Thu, May 7, 2020 at 7:03 PM Ron Bonica <rbonica=[email-masked]> wrote:
>
> Hi Daniel,
>
>
>
> When the packet already contains an SRH
> When the IPv6 Destination Address contains uSIDs
>
>
>
> The uSID block identifier is 32 bits long
> Each uSID is 16 bits long
> The end-of-carrier marker is also 16 bits long
>
>
>

---

From: "Chengli (Cheng Li)" <[email-masked]>
Date: Sat, 9 May 2020 11:35:46 +0000

Well, I don't know other vendors, but we may not do that. 

Time and resources are really important, and they should be used for developing what we want to provide for our customers.

Also, I will be excited for sure if my draft is implemented and demoed in inter-op test, that means a lot.

But anyway, fact is fact, opinion is opinion. We can let them be there together. 

We know the fact, and we have our opinions, that is it.

Best,
Cheng

-----Original Message-----
From: ipv6 [mailto:[email-masked]] On Behalf Of Voyer, Daniel
Sent: Friday, May 8, 2020 11:46 PM
To: Joel M. Halpern <[email-masked]>; Robert Raszuk <[email-masked]>
Cc: 6man <[email-masked]>; Darren Dukes (ddukes) <ddukes=[email-masked]>
Subject: RE: Routing Header Insertion

Dan