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

[Jari Arkko]

Many thanks for your review of this and the other draft, Ron!

Jari

On 08 Sep 2015, at 19:19, Ronald Bonica  wrote:

> I am the assigned Gen-ART reviewer for this draft. For background on Gen-ART, 
> please see the FAQ at 
> 
> 
> 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.
> 
> Minor Issues: None
> 
> Editorial Issues:
> 
> 
> 
> 
> 
> 
> Ron Bonica
> 
> ___
> Gen-art mailing list
> Gen-art@ietf.org
> https://www.ietf.org/mailman/listinfo/gen-art



signature.asc
Description: Message signed with OpenPGP using GPGMail
___
Gen-art mailing list
Gen-art@ietf.org
https://www.ietf.org/mailman/listinfo/gen-art

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

[Suresh Krishnan]

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' ; gen-art@ietf.org
>> Cc: draft-ietf-conex-tcp-modifications....@tools.ietf.org
>> 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:suresh.krish...@ericsson.com]
>>> Sent: Tuesday, September 08, 2015 2:47 PM
>>> To: Ronald Bonica ; gen-art@ietf.org
>>> Cc: draft-ietf-conex-tcp-modifications@tools.ietf.org
>>> 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
Gen-art@ietf.org
https://www.ietf.org/mailman/listinfo/gen-art

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

[Ronald Bonica]

Resend, this time with correct email address


> -Original Message-
> From: Ronald Bonica
> Sent: Wednesday, September 09, 2015 4:50 PM
> To: 'Suresh Krishnan' ; gen-art@ietf.org
> Cc: draft-ietf-conex-tcp-modifications@tools.ietf.org
> 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:suresh.krish...@ericsson.com]
> > Sent: Tuesday, September 08, 2015 2:47 PM
> > To: Ronald Bonica ; gen-art@ietf.org
> > Cc: draft-ietf-conex-tcp-modifications@tools.ietf.org
> > 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
Gen-art@ietf.org
https://www.ietf.org/mailman/listinfo/gen-art

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

[Mirja Kühlewind]

Hi Ron,

sorry I'm slightly confused now... see below.

On 09.09.2015 22:49, Ronald Bonica wrote:

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.


Just as a side note last call for both docs is already over, but that's no 
problem.

I'm not sure where and in which document you want to change something now. >From 
my point of view draft-ietf-conex-tcp-modifications does not have to give a 
justification because it's simply using what's defined in 
draft-ietf-conex-destopt. And draft-ietf-conex-destopt does give some reasoning 
why this choice was taken.


Btw. draft-ietf-conex-destopt is basiaclly already finished for quite some time, 
we just waited to submit it until the other docs are ready in case we detect 
something that would require a change in draft-ietf-conex-destopt.


Please tell me again what you'd propose to change where!

Thanks,
Mirja




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:suresh.krish...@ericsson.com]
Sent: Tuesday, September 08, 2015 2:47 PM
To: Ronald Bonica ; gen-art@ietf.org
Cc: draft-ietf-conex-tcp-modifications....@tools.ietf.org
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



--
--
Dipl.-Ing. Mirja Kühlewind
Communication Systems Group
Institute TIK, ETH Zürich
Gloriastrasse 35, 8092 Zürich, Switzerland

Room 

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

[Ronald Bonica]

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:suresh.krish...@ericsson.com]
> Sent: Tuesday, September 08, 2015 2:47 PM
> To: Ronald Bonica ; gen-art@ietf.org
> Cc: draft-ietf-conex-tcp-modifications@tools.ietf.org
> 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
Gen-art@ietf.org
https://www.ietf.org/mailman/listinfo/gen-art

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

[Suresh Krishnan]

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 
> 
>
> 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
Gen-art@ietf.org
https://www.ietf.org/mailman/listinfo/gen-art

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

[Ronald Bonica]

I am the assigned Gen-ART reviewer for this draft. For background on Gen-ART, 
please see the FAQ at 

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. 

Minor Issues: None

Editorial Issues:






Ron Bonica

___
Gen-art mailing list
Gen-art@ietf.org
https://www.ietf.org/mailman/listinfo/gen-art