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

From: Spencer Dawkins <[email-masked]>
Date: Wed, 07 Feb 2007 11:20:14 -0600

I have been selected as the General Area Review Team (Gen-ART)
reviewer for this draft (for background on Gen-ART, please see
http://www.alvestrand.no/ietf/gen/art/gen-art-FAQ.html).

Please resolve these comments along with any other Last Call comments
you may receive.

Document: draft-ietf-avt-hc-over-mpls-protocol-07
Reviewer: Spencer Dawkins
Review Date: 2007-01-30
IETF LC End Date: 2007-07-07
IESG Telechat date: (not known)

Summary: This document is on the right track for publication as Proposed 
Standard. I had some questions (please see below), but the quality seemed 
very good (thanks for that).

I'd like to see some work on my comments in 5.1, 5.2 (especially 5.2.1), and 
5.3. I had some comments on clarity in section 6, but these were 
more-than-nits-but-not-problems.

Thanks!

Spencer

Comments:

1. Introduction

   Voice over IP (VoIP) typically uses the encapsulation
   voice/RTP/UDP/IP.  When MPLS labels [RFC3031] are added, this becomes
   voice/RTP/UDP/IP/MPLS-labels.  MPLS VPNs (e.g., [RFC2547]) use label
   stacking, and in the simplest case of IPv4 the total packet header is
   at least 48 bytes, while the voice payload is often no more than 30
   bytes, for example.  When IPv6 is used, the relative size of the
   header in comparison to the payload is even greater.  The interest in
   header compression (HC) is to exploit the possibility of
   significantly reducing the overhead through various compression
   mechanisms, such as with enhanced compressed RTP (ECRTP) [RFC3545]
   and robust header compression (ROHC) [RFC3095], and also to increase
   scalability of HC.  MPLS is used to route HC packets over an MPLS
   label switched path (LSP) without compression/decompression cycles
   at each router.  Such an HC over MPLS capability can increase
   bandwidth efficiency as well as the processing scalability of the
   maximum number of simultaneous compressed flows that use HC at each
   router.  Goals and requirements for HC over MPLS are discussed in
   [RFC4247].  The solution put forth in this document using MPLS
   pseudowire (PW) technology has been designed to address these goals
   and requirements.

Spencer (Nit): I think the last sentence is actually "The solution using 
MPLS pseudowire
(PW) technology put forth in this document has been designed to address
these goals and requirements." (the solution wasn't actually put forth using 
MPLS PW technology :-)

2. Contributors

   Besides the editors listed in Section 12, the following people
   contributed to the document:

Spencer (Nit): I like the use of this section, but it seems odd to have it
so far from the acknowledgements section. I'm not sure if IESG has an agreed
sense of taste for placement or not. Cullen?

3. Terminology

   PSN Tunnel Signaling: Used to set up, maintain, and tear down the
   underlying PSN tunnel

Spencer (Nit): s/Used/A protocol used/ (all of the other definitions look
like complete sentences, this one is a fragment)

5.1 MPLS Pseudowire Setup & Signaling

   This specification defines new PW type values to be carried within
   the FEC object to identify HC PWs for each HC scheme.  The PW type is
   a 15-bit parameter assigned by IANA, as specified in the [RFC4446]
   registry, and MUST be used to indicate the HC scheme being used on
   the PW.  The following PW type values have been set aside for
   assignment by IANA:

   0x001A  ROHC Transport Header-compressed Packets    [RFC3095]
   0x001B  ECRTP Transport Header-compressed Packets   [RFC3545]
   0x001C  IPHC Transport Header-compressed Packets    [RFC2507]
   0x001D  cRTP Transport Header-compressed Packets    [RFC2508]

Spencer: "have been set aside for assignment by IANA", with RFC references,
confused me badly here. I read this text as saying that these values were
set aside IN [RFC3095], etc, which was wrong. Perhaps "IANA is requested to
assign the following new PW type values:"?

   The PW control word enables distinguishing between various packets
   types (e.g., uncompressed, UDP compressed, RTP compressed,
   context-state, etc.).  However, the PW control word indications are
   not unique across HC schemes, and therefore the PW type value allows
   the HC scheme to be identified.

