Subject: [spring] Spirit and Letter of the Law (was: Question about SRv6 Insert function)

From: Ron Bonica <[email-masked]>
Date: Wed, 4 Sep 2019 18:27:54 +0000

Ole,

Yes, a deep breath and some introspection are always a good thing.

First, I think that we need to make a distinction between the "spirit" and "letter" of the law. Next, we need to make a statement regarding good engineering practice.

RFC 8200 mandates some things. For example, In an IPv6 header, the source address must precede the destination address. Any attempt to reverse those two would violate the letter of the law.

By contrast, RFC 8200 strongly suggests other things. For example, transit nodes should not insert or delete extension headers. In general, these suggestions should be heeded. But exemptions can be granted, on a case-by-case basis, given that the motivation is strong, the risk is minimal, and there are no viable alternatives.

For better or worse, RFC 8200 does not use RFC 2119 language. So it is difficult to distinguish between the spirit and letter of the law. I think that is the genesis of the current debate.

Beyond that, we need to make a statement regarding good engineering practice. If a technology violates the spirit of RFC 8200 once, with good reason, that is fine. If it violates the spirit of RFC 8200 twice, we should all start asking questions. If it violates the spirit of RFC 8200 three times, and promises to do so again in the future, we should start to question whether that technology is building on RFC 8200 or trying to redefine it.
                                                                                             Ron

Juniper Business Use Only

-----Original Message-----
From: Ole Troan <[email-masked]> 
Sent: Wednesday, September 4, 2019 2:58 AM
To: Fernando Gont <[email-masked]>
Cc: Suresh Krishnan <[email-masked]>; Ron Bonica <[email-masked]>; [email-masked]; [email-masked]; draft-voyer-6man-extension-header-insertion <[email-masked]>; draft-ietf-spring-srv6-network-programming <[email-masked]>
Subject: Re: Question about SRv6 Insert function

[ snip ]
I would prefer that we calmed down a bit on the protocol policing.

[ snip ]

---

From: Fernando Gont <[email-masked]>
Date: Thu, 5 Sep 2019 04:23:28 +0300

On 4/9/19 21:27, Ron Bonica wrote:
> By contrast, RFC 8200 strongly suggests other things. For example, transit nodes should not insert or delete extension headers.

I don't think it "suggests" this. It clearly forbids it.

> In general, these suggestions should be heeded. But exemptions can be granted, on a case-by-case basis, 

An exception about this would be a major change regarding what IPv6 is
and its operation.

> For better or worse, RFC 8200 does not use RFC 2119 language. So it is difficult to distinguish between the spirit and letter of the law.

I think you can talk about spirit when there's room for interpretation,
or the text is not clear.

I don't think there's any of that in RFC8200 regarding EH insertion
being forbidden.

In fact, we added the text we added to make it clear that it was forbidden.

> Beyond that, we need to make a statement regarding good engineering practice.

I would like to contribute one: if one is to get into publishing specs,
new specs should comply with the specs they depend on (i.e. the
normative references). That means:

1) Don't violate other specs, or,
2) If you strongly feel like it, you first update the target spec, so
that you behave nicely (you eventually comply with it).

> If a technology violates the spirit of RFC 8200 once, with good reason, that is fine. 

I tend to differ here. If a technology is violating an aspect of a spec
on which we spend a long time and energy, that's not fine.

If we (IETF) do it, that would seem to be an indication of issues in the
standardization process -- we publishing specs that not even us comply
with doesn't seem to look nice.

Doing this kind of major surgery (EH insertion) after elevating IPv6 to
"Internet Standard" would bring another set of uncomfortable questions.

Thanks,
-- 
Fernando Gont
SI6 Networks
e-mail: [email-masked]
PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492

---

From: li zhenqiang <[email-masked]>
Date: Thu, 5 Sep 2019 02:58:30 +0000

Hello all,

I don't think we can infer from RFC 8200 that something is mandated and something is strongly suggested. If guys with different interests can infer from an "Internet Standard" what they are interested, the standard is ambiguous and deserves a bis.

If the standard is clear, we MUST obey it, especially for the result after intensive debates, do we need to repeat the discussion again?

Best Regards,
Zhenqiang Li
________________________________
[email-masked]

From: Fernando Gont<mailto:[email-masked]>
Date: 2019-09-05 09:23
To: Ron Bonica<mailto:rbonica=[email-masked]>; Ole Troan<mailto:[email-masked]>; Fernando Gont<mailto:[email-masked]>
CC: draft-voyer-6man-extension-header-insertion<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; Suresh Krishnan<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; draft-ietf-spring-srv6-network-programming<mailto:[email-masked]>
Subject: Re: Spirit and Letter of the Law (was: Question about SRv6 Insert function)

Thanks,

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

---

From: Ron Bonica <[email-masked]>
Date: Thu, 5 Sep 2019 03:01:18 +0000

Fernando, Zhenqiang,

You both have valid points. Maybe I am becoming too tolerant of deviations from the specification.

                                                                                   Ron

Juniper Business Use Only
From: li zhenqiang <[email-masked]>
Sent: Wednesday, September 4, 2019 10:59 PM
To: Fernando Gont <[email-masked]>; Ron Bonica <[email-masked]>; Ole Troan <[email-masked]>; Fernando Gont <[email-masked]>
Cc: draft-voyer-6man-extension-header-insertion <[email-masked]>; [email-masked]; Suresh Krishnan <[email-masked]>; [email-masked]; draft-ietf-spring-srv6-network-programming <[email-masked]>
Subject: Re: Re: Spirit and Letter of the Law (was: Question about SRv6 Insert function)

Hello all,

Best Regards,
Zhenqiang Li
________________________________
[email-masked]<mailto:[email-masked]>

On 4/9/19 21:27, Ron Bonica wrote:
> Ole,
>
> Yes, a deep breath and some introspection are always a good thing..
>

Thanks,
--
Fernando Gont
SI6 Networks
e-mail: [email-masked]<mailto:[email-masked]>
PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492

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

---

From: Ole Troan <[email-masked]>
Date: Thu, 5 Sep 2019 10:18:50 +0200

Dear Ron,

The IETF is not writing de jure standards.
In fact reality is quite different, and the Internet evolves the way it does somewhat independently of what documents the IETF produces.
In fact I know of no networking products (or deployments) that follow the intent and spirit of RFC8200. I challenge to point me to one! ;-)

Let me quote Tony Li's response to Fernando's escalation email to the architecture list:

"The fact of the matter is that the IETF is completely helpless to prevent such things. 
True, it can block standardization, but if the market wants it, the market will drive it
and all that the IETF does is to make itself irrelevant to the process."

My suggestion to Fernando was to argue the issues on technical merit.
Can you please explain why you don't do that?

- Does it break end to end transparency?
- Can end host protect their traffic with encryption or do the proposed mechanisms break that?
- How is PMTUD, ICMP errors, AH being handled?
- Does it break intereroperability?

Best regards,
Ole

> On 4 Sep 2019, at 20:27, Ron Bonica <[email-masked]> wrote:
> 
> Ole,
>

---

From: Fernando Gont <[email-masked]>
Date: Thu, 5 Sep 2019 14:59:07 +0300

> In fact I know of no networking products (or deployments) that follow the intent and spirit of RFC8200. I challenge to point me to one! ;-)

How did we elevate IPv6 to Internet Standard, then?  On the shepherd
write up for rfc2460bis, you argued essentially the opposite to what
you're arguing now:
https://datatracker.ietf.org/doc/draft-ietf-6man-rfc2460bis/shepherdwriteup/

Thanks,

---

From: Fernando Gont <[email-masked]>
Date: Thu, 5 Sep 2019 15:12:59 +0300

[...]
> and all that the IETF does is to make itself irrelevant to the process."

Even doing SRv6 does not need to imply doing EH insertion.

For instance, I just re-read
draft-voyer-6man-extension-header-insertion, and there's no comment
whatsoever why they don't address the same issues with encapsulation.

> My suggestion to Fernando was to argue the issues on technical merit.

The ietf consensus on this topic resulted from technical merit.

I don't think it's productive or even fair to simply ignore such
discussions and consensus, and ignore standards at will.

If you don't like the standard, make your case why you think it should
be updated, and work on it. The onus is on you to change the standard,
not on the standard to remain "as is".

> - Does it break end to end transparency?

Is IPv6 an end-to-end protocol if you allow EH-insertion in the middle
of a network?

Thanks,
-- 
Fernando Gont
e-mail: [email-masked] || [email-masked]
PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1

---

From: Ole Troan <[email-masked]>
Date: Thu, 5 Sep 2019 15:05:14 +0200

Fernando,

> https://datatracker.ietf.org/doc/draft-ietf-6man-rfc2460bis/shepherdwriteup/

I have not changed my position with regards to header insertion.
I'm arguing that you should argue technical merit on actual proposals.
Instead of trying to make RFC documents apply as laws and slap people over the head with those...

Cheers,
Ole

---

From: "Joel M. Halpern" <[email-masked]>
Date: Thu, 5 Sep 2019 09:11:50 -0400

