Thanks a lot Ron. I will craft some explanatory text to add to Section 5 and get back to you in a day or two.
Regards Suresh On 09/10/2015 12:48 PM, Ronald Bonica wrote: > > Resend, this time with correct email address > > >> -----Original Message----- >> From: Ronald Bonica >> Sent: Wednesday, September 09, 2015 4:50 PM >> To: 'Suresh Krishnan' <[email protected]>; [email protected] >> Cc: [email protected] >> 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:[email protected]] >>> Sent: Tuesday, September 08, 2015 2:47 PM >>> To: Ronald Bonica <[email protected]>; [email protected] >>> Cc: [email protected] >>> 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 >>> > > _______________________________________________ Gen-art mailing list [email protected] https://www.ietf.org/mailman/listinfo/gen-art
