[Gen-art] Re: Gen-ART Last Call Review of draft-ietf-avt-hc-over-mpls-protocol-07

Spencer Dawkins <spencer@mcsr-labs.org> Thu, 08 February 2007 05:52 UTC

Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HF2DB-0005p2-04; Thu, 08 Feb 2007 00:52:49 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HF2D9-0005ou-Pi; Thu, 08 Feb 2007 00:52:47 -0500
Received: from usaga01-in.huawei.com ([206.16.17.211]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HF2D8-0007H7-H0; Thu, 08 Feb 2007 00:52:47 -0500
Received: from huawei.com (usaga04-in [172.18.9.16]) by usaga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0JD4003M1QZVHP@usaga04-in.huawei.com>; Wed, 07 Feb 2007 23:52:43 -0600 (CST)
Received: from s73602 (cpe-72-190-0-23.tx.res.rr.com [72.190.0.23]) by usaga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTPA id <0JD400MW8QYCTI@usaga04-in.huawei.com>; Wed, 07 Feb 2007 23:52:43 -0600 (CST)
Date: Wed, 07 Feb 2007 23:51:41 -0600
From: Spencer Dawkins <spencer@mcsr-labs.org>
To: "ASH, GERALD R (JERRY), ATTLABS" <gash@att.com>
Message-id: <002201c74b45$463280d0$6501a8c0@china.huawei.com>
MIME-version: 1.0
X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.2962
X-Mailer: Microsoft Outlook Express 6.00.2900.2869
Content-type: text/plain; format="flowed"; charset="iso-8859-1"; reply-type="original"
Content-transfer-encoding: 7bit
X-Priority: 3
X-MSMail-priority: Normal
References: <9473683187ADC049A855ED2DA739ABCA0DDC81BA@KCCLUST06EVS1.ugd.att.com>
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 0a7aa2e6e558383d84476dc338324fab
Cc: ext Cullen Jennings <fluffy@cisco.com>, ietf@ietf.org, Andy.Malis@tellabs.com, lars-erik@lejonsson.com, General Area Review Team <gen-art@ietf.org>, "raymond.zhang" <raymond.zhang@bt.infonet.com>, Mark Townsley <townsley@cisco.com>, "GOODE, B (BUR), ATTLABS" <bgoode@att.com>, "HAND, JAMES, ATTLABS" <jameshand@att.com>, avt-chairs@tools.ietf.org, pwe3-chairs@tools.ietf.org
Subject: [Gen-art] Re: Gen-ART Last Call Review of draft-ietf-avt-hc-over-mpls-protocol-07
X-BeenThere: gen-art@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: "GEN-ART: General Area Review Team" <gen-art.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/gen-art>, <mailto:gen-art-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/gen-art>
List-Post: <mailto:gen-art@ietf.org>
List-Help: <mailto:gen-art-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/gen-art>, <mailto:gen-art-request@ietf.org?subject=subscribe>
Errors-To: gen-art-bounces@ietf.org

Hi, Jerry,

This is easier than it should be... slicing down through the stuff we 
already worked out (if I deleted it, I agree with your plan)...

>    option is the same for both IPCP and IPV6CP.  This configuration
>    option MUST be included for ECRTP, CRTP and IPHC PW types and MUST
>    NOT be included for ROHC PW types.
>
> Spencer: Is it obvious what the decompressor does if it sees this
> configuration option for ROHC PW types? It may be - I'm just
> asking. I'd
> have the same question elsewhere (in 5.2.2, for example), but
> will only ask it here.

Yes.  The corresponding text for the ROHC configuration option is
specified in Section 5.2.5.  In other sections we specify that the
configuration options are only applicable to specific header compression
formats, e.g., as in Section 5.2.2 for cRTP.

Spencer: there was this theory about testing TCP with "kamikaze" or 
"Christmas tree" packets (you set all the options to "1", whether that makes 
sense or not, and see what the other guy does). I think I'm asking "what 
SHOULD happen if the decompressor sees a packet like this". I'm wondering if 
we still worry about things like this...

>    and loss, it is still the protocol of choice in many
>    cases.  In these
>    circumstances, it must be implemented and deployed with care.  IPHC
>    should use TCP_NODELTA, ECRTP should send absolute values, ROHC
>    should be adapted as discussed in [RFC4224].  An evaluation and
>    simulation of ECRTP and ROHC reordering is given in [REORDER-EVAL].
>
> Spencer (Probably a Nit): It wasn't obvious to me whether these
> recommendations are sufficient to "implement and deploy with care", or
> whether additional precautions must be taken. Even putting these
> recommendations in a numbered list immediately after
> "deployed with care"
> would be sufficient, if these recommendations are sufficient.

This goes back to a discussion with Allison Mankin RE CRTP issues
discussed icw RFC 4446.  There was no further list of recommendations
out of that discussion, rather, the point is that in packet-lossy
environments, for example, CRTP may not work well and ECRTP may perform
better.  Some folks felt that CRTP should be excluded because of that
problem.  There were, however, other concerns raised on deploying ECRTP
(e.g., CRTP is already widely deployed, plus other reasons).

Spencer: would it be appropriate to say "implement and deploy with care:", 
and then put the recommendations in a numbered list? My concern was pretty 
basic - if I follow these recommendations, do I still have a problem, or am 
OK?

Again, thanks for a quick followup, while I can still remember what I was 
thinking when I wrote the review :-)

Spencer 



_______________________________________________
Gen-art mailing list
Gen-art@ietf.org
https://www1.ietf.org/mailman/listinfo/gen-art