Part of the reason we write restrictions and requirements into RFCs is 
so that we do not have to repeat the arguments.

If the proponents of the insertion have arguments for why it is now 
okay, they need to make those arguments.  And they need to make sure 
that the discussion is taken to the relevant working groups.  The burden 
should not be on those who are asking that attention be paid to existing 
RFCs.

Yours,
Joel

On 9/5/2019 9:05 AM, Ole Troan wrote:
> _______________________________________________
> spring mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/spring
>

---

From: Fernando Gont <[email-masked]>
Date: Thu, 5 Sep 2019 16:19:44 +0300

> I have not changed my position with regards to header insertion.

You seem to argue that following the spec closely doesn't matter,
because nobody does. I which case I wonder how we got to elevate IPv6 to
internet standard.

> Instead of trying to make RFC documents apply as laws and slap people over the head with those...

I think this is a misrepresentation of what's going on.

The only thing that I am asking is that the corresponding procedure is
followed, as opposed to circumvented. If IPv6 should allow header
insertion, and there is a very good rationale for that, so be it. But
the procedure should be to have such discussion, for folks to elaborate
why they dont't do encap/decap instead, and, if there is a good
rationale, update the IPv6 spec as appropriate. *Then*, and only then,
publish documents that assume you can fiddle with packets in the network.

What we have now is folks ignoring RFC8200, and violating its
requirements at will -- something that I don't think is the right way to
go, and certainly is not fair with all the folks that put energy in the
discussions that led to RFC8200.

The above procedure is what mere mortals like myself have followed in
6man to produce protocol improvements. -- unfortunately, at times we
have not been that lucky, and did get slapped with RFCs or "IPv6 has not
been designed to support that".. no matter the technical merits.

Thanks,

---

From: Ole Troan <[email-masked]>
Date: Thu, 5 Sep 2019 15:34:49 +0200

Joel,

> Part of the reason we write restrictions and requirements into RFCs is so that we do not have to repeat the arguments.
> 
> If the proponents of the insertion have arguments for why it is now okay, they need to make those arguments.  And they need to make sure that the discussion is taken to the relevant working groups.  The burden should not be on those who are asking that attention be paid to existing RFCs.

As far as I know, but I'm trying to stay away from the actual proposals and argue this generally, no-one is proposing to update the RFC8200 header insertion text.
What people are proposing are for specific domains. And given that, I believe people need to argue the technical merits of those specific proposals.
As opposed to throwing the "law book" around.

Best regards,
Ole

---

From: Fernando Gont <[email-masked]>
Date: Thu, 5 Sep 2019 16:46:08 +0300

> As opposed to throwing the "law book" around.

Se, please let me recap the history on this topic, for those that missed it:

1) EH insertion was originally proposed on the basis that RFC2460 wasn't
clear whether it was allowed or not.

2) Since we were doing rfc2460bis (now RFC8200), we incorporated text
into RFC8200 so that nobody could claim that the IPv6 spec is not clear
on this topic.

3) Now there's at least one I-D in spring that ignores RFC8200, and
proposes EH-insertion as if it was allowed, essentially circumventing
RFC8200, and IETF consensus.

I don't think it's in the spring wg's charter to specify how IPv6 works.
It should be done in 6man (or not even, because that's a major
modification, and not really "maintenance").

The only book I'm throwing is: proposals from big vendors should follow
the same procedures as those from mere mortals that don't happen to work
for a big vendor.

---

From: Tim Chown <[email-masked]>
Date: Thu, 5 Sep 2019 13:46:18 +0000

> On 5 Sep 2019, at 14:05, Ole Troan <[email-masked]> wrote:
> 

You made me look to see if I could find the heaviest RFC. It seems to be RFC 5661, at 615 pages, which I think would be 1.7kg if printed double sided A4.  

Tim

---

From: Fernando Gont <[email-masked]>
Date: Thu, 5 Sep 2019 16:52:45 +0300

> You made me look to see if I could find the heaviest RFC. It seems to be RFC 5661, at 615 pages, which I think would be 1.7kg if printed double sided A4.  

Jesus!  And I thought the HTTP spec was already too long! :-)

---

From: Tom Herbert <[email-masked]>
Date: Thu, 5 Sep 2019 07:17:51 -0700

Ole,

I don't believe the requirements of RFC8200 were ever intended to be
conditional based on the runtime environment. Either it's IPv6 or it's
not. I would be opposed to bifurcating standard protocols so that they
work differently in the open Internet versus a limited domain.

> As opposed to throwing the "law book" around.

This is isn't just throwing the law book around. Consider that
extension header insertion was proposed in
draft-voyer-6man-extension-header-insertion and there was much
discussion on the list. There were a number of very specific arguments
articulated why this is not robust and how this can break other
protocols. I don't see that the proponents of haven't provided counter
arguments. So I believe that the current consensus is that EH
insertion is not allowed, but that 's not just because RFC8200 says so
but also because there are material reasons why it's a bad idea. This
doesn't preclude the possibility of the EH insertion could be accepted
some day, but I don't see how that can happen unless the arguments
against it are addressed.

Tom

---

From: Enno Rey <[email-masked]>
Date: Thu, 5 Sep 2019 16:21:08 +0200

Hi Ole,

> >> In fact reality is quite different, and the Internet evolves the way it does somewhat independently of what documents the IETF produces.

one may then wonder: why does the IETF produce documents "for the Internet"? [A: maybe in some cases they don't, but for the interests of vendors being involved]

I've been in the IPv6 world for a while now, mostly with some distance to what's happening in the IETF. From that experience I can confirm that the [IPv6] Internet evolves "independently of what documents the IETF [here: 6man] produces". Let me still state that from such an outsider's perspective the whole debate around EH insertion for segment routing looks so blatantly obviously vendor-driven that 6man has completely lost its credibility in many circles being involved in deploying IPv6 in "the Internet". I know you folks don't rly care but mentioning 6man usually produces rolling eyes and quirky smiles. 
I understand that this e-mail does not argue on the grounds of technical merit, and it actually wastes more bandwidth, neutrons and life time of smart people reading this, in a debate which has already wasted *a lot* of those. May I hence ask for a response in a direct manner if you ever feel inclined to write one. thanks. 

Everybody have a great day

Enno

--
Enno Rey

---

From: Nick Hilliard <[email-masked]>
Date: Thu, 5 Sep 2019 15:23:52 +0100

> should not be on those who are asking that attention be paid to existing 

+1 on this.  there's been extensive discussion about this issue on 6man, 
and the onus is on the authors of 
draft-ietf-spring-srv6-network-programming to justify this change in 
behaviour in IPv6 specification rather than the other way around.

Nick

---

From: Robert Raszuk <[email-masked]>
Date: Thu, 5 Sep 2019 16:28:04 +0200

> RFC8200, and IETF consensus.

Incorrect. RFC8200 makes it black on white clear that insertion, deletion
and mangling is allowed in IPv6 if destination is yourself in the packet's
IPv6 outer header.

So functions to insert SRH or delete it discussed in SPRING DO NOT violate
anything.

Remember - in SRv6 you *change* IPv6 dst at each end of segment. So each SR
segment node can legally  do whatever it needs with EH.

Is this clear enough?

- - -

There is other individual document in 6man proposing a solution for FRR in
IPv6 which goes beyond the above. But it in no way that should impact base
specs. As written base specs can be used 100% legally according to RFC8200
as it stands today.

Now if 6man response to proposl of SRv6 use case for FRR with TI-LFA will
state "IPv6 was not designed for that" - I am fine. It will make IPv6
deployments for sure much more robust. It may even help end to end
principle shine again and get all of your end IPv6 compute and set-top
boxes full open to global hackers.

Thx,
R.

---

From: Fernando Gont <[email-masked]>
Date: Thu, 5 Sep 2019 17:35:19 +0300

On 5/9/19 17:28, Robert Raszuk wrote:
> Incorrect. RFC8200 makes it black on white clear that insertion,
> deletion and mangling is allowed in IPv6 if destination is yourself in
> the packet's IPv6 outer header.

You only get to create EHs if you are sourcing the packets. Period.

Either you are sourcing packets -- and hence you are not doing insertion
--, or you are not sourcing the packets, and hence are doing insertion.

And EH insertion is prohibited by RFC8200.

---

From: Fernando Gont <[email-masked]>
Date: Thu, 5 Sep 2019 17:42:28 +0300

[....]
> 
> Now if 6man response to proposl of SRv6 use case for FRR with TI-LFA
> will state "IPv6 was not designed for that" - I am fine.

As I have reiterated numerous times, nobody is arguing that.

My argument is: you can't simply violate specs at will. If you have a
strong case for updating any spec (IPv6, or any other), please
explicitly propose it at the WG chartered to do that. Then you can
proceed with the rest of the work.

I'm quite pragmatic, and have spent a lot of energy doing updates to the
IPv6 case when I felt I had a strong case to do so.

But most of what I've seen in terms of EH-insertion is essentially
trying to impose a vendor's agenda on everyone else, igonring standards
and IETF consensus at will.

*This* is what this discussion is about.

---

From: Philip Homburg <[email-masked]>
Date: Thu, 05 Sep 2019 16:42:13 +0200

>As far as I know, but I'm trying to stay away from the actual proposals and ar
>gue this generally, no-one is proposing to update the RFC8200 header insertion
> text.
>What people are proposing are for specific domains. And given that, I believe 
>people need to argue the technical merits of those specific proposals.

Maybe I missed it somewhere, but why is it so hard to publish an RFC that
updates RFC 8200? Is this a process failure that we cannot update an Internet
Standard?

One thing is that firewalls and other middle boxes routinely violate RFC 8200
by looking beyond the IPv6 header. It is bad to have specs that do not
reflect reality. I'm not aware of wide spread middle boxs that modify IPv6
packets, though there is some amount of NAT66.

In general, inserting new EHs is bad for the various reasons brought up in the
past. However, SR is a special case. And there is no reason we can't make an
exception for a specific situation.

However, somebody reading the IPv6 specs should not have an unexpected
surprise of reading RFC 8200 and then later finding that some nodes violate it
due to a completely unrelated RFC.

It is not that much work to add a section that officially updates RFC 8200.

---

From: Robert Raszuk <[email-masked]>
Date: Thu, 5 Sep 2019 16:46:20 +0200

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

So now please provide the quote from RFC8200 or any other IPv6 RFC
that says explicitly:

"You only get to create EHs if you are sourcing the packets. Period."

While there I am still waiting for an answer to the other question ...

if IPv6 packets can be legally encapsulated or not. Is encapsulation

not an event of sourcing effectively a new packet with some payload ?

Many thx,

R.

---

From: Fernando Gont <[email-masked]>
Date: Thu, 5 Sep 2019 18:05:52 +0300

>    in the case of multicast) identified in the Destination Address field

