RE: Routing Header Insertion

[Andrew Alston <[e-mail]>]

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 <[e-mail]> On Behalf Of Ron Bonica
Sent: Thursday, 7 May 2020 20:26
To: Darren Dukes (ddukes) <ddukes=[e-mail]>; Krzysztof Szarkowicz <[e-mail]>
Cc: 6man <[e-mail]>
Subject: RE: Routing Header Insertion

Darren,

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

                                                                    Ron




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

[External Email. Be cautious of content]

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 <[e-mail]<mailto:[e-mail]>> wrote:

Also,

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

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

Thanks,
Krzysztof

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

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

From: ipv6 <[e-mail]<mailto:[e-mail]>> on behalf of "Eric Vyncke (evyncke)" <evyncke=[e-mail]<mailto:evyncke=[e-mail]>>
Date: Wednesday, May 6, 2020 at 7:08 AM
To: Ron Bonica <rbonica=[e-mail]<mailto:rbonica=[e-mail]>>, 6man <6man@ietf..org<mailto:[e-mail]>>
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 <[e-mail]<mailto:[e-mail]>> on behalf of Ron Bonica <rbonica=[e-mail]<mailto:rbonica=[e-mail]>>
Date: Wednesday, 6 May 2020 at 02:52
To: 6man <[e-mail]<mailto:[e-mail]>>
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
--------------------------------------------------------------------
IETF IPv6 working group mailing list
[e-mail]<mailto:[e-mail]>
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-$>
--------------------------------------------------------------------

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



Juniper Business Use Only