5.2 Header Compression Scheme Setup, Negotiation, & Signaling

   Pseudowire Interface Parameter Sub-TLV type values are specified in
   [RFC4446].  Two code-points have been reserved, as follows:

   Parameter ID Length        Description                     References
   0x0D      up to 256 bytes  ROHC over MPLS configuration    RFC 3241
   0x0F      up to 256 bytes  CRTP/ECRTP/IPHC HC over MPLS    RFC 3544
                              configuration

Spencer: Again, something like "IANA is requested to assign these new
code-points" would help me with what seems to be ambiguous text.

5.2.1 Configuration Option Format [RFC3544]

   Both the network control protocol for IPv4, IPCP [RFC1332] and the
   IPv6 NCP, IPV6CP [RFC2472] may be used to negotiate IP HC parameters
   for their respective protocols.  The format of the configuration

Spencer (Nit): I understand what you're saying with "their respective
protocols", but I don't think what you're saying, and what I'm hearing, is
actually what these words mean. Perhaps "their respective controlled
protocols"? That would be unambiguous.

   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.

5.2.3 Enhanced RTP-Compression Suboption [RFC3544]

   To use the enhanced RTP HC defined in [RFC3545], a
   new sub-option 2 is added.  Sub-option 2 is negotiated instead of,
   not in addition to, sub-option 1.  This suboption MUST be included

Spencer: is it obvious what the decompressor does if it sees a compressor
specifying sub-option 1 AND sub-option 2?

   for ECRTP PWs (0x001B) and MUST NOT be included for other PW types.

   MAX_HEADER

      NOTE: The four ROHC profiles defined in RFC 3095 do not provide
      for a MAX_HEADER parameter.  The parameter MAX_HEADER defined by
      this document is therefore without consequence in these profiles.
      Other profiles (e.g., ones based on RFC 2507) can make use of the
      parameter by explicitly referencing it.

Spencer: is there any statement you can make about the largest header that
can be compressed in these profiles? Even if not, it might be good to say so
explicitly - I don't know what "without consequence" says about what
implementations may encounter in practice.

5.4 Packet Reordering

   Packet reordering for ROHC is discussed in [RFC4224], which is a
   useful source of information.  In case of lossy links and other
   reasons for reordering, implementation adaptations are needed to
   allow all the schemes to be used in this case.  Although CRTP is
   viewed as having risks for a number PW environments due to reordering

Spencer (Nit): "a number of PW environments" ("of" is missing)

   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.

6. HC Pseudowire Setup Example

   The Label Mapping message sent from R4/HD to R1/HC would be almost
   identical to the one sent in the opposite direction, with the
   following exceptions

Spencer (Nit): missing a colon here...

   As soon as either R1/HC or R4/HD had both transmitted and received
   Label Mapping Messages with the same PW Type and PW ID, it could

Spencer: "it" is not entirely clear here. "It" usually refers to one thing 
(in my mind), and the subject of the sentence is two things ("either R1/HC 
or R4/HD"). Mumble. Would it help to say that each ROHC endpoint considers 
the PW established when it has seen both packets?

   consider the PW established.  R1/HC could send ECRTP packets using
   the label it received in the Label Mapping Message from R4/HD, Lr4,
   and could identify received ECRTP packets by the label it had sent to
   R4/HD, Lr1.  And vice versa.

   The following 3 RTP packets from this flow would be sent as

Spencer: "following" is not entirely clear here. Suggest "next"?

   COMPRESSED_UDP_8, to establish the absolute and delta values of the
   IPv4 identifier and RTP timestamp fields.  These packets would use
   the same ECRTP CID as the previous 3 FULL_HEADER packets.  The MPLS
   and PW headers at the beginning of these packets would be formatted
   as follows: 

_______________________________________________
Gen-art mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/gen-art

---

From: Spencer Dawkins <[email-masked]>
Date: Wed, 07 Feb 2007 17:25:08 -0600

Hi, Andy (and the rest of the crew)

That's what I thought was happening, based on comments in the ID tracker. This one is easy, I think.

OId: 

The following PW type values have been set aside for
  assignment by IANA:

New:

IANA has set aside the following PW type values for assignment:

May they always be so easy, if this works for you :-)

Thanks,