At the time the packet is created, the Destination Address of course
identifies the destination node.

The very speficication of the Routing Header says:
   The Routing header is used by an IPv6 source to list one or more
   intermediate nodes to be "visited" on the way to a packet's
   destination.

So each of those intermediate nodes are part of the packet delivery
path, and are not allowd to do EH insertion.

As noted, draft-ietf-spring-srv6-network-programming-01 has a normative
reference to voyer-6man-extension-header-insertion for a reason.

I hope things are clear now.

> not an event of sourcing effectively a new packet with some payload ? 

Yes. If you create a new packet, and you put your own address in the SA
of the packet, and encapsulate what you received in the IPv6 payload,
you're free to generate as many EHs as you wish.

Thanks,

---

From: Alexander Vainshtein <[email-masked]>
Date: Thu, 5 Sep 2019 15:42:47 +0000

Fernando,

With regard to the last statement in your email "If you create a new packet, and you put your own address in the SA of the packet, and encapsulate what you received in the IPv6 payload, you're free to generate as many EHs as you wish", do you see the need to comply with the 8200 recommendation that says

<quote>
   Each extension header should occur at most once, except for the
   Destination Options header, which should occur at most twice (once
   before a Routing header and once before the upper-layer header).

<end quote>

Regards,

Sasha

Office: +972-39266302

Cell:      +972-549266302

Email:   [email-masked]

-----Original Message-----
From: spring <[email-masked]> On Behalf Of Fernando Gont
Sent: Thursday, September 5, 2019 6:06 PM
To: Robert Raszuk <[email-masked]>
Cc: [email-masked]; [email-masked]; Ole Troan <[email-masked]>; Suresh Krishnan <[email-masked]>; Robert Raszuk <[email-masked]>; Joel M. Halpern <[email-masked]>
Subject: Re: [spring] Spirit and Letter of the Law (was: Question about SRv6 Insert function)

>    of the IPv6 header.

At the time the packet is created, the Destination Address of course identifies the destination node.

   destination.

So each of those intermediate nodes are part of the packet delivery path, and are not allowd to do EH insertion.

As noted, draft-ietf-spring-srv6-network-programming-01 has a normative reference to voyer-6man-extension-header-insertion for a reason.

> not an event of sourcing effectively a new packet with some payload ?

Yes. If you create a new packet, and you put your own address in the SA of the packet, and encapsulate what you received in the IPv6 payload, you're free to generate as many EHs as you wish.

Thanks,

--

Fernando Gont

SI6 Networks

spring mailing list

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

https://clicktime.symantec.com/38feYMbEeTFJDWxDfZN3pKM6H2?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: Fernando Gont <[email-masked]>
Date: Thu, 5 Sep 2019 06:26:02 +0300

Ron,

> deviations from the specification.

This is not a deviation in the spec. It's an outright violation of the spec.

This topic has a rich history in 6man, which I will summarize as follows:

1) Folks proposed the segment routing header I-D with the argument that
it wasn't clear whether EH-insertion was allowed in RFC2460 or not --
when it was clear to virtually everyone else that it was forbidden

2) The segment-routing header I-D was adopted on the condition that all
text related to EH insertion should be removed.

3) Since we were in the process of doing rfc2460bis, we had the
discussion to make the text crystal-clear that EH-insertion was
forbidden. -- in fact, it already was. But based on 1) we discussed to
make it 200% clear.

4) Some folks argued not to add text on the topic, leaving, from their
pov, the spec ambiguous. This "version" of rfc2460bis was shipped from
the wg.

5) During IETF LC of rfc2460bis, the issue was raised again, and there
was finally consensus to add very explicit text noting that EH insertion
is forbidden. And this became RFC8200.

My question to the spring wg chairs and routing area ADs therefore is:
how come the wg adopted a document (e.g.:
https://tools.ietf.org/html/draft-ietf-spring-srv6-network-programming-01)
when it contains outright violations of specs (RFC8200) that are not in
the charter of spring wg to update? (as far as I understand).

Thanks,

---

From: Mark Smith <[email-masked]>
Date: Thu, 5 Sep 2019 14:33:13 +1000

> You both have valid points. Maybe I am becoming too tolerant of deviations from the specification.

I think by definition RFCs are the authoritative definition of how
protocols and their implementations are to behave. I expect to be able
to use them to find out how implementations devices are to behave, or
to be able to use them to report bugs to vendors when the vendors'
devices aren't behaving per the RFC. An unofficial deviation from the
spec makes troubleshooting harder, and could significantly increase
the time to resolve a fault for a service critical to a paying
customer.

I've wondered if SPRING may be viewing MPLS and IPv6 are equivalent
utility protocols in the SR context, and therefore are unconsciously
thinking that re-purposing IPv6 fields or changing IPv6 processing and
behaviour both can be done and can be done as easily as it is possible
to do things like re-purpose the MPLS label field to carry SIDs.

There's quite a lot of significant differences between MPLS and IPv6,
even if both could be used for SR.

IPv6 is an end-to-end protocol talked by hosts. It's obviously not an
optional protocol for both hosts and network to have enabled if they
want to use IPv6 services. It isn't a local network protocol, it's
intended to operate end-to-end across the entire Internet, with all
devices involved complying with RFC8200 or its ancestors.

MPLS is optional in a network, usually limited to the network, is
rarely talked by hosts, and isn't talked by hosts by default. There's
much more scope to modify it and re-purpose it when it's a much more
limited domain protocol than IPv6.

These significant differences between MPLS and IPv6 are the reasons
why I think it is important that the use of IPv6 with SR complies with
the existing IPv6 standard RFC.

Regards,
Mark.

> From: Fernando Gont
> To: Ron Bonica; Ole Troan; Fernando Gont
>
> CC: draft-voyer-6man-extension-header-insertion; [email-masked]; Suresh Krishnan; [email-masked]; draft-ietf-spring-srv6-network-programming
>

---

From: <[email-masked]>
Date: Thu, 5 Sep 2019 14:46:13 +0000

Fernando,

> the charter of spring wg to update? (as far as I understand).

1) draft-ietf-spring-srv6-network-programming has a normative reference to [I-D.voyer-6man-extension-header-insertion].
As such, from a process standpoint, it's clear that it would not going to be published before [I-D.voyer-6man-extension-header-insertion] be published as RFC. And from its name, the latter is intended to be discussed and within control of the 6MAN WG.

2) When writing a specification (i.e. changing the standard), there is the question of whether we directly define the new behavior, or whether we need to motivate the change from a usage perspective. Aka do we need use cases documents or is this a waste of IETF time? When the point is difficult or subject to debate, the proposed change is easily dismissed based on the absence of a written need for that change.
Hence it looks to me reasonable that the SPRING WG explicitly states that SRH insertion would be useful, rather than some individual brings this to the 6MAN WG, individually claiming that it's useful for SR. If you are fine with this, AFAIK, this is done with a WG adoption.
Again, draft-ietf-spring-srv6-network-programming has a normative reference that would automatically block RFC publication. I'm not sure what additional safety you would want?
The SPRING WG is not to be point of asking publication of draft-ietf-spring-srv6-network-programming. It's in a WG for discussion. If your point is that you don't want the spring WG to discuss the usage of EH insertion, then you are welcome to contribute to the SPRING WG. And thank you for doing that.

--Bruno

> Thanks,

_________________________________________________________________________________________________________________________

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: Ron Bonica <[email-masked]>
Date: Thu, 5 Sep 2019 17:51:55 +0000

