Re: Alvaro Retana's Discuss on draft-ietf-6man-rfc2460bis-09: (with DISCUSS and COMMENT)

[Fernando Gont <[e-mail]>]

Alvaro,

On 04/07/2017 07:39 PM, Alvaro Retana wrote:
> First off, this DISCUSS is NOT about questioning the rough consensus
> calls that the responsible Chair and AD have made, or wanting to change
> them, but about clarifying to avoid misinterpretations.
> 
> Given the ongoing discussion about Extension Headers and controlled
> domains (for example [1] and [2]), the text should be very specific on
> what is expected and where.  Because it is not, I think that this
> document is teetering along the line of having a "high degree of
> technical maturity", and not being ready for Internet Standard
> [rfc6410].

Why should any talk on EH insertion affect this document being ready for IS?

Actually, it's quite the opposite: the experience we have with IPv6 is
with "IPv6 'as is'" (i.e.,an end to end protocol that obviously does not
allow for EH insertion). Opening the door to EH insertion would make
this document, by definition, not ready for IS -- and actually, not even
suitable for 6man (which is expected to be about maintaining IPv6,
rather than about applying radical changes).

So this document is clarifying what IPv6 has always been: EHs cannot not
inserted by intermediate nodes.


I personally don't get why the future plans of a vendor should
essentially rule 6man to fundamentally change an end-to-end protocol
(IPv6) into a...whatchamacallit, or be a show stopper during IESG review.



> Without further clarifications and guidance, this document also brings on
> unanticipated second order effects [rfc3439] that can impact the
> direction, or even the viability, of future work in the IETF. 

An Architecture will clearly limit and delineate what you can and what
you can't do. If you can do anything that you please, then that's an
indication that you don't really have an architecture.



> Specifically, a straight forward interpretation of the text in Section 4
> is the absolute prohibition to process, insert or delete EHs -- but
> discussion on the 6man mailing list seems to point at an understanding
> that the conditions inside a controlled domain may be different, for
> example (from Brian Carpenter [3]):

If you agree with the IETF LC (as oted), I'm not sure why *opinions*
verted into the mailing list (*not* wg consensus of any sort) that
happened *after* the IETF LC should affect this document moving forward.



[...]
> [N.B.: I'm not implying that Brian's opinion represents consensus, that
> is not my call to make.]
> 
> I'm pointing at an opinion (which I agree with) that recognizes the need
> to differentiate between contexts -- but the current text in rfc2460bis
> doesn't do that.  I believe that this issue is significant (as reflected
> by the ongoing discussions) that that it should be resolved (by
> clarifying the text) before proceeding with the publication of this
> document as an Internet Standard. 

As a wg participant, I strongly oppose to that. rfc2460bis specifies
IPv6 -- an end to end protocol. EH insertion has nothing to do with
that. In fact, it implies a radical change to the architecture. So I'm
not sure why we're discussing what seems to be "yet another possible
loophole so that a given vendor can do what it has in its plans".

Please note: 6man decided to accept
draft-ietf-6man-segment-routing-header  on the condition that any
suggestions/specification of EH insertion were removed. That, together
with the IETF LC should be an indication regarding what seems to have
been the consensus on the topic.

I'm puzzled why any sort of ongoing discussion, taig place past IETF LC,
and on a very radical change to the protocol and architecture should
have an effect on rfc2460bis being moved forward.



> To summarize, the text in this document has the second order effect of
> not leaving a clear path forward for extensions to IPv6 so that they
> adhere to the protocol's architecture, specially when applied to a
> controlled domain.  At a minimum, I would like to see a clear path
> forward, whether that is in the form of an update for use of extensions
> in controlled domains, or a statement that this document just applies to
> IPv6 traffic intended to cross the Internet (as suggested at the 6man
> meeting in Chicago [4])...  My opinion is that this document should not
> be published as an Internet Standard until the remaining open discussions
> are explicitly resolved and this document reflects that resolution.

The onus is on folks wanting to change the current state of affairs.
Changing IPv6 (an end-to-end protocol) to allow for EH insertion is
essentially a very radical change... not only to the protocol, but even
to the architecture.


[...]
> (B)
> 
> As it stands, the note about the changed expectations for the Hop-by-Hop
> options header opens a significant door to work around the "limitations"
> of other options.  For example, it would be relatively straight forward
> to define a new Hop-by-Hop option to carry any type of information that
> could then be "examined, processed, inserted, or deleted by any node
> along a packet's delivery path". 

Yes, the text is misleading, and should be improved. I pointed this one
to Brian and Suresh off-list, based on comments by Ivan Arce (CCed). The
text needs to be improved, so that this is not seen as a yet another
loophole for suggesting that H insertion is allowed in IPv6 -- which was
certainly not the intent.



> ----------------------------------------------------------------------
> COMMENT:
> ----------------------------------------------------------------------
> 
> Appendix B. (Changes Since RFC2460) mentions that the text was revised
> based on updates from several other RFCs which Updated rfc2460.  I didn't
> check all the details, but if the updates were incorporated in this
> document, why are those RFCs not marked as being Obsolete?  Is there any
> value left in them?

AFAICT, in most cases rfc2460bis incorporated the changes, but didn't
reproduce the rationale. Hence, at least the "rationale for the changes"
is the value left in them, I'd say.

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