Spencer
  ----- Original Message ----- 
  From: Andrew G. Malis 
  To: Spencer Dawkins 
  Cc: [email-masked] ; [email-masked] ; [email-masked] ; Jerry Ash ; Mark Townsley ; ext Cullen Jennings ; General Area Review Team ; Andrew Malis ; [email-masked] 
  Sent: Wednesday, February 07, 2007 4:11 PM
  Subject: Re: Gen-ART Last Call Review of draft-ietf-avt-hc-over-mpls-protocol-07

  Spencer,

  Thanks for your review.  Please note that I'm no longer at Tellabs - Jerry, we can put in my new contact info in a note to the RFC Editor, assuming we don't need to do another rev. If we do, we can put in my new contact info there. 

  As the primary editor, I'll let Jerry speak to the nits.  However, I can reply regarding your comments on sections 5.1 and 5.2.  In these cases, IANA actually has already reserved the included values for this draft, and we're just reflecting the fact that IANA has already reserved them - we're really not requesting the assignments, since they've already been done.  If you can suggest a less confusing way to reflect that, we can put it in.  The references to the other RFCs are where ROHC is specified, ECRTP is specified, etc. 

  Thanks again,
  Andy
   
  On 2/7/07, Spencer Dawkins <[email-masked]> wrote: 
    I have been selected as the General Area Review Team (Gen-ART)
    reviewer for this draft (for background on Gen-ART, please see 
    http://www.alvestrand.no/ietf/gen/art/gen-art-FAQ.html).

    Thanks!

    Spencer

    Comments:

    1. Introduction

    2. Contributors

    3. Terminology

      MAX_HEADER 

    5.4 Packet Reordering

    _______________________________________________
    Ietf mailing list
    [email-masked]
    https://www1.ietf.org/mailman/listinfo/ietf

---

From: Spencer Dawkins <[email-masked]>
Date: Wed, 07 Feb 2007 23:51:41 -0600

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)...

> 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...

> 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

---

From: Spencer Dawkins <[email-masked]>
Date: Thu, 08 Feb 2007 00:09:21 -0600

The AD gets to pick, but I do see small revisions handled with RFC Editor notes.

And thanks!

