Subject: Re: [spring] Request to close the LC and move forward//RE: WGLC - draft-ietf-spring-srv6-network-programming

From: "Maojianwei (Mao)" <[email-masked]>
Date: Thu, 27 Feb 2020 09:30:19 +0000

Hi friends,

Internet standard is aimed to promote deployment and innovation, but not to be a barrier.

While this WG LC has been extended again and again,
if we have reached an agreement that SRv6 can bring many advantages for our network in future,
we should shelve the dispute and promote industry.

Meanwhile, we can have a discussion in the future about how to resolve the problem, bis 8200 or what else.

So, I agree we close the WG LC now, and go ahead.

Cheers~
Mao

发件人: spring [mailto:[email-masked]] 代表 Lizhenbin
发送时间: 2020年2月26日 19:55
收件人: [email-masked]; 'SPRING WG List' <[email-masked]>
抄送: [email-masked]; draft-ietf-spring-srv6-network-programming <[email-masked]>
主题: [spring] Request to close the LC and move forward//RE: WGLC - draft-ietf-spring-srv6-network-programming

Hi Bruno and WG,
The LC has lasted for almost 3 months which greatly exceeds the expected 2 week. In the process all the comments have been resolved while some issues is raised again and again with little value.
On the other hand, there have been multiple commercial implementation and inter-op test and almost 20 deployments for SRv6 which justify the solution proposed by the draft in practice.

We sincerely request to close the LC of the draft and move forward.

Best Regards,
Zhenbin (Robin)

From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]]
Sent: Friday, December 06, 2019 1:15 AM
To: 'SPRING WG List' <[email-masked]<mailto:[email-masked]>>
Cc: [email-masked]<mailto:[email-masked]>; draft-ietf-spring-srv6-network-programming <[email-masked]<mailto:[email-masked]>>
Subject: WGLC - draft-ietf-spring-srv6-network-programming

Hello SPRING,

This email starts a two weeks Working Group Last Call on draft-ietf-spring-srv6-network-programming [1].

Please read this document if you haven't read the most recent version, and send your comments to the SPRING WG list, no later than December 20.

You may copy the 6MAN WG for IPv6 related comment, but consider not duplicating emails on the 6MAN mailing list for the comments which are only spring specifics.

If you are raising a point which you expect will be specifically debated on the mailing list, consider using a specific email/thread for this point.

This may help avoiding that the thread become specific to this point and that other points get forgotten (or that the thread get converted into parallel independent discussions)

Thank you,

Bruno

[1] https://tools.ietf.org/html/draft-ietf-spring-srv6-network-programming-05

_________________________________________________________________________________________________________________________

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.

---

From: Ted Lemon <[email-masked]>
Date: Thu, 27 Feb 2020 05:27:25 -0500

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?

> On Feb 27, 2020, at 04:30, Maojianwei (Mao) <[email-masked]> wrote:
> 
> 
> Hi friends,
>  
> From: [email-masked] [mailto:[email-masked]] 
> To: 'SPRING WG List' <[email-masked]>
> Cc: [email-masked]; draft-ietf-spring-srv6-network-programming <[email-masked]>
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> [email-masked]
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------

---

From: Andrew Alston <[email-masked]>
Date: Thu, 27 Feb 2020 10:35:25 +0000

The problem is – I’m not convinced we have reached such an agreement – far from it.

My view on this is that – and I have stated this many times – I have no problem with the standard moving forward – providing that it does not violate other well defined standards (rfc8200 etc)

I also as I have stated multiple times – and which have never been addressed have concerns about

  1.  The burn of address space required to adequately deploy some of this (something that there was agreement on in Montreal that there would be analysis on – which was never done)
  2.  The potential problems we could run into as regards RFC7112 in deep SID stack environments
  3.  The inflation of the IGP created by the fact that you now need to run both your normal loopbacks and your SID’s

Points (a) through (c) though – are all things that I can kinda live with going into the standard – why – because I view this standard as overly complex, an operational nightmare, and nothing I will ever run on my network – but I accept that others may wish to use this and deal with those issues as they come up and each network should make its own decisions.  What I cannot however live with – is the violation of rfc8200 which could cause unintended side effects.

