Re: [spring] Thoughts and concerns

[<[e-mail]>]

Andrew,

I think we have enough with technical discussions to be held on the so called ‘Beyond SRv6’ subjects.
I don’t think that commenting on non IETF documents or initiating a thread which has a possibility of been heated and which is not likely to bring progress with regards to the technical choices and directions that we want to follow, is going to be useful or a good use of everyone’s time.
I would rather encourage you to work on the next steps which have been proposed by the chairs during IETF 106.

Several solutions on the table. Need to be explicit about the goals and the costs of each proposal.
■ Authors are invited to explicit both in their document (short text)
https://datatracker.ietf.org/meeting/106/materials/slides-106-spring-sessa-chairs-slides

So regarding the document that you have quoted, or any document or video that you may find in the Internet, or any vendor roadmap that you may disagree with, I think that I would be more efficient that you engage with their authors or the representative of the companies you are working with (or not working with). I can hear that from an network operator standpoint, sourcing issues do exist, but this is not an IETF business. Coming back to a related comment that you previously made, the IETF has worked and standardized SR-MPLS for IPv6 prefixes/FEC. The fact that some vendors do not implement it (soon enough) is not a standard issue not something that the IETF can work on. In itself, it’s also not a (strong) reason for the IETF to work on another solution.


Regarding IETF protocol work, again, we have multiple solutions on the table. Let’s go a bit deeper with the technical discussions about the goal(s) and means proposed by each solution. Let’s see if we can identity the technical points that are worth discussing and try to gain consensus on that. Keeping in mind that both on the requirements and solutions aspects, tradeoffs are likely involved.
Let’s go further than ‘my solution is the best/simplest/more beautiful’. I’m even dreaming that we could go further than my solution is better on KPI/requirement X. (disregarding other KPI/requirements).


Ø  The forth bullet point is really interesting - because I have yet to see a last-call for this document on the mailing list - unless I missed it - which is explicitly required as per RFC2418 Section 3.2
If this is a point for spring chairs, that they have not yet initiated the last call, nearly a week after the IETF 106 meeting, ok, point taken.

Thank you,
--Bruno

From: spring [mailto:[e-mail]] On Behalf Of Andrew Alston
Sent: Thursday, November 28, 2019 4:27 PM
To: 'SPRING WG List'
Subject: [spring] Thoughts and concerns

Hi Guys,

I have some questions - I ran across a document which has me deeply concerned - that purports to be written by the authors of SRH and makes direct reference to this working group.  And since the claims in it are deeply worrying - I think its time to ask for some answers. I fully realize that well - what people publish outside of the IETF is probably no business of the IETF - but, a document that claims to be published by the authors of a draft - that makes false claims about the working groups very charter - that - concerns me.

The document itself can be found at: https://www.segment-routing.net/images/20191029-02-Update-on-SRv6-standardization-activities.pdf

Now - here is my issue

Firstly - the second bullet point in that document runs *DIRECTLY* contrary to what is stated in the spring charter - to quote the charter:

The Source Packet Routing in NetworkinG (SPRING) Working Group is the home of Segment Routing (SR) using MPLS (SR-MPLS) and IPv6 (SRv6).
SPRING WG serves as a forum to discuss SPRING networks operations, define new applications of, and specify extensions of Segment Routing
technologies.

The forth bullet point is really interesting - because I have yet to see a last-call for this document on the mailing list - unless I missed it - which is explicitly required as per RFC2418 Section 3.2

I am not going to bother with the rest of the document - because well - people are free to their own technical opinions - but it greatly bothers me when the authors of a draft are publishing what are in effect blatant untruths in order to promote their work - and I believe it should bother everyone in this working group when such appears.

Thanks

Andrew



_________________________________________________________________________________________________________________________

Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.

This message and its attachments may contain confidential or privileged information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.
Thank you.