Spencer
  ----- Original Message ----- 
  From: Andrew G. Malis 
  To: Spencer Dawkins 
  Cc: [email-masked] ; [email-masked] ; [email-masked] ; Jerry Ash ; Mark Townsley ; ext Cullen Jennings ; General Area Review Team ; [email-masked] ; Andrew Malis 
  Sent: Thursday, February 08, 2007 12:06 AM
  Subject: Re: Gen-ART Last Call Review of draft-ietf-avt-hc-over-mpls-protocol-07

  Spencer,

  Works for me. Generally, is there another spin of a draft following a gen-art review, or can the changed be handled by instructions to the RFC editor?

  Jerry, if you're going to do another rev, my new contact information is:

  Andrew G. Malis
  Verizon Communications
  40 Sylvan Road
  Waltham, MA  02451
  USA
  Email: [email-masked]

  Cheers,
  Andy

    OId: 

    New:

    Thanks,

    Spencer
      ----- Original Message ----- 
      From: Andrew G. Malis 
      To: Spencer Dawkins 
      Cc: [email-masked] ; [email-masked] ; [email-masked] ; Jerry Ash ; Mark Townsley ; ext Cullen Jennings ; General Area Review Team ; Andrew Malis ; [email-masked] 
      Sent: Wednesday, February 07, 2007 4:11 PM
      Subject: Re: Gen-ART Last Call Review of draft-ietf-avt-hc-over-mpls-protocol-07

      Spencer,

      Thanks again,
      Andy
       
      On 2/7/07, Spencer Dawkins <[email-masked] > wrote: 
        I have been selected as the General Area Review Team (Gen-ART)
        reviewer for this draft (for background on Gen-ART, please see 
        http://www.alvestrand.no/ietf/gen/art/gen-art-FAQ.html).

        Thanks!

        Spencer

        Comments:

        1. Introduction

        2. Contributors

        3. Terminology

          MAX_HEADER 

        5.4 Packet Reordering

---

From: "Andrew G. Malis" <[email-masked]>
Date: Thu, 8 Feb 2007 01:06:39 -0500

Spencer,

Works for me. Generally, is there another spin of a draft following a
gen-art review, or can the changed be handled by instructions to the RFC
editor?

Andrew G. Malis
Verizon Communications
40 Sylvan Road
Waltham, MA  02451
USA

Cheers,
Andy

On 2/7/07, Spencer Dawkins <[email-masked]> wrote:
> *From:* Andrew G. Malis <[email-masked]>
> *To:* Spencer Dawkins <[email-masked]>
> *Cc:* [email-masked] ; [email-masked] ;
> [email-masked] ; Jerry Ash <[email-masked]> ; Mark Townsley<[email-masked]>; ext
> Cullen Jennings <[email-masked]> ; General Area Review Team<[email-masked]>; Andrew
> Malis <[email-masked]> ; [email-masked]
> *Sent:* Wednesday, February 07, 2007 4:11 PM
> *Subject:* Re: Gen-ART Last Call Review of
> draft-ietf-avt-hc-over-mpls-protocol-07
>
>
> Spencer,
>
> Thanks for your review.  Please note that I'm no longer at Tellabs -
> Jerry, we can put in my new contact info in a note to the RFC Editor,
> assuming we don't need to do another rev. If we do, we can put in my new
> contact info there.
>
> As the primary editor, I'll let Jerry speak to the nits.  However, I can
> reply regarding your comments on sections 5.1 and 5.2.  In these cases,
> IANA actually has already reserved the included values for this draft, and
> we're just reflecting the fact that IANA has already reserved them - we're
> really not requesting the assignments, since they've already been done.  If
> you can suggest a less confusing way to reflect that, we can put it in.  The
> references to the other RFCs are where ROHC is specified, ECRTP is
> specified, etc.
>
> Thanks again,
> Andy
>

---

From: "ASH, GERALD R \(JERRY\), ATTLABS" <[email-masked]>
Date: Wed, 7 Feb 2007 18:29:54 -0600

Hi Spencer,

Many thanks for your thorough and constructive review of the draft.  

Please see responses to your comments below, and please let us know of
any further comments or suggestions.

Thanks,
Regards,
Jerry 

> -----Original Message-----
> From: Spencer Dawkins [mailto:[email-masked]] 
> Sent: Wednesday, February 07, 2007 12:20 PM
> To: [email-masked]; [email-masked]; 
> [email-masked]; HAND, JAMES, ATTLABS; ASH, GERALD R 
> (JERRY), ATTLABS; Mark Townsley; ext Cullen Jennings
> Cc: [email-masked]; General Area Review Team
> Subject: Gen-ART Last Call Review of 
> Spencer (Nit): I think the last sentence is actually "The 
> solution using MPLS pseudowire
> these goals and requirements." (the solution wasn't actually 
> put forth using MPLS PW technology :-)

Agree with your suggested rewording.
 
> sense of taste for placement or not. Cullen?

In a recent RFC review I saw the RFC editor put the "Contributing
Authors" section right before the "Editor's Address" section, where both
sections were toward the end of the RFC (near the "Acknowledgements"
section).  It seems like a good approach IMO.
 
> like complete sentences, this one is a fragment)

OK.
 
> set aside IN [RFC3095], etc, which was wrong. Perhaps "IANA 
> is requested to assign the following new PW type values:"?

The language is based on exchanges with Luca Martini icw RFC 4446.  The
registry is specified in RFC 4446
http://www.ietf.org/rfc/rfc4446.txt?number=4446.  Using the text you
suggested in the email exchange with Andy:

"IANA has set aside the following PW type values for assignment
according to the registry specified in RFC 4446, Section 3.2:

  PW type Description                                 Reference
  =============================================================
  0x001A  ROHC Transport Header-compressed Packets    [RFC3095]
  0x001B  ECRTP Transport Header-compressed Packets   [RFC3545]
  0x001C  IPHC Transport Header-compressed Packets    [RFC2507]
  0x001D  cRTP Transport Header-compressed Packets    [RFC2508]"

> code-points" would help me with what seems to be ambiguous text.

Again, suggest this clarifying text:

"IANA has set aside the following Pseudowire Interface Parameter Sub-TLV
type values according to the registry specified in RFC 4446, Section
3.3:

                             configuration"