Robert,

I think that I can summarize what you are saying as follows:

  *   An IPv6 path contains a source node, a destination node, and transit nodes
  *   Some transit nodes are also segment endpoints. Segment endpoints are identified by either of the following:
     *   The initial value of the IPv6 address
     *   An entry in the segment list of the Routing header
  *   According to RFC 8200, segment endpoints can insert, change, or delete extension headers. However, transit nodes that are not segment headers cannot insert, change or delete extension headers

Have I read your email, below, correctly? Is this what you are actually saying?

                                                                  Ron

From: spring <[email-masked]> On Behalf Of Robert Raszuk
Sent: Thursday, September 5, 2019 10:28 AM
To: Fernando Gont <[email-masked]>
Cc: Suresh Krishnan <[email-masked]>; [email-masked]; Ole Troan <[email-masked]>; Joel M. Halpern <[email-masked]>; [email-masked]
Subject: Re: [spring] Spirit and Letter of the Law (was: Question about SRv6 Insert function)

Incorrect. RFC8200 makes it black on white clear that insertion, deletion and mangling is allowed in IPv6 if destination is yourself in the packet's IPv6 outer header.

So functions to insert SRH or delete it discussed in SPRING DO NOT violate anything.

Remember - in SRv6 you *change* IPv6 dst at each end of segment. So each SR segment node can legally  do whatever it needs with EH.

Is this clear enough?

- - -

There is other individual document in 6man proposing a solution for FRR in IPv6 which goes beyond the above. But it in no way that should impact base specs. As written base specs can be used 100% legally according to RFC8200 as it stands today.

Now if 6man response to proposl of SRv6 use case for FRR with TI-LFA will state "IPv6 was not designed for that" - I am fine. It will make IPv6 deployments for sure much more robust. It may even help end to end principle shine again and get all of your end IPv6 compute and set-top boxes full open to global hackers.

Thx,
R.

---

From: Robert Raszuk <[email-masked]>
Date: Thu, 5 Sep 2019 20:00:48 +0200

Hi Ron,

Nope that is not correct interpretation. Let me try to rephrase it ...

   - An IPv6 path contains a source node, a destination node, and transit
   nodes
   - Transit nodes belong to network operators which move the packets
   - When packet enters operator's network it can be encapsulated and new
   src, dst and any other elements added to its header - original packet
   becomes just the payload
   - Then new packet (and payload) is send within given domain via transit
   nodes.
   - Some transit nodes just do basic IPv6 forwarding, some may see
   themselves in the dst field of the packet imposed by ingress node.
   - If this is the case (when packet is received by segment endpoint)
   packets are processed as defined by SRv6 rules.
   - According to RFC 8200, segment endpoints can insert, change, or delete
   extension headers. However, transit nodes that are not segment nodes cannot
   insert, change or delete extension headers

Now that is more like what I highlighted few times already ...

Best,
R.

On Thu, Sep 5, 2019 at 7:52 PM Ron Bonica <rbonica=
[email-masked]> wrote:

>    - An IPv6 path contains a source node, a destination node, and transit
>    nodes
>    - Some transit nodes are also segment endpoints. Segment endpoints are
>    identified by either of the following:
>       - The initial value of the IPv6 address
>       - An entry in the segment list of the Routing header
>    - According to RFC 8200, segment endpoints can insert, change, or
>    delete extension headers. However, transit nodes that are not segment
>    headers cannot insert, change or delete extension headers
>
>
>
> *From:* spring <[email-masked]> *On Behalf Of *Robert Raszuk
> *Sent:* Thursday, September 5, 2019 10:28 AM
> *To:* Fernando Gont <[email-masked]>
> *Cc:* Suresh Krishnan <[email-masked]>; [email-masked]; Ole
> Troan <[email-masked]>; Joel M. Halpern <[email-masked]>;
> [email-masked]
> *Subject:* Re: [spring] Spirit and Letter of the Law (was: Question about
> SRv6 Insert function)
>
>
>
>
>
> Remember - in SRv6 you *change* IPv6 dst at each end of segment. So each
> SR segment node can legally  do whatever it needs with EH.
>
>
>
> Is this clear enough?
>
>
>
> - - -
>
>
>
> as it stands today..

---

From: Tom Herbert <[email-masked]>
Date: Thu, 5 Sep 2019 11:34:16 -0700

On Thu, Sep 5, 2019 at 11:01 AM Robert Raszuk <[email-masked]> wrote:
> An IPv6 path contains a source node, a destination node, and transit nodes
> Transit nodes belong to network operators which move the packets
> When packet enters operator's network it can be encapsulated and new src, dst and any other elements added to its header - original packet becomes just the payload
> Then new packet (and payload) is send within given domain via transit nodes.
> Some transit nodes just do basic IPv6 forwarding, some may see themselves in the dst field of the packet imposed by ingress node.
> If this is the case (when packet is received by segment endpoint) packets are processed as defined by SRv6 rules.
> According to RFC 8200, segment endpoints can insert, change, or delete extension headers. However, transit nodes that are not segment nodes cannot insert, change or delete extension headers
>
Robert,

That's an arbitrary interpretation of RFC8200. Even we were to accept
that, it still doesn't address the issues raised for extension header
insertion. For instance, I'd invite you do the thought experiment
about what happens when an intermediate node inserts a header that
causes the packet to exceed the MTU of some downstream forwarding
node. There is no robust protocol mechanism to deal with this. The
fact that the extension header in question happens to be segment
routing doesn't change things in this regard.

Tom

> R..
> On Thu, Sep 5, 2019 at 7:52 PM Ron Bonica <rbonica=[email-masked]> wrote:
>>
>> Robert,
>>
>>
>>
>> An IPv6 path contains a source node, a destination node, and transit nodes
>> Some transit nodes are also segment endpoints. Segment endpoints are identified by either of the following:
>>
>> The initial value of the IPv6 address
>> An entry in the segment list of the Routing header
>>
>> According to RFC 8200, segment endpoints can insert, change, or delete extension headers. However, transit nodes that are not segment headers cannot insert, change or delete extension headers
>>
>>
>>
>> There is other individual document in 6man proposing a solution for FRR in IPv6 which goes beyond the above. But it in no way that should impact base specs. As written base specs can be used 100% legally according to RFC8200 as it stands today...
>>
>>
>>

---

From: Fernando Gont <[email-masked]>
Date: Thu, 5 Sep 2019 18:57:42 +0300

On 5/9/19 18:31, Robert Raszuk wrote:
> Fernando,
> 
> I am taking you extremely seriously ! In fact some of your emails make
> me even worried. 
> 
> You say in one email that encapsulation is allowed and that the event of
> encapsulation is the same as sourcing. 
> 
> So please notice text in network programming draft which says: 
> 
>    This document defines the SRv6 Network Programming concept and aims
>    at standardizing the main segment routing functions to enable the
>    creation of interoperable *overlays*
> *
> *
> I am not sure what is your definition of an overlay is but to me the
> most common way to create an overlay of any sort is via encapsulation. 
> 
> I would not mix the use cases of net programming which apparently
> happened and generated so much confusion around. Sure it could be used
> also without encapsulation, but does it make it immediately illegal ? 

I'm lost here.

Again:

* draft-ietf-spring-srv6-network-programming has a normative reference
to draft-voyer-6man-extension-header-insertion

* draft-voyer-6man-extension-header-insertion is about EH insertion

* EH insertion is forbidden by RFC8200

We have wasted way too much time and energy with all the methafores and
curious interpretations of standards by folks pushing and/or supporting
EH insertion, really.

---

From: Fernando Gont <[email-masked]>
Date: Thu, 5 Sep 2019 19:06:44 +0300

On 5/9/19 18:42, Alexander Vainshtein wrote:
> Fernando,
> 
> With regard to the last statement in your email "If you create a new
> packet, and you put your own address in the SA of the packet, and
> encapsulate what you received in the IPv6 payload, you're free to
> generate as many EHs as you wish", do you see the need to comply with
> the 8200 recommendation that says
> 
>  
> 
> <quote>
> 

Of course. I was mostly meaning that if you encapsulate, then the
resulting packet can contain an EH, because you'd not be *inserting* and
EH in an existing packet, but rather creating a brand new one.

Of course, the rest of RFC8200 still applies.

---

From: Fernando Gont <[email-masked]>
Date: Thu, 5 Sep 2019 21:36:43 +0300

On 5/9/19 21:00, Robert Raszuk wrote:

>   * According to RFC 8200, segment endpoints can insert, change, or
>     delete extension headers. However, transit nodes that are not
>     segment nodes cannot insert, change or delete extension headers

Seriously?

The text in RFC8200 is there with respect to any intermmediate box.
segment endpoints, unless they encapsulate the packet in a new outer
packet, are still intermmediate systems.

Thanks,

---

From: Robert Raszuk <[email-masked]>
Date: Thu, 5 Sep 2019 21:20:20 +0200

Hi Tom,

> node.

Absolutely.

But SRH is meaningful only within a given domain.

