Re: [Gen-art] Gen-ART review of draft-ietf-conex-tcp-modifications

[Ronald Bonica <[e-mail]>]

Resend, this time with correct email address


> -----Original Message-----
> From: Ronald Bonica
> Sent: Wednesday, September 09, 2015 4:50 PM
> To: 'Suresh Krishnan' <[e-mail]>; [e-mail]
> Cc: [e-mail]
> Subject: RE: [Gen-art] Gen-ART review of draft-ietf-conex-tcp-modifications
> 
> Suresh,
> 
> You are absolutely right. We have two possible solutions, an HBH Option and
> a Destination Option.  Both solutions severely limit CONEX deployability.
> 
> Since my comment is more about draft-ietf-conex-destopt than it is about
> draft-ietf-conex-tcp-modifications, I think that we can let draft-ietf-conex-
> tcp-modifications go forward, as is.
> 
> Before draft-ietf-conex-tcp-modifications comes up for last call, we might
> want to augment Section 5, explaining why both solutions limit severely limit
> CONEX deployability. Since all of the CONEX documents are EXPERIMENTAL,
> that caveat shouldn't be an impediment to publication.
> 
> We will need to address the problem before the CONEX documents become
> PROPOSED STANDARD. But we can cross that bridge when we get to it.
> 
>                                                                                       Ron
> 
> 
> 
> 
> > -----Original Message-----
> > From: Suresh Krishnan [mailto:[e-mail]]
> > Sent: Tuesday, September 08, 2015 2:47 PM
> > To: Ronald Bonica <[e-mail]>; [e-mail]
> > Cc: [e-mail]
> > Subject: Re: [Gen-art] Gen-ART review of
> > draft-ietf-conex-tcp-modifications
> >
> > Hi Ron,
> >    Thanks for your review. Please find comments inline.
> >
> > On 09/08/2015 12:20 PM, Ronald Bonica wrote:
> > > I am the assigned Gen-ART reviewer for this draft. For background on
> > > Gen-ART, please see the FAQ at
> > > <http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq>
> > >
> > > Document:                                      draft-ietf-conex-tcp-modifications-09
> > > Reviewer:                                        Ron Bonica
> > > Review Date:                                  2015-09-07
> > > IETF LC End Date:                          2015-08-31
> > > IETF Telechat Date:                      2015-10-01
> > >
> > > Summary:          This document will be ready for publication as soon as the
> > major issue (below) below is addressed.
> > >
> > > Major Issues:
> > >
> > > This document contains a normative reference to
> > > draft-ietf-conex-destopt-
> > 09. The normative reference is appropriate, because this document
> > doesn't work at all unless the concepts described in
> > draft-ietf-conex-destopt-09 work.
> > >
> > > I am concerned about draft-ietf-conex-destopt-09. It uses an IPv6
> > Destination Option to signal CONEX state to intermediate routers.
> > However, according to RFC 2460:
> > >
> > >     "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."
> > >
> > > The exception to which RFC 2460 refers is the Hop-by-hop Extension
> > Header. Intermediate routers don't examine Destination Options.
> > >
> > > Section 5 of draft-ietf-conex-destopt-09 attempts to address this
> > > issue, but
> > I am not sure that the argument is acceptable.
> >
> > I think we can discuss this further but in my view there are no good
> > solutions to this problem. There are two probable alternatives here
> >
> > Hop-by-hop options: This is arguably the right way to define
> > information that is inspected on intermediate nodes. But using this
> > implies that there is a huge performance penalty for conex packets
> > that hit conex unaware routers (basically being punted into the slow
> > path in the best case, being dropped at worst). RFC7045 section 2.2
> > talks about this explicitly but this problem has been known for much
> longer. This will break requirement R-3.
> >
> > Destination options: Intended for the destination of the packet, but
> > capable of being read at *consenting* conex-aware network nodes. Does
> > not affect nodes that are conex unaware. This is no different than a
> > router that looks at a TCP port for an enforcing an ACL, right?
> >
> > Let me know what you think. (Especially, we would be grateful if you
> > think there is a better solution we ought to be considering that would
> > meet the
> > requirements)
> >
> > Regards
> > Suresh
> >