> protocols"? That would be unambiguous.

Agree with your proposed rewording.

 
> Spencer: is it obvious what the decompressor does if it sees 
> a compressor specifying sub-option 1 AND sub-option 2?

"Sub-option 1" refers to the RTP-Compression Suboption, as specified in
Section 5.2.2, and "sub-option 2" refers to the Enhanced RTP-Compression
Suboption, as specified in Section 5.2.3.  These suboptions do not occur
together.  I agree that this should be clarified in the text.
 
>       this document is therefore without consequence in these 
>       profiles.  Other profiles (e.g., ones based on RFC 2507) can
make 
>       use of the parameter by explicitly referencing it.
> 

Have to look into whether there is largest header that can be compressed
in these ROHC profiles.  I agree that the 'without consequence' phrasing
should be clarified.
 
> Spencer (Nit): "a number of PW environments" ("of" is missing)

OK.

 
> Spencer (Nit): missing a colon here...

OK.

> the PW established when it has seen both packets?

Agree with your suggested rewording.
 
> Spencer: "following" is not entirely clear here. Suggest "next"?

OK.
 
>    and PW headers at the beginning of these packets would be formatted

Subject: [PWE3] Re: Header Compression over MPLS & Allison's DISCUSS Commenton PWE3 IANA Allocation Draft
From: "Allison Mankin" <[email-masked]>
To: <[email-masked]>
Cc: <[email-masked]>, <[email-masked]>, <[email-masked]>, <[email-masked]>, <[email-masked]>, <[email-masked]>, "Luca Martini" <[email-masked]>, "Stewart Bryant" <[email-masked]>
Date: Thu, 27 Oct 2005 07:43:11 -0600

Hi,

In a bit of off-list discussion, we had two threads:

1. would it be practical to assume that the RFC 3544
   protocol would be present for IPHC/CRTP eCRTP?  The answer
   is that the implementations are not restricting themselves
   to that design, so Kristofer Sandlun's thoughtful codepoint 
   suggestion isn't an option.

2. are there some very pressing reasons why vendors cannot
   use eCRTP and find themselves using CRTP?  The answer to
   this turns out to be yes, and turns out to be
   sometimes IPR, which is certainly not an unknown finding
   for IETF...

I agreed to put cRTP back in the registrations with a note
that reflects that the use of cRTP has to be an informed tradeoff
(because the later IETF documents say that cRTP has risks for
general use).  I've cc'd the AVT chairs because they may want
to take the new protocol takeup info into account.  Of course,
no specifics - that's also not unknown for IETF.

Here's Yet Another List of these - maybe we are looking at our last one
:)

------
   0x001A  ROHC Transport Header-compressed Packets         [RFC3095, 
 
draft-ietf-rohc-over-reordering-03.txt]
   0x001B  eCRTP Transport Header-compressed Packets        [RFC3545]
   0x001C  IPHC Transport Header-compressed Packets         [RFC2507]
   0x001D  cRTP Transport Header-compressed Packets
[RFC2508][Note 1]

[Note 1]   Although CRTP is viewed as having risks for a number
  PW environments due to misordering and loss, it is registered
  because of markets where commercial issues lead to its choice
  In these circumstances, it must be implemented and deployed
  with care.

-- Add Informational Reference to draft-ietf-rohc-over-reordering-03.txt
------

I added the i-d that gives the advice about improving ROHC for
reordering to the references for ROHC.  This was a good idea derived 
from Kristopher's email.

I couldn't decide there was urgency to record Kristofer's additional
guidance
IPHC and eCRTP here.  But his expertise on these convinced me that IPHC
can
be there without causing trouble, 

So I hope this is it for this material.

Now, about part 1 of my Discuss, if Luca or the group will respond, I'd
love to settle this.

Allison

_______________________________________________
pwe3 mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/pwe3
_______________________________________________
Gen-art mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/gen-art

---

From: "Andrew G. Malis" <[email-masked]>
Date: Wed, 7 Feb 2007 17:11:11 -0500

Spencer,

Thanks for your review.  Please note that I'm no longer at Tellabs - Jerry,
we can put in my new contact info in a note to the RFC Editor, assuming we
don't need to do another rev. If we do, we can put in my new contact info
there.