At least I would worry much less about MTU being exceeded when you insert
EH as compared when you encapsulate with complete new header including EH,
DO etc ... which somehow everyone seems to be happy about. I am not seeing
much logic here.

Moreover if you look at telco transport today a lot of "circuits" are
emulated circuits which use encap in the middle of the transports which in
turn runs over their IP networks. How do you deal with such cases when one
day it works and when telco underly reroutes such that it goes via
bottleneck it does not ?

I am seeing this daily. We even wrote IETF drafts to detect this. Now the
BFD draft stuffing is a third attempt to have a tool to detect it. If IPv6
works end to end, hosts to hosts such MTU bottleneck should be part of the
IPv6 transport.

There is no robust protocol mechanism to deal with this.

That's a problem much bigger then SR. See when I am building transport over
third parties I use SLA probes which periodically validates not only SLA
data but also end to end max MTU. When I see an issue I choose
automatically different underlay path such that end applications do not
notice the issue.

Many thx,
R.

---

From: Robert Raszuk <[email-masked]>
Date: Thu, 5 Sep 2019 21:24:02 +0200

> curious interpretations of standards by folks pushing and/or supporting

Please notice that version -00 which was accepted by the WG does not have
such normative reference.

https://tools.ietf.org/html/draft-ietf-spring-srv6-network-programming-00

It is not even listed as informative reference.

So it can be removed tomorrow if it bothers you :)

Cheers,
R.

---

From: Ole Troan <[email-masked]>
Date: Thu, 5 Sep 2019 21:30:18 +0200

> On 5 Sep 2019, at 21:03, Fernando Gont <[email-masked]> wrote:
> 

Pot calling kettle black?

This is an issue we all know is there. And has to be resolved one way or the other. I am sure you will get ample opportunity to debate later. 

How this thread or discussing the topic on those terms adds value is beyond me. So I suggest we stop. 

Ole

---

From: Andrew Alston <[email-masked]>
Date: Thu, 5 Sep 2019 19:35:17 +0000

Even if you remove the reference – you still have problems in 4.13 and 4.21 which manipulate the headers.

I also point out that it’s rather hard to argue that headers aren’t being inserted when the network programming draft is explicitly mentioned as a normative reference for draft-ietf-lsr-isis-srv6-extensions-02 in section 4.3, and in there, it specifies a type to specify the maximum number of SID’s to be inserted as part of the T.insert behavior – as per section 5.2 – which explicitly refers to inserting SRH in transit.

Andrew

From: spring <[email-masked]> On Behalf Of Robert Raszuk
Sent: Thursday, 5 September 2019 22:24
To: Fernando Gont <[email-masked]>
Cc: 6man WG <[email-masked]>; Alexandre Petrescu <[email-masked]>; Robert Raszuk <[email-masked]>; [email-masked]
Subject: Re: [spring] Spirit and Letter of the Law (was: Question about SRv6 Insert function)

Please notice that version -00 which was accepted by the WG does not have such normative reference.

https://tools.ietf.org/html/draft-ietf-spring-srv6-network-programming-00<https://tools.ietf.org/html/draft-ietf-spring-srv6-network-programming-00>

Cheers,
R.

---

From: Andrew Alston <[email-masked]>
Date: Thu, 5 Sep 2019 19:37:46 +0000

Ole,

I'm far from convinced that saying we stop - while the issue is a very big can of worms - is a good idea.  Right now, there is a clear issue on the table here - and there are no proposals on how to address this - where addressing it would be either to remove the issue from the draft or propose something to update RFC8200 from my perspective.  I fail to see how we can therefore  think that closing this discussion to "some other unforeseen date" helps anyone - other than pushing the can down the road...

Andrew

From: spring <[email-masked]> On Behalf Of Ole Troan
Sent: Thursday, 5 September 2019 22:30
To: Fernando Gont <[email-masked]>
Cc: 6man WG <[email-masked]>; Alexandre Petrescu <[email-masked]>; Robert Raszuk <[email-masked]>; [email-masked]
Subject: Re: [spring] Spirit and Letter of the Law (was: Question about SRv6 Insert function)

> On 5 Sep 2019, at 21:03, Fernando Gont <[email-masked]<mailto:[email-masked]>> wrote:
>

Ole
_______________________________________________
spring mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/spring<https://www.ietf.org/mailman/listinfo/spring>

---

From: Tom Herbert <[email-masked]>
Date: Thu, 5 Sep 2019 12:42:29 -0700

Robert,

I don't see how that's relevant. The fact that a protocol is
_intended_ to be used only in a controlled domain is hardly a
substitute for doing the work to make the protocol robust. I don't
subscribe to the idea that just because a protocol runs in a limited
domain all of the problems magically go away.

> At least I would worry much less about MTU being exceeded when you insert EH as compared when you encapsulate with complete new header including EH, DO etc ... which somehow everyone seems to be happy about. I am not seeing much logic here.
>
Because, when a node encapsulates a packet it places _its_ address in
the source address field. This provides the necessary attribution. So
when the encapsulated packet causes issues it is clear who the culprit
is-- they receive the ICMP error or when the packet is error is logged
it's clear who created it. Attribution is critical to correct network
operation.

> Moreover if you look at telco transport today a lot of "circuits" are emulated circuits which use encap in the middle of the transports which in turn runs over their IP networks. How do you deal with such cases when one day it works and when telco underly reroutes such that it goes via bottleneck it does not ?
>
That's a deployment problem, not a protocol problem. That should be
taken up in IPv6 ops WG I would think.

> I am seeing this daily. We even wrote IETF drafts to detect this. Now the BFD draft stuffing is a third attempt to have a tool to detect it. If IPv6 works end to end, hosts to hosts such MTU bottleneck should be part of the IPv6 transport.
>
> That's a problem much bigger then SR. See when I am building transport over third parties I use SLA probes which periodically validates not only SLA data but also end to end max MTU. When I see an issue I choose automatically different underlay path such that end applications do not notice the issue.

Right, anytime an intermediate node materially changes a packet
outside of the standard protocol or increases the size of packet they
are risking end to end robustness and reliability. That's why RFC8200
precludes EH insertion, and why other similar proposals to make
non-standard modifications to packets in flight will be met with
resistance in IETF.

Tom

---

From: Fernando Gont <[email-masked]>
Date: Thu, 5 Sep 2019 22:52:29 +0300

> Pot calling kettle black?

Not really.

Since this whole EH-insertion debate started, it has all been about
pushing it forward no matter what.

The spec is clear. If you want to change it, make a strong case for it.
BUt do not try to circumvent the IETF consensus on the topic.

---

From: Ole Troan <[email-masked]>
Date: Thu, 5 Sep 2019 23:58:37 +0200

Fernando,

> On 5 Sep 2019, at 21:54, Fernando Gont <[email-masked]> wrote:
> 

Straw man attack. 

I think you have repeatedly made your point. 

O.

---

From: Ron Bonica <[email-masked]>
Date: Fri, 6 Sep 2019 03:26:17 +0000

Ole,

The IETF does not write de jure standards. At the same time, it must not blithely progress proposals that ignore existing standards. We need to find a balance.

Generally speaking, proposals that conform to the spirit and letter of existing standards are better than proposals that deviate. This is a matter of hygiene. However, exemptions might be granted.

IMHO, a WG can progress a proposal that deviates from existing standards if all of the following conditions are met:

1) The proposal documents the deviation
2) The proposal explores alternative solutions that do not deviate
3) The proposal explains either a) that alternative solutions do not exist, or b) why alternative solutions are not viable
4) The proposal describes the possibly limited deployment environment in which it is applicable
5) The WG cannot demonstrate any risk associated the deviation in the described deployment environment

A naïve reading of your message, below, suggests that we fixate on Condition #5, ignoring conditions #1 - #4. I'm pretty sure that wasn't your intent. If it were, our new process lead us into some bad places.

Like you, I want to avoid legalistic readings of existing standards. This is why I talk about the "spirit and letter" of a standard. For example, assume the following:

- An existing standard defines a mechanism for doing something
- A new proposal reinvents that wheel without sufficient motivation

The new proposal does not violate the letter of the existing standard, but it does violate its spirit.

Clearly, the barriers to progressing a draft that violates the letter of an existing standard should be higher than the barriers to progressing a draft that violates the spirit of an existing standard. 

                                                                                                  Ron

-----Original Message-----
From: Ole Troan <[email-masked]> 
Sent: Thursday, September 5, 2019 4:19 AM
To: Ron Bonica <[email-masked]>
Cc: Fernando Gont <[email-masked]>; Suresh Krishnan <[email-masked]>; [email-masked]; [email-masked]; draft-voyer-6man-extension-header-insertion <[email-masked]>; draft-ietf-spring-srv6-network-programming <[email-masked]>
Subject: Re: Spirit and Letter of the Law (was: Question about SRv6 Insert function)

Dear Ron,

"The fact of the matter is that the IETF is completely helpless to prevent such things. 
True, it can block standardization, but if the market wants it, the market will drive it and all that the IETF does is to make itself irrelevant to the process."

Best regards,
Ole

