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

[神明達哉 <[e-mail]>]

On Wed, Feb 26, 2020 at 11:39 AM <[e-mail]> wrote:

> > So... is the plan to ship a document that violates RFC8200?
>
> Please forgive me asking some clarification question that seems to be
> obvious for others: which part of
> draft-ietf-spring-srv6-network-programming-10 violates RFC8200?  From
> a quick read of it, Section 4.16 seems to describe the removal of an
> extension header from an IPv6 packet at a forwarding node.  Is that
> the one referenced as a violation?  Or is it something else, or are
> there others in addition to 4.16?

I've not seen any feedback, but according to the thread messages since
then, it's now pretty clear to me that it's at least about Section
4.16 (or more specifically, 4.16.1, which describes "PSP").

In that case, I have to oppose moving this doc forward in its current
form.

First, as (I believe) Brian also pointed out, the description of this
section is obscure.  And, in fact, it wasn't immediately clear to me
whether it's a violation of RFC8200 (hence the question).

Secondly, with more accurate understanding of the intent of this
section through the discussion of this thread, it's now clearer to me
that it's a violation of the following part of 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.

in that an intermediate node specified in a routing header with
segment left > 0 deletes an extension header.  So at least this
document has to clearly declare updating RFC8200 and get consensus
about it before moving on.  It's not done yet.  Hence my objection.

It's surprising to me that some people seem to (still) argue it's not
a violation because this node "is identified in the Destination
Address field of the IPv6 header" (before swapping it with the next
hop specified in the routing header).  Aside from that this
interpretation logically doesn't make sense as it's not compatible
with AH or PMTUD, if it could be justified with that logic, we
wouldn't have had to go through the long debate in promoting RFC2460
to RFC8200 in the first place.

The conclusion at that time (I wouldn't call it a "consensus" as I
know not everyone was happy about it) was that
- Such kind of insertion and deletion is indeed a violation of
  RFC2460; that's why RFC8200 now clearly says "inserted, or deleted"
  while RFC2460 only states "examined or processed".
- 6man and SPRING WGs will work together to see if we can define an
  exception to loosen the limitation so that a future version of
  SRv6 can validly coexist the base IPv6 standard.  Until then,
  encapsulation/decapsulation is the only standard-compliant behavior.

Now, beyond these technical points, I also have meta-level concerns.
Here I share the frustration of Fernando, even if his word may be too
blunt.  After the hot debate on revising RFC2460, I expected us to
"work together" towards the goal of seeking some middleground.
Admittedly, this process wouldn't be easy - some people who opposed to
the insertion/deletion at that time seem to believe there's no such
middleground anyway.  But some others seem more flexible, and, as far
as I can see, at least everyone is open to have discussions.

But, after nearly 3 years since the publication of RFC8200, we still
seem to have the same easy circumvention:
- Simply dismissing the concern by arguing this is not a violation
- Labeling those who raise concerns as innovation blockers
- Just blaming the IPv6 base protocol as being broken (because it
  doesn't accommodate a feature they want)
- Insisting SRv6 just happens to use IPv6 packet format and some part
  of spec but is not IPv6, indicating it doesn't matter whether it
  violates the IPv6 standard
- Pushing industry agenda instead of working together to reach consensus

I'm sad, but if this doesn't change, the only thing I, as a poor
individual, can make objections to last calls.  At least in the purely
technical sense, I've not seen any difference now and then.  So, the
history would suggest even if we blindly pass this WGLC we'll have a
very long debate at the IETF last call and just reach the same
conclusion.

That would be a waste of time for everyone.  I hope we can be more
cooperative instead of that.

--
JINMEI, Tatuya