And so – while I do not stand opposed to this moving forward if the violations of other RFC’s are resolved – in no way shape or form can it be said that myself, and several others, believe that this brings advantages to our environments – indeed – I would argue it would bring an absolute nightmare and as such – I can say categorically that even if it proceeds – it won’t be deployed on my network.

(Please refer to https://mailarchive.ietf.org/arch/msg/ipv6/AaK6S2IOjWGQWbOT3bvv53U7EMc/ for more of my thoughts on this issue)

Andrew

From: ipv6 <[email-masked]> On Behalf Of Maojianwei (Mao)
Sent: Thursday, 27 February 2020 12:30
To: Lizhenbin <[email-masked]>; [email-masked]; 'SPRING WG List' <[email-masked]>
Cc: [email-masked]; draft-ietf-spring-srv6-network-programming <[email-masked]>
Subject: RE: Request to close the LC and move forward//RE: WGLC - draft-ietf-spring-srv6-network-programming

Hi friends,

Cheers~
Mao

发件人: spring [mailto:[email-masked]] 代表 Lizhenbin
发送时间: 2020年2月26日 19:55
收件人: [email-masked]<mailto:[email-masked]>; 'SPRING WG List' <[email-masked]<mailto:[email-masked]>>
抄送: [email-masked]<mailto:[email-masked]>; draft-ietf-spring-srv6-network-programming <[email-masked]<mailto:[email-masked]>>
主题: [spring] Request to close the LC and move forward//RE: WGLC - draft-ietf-spring-srv6-network-programming

Hi Bruno and WG,

Best Regards,
Zhenbin (Robin)

Hello SPRING,

Thank you,

Bruno

[1] https://tools.ietf.org/html/draft-ietf-spring-srv6-network-programming-05<https://tools.ietf.org/html/draft-ietf-spring-srv6-network-programming-05>

Thank you.

---

From: Fernando Gont <[email-masked]>
Date: Thu, 27 Feb 2020 08:11:08 -0300

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

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: [email-masked] || [email-masked]
PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1

---

From: "Xiejingrong (Jingrong)" <[email-masked]>
Date: Thu, 27 Feb 2020 12:05:09 +0000

However, the PSP behavour doesn't even fit in that fictional interpretation of RFC8200.

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

RFC8200:
   Extension headers (except for the Hop-by-Hop Options header) are not
   processed, inserted, or deleted by any node along a packet's delivery
   path, until the packet reaches the node (or each of the set of nodes,
   in the case of multicast) identified in the Destination Address field
   of the IPv6 header.

Isn't the word 'reaches' clear? A packet with the destination address owing to node B 'reaches' the node B. 

How can this be claimed again violation 8200 after 2 months? 

I remember that, Bob, Joel and many others had clarified this very clearly 2 months before, which led to the errata, saying 'clarifying' 8200.

----look at the errata----
Section 4 says:
   Extension headers (except for the Hop-by-Hop Options header) are not
   processed, inserted, or deleted by any node along a packet's delivery
   path, until the packet reaches the node (or each of the set of nodes,
   in the case of multicast) identified in the Destination Address field
   of the IPv6 header.
It should say:
   Extension headers (except for the Hop-by-Hop Options header, or a 
   Destination Options header preceding a Routing header) are not processed,
   inserted, or deleted by any node along a packet's delivery path, until the
   packet reaches the final destination node (or each of the set of final
   destination nodes, in the case of multicast).

So do you think the RFC8200 had made so big a mistake without awareness of the distinction of 'destination' and 'final destination' for 25 years since 1883 ?
And the folks that had been participated in the meantime had been made the same mistake for 25 years since 1883?
I can find the word 'reaches', 'destination' and 'final destination' in RFC1883 clearly, and I assume this distinction had been well aware of since 1883.

Thanks
Jingrong

---

From: "Voyer, Daniel" <[email-masked]>
Date: Thu, 27 Feb 2020 12:45:02 +0000

+1 !

Sent from my mobile

Hi friends,

Cheers~
Mao

Hi Bruno and WG,

Best Regards,
Zhenbin (Robin)

Hello SPRING,

Thank you,

Bruno

Thank you.

--------------------------------------------------------------------
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: "Voyer, Daniel" <[email-masked]>
Date: Thu, 27 Feb 2020 13:02:04 +0000

On Feb 27, 2020, at 05:27, Ted Lemon <[email-masked]> wrote:

The IETF serves users, not “industry”.
Wrong - it’s not the users that fund you to be here, it’s the industry - everything is about the money
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.
You should rephrase that - 1 objection can’t prevent the rest of us to move forward hence why sometime we need to go with a rough consensus.

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.
Yep, rough consensus

Clearly in this thread, along with the few presentations out there, there is more than 10 vendors that has implementation of SRv6, which is time and money invested, and there’s few operators running this already (time & money), so its in the field already. I expect the working to be conscious of that and “quickly” resolved this situation.

Dan

It may feel unreasonable, and like an imposition, but it is not. It is part of the process.

Hi friends,

Cheers~
Mao

Hi Bruno and WG,

Best Regards,
Zhenbin (Robin)

Hello SPRING,

Thank you,

Bruno

Thank you.

________________________________

---

From: Ted Lemon <[email-masked]>
Date: Thu, 27 Feb 2020 08:04:22 -0500

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

---

From: Ted Lemon <[email-masked]>
Date: Thu, 27 Feb 2020 08:08:46 -0500

> You should rephrase that - 1 objection can’t prevent the rest of us to move forward hence why sometime we need to go with a rough consensus.

Rough consensus means all the objections have been addressed, not that everyone agrees.  The situation here is that all the objections appear not to have been addressed, and that agreed-upon supporting work has not been done (and nobody wants to do it).

---

From: Alexander Vainshtein <[email-masked]>
Date: Thu, 27 Feb 2020 13:27:01 +0000

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://tools.ietf.org/html/draft-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:   [email-masked]

-----Original Message-----
From: spring <[email-masked]> On Behalf Of Ted Lemon
Sent: Thursday, February 27, 2020 3:04 PM
To: Fernando Gont <[email-masked]>
Cc: [email-masked]; SPRING WG List <[email-masked]>; Maojianwei (Mao) <[email-masked]>; draft-ietf-spring-srv6-network-programming <[email-masked]>
Subject: Re: [spring] Request to close the LC and move forward//RE: WGLC - draft-ietf-spring-srv6-network-programming

> On Feb 27, 2020, at 6:11 AM, Fernando Gont <[email-masked]<mailto:[email-masked]>> wrote:

> e-mail: [email-masked]<mailto:[email-masked]> || [email-masked]<mailto:[email-masked]> PGP Fingerprint:

> 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1

_______________________________________________

spring mailing list

[email-masked]<mailto:[email-masked]>

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

---

From: Andrew Alston <[email-masked]>
Date: Thu, 27 Feb 2020 13:27:33 +0000

Considering the discussion about how +1’s don’t mean much – I still feel that I need to +1 what Ted said in the below paragraph 😊

It seems to me that there is a belief that if you ignore objections long enough – and shout loud enough – the objections will some how disappear.

That if you promise things at a meeting – like the review of the amount of address space burn – and then do nothing – sooner or later – the issues will disappear.

Guess what – that isn’t the case – and if people truly want to get something passed – instead of playing a war of attrition – which seems to be what is going on here – they will actually go and do the work and address the concerns.

Andrew

---

From: Nick Hilliard <[email-masked]>
Date: Thu, 27 Feb 2020 13:55:31 +0000

Andrew Alston wrote on 27/02/2020 10:35:
>  1. The burn of address space required to adequately deploy some of this
>     (something that there was agreement on in Montreal that there would
>     be analysis on – which was never done)

I'm a bit alarmed by the lack of engagement here between the authors of 
this draft and the RIR community about addressing. This draft has the 
capacity to require significant changes to address allocation / 
assignment policy, but so far there's been no discussion about how this 
might work within current or future RIR allocation / assignment 
policies, or indeed upstream at IANA.  Could the authors provide some 
information on how they intend to approach this issue?

Nick

---

From: Stefano Salsano <[email-masked]>
Date: Thu, 27 Feb 2020 17:22:05 +0100

Fernando,

Il 2020-02-27 12:11, Fernando Gont ha scritto:

[... removed non-technical discussion]

> This case is not even covered by their fictional interpretation of RFC8200.

router B receives a packet whose DA belongs to B

in the pseudo code router B sets the DA of the packet to C before 
removing the SRH, this is only the description of the internal 
processing that happens in the router

this does *NOT* mean that router B can remove an SRH in a received 
packet in which the DA belongs to C

Stefano

[... removed non-technical discussion]

-- 
*******************************************************************
Stefano Salsano
Professore Associato
Dipartimento Ingegneria Elettronica
Universita' di Roma Tor Vergata
Viale Politecnico, 1 - 00133 Roma - ITALY

http://netgroup.uniroma2.it/Stefano_Salsano/

E-mail  : [email-masked]
Cell.   : +39 320 4307310
Office  : (Tel.) +39 06 72597770 (Fax.) +39 06 72597435
*******************************************************************

---

From: "Pablo Camarillo (pcamaril)" <[email-masked]>
Date: Thu, 27 Feb 2020 20:38:49 +0000

Nick,

The draft does not require changes to address assignment policy.
SRv6 has been already deployed using IPv6 addresses already available to the operator.
As an example for Softbank (all this is based on their public information that they have reported): 
They have a /20 IPv6 prefix available from ARIN. They have deployed SRv6 using only one millionth! of their /20 prefix. 

Cheers,
Pablo.

-----Original Message-----
From: ipv6 <[email-masked]> on behalf of Nick Hilliard <[email-masked]>
Date: Thursday, 27 February 2020 at 14:56
To: Andrew Alston <[email-masked]>
Cc: 'SPRING WG List' <[email-masked]>, "[email-masked]" <[email-masked]>
Subject: Re: Request to close the LC and move forward//RE: WGLC - draft-ietf-spring-srv6-network-programming

    
    Nick

---

From: "Pablo Camarillo (pcamaril)" <[email-masked]>
Date: Thu, 27 Feb 2020 20:38:48 +0000

Ted,

> The situation here is that all the objections appear not to have been addressed, and that agreed-upon supporting work has not been done (and nobody wants to do it).

Let me recall:
1.- draft-ietf-spring-srv6-network-programming contained a section about SRH insertion by a transit node
2.- There were objections on whether this is allowed
3.- There was an agreement of:
3.a.- Move the SRv6 behaviors that relied on SRH insertion by a transit node from the NET-PGM document into a new document
3.b.- Have the previous draft with a normative reference to a 6man draft where the details of Extension Header insertion by a transit node discussion would happen at 6man

3.a has been done (draft-filsfils-spring-srv6-net-pgm-insertion). This work is waiting progress on 3.b.
3.b. is work in progress in here (draft-voyer-6man-extension-header-insertion).

Neither 3.a nor 3.b are the object of the discussion that we are having here. 
The discussion that we are having is about PSP which has nothing to do with that.

I would suggest that before you jump to your conclusion you refer to the SPRING working group mailer archives where extensive discussions have happened resulting in draft updates to address comments. 

Cheers,
Pablo.

---

From: Ted Lemon <[email-masked]>
Date: Thu, 27 Feb 2020 15:54:49 -0500

> The discussion that we are having is about PSP which has nothing to do with that.

So, there is text in the document that addresses Brian’s question?

---

From: "Ketan Talaulikar (ketant)" <[email-masked]>
Date: Fri, 28 Feb 2020 04:25:43 +0000

Hi Ted,

I’ve tried to clarify Brian’s point : https://mailarchive.ietf.org/arch/msg/spring/rb23KclF_SKqRsnjvm82192vBZ8/

The draft under WGLC review in Spring WG already has pointers to all those drafts that I’ve mentioned.

Thanks,
Ketan

From: ipv6 <[email-masked]> On Behalf Of Ted Lemon
Sent: 28 February 2020 02:25
To: Pablo Camarillo (pcamaril) <[email-masked]>
Cc: [email-masked]; [email-masked]
Subject: Re: Request to close the LC and move forward//RE: WGLC - draft-ietf-spring-srv6-network-programming

On Feb 27, 2020, at 3:38 PM, Pablo Camarillo (pcamaril) <[email-masked]<mailto:[email-masked]>> wrote:
The discussion that we are having is about PSP which has nothing to do with that.