> Cc: Suresh Krishnan <[email-masked]>; Ron Bonica 
> <[email-masked]>; [email-masked]; [email-masked]; 
> draft-voyer-6man-extension-header-insertion 
> <[email-masked]>; 
> draft-ietf-spring-srv6-network-programming 
> <[email-masked]>

---

From: Alexandre Petrescu <[email-masked]>
Date: Fri, 6 Sep 2019 10:57:38 +0200

This is a non-technical side note about the Spirit and Letter of the Law
in IPv6 WG.

In these discussions about IPv6 like routing header, insertion,
mutability, 64bit, limited domains, multihoming, smart end dumb network,
and numerous other 'tussles', one is supposed to take a side among one
of those two:

- maintain rock solid principles, continue the tradition, keep it up
working as it was designed to and that demonstrated its validity on very
large scale.

- break away from tradition, foster innovation, things will work anyways
because humans engineer them and market regulates them.

Only deep convictions about one of those two sides can make IPv6
deployment and development progress.

On my side, I cant make have such deep convictions.

Alex

---

From: Robert Raszuk <[email-masked]>
Date: Fri, 6 Sep 2019 11:06:01 +0200

Hi Alex,

This is really spot on and very brilliant summary of the state we are in !

And since last 25 years rather proved that the first options is not working
the choice seems pretty clear that we should rather choose the second one.

Best,
R.

---

From: Sander Steffann <[email-masked]>
Date: Fri, 6 Sep 2019 23:11:54 +0200

Hi Ole,

> I think you have repeatedly made your point.

Yes he has, and he makes a good point that should be heard. Your argument of "RFCs aren't the law, and we can ignore parts of them if it suits us" just isn't true. RFCs are based on consensus, and ignoring the outcome of that consensus when it suits you is unacceptable for a WG chair.

Cheers,
Sander

---

From: Ole Troan <[email-masked]>
Date: Fri, 6 Sep 2019 23:25:44 +0200

> Yes he has, and he makes a good point that should be heard. Your argument of "RFCs aren't the law, and we can ignore parts of them if it suits us" just isn't true. RFCs are based on consensus, and…

Then I don’t think I have expressed myself in a way that has been understood by you. 

But he isn’t making a point that hasn’t been made many times before. I asked him to argue his point in the context of the actual drafts in question, which I believe he did not. The protocol police rhetoric used in the wider community doesn’t appear to me to add value, rather create disruption. 
 
I don’t see a need to continue this debate on meta issues, but since you framed this as criticism of me in the chair role I found it required to reply. 

Ole

---

From: Sander Steffann <[email-masked]>
Date: Fri, 6 Sep 2019 23:57:59 +0200

Hi Ole,

> I don’t see a need to continue this debate on meta issues, but since you framed this as criticism of me in the chair role I found it required to reply. 

I expect the chair to uphold a previously reached consensus and put the requirement of justifying deviating from it with the ones that want to go against said consensus.

Cheers,
Sander

---

From: Ole Troan <[email-masked]>
Date: Sat, 7 Sep 2019 00:08:14 +0200

> I expect the chair to uphold a previously reached consensus and put the requirement of justifying deviating from it with the ones that want to go against said consensus.

Proposals are judged on their merits. 
There is no protocol police. 

These proposals are not moving as far as I can see. So what are you trying to achieve by getting your collective knickers in a twist now?

Ole

---

From: Robert Raszuk <[email-masked]>
Date: Sat, 7 Sep 2019 00:11:07 +0200

Sander,

But this is exactly what both chairs of 6man did with the help of AD long
time back. You must have missed it !

And below is a link precisely written to address requirement of justifying
deviation:

https://tools.ietf.org/html/draft-voyer-6man-extension-header-insertion-06

And let me repeat one more and last time ... all other documents in
progress use two different insertions. Most of them does SRH insertion +
new IPv6 encapsulation which is allowed by all IPv6 related RFCs - so zero
violation of any consensus.

Just NP document also adds two functions for insertion without
encapsulation, as additional tools which can be used for things like FRR if
such application will be approved in 6man WG.

All SRv6 existing specs can progress just fine with that last mode of
insertion being removed if rough consensus in 6man would not get reached.

Cheers,
Robert.

On Fri, Sep 6, 2019 at 11:58 PM Sander Steffann <[email-masked]> wrote:

> Hi Ole,
>
> > I don’t see a need to continue this debate on meta issues, but since you
> framed this as criticism of me in the chair role I found it required to
> reply.
>
> I expect the chair to uphold a previously reached consensus and put the
> requirement of justifying deviating from it with the ones that want to go
> against said consensus.
>
> Cheers,
> Sander
>
>

---

From: Sander Steffann <[email-masked]>
Date: Sat, 7 Sep 2019 00:19:48 +0200

Hi Ole,

> There is no protocol police. 

There is existing consensus, and changing that requires consensus on the changes. The onus is on those wanting the change, yet you demand the ones referring to the existing consensus to defend themselves. That is not their responsibility.

> These proposals are not moving as far as I can see. So what are you trying to achieve by getting your collective knickers in a twist now?

Seeing extremely bad precedent being set by a chair. Chairs have the responsibility to stand up for the consensus in their working group. Always. No matter their personal opinion. No matter who they work for. Always.

The discussion has been had, consensus has been reached. Requiring someone else to defend an existing consensus is disrespectful to the working group that worked towards that consensus.

Sander

---

From: Sander Steffann <[email-masked]>
Date: Sat, 7 Sep 2019 00:23:47 +0200

Hi Robert,

> All SRv6 existing specs can progress just fine with that last mode of insertion being removed if rough consensus in 6man would not get reached. 

My problem is that Fernando is being told to defend the existing RFC. That is wrong. It is up to the SRv6 proposers to argue and defend the changes they want.

Consensus has to be reached to make a change, not to keep the current consensus.

Cheers,
Sander

---

From: Tom Herbert <[email-masked]>
Date: Fri, 6 Sep 2019 15:26:59 -0700

> The discussion has been had, consensus has been reached. Requiring someone else to defend an existing consensus is disrespectful to the working group that worked towards that consensus.
What consensus has been reached that you are referring to?

Tom

---

From: Nick Hilliard <[email-masked]>
Date: Fri, 6 Sep 2019 23:28:15 +0100

> What consensus has been reached that you are referring to?

rfc8200.

Nick

---

From: Sander Steffann <[email-masked]>
Date: Sat, 7 Sep 2019 00:28:33 +0200

Hi,

> What consensus has been reached that you are referring to?

The consensus on the text of RFC8200.

Cheers, sander

---

From: Robert Raszuk <[email-masked]>
Date: Sat, 7 Sep 2019 00:37:30 +0200

> My problem is that Fernando is being told to defend the existing RFC.

And who told him to do that ? Some one who recommended him to grep for
"insertion" string in the text without understanding the full sentences
where such world may exist ? Hmmm why would anyone do that ?

By that notion it would be much more productive to simply talk to tools
team and update draft submission parser. When in any document "IPv6" and
"insertion" strings occur even once - REJECT. It would save so many emails
....

And Fernando is doing great job btw - but there is just little problem - no
one is attacking any existing RFC.

> It is up to the SRv6 proposers to argue and defend the changes they want.

And that is precisely what is happening. The draft quoted mail earlier is a
real prove of that.

Now let's relax and enjoy the weekend :-)

Cheers,
R.

---

From: Tom Herbert <[email-masked]>
Date: Fri, 6 Sep 2019 15:59:49 -0700

On Fri, Sep 6, 2019 at 3:11 PM Robert Raszuk <[email-masked]> wrote:
>
> Sander,
>
> But this is exactly what both chairs of 6man did with the help of AD long time back. You must have missed it !
>
> And below is a link precisely written to address requirement of justifying deviation:
>

Yes, and that draft was discussed in depth in 6man, a number of issues
were raised, and we haven't heard back from the authors. And this was
not just a case of saying it violates RFC8200, there were specific
reasons given why it isn't robust. So it's correct to say that current
consensus in 6man is that extension header insertion is disallowed.

I also have a nit about that draft. The very first line of the
abstract is "The network operator and vendor community has clearly
indicated that IPv6 header insertion is useful and required." The fact
that somebody _really_ wants their protocol to be adopted by IETF is
hardly going to influence anyone. Obviously, anyone writing a draft
thinks that it is useful and required, it's up to the authors to show
that. Frankly, I think this statement comes off as being condescending
and sets a poor tone for reading the rest of the document.

Tom

> And let me repeat one more and last time ... all other documents in progress use two different insertions. Most of them does SRH insertion + new IPv6 encapsulation which is allowed by all IPv6 related RFCs - so zero violation of any consensus.
>
> Just NP document also adds two functions for insertion without encapsulation, as additional tools which can be used for things like FRR if such application will be approved in 6man WG.
>

---

From: Mark Smith <[email-masked]>
Date: Sat, 7 Sep 2019 11:07:29 +1000

On Sat, 7 Sep 2019, 09:00 Tom Herbert, <[email-masked]> wrote:

> > But this is exactly what both chairs of 6man did with the help of AD
> long time back. You must have missed it !
> >

Yes, it's a appeal to authority.

Earlier versions had 10 or more authors listed. That is also an appeal to
authority.

