On 12-Mar-20 05:06, Alexander Vainshtein wrote: > Darren, > > Lots of thanks for the clarification. > > > > However, I have several issues with your response: > > 1. The SRH draft is a 6MAN document. I am not sure if the provision for > new documents defining new SID types and their handling means that such > definitions can be done in the documents handled by other WGs,
They certainly can, because the decision point in the IETF is not the WG; it's the IESG, following an IETF Last Call. It's very common for one WG to build on the output of another. > especially since we see strong opposition to these changes from several > participants of the 6MAN WG. (To make it clear, I am not a 6MAN WG member, > and personally neutral about PSP - but I am worried about the IETF process) > > 2. The SRv6 Network Programming draft has a Normative reference to the > SRH draft, but it does not ever mentions that it updates it (not in the text > and not in the Metadata). An extension is not necessarily an "update". This is a weakness in our vocabulary, and there is a current proposal to change it: https://tools.ietf.org/html/draft-kuehlewind-update-tag > > 3. Section 4.3.1 of the SRH draft defines the behavior associated with > the SRv6 SID that */is locally instantiated/*, and explains that other SID > types may be defined. But PSP-flavored SIDs are NOT locally instantiated in > the penultimate node, they are instantiated in the ultimate node of the path. > Therefore (and I may be too literal in my interpretation of the SRH draft), I > think that the provision for new documents defining new SID types */only > applies to locally instantiated SIDs of the handling node/* and does not > cover the PSP case. I think this is governed by RFC8402, as I mentioned yesterday. > In my original email I have suggested to the PSP/USP proponents to post a > draft that updates the SRH one (or the RFC that hopefully soon will be > published) - and to run it thru the 6MAN WG in the usual manner. I understand > that his will take time, but I still think that this would be the most > appropriate way to resolve the current conflict that has already gone too far. I don't see how that would help, since the argument is about the interpretation of RFC8200 (and RFC4291), not about the SRH spec. Regards Brian > > > > Regards, > > Sasha > > > > Office: +972-39266302 > > Cell: +972-549266302 > > Email: alexander.vainsht...@ecitele.com > > > > *From:*Darren Dukes (ddukes) <ddu...@cisco.com> > *Sent:* Wednesday, March 11, 2020 4:44 PM > *To:* Alexander Vainshtein <alexander.vainsht...@ecitele.com> > *Cc:* Ted Lemon <mel...@fugue.com>; Fernando Gont <ferna...@gont.com.ar>; > SPRING WG List <spring@ietf.org>; 6...@ietf.org; > draft-ietf-spring-srv6-network-programming > <draft-ietf-spring-srv6-network-programm...@ietf.org> > *Subject:* Re: [spring] Request to close the LC and move forward//RE: WGLC - > draft-ietf-spring-srv6-network-programming > > > > Hi Sasha, > > > > I think this question got lost in the other emails around this time. Thanks > for asking though and, let me clarify. > > > > The SRH doc was built with section 4.3.1 > <https://clicktime.symantec.com/3LLGD1Uzfhu26ZSxmbnqzXQ6H2?u=https%3A%2F%2Ftools.ietf.org%2Fhtml%2Fdraft-ietf-6man-segment-routing-header-26%23section-4.3.1> > stating: > > "Future documents may define additional SRv6 SIDs. In which case, the entire > > content of this section will be defined in that document.” > > > > > > So draft-ietf-6man-segment-routing header explicitly gives other documents > the ability to fully define new SIDs. > > In those documents the behavior of those SIDs would be fully defined, > regardless of the text in section 4.3.1. > > > > draft-ietf-spring-srv6-network-programming is one of those documents, there > are others that are and will be written defining new SID behaviors and their > processing, this was expected and is necessary for the definition of new SIDs > and their behaviors. > > > > Thanks, > > Darren > > > > > > > > > > On Feb 27, 2020, at 8:27 AM, Alexander Vainshtein > <alexander.vainsht...@ecitele.com <mailto:alexander.vainsht...@ecitele.com>> > wrote: > > > > Hi all, > > I cannot say whether PSP is allowed or disallowed by RFC 8200. > > > > But, to the best of my understanding, format of SRH and its handling are > specified by the IPv6 Segment Routing Header > <https://clicktime.symantec.com/3UnfQgAfW5ZSe3uASGKwXGq6H2?u=https%3A%2F%2Ftools.ietf.org%2Fhtml%2Fdraft-ietf-6man-segment-routing-header-26> > draft that is owned by the 6MAN WG and */is already in the RFC Editor > queue/*. Specifically, handling of the SRH by the Segment End Point ((of > which PSP is a special use case) is defined in Section 4.3.1.1 and says: > > > > S01. When an SRH is processed { > > S02. If Segments Left is equal to zero { > > S03. Proceed to process the next header in the packet, > > whose type is identified by the Next Header field in > > the Routing header. > > S04. } > > S05. Else { > > S06. If local configuration requires TLV processing { > > S07. Perform TLV processing (see TLV Processing) > > S08. } > > S09. max_last_entry = ( Hdr Ext Len / 2 ) - 1 > > S10. If ((Last Entry > max_last_entry) or > > S11. (Segments Left is greater than (Last Entry+1)) { > > S12. Send an ICMP Parameter Problem, Code 0, message to > > the Source Address, pointing to the Segments Left > > field, and discard the packet. > > S13. } > > S14. Else { > > S15. Decrement Segments Left by 1. > > S16. Copy Segment List[Segments Left] from the SRH to the > > destination address of the IPv6 header. > > S17. If the IPv6 Hop Limit is less than or equal to 1 { > > S18. Send an ICMP Time Exceeded -- Hop Limit Exceeded in > > Transit message to the Source Address and discard > > the packet. > > S19. } > > S20. Else { > > S21. Decrement the Hop Limit by 1 > > S22. Resubmit the packet to the IPv6 module for transmission > > to the new destination. > > S23. } > > S24. } > > S25. } > > S26. } > > > > I.e., 6MAN WG did not define any special processing of the SRH by the > penultimate segment endpoint. And the processing it has defined in the > ultimate segment endpoint does not mention removal of the SRH either. > > > > I do not think that SPRING WG can change these definitions by and of > itself. If PSP is so important, a new individual draft updating the (yet > unpublished) RFC defining the SRH has to be submitted and discussed in the > 6MAN WG in accordance with the normal IETF process. > > > > My 2c, > > Sasha > > > > Office: +972-39266302 > > Cell: +972-549266302 > > Email: alexander.vainsht...@ecitele.com > <mailto:alexander.vainsht...@ecitele.com> > > > > -----Original Message----- > From: spring <spring-boun...@ietf.org <mailto:spring-boun...@ietf.org>> > On Behalf Of Ted Lemon > Sent: Thursday, February 27, 2020 3:04 PM > To: Fernando Gont <ferna...@gont.com.ar <mailto:ferna...@gont.com.ar>> > Cc: 6...@ietf.org <mailto:6...@ietf.org>; SPRING WG List <spring@ietf.org > <mailto:spring@ietf.org>>; Maojianwei (Mao) <maojian...@huawei.com > <mailto:maojian...@huawei.com>>; draft-ietf-spring-srv6-network-programming > <draft-ietf-spring-srv6-network-programm...@ietf.org > <mailto:draft-ietf-spring-srv6-network-programm...@ietf.org>> > Subject: Re: [spring] Request to close the LC and move forward//RE: WGLC > - draft-ietf-spring-srv6-network-programming > > > > This is really not helpful, Fernando, and goes some way toward explaining > why communication isn’t happening. > > > > What I reacted to in Brian’s message is that he asked a really simple > question that could be readily answered with a pointer to the text in the > document where the answer is given. Since the response was instead to > explain in email, that tells me that the spec is incomplete. > > > > Separately, Brian mentioned that there is an issue with RFC8200 that > would require an update, that discussions had occurred around this, but then > the work never happened. It’s reasonable to raise an objection to > proceeding with work that depends on other work that hasn’t been done. > > > > What I objected to in Maojianwei’s comment is the notion that the > document should pass last call to support the industry. No, the working > group should do the work to address the objections that have been raised. > If you find yourself explaining some concept that’s mentioned in the document > using text that is not in the document and not in another document referenced > by the document, the fix is not to just publish anyway, because it supports > the industry. The fix is to update the document. A dozen or so +1s should > not be taken seriously if the work has not been done and nobody wants to do > it. > > > > > On Feb 27, 2020, at 6:11 AM, Fernando Gont <ferna...@gont.com.ar > <mailto:ferna...@gont.com.ar>> wrote: > > > > > > On 27/2/20 07:27, Ted Lemon wrote: > > >> The IETF serves users, not “industry”. The IETF does not promote. Our > job is to make the internet work interoperably. Brian has raised an objection > that could be answered, but has not been. It is inappropriate to say that > this document has passed last call. > > >> In my experience, when it is hard to get consensus in situations like > this it is because there is a wish to not address a concern that has been > raised, not because the concern could not be addressed or should not have > been raised. It may feel unreasonable, and like an imposition, but it is not. > It is part of the process. > > >> Rather than trying to steamroll over the objection, why not simply > answer it? > > > > > > As a service to the community, let me explain: > > > > > > Essentially, and for some reason, they seem to be meaning to circumvent > specs and processes. > > > > > > One of their last inventions has been to pretend that IPv6 allows EH > insertion/deletion en-route, based on their reading of RFC8200. Based on a > curious interpretation of the text, they claim that each waypoint > (intermmediate router that received the packet because its address was set as > de Destination Address) can insert/remove EHs, and they claim that that's not > a violation of RFC8200. > > > > > > However, the PSP behavour doesn't even fit in that fictional > interpretation of RFC8200. > > > > > > What PSP does is that, given: > > > > > > ---- B ----- C > > > > > > > > > routers, when B realizes, after processing the SRH and setting the Dest > Addr to the last segment, SegmentsLeft==0, it removes the SRH. > > > > > > This case is not even covered by their fictional interpretation of > RFC8200. > > > > > > Hence the question is avoided, u<because thye would have no option than > admiting they are violating RFC8200..unless... who knows... there might be > yet another curious interpretation of the spec that allows it. > > > > > > > > > It should eb evident here that the strategy is not really to follow > IETF process, gain consensus, formally update specs if/where needed, but > rather push whatever they publish, at whatever cost, ignoring the issues > raised in this wg, and circumventing IETF process. > > > > > > The fact that this behavior is allowed seems to be unfair with > participants, and a dis-service to the group. > > > > > > Thanks, > > > -- > > > Fernando Gont > > > e-mail: ferna...@gont.com.ar <mailto:ferna...@gont.com.ar> || > fg...@si6networks.com <mailto:fg...@si6networks.com> PGP Fingerprint: > > > 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1 > > > > > > > > > > > > > _______________________________________________ > > spring mailing list > > spring@ietf.org <mailto:spring@ietf.org> > > > https://clicktime.symantec.com/a/1/o-dBN-ZJMARHA7wJjIE7olF-RwnUUzVtRfXwdFqzmq0=?d=atw_kIqYFUZmbITw7iRdx05oul7SqRcF_hk-ksY2RXOVWKrcCK0_wLPVA5oOx3wxd3LHRWzwabnrklpMwnJcysKDzB7ZAlgkvkI_TBgMOmmWYTmUi7Cm9DeRzA9j6wTSFHHT2weAR7rEioVw_JRBIGcaxmodH6_sktn84eDFcI7b-TIpjSTD5gU0KWBiQuDvf1fgXAGOMtYb2BcOlbUxU6OvpXZ6eEmX0ugTpLkPxEZFSk2oe1Z9fA9GHFrSipsTECbnE9i46sWaYjDh7GATRMJrjPz08XHrqoPpRB7Hsm9rjbmV88d0ZyolqYLMiUxJbp5amhzqx_c2BeMoCNWWvFXQvMuI7SjxdfYP_1Gl0kSP848JuUk6nscdAGk9674LMjiQnz9vnahy-HtQGjQKqurWyHUm6-Tz1xtmpxiRiHJNYk2yxwQqWOUECBStdTdJLvRtWygm6L4Af-pDvPecd5eBAZ-N2ZNF2MODlL14q3R4Ewbq5YIX0rNIi1WDxNdv8YnDaK-qKbLgGNwUcBpswtWNGkMPNLYy0mNNlvCPHw%3D%3D&u=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fspring > > > > ___________________________________________________________________________ > > This e-mail message is intended for the recipient only and contains > information which is > CONFIDENTIAL and which may be proprietary to ECI Telecom. If you have > received this > transmission in error, please inform us by e-mail, phone or fax, and then > delete the original > and all copies thereof. > > ___________________________________________________________________________ > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > i...@ietf.org <mailto:i...@ietf.org> > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > <https://clicktime.symantec.com/38hWJKXwHtJe4zsy3VGGagg6H2?u=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fipv6> > -------------------------------------------------------------------- > > > > > ___________________________________________________________________________ > > This e-mail message is intended for the recipient only and contains > information which is > CONFIDENTIAL and which may be proprietary to ECI Telecom. If you have > received this > transmission in error, please inform us by e-mail, phone or fax, and then > delete the original > and all copies thereof. > ___________________________________________________________________________ > > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > i...@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- > _______________________________________________ spring mailing list spring@ietf.org https://www.ietf.org/mailman/listinfo/spring