As the primary editor, I'll let Jerry speak to the nits.  However, I can
reply regarding your comments on sections 5.1 and 5.2.  In these cases, IANA
actually has already reserved the included values for this draft, and we're
just reflecting the fact that IANA has already reserved them - we're really
not requesting the assignments, since they've already been done.  If you can
suggest a less confusing way to reflect that, we can put it in.  The
references to the other RFCs are where ROHC is specified, ECRTP is
specified, etc.

Thanks again,
Andy

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 08 Feb 2007 11:34:19 +0100

Andy,

> gen-art review, or can the changed be handled by instructions to the RFC

Generally, it depends ;-) The document shepherd should advise you on this.
A few small edits are often handled by a note to the RFC Editor, but
if that gets clumsy, a new spin may be appropriate.

     Brian
>> > I'd like to see some work on my comments in 5.1, 5.2 (especially 
>> 5.2.1),
>> > and
>> > set aside IN [RFC3095], etc, which was wrong. Perhaps "IANA is 
>> requested
>> > to
> ------------------------------------------------------------------------
>

---

From: Colin Perkins <[email-masked]>
Date: Thu, 8 Feb 2007 11:01:14 +0000

> Generally, it depends ;-) The document shepherd should advise you  

As document shepherd, I think you should submit a new draft. The AD  
usually has final say, however... Cullen?

Colin

---

From: "ASH, GERALD R \(JERRY\), ATTLABS" <[email-masked]>
Date: Fri, 9 Feb 2007 08:31:50 -0600

Hi Spencer,

Thanks a lot for the quick reply.  Please see below. 

> Sent: Thursday, February 08, 2007 12:52 AM
> To: ASH, GERALD R (JERRY), ATTLABS
> Cc: [email-masked]; General Area Review Team; 
> [email-masked]; [email-masked]; 
> [email-masked]; HAND, JAMES, ATTLABS; Mark Townsley; 
> ext Cullen Jennings; GOODE, B (BUR), ATTLABS; raymond.zhang; 
> [email-masked]
> >    option MUST be included for ECRTP, CRTP and IPHC PW 
> >    types and MUST NOT be included for ROHC PW types.
> >
> configuration options are only applicable to specific header 
> compression formats, e.g., as in Section 5.2.2 for cRTP.
> 
> SHOULD happen if the decompressor sees a packet like this". 
> I'm wondering if we still worry about things like this...

You make a very good point, error legs of course are critical for
whatever erroneous configuration or coding may occur.  We can specify
something like this in Section 5.2.1 (Configuration Option Format)

  "... This configuration
   option MUST be included for ECRTP, CRTP and IPHC PW types and MUST
   NOT be included for ROHC PW types.  A decompressor MUST reject this
   option (if misconfigured) for ROHC PW types and send an explicit
   error message to the compressor [RFC3544]."

> basic - if I follow these recommendations, do I still have a 
> problem, or am OK?

There really isn't any list of 'recommendations' as to how to 'deploy
(CRTP) with care' in the case of lossy links and reordering issues, that
phrasing should be removed as misleading.  Rather, we can further
explain the issue with CRTP, as described in [RFC3545]:

"5.4 Packet Reordering

   ...Although CRTP is
   viewed as having risks for a number PW environments due to reordering
   and loss, it is still the protocol of choice in many cases.  CRTP was
   designed for reliable point to point links with short delays.  It
does
   not perform well over links with high rate of packet loss, packet
   reordering and long delays.  In such cases ECRTP [RFC3545] may be
   considered to increase robustness to both packet loss and misordering
   between the compressor and the decompressor.  This is achieved by
   repeating updates and sending of absolute (uncompressed) values in
   addition to delta values for selected context parameters. IPHC should
   use ..."

Thanks again,
Regards,
Jerry

---

From: Spencer Dawkins <[email-masked]>
Date: Fri, 09 Feb 2007 11:02:52 -0600

Hi, Jerry,

Definitely headed the right direction. Do the right thing - and thanks.

Spencer

From: "ASH, GERALD R (JERRY), ATTLABS" <[email-masked]>

Hi Spencer,

  "... This configuration

"5.4 Packet Reordering

   ...Although CRTP is

Thanks again,
Regards,
Jerry