The draft doesn't say why insertion is considered necessary. There is no
justification presented.

There is no statement that says, "When using IPv6 tunnelling with 128 bit
SIDs, the per packet overhead can become too high." That would be admitting
what the real cause was, and make people question whether using 128 bit
SIDs was really the right decision - as they should.

Considering all that, I would describe this draft as trying to get its
proposal approved through social engineering rather than technical
engineering.

> >> > I don’t see a need to continue this debate on meta issues, but since
> you framed this as criticism of me in the chair role I found it required to
> reply.
> >>

---

From: Ron Bonica <[email-masked]>
Date: Sat, 7 Sep 2019 01:27:08 +0000

Mark,

Thanks for saying what we were all thinking.

Ron
Sent from my phone

On Sep 6, 2019, at 9:07 PM, Mark Smith <[email-masked]<mailto:[email-masked]>> wrote:

On Sat, 7 Sep 2019, 09:00 Tom Herbert, <[email-masked]<mailto:[email-masked]>> wrote:
On Fri, Sep 6, 2019 at 3:11 PM Robert Raszuk <[email-masked]<mailto:[email-masked]>> wrote:
> https://tools.ietf.org/html/draft-voyer-6man-extension-header-insertion-06<https://urldefense.com/v3/__https://tools.ietf.org/html/draft-voyer-6man-extension-header-insertion-06__;!8WoA6RjC81c!QCUnocXqhwmktJnIOEJVs_z0uIoC21MOFOVAR0vgcgeAgGzg9MirMP7krfiJ6n4a$>
>

Earlier versions had 10 or more authors listed. That is also an appeal to authority.

The draft doesn't say why insertion is considered necessary. There is no justification presented.

There is no statement that says, "When using IPv6 tunnelling with 128 bit SIDs, the per packet overhead can become too high." That would be admitting what the real cause was, and make people question whether using 128 bit SIDs was really the right decision - as they should.

Considering all that, I would describe this draft as trying to get its proposal approved through social engineering rather than technical engineering.

Tom

> On Fri, Sep 6, 2019 at 11:58 PM Sander Steffann <[email-masked]<mailto:[email-masked]>> wrote:
>>
>> Hi Ole,
>>
>> https://www.ietf.org/mailman/listinfo/spring<https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/spring__;!8WoA6RjC81c!QCUnocXqhwmktJnIOEJVs_z0uIoC21MOFOVAR0vgcgeAgGzg9MirMP7krR6VKe7s$>
>
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6<https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/ipv6__;!8WoA6RjC81c!QCUnocXqhwmktJnIOEJVs_z0uIoC21MOFOVAR0vgcgeAgGzg9MirMP7krbgSAl-0$>

--------------------------------------------------------------------
IETF IPv6 working group mailing list
[email-masked]<mailto:[email-masked]>
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6<https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/ipv6__;!8WoA6RjC81c!QCUnocXqhwmktJnIOEJVs_z0uIoC21MOFOVAR0vgcgeAgGzg9MirMP7krbgSAl-0$>
--------------------------------------------------------------------
--------------------------------------------------------------------
IETF IPv6 working group mailing list
[email-masked]<mailto:[email-masked]>
Administrative Requests: https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/ipv6__;!8WoA6RjC81c!QCUnocXqhwmktJnIOEJVs_z0uIoC21MOFOVAR0vgcgeAgGzg9MirMP7krbgSAl-0$
--------------------------------------------------------------------

---

From: Fernando Gont <[email-masked]>
Date: Sat, 7 Sep 2019 05:49:21 +0300

On 7/9/19 04:07, Mark Smith wrote:
>     > But this is exactly what both chairs of 6man did with the help of
>     AD long time back. You must have missed it !
>     >

Exactly. The relevant text in RFC8200 was added *exactly because of
this*, indeed.

> Earlier versions had 10 or more authors listed. That is also an appeal

https://tools.ietf.org/html/draft-filsfils-spring-net-pgm-extension-srv6-usid-00
has 26. About 5 authors per non-boilerplate page.

> There is no statement that says, "When using IPv6 tunnelling with 128
> bit SIDs, the per packet overhead can become too high." That would be
> admitting what the real cause was, and make people question whether
> using 128 bit SIDs was really the right decision - as they should.
> 

Indeed. The original argument was "we do it, because it is not
forbidden" -- when I think it was obvious to everyone that IPv6 didn't
allow for header insertion.

Then there was a big push to keep what became RFC8200 ambiguous in this
respect.

Eventually we got IETF consensus to incorporate specific text that
forbids EH insertion, for all the considerations that had been made
while the topic was discussed in 6man.

Now the argument is that we should kind of ignore RFC8200, and "judge
the technical merits of EH-insertion", as if the text we included in
RFC8200 was just some random bits we added into the spec, because we had
nothing else to do.

And having us to find if EH-insertion breaks anything (which was already
discussed ad nauseam on 6man), rather than the proponents making a case
about why they need EH insertion in the first place.

---

From: Fernando Gont <[email-masked]>
Date: Sat, 7 Sep 2019 05:32:40 +0300

> consensus in 6man is that extension header insertion is disallowed.

Exactly. And the text in RFC8200 reflects that consensus.

> indicated that IPv6 header insertion is useful and required."

I would be quite curious (but might be wrong) if the operator community
cared about doing EH insertion. They are normally more interested about
solving problems... and EH-insertion, per-se, has nothing to do with
solving problems.

The draft in question doesn't comment on the most basic question: why do
you want to do EH-insertion as opposed to encap/decap into a new packet?

I asked this question a number of times, and nobody answered. Rumor on
the corridors had it that it had to do with one specific vendors having
issues (of some sort) with implementing this with doing encap/decap. --
but that's the closest that I got to a rationale for the motivation of
EH-insertion.

Thanks,

---

From: Fernando Gont <[email-masked]>
Date: Sat, 7 Sep 2019 06:00:29 +0300

> A naïve reading of your message, below, suggests that we fixate on Condition #5, ignoring conditions #1 - #4. I'm pretty sure that wasn't your intent. If it were, our new process lead us into some…

That is *exactly* the point I've been trying to make.

> Clearly, the barriers to progressing a draft that violates the letter of an existing standard should be higher than the barriers to progressing a draft that violates the spirit of an existing stand…

In this case, EH-insertion violates both the letter and the spirit of
the standard. And the proposal never even commented why encap/decap is
not a feasible solution, instead of EH-insertion. (the most basic
content of your item #2 above).

Thanks,

---

From: Sander Steffann <[email-masked]>
Date: Sat, 7 Sep 2019 18:33:54 +0200

Hi Ole,

> I don’t see a need to continue this debate on meta issues, but since you framed this as criticism of me in the chair role I found it required to reply.

Following up now that I had some rest :)

I consider you a friend, and I respect you a lot. Which is why the way you were approaching this discussion surprised (and to be fair annoyed) me so much. It is not something I would expect from you. Which is why I kept silent for a while but in the end decided I should speak up. Being a chair brings great responsibility, and the first and foremost responsibility is to the working group. Part of that is steering discussions, upholding previously attained consensus so that their value/validity is not challenged over and over again, wasting a lot of time and energy of working group participants. I'm not saying that consensus can never change, but doing so needs proper timing and discussion. Reevaluating consensus on a topic too often leads to a "revised consensus by attrition", which is not in the working groups interest.

I still support you as a chair, and I am sure you can maintain the balance between stability and flexibility. As a friend I just felt that I should tell you I disagree with your approach. Friends should be honest to each other :)

Cheers,
Sander

---

From: "Zafar Ali (zali)" <[email-masked]>
Date: Sat, 7 Sep 2019 17:37:25 +0000

Hi Alex, Robert,

I agree fully.

From an IETF process viewpoint, Suresh recently cited his email on this topic:
https://mailarchive.ietf.org/arch/msg/ipv6/4MevopH9_iQglUizhoT5Rl-TjRc

“I just want to confirm that header insertion work can be considered in the future, and that it should be judged on its own merits and not be blocked solely based on the header insertion related text in 2460bis.”

The required justification has been provided, again and again, like current email from Robert, Ketan and many others:
E.g., https://mailarchive.ietf.org/arch/msg/spring/oFsaIAFXyw0PYdVpVVv9xOxYYNQ

Thanks

Regards … Zafar

From: ipv6 <[email-masked]> on behalf of Robert Raszuk <[email-masked]>
Date: Friday, September 6, 2019 at 5:07 AM
To: Alexandre Petrescu <[email-masked]>
Cc: Fernando Gont <[email-masked]>, 6man WG <[email-masked]>, "[email-masked]" <[email-masked]>
Subject: Re: [spring] Spirit and Letter of the Law - non-technical side note

Hi Alex,

And since last 25 years rather proved that the first options is not working the choice seems pretty clear that we should rather choose the second one.

Best,
R.

On Fri, Sep 6, 2019 at 10:57 AM Alexandre Petrescu <[email-masked]<mailto:[email-masked]>> wrote:

Alex

---

From: Tom Herbert <[email-masked]>
Date: Sat, 7 Sep 2019 11:35:10 -0700

> E.g., https://mailarchive.ietf.org/arch/msg/spring/oFsaIAFXyw0PYdVpVVv9xOxYYNQ
Zafar,

Extension header insertion WAS considered by the 6man WG.
draft-voyer-6man-extension-header-insertion was discussed at length.
(https://mailarchive.ietf.org/arch/msg/ipv6/VSMm27TQFeJbvsD6pDnIPA4w4Yw).
The consensus from that discussion was that extension header insertion
is disallowed by RFC8200 AND here are the specific problems with it.
Most of the issues, particularly the attribution, have not been
addressed. There is nothing precluding the EH insertion proponents
from updating the draft to answer the issues to try to move it
forward.

So, I believe it is inaccurate to claim that EH insertion is being
blocked by purist arguments to uphold RFC8200. IMO, if that claim is
being made then it's a disservice to the reviewers of
draft-voyer-6man-extension-header-insertion that put in substantial
effort to review, analyze, and comment on the idea.

Tom

> On Fri, Sep 6, 2019 at 10:57 AM Alexandre Petrescu <[email-masked]> wrote:
>
>

---

From: Michael Richardson <[email-masked]>
Date: Sun, 08 Sep 2019 12:55:15 +0100

Fernando Gont <[email-masked]> wrote:
    >> 
    >> Why do these kind of arguments emerge right now instead of 5 years
    >> ago?  We left the “problem “ for 5 years? And suddenly we notice them?
    >> How interesting.

    > One possibility: All this kind of arguments did emerge a long time ago
    > -- NAmely, when working on rfc2460bis, which eventually became
    > RFC8200. As a results of the problems associated with EH-insertion,
    > there was IETF consensus to explicitly ban it in RFC8200. Maybe some
    > 6man'ers were not subscribed to the spring wg list, were quite
    > surprised to see documents relying on EH-insertion (one ins spring, and
    > another, indirectly, in lsr), and hence decided to comment.

I would suggest that the result was slightly different.

We decided in RFC8200 that EH-insertion by random devices for randomly
defined purposes was banned.

That if a device/operator needed to do that, that they ought to use IPIP
insertion. We failed to actually follow through with RFC8504 to make
it possible to actually use IPIP in a general case.

What I think that we wound up in RFC8200, and I think that it was
intentionally very subtly under-stated by the AD at the time, was that any
IETF Specification could in effect make any rule it wanted, and it
would be subject to IETF Last Call and IESG review.

So what we banned was EH-insertion by vendors or operators without
significant (standards-level) thought as to applicability.  We are now here,
we are supposed to be discussing if this use case, along with it's
applicability, warant a reasonable exception.

I have not followed the hundreds of messages in this thread, but I read a few.

-- 
Michael Richardson <[email-masked]>, Sandelman Software Works
 -= IPv6 IoT consulting =-

---

From: "Chengli (Cheng Li)" <[email-masked]>
Date: Fri, 6 Sep 2019 15:32:10 +0000

Hi Bruno,

Agree. I am very curious that why so many emails everyday? And I saw the POVs again and again in different format. I think you have explained very clear.

It looks to me like SRv6 NP draft is going to be published as a RFC. But actually it is a WG item only，and a normative reference to eh insertion draft is in there. Everything is going in the right process.

But I have a question:

Why do these kind of arguments emerge right now instead of 5 years ago? We left the “problem “ for 5 years? And suddenly we notice them? How interesting.

________________________________
Cheng Li
Email: [email-masked]<mailto:[email-masked]>

From: bruno.decraene<[email-masked]<mailto:[email-masked]>>
To: Fernando Gont<[email-masked]<mailto:[email-masked]>>;Ron Bonica<[email-masked]<mailto:[email-masked]>>;li zhenqiang<[email-masked]<mailto:[email-masked]>>;Ole Troan<[email-masked]<mailto:[email-masked]>>;Fernando Gont<[email-masked]<mailto:[email-masked]>>
Cc: spring<[email-masked]<mailto:[email-masked]>>;6man<[email-masked]<mailto:[email-masked]>>;Suresh Krishnan<[email-masked]<mailto:[email-masked]>>;draft-voyer-6man-extension-header-insertion<[email-masked]<mailto:[email-masked]>>;rtg-ads<[email-masked]<mailto:[email-masked]>>;draft-ietf-spring-srv6-network-programming<[email-masked]<mailto:[email-masked]>>
Subject: RE: IPv6 EH-insertion (Re: Spirit and Letter of the Law (was: Question about SRv6 Insert function))
Time: 2019-09-05 22:47:44

Fernando,

--Bruno

---

From: Fernando Gont <[email-masked]>
Date: Sat, 7 Sep 2019 05:54:36 +0300

On 6/9/19 18:32, Chengli (Cheng Li) wrote:
>
> But I have a question:
> 
> Why do these kind of arguments emerge right now instead of 5 years ago?
> We left the “problem “ for 5 years? And suddenly we notice them? How
> interesting.

One possibility:
All this kind of arguments did emerge a long time ago -- NAmely, when
working on rfc2460bis, which eventually became RFC8200. As a results of
the problems associated with EH-insertion, there was IETF consensus to
explicitly ban it in RFC8200. Maybe some 6man'ers were not subscribed to
the spring wg list, were quite surprised to see documents relying on
EH-insertion (one ins spring, and another, indirectly, in lsr), and
hence decided to comment.

Just a guess, though.

---

From: Mark Smith <[email-masked]>
Date: Sat, 7 Sep 2019 15:57:23 +1000

> hence decided to comment.

It's been clear since RFC 1883, the first IPv6 specification RFC from
December 1995:

"With one exception, extension headers are *not examined or processed
   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."

Similar text goes back to the SIPP spec from 1994 when EHs were called
"optional headers":

"With one exception, optional headers are not examined or processed by any
node along a packet's delivery path, until the packet reaches the node (or
set of nodes, in the case of multicast) identified in the Destination
Address field of the SIPP header."

https://tools.ietf.org/html/draft-ietf-sipp-spec-00

It was more specifically explained in RFC 8200 only because some
people were claiming that the meaning of "examined" or "processed" are
ambiguous.

---

From: li zhenqiang <[email-masked]>
Date: Mon, 9 Sep 2019 09:57:09 +0000

Hello all,

And we should not ignore that RFC8200 also says:
Each extension header should occur at most once, except for the Destination Options header, which should occur at most twice (once before a Routing header and once before the upper-layer header).

Best Regards,
Zhenqiang Li

From: Robert Raszuk<mailto:[email-masked]>
Date: 2019-09-06 02:00
To: Ron Bonica<mailto:rbonica=[email-masked]>
CC: [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; Suresh Krishnan<mailto:[email-masked]>; Fernando Gont<mailto:[email-masked]>
Subject: Re: [spring] Spirit and Letter of the Law (was: Question about SRv6 Insert function)
Hi Ron,

  *   An IPv6 path contains a source node, a destination node, and transit nodes
  *   Transit nodes belong to network operators which move the packets
  *   When packet enters operator's network it can be encapsulated and new src, dst and any other elements added to its header - original packet becomes just the payload
  *   Then new packet (and payload) is send within given domain via transit nodes.
  *   Some transit nodes just do basic IPv6 forwarding, some may see themselves in the dst field of the packet imposed by ingress node.
  *   If this is the case (when packet is received by segment endpoint) packets are processed as defined by SRv6 rules.
  *   According to RFC 8200, segment endpoints can insert, change, or delete extension headers. However, transit nodes that are not segment nodes cannot insert, change or delete extension headers

Best,
R..

On Thu, Sep 5, 2019 at 7:52 PM Ron Bonica <rbonica=[email-masked]<mailto:[email-masked]>> wrote:
Robert,

                                                                  Ron

From: spring <[email-masked]<mailto:[email-masked]>> On Behalf Of Robert Raszuk
Sent: Thursday, September 5, 2019 10:28 AM
To: Fernando Gont <[email-masked]<mailto:[email-masked]>>
Cc: Suresh Krishnan <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>; Ole Troan <[email-masked]<mailto:[email-masked]>>; Joel M. Halpern <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>
Subject: Re: [spring] Spirit and Letter of the Law (was: Question about SRv6 Insert function)

Is this clear enough?

- - -

Thx,
R.

---

From: Fernando Gont <[email-masked]>
Date: Mon, 9 Sep 2019 21:31:46 +0300

> would be subject to IETF Last Call and IESG review.

Yeah, that's IETF process, right? You can make any rule that you want
(assuming you do it within a wg with the proper scope), and you get wg
review and ietf-wide review. No new here. And I don't know why the rules
should be any different for eh-insertion.

> significant (standards-level) thought as to applicability.

Huh?

EH insertion is banned. If you want to violate that, you have to publish
a spec that updates RFC8200. Either to remove the corresponding text in
RFC8200, or at least to include an "UPdates: RFC8200" tag, such that
folks that read RFC8200 know what are the excemptions to the rule.

> We are now here,

I assume by "we" you mean IETF. Because this doesn't look like a minor
modification to IPv6. Hence, that would be out of scope for 6man.

Thanks,