[AVT] draft-ietf-avt-hc-over-mpls-protocol-05.txt

COMMENTS:
========

On page 8, next to last paragraph, it provides the following
example:

  "For example, if two different compressors, HCa and HCb, both 
   assign the same CID to each of 2 separate flows destined to 
   decompressor HDc, HDc can still differentiate the flows and 
   locate the proper decompression context for each, because the 
   tuples <PWlabel-HCa, CID> and <PWlabel-HCb, CID> are still 
   unique."

This is an example, yet I cannot find the explicit statement in
the protocol portion of this specification (nor in the base PWE
signaling specification RFC 4447) that requires the LSR (which 
will be performing de-compression) to ensure that the label it
distributes via LDP for a channel is unique.  The example assumes 
perfectly reasonable behavior that does not appear to be required.

-----------------------------------------------------------------

On page 13, about mid-page, the following statement appears:

  "The following PW type values have been reserved [RFC4446]:

   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]"

This is not strictly accurate, as RFC 4446 makes no direct
mention of these reserved values.  Also I cannot find them
listed in the IANA registry.

I checked with Luca, and this was apparently an oversight,
and these values are indeed intended to be used as indicated.

I would suggest changing the words to read - 

  "The following PW type values are available for use [RFC4446]:

   ..."

-----------------------------------------------------------------

I strongly suggest that you take whatever steps you need to in
order to be able to list RFC 3031 as an Informative Reference.

-----------------------------------------------------------------

The current wording (section 5.3, page 21) -  

"As discussed in [ECMP-AVOID], since this MPLS payload type is 
 not IP, the first nibble is set to 0000 to avoid being mistaken 
 for IP. This is also consistent with the encoding of the PWE3 
 control word [PW-CNTL-WORD]."

- the last part will not be true if [PW-CNTL-WORD] subsequently 
changes this usage.  Since [PW-CNTL-WORD] is a work in progress 
and can theoretically change, the corresponding reference should 
be Normative.

A subsequent reference to [PW-CNTL-WORD] in the 2nd paragraph
after this reference also appears to be Normative in nature.

-----------------------------------------------------------------

QUESTIONS:
=========

In number 3 (section 4, under summary of procedures), it says:

"R1/HC assigns a CID to the flow and uses the R1 --> R4 LSP/PW to
 send HC scheme control packets and compressed packets to R4/HC, 
 with LSP and PW labels."

Do the existing compression schemes universally provide a means
to ensure that this information is received by the de-compressor
(i.e. - do they include an ACK for this)?

-----------------------------------------------------------------

Section 5.1, 1st paragraph, 3rd sentence (next to last one on
page 12) - "Any acceptable method of MPLS label distribution"
- what does "acceptable" mean?  Does it have to be via label
distribution, or can configuration be used?  

I suspect there is a reference you could point to for this...

MINOR COMMENTS:
==============

In Figure 3, the delimination of "header" should be removed from
both the Link Layer and PHY portions of the diagram.  It is more
accurate simply to show that the PDU at that level is larger by
some unspecified amount.  The actual formats for a variety of L2
and L1 PDUs is nowhere near as simple as this figure indicates.

Figure 3 is on page 12 in version "05".

-----------------------------------------------------------------

NITs:
====
There are too many acronyms in the abstract, many not expanded
and some not actually necessary at this point. This is often a
problem for the RFC Editor.  In addition, the abstract is very
nearly a verbatim copy of the introduction.

I suggest replacing the entire abstract with the following:

   This specification defines how to use Multi-Protocol Label
   Switching (MPLS) to route Header-Compressed (HC) packets over
   an MPLS Label Switched Path (LSP).  HC can significantly 
   reduce packet-header overhead and - in combination with MPLS
   - can also increases bandwidth efficiency and processing 
   scalability (in terms of the maximum number of simultaneous 
   compressed flows that use HC at each router).  Here we define
   how MPLS pseudowires are used to transport the HC context and 
   other control messages between the ingress and egress MPLS 
   Label Switched Router (LSR).  This is defined for a specific
   set of existing HC mechanisms that might be used - for example 
   - to support Voice over IP.  This specification also describes
   extension mechanisms to allow support for future - as yet to be 
   defined - HC schemes.  In this specification, each HC scheme 
   operates independently over a single pseudowire instance very 
   much as it would over a single point-to-point link.

-----------------------------------------------------------------

The Editors are listed twice - both in the section entitled
"Contributors" and in the section entitled "Authors' Addresses".

Since the "Contributors" section starts with -

"Besides the editors, the following people contributed to the
 document:"

- names and contact information for the Editors should be removed
from that section.

-----------------------------------------------------------------

The following terms and/or acronyms need to be added to section
3 ("Terminology") - as separate entries:

cRTP		[RFC 2508]
ECRTP		[RFC 3545]
ESP*		[]
IPHC		[RFC 2507]
ROHC		[RFC 3095]
RTP*		[]

In addition, some of these (*) should probably list a reference 
as part of the definition.

Many of these are listed under "header compression", but are 
referenced through-out the document.  Finding the definitions
underneath a group definition is not necessarily obvious.

The definition for MPLS is incomplete both in that it does not 
end with a period and because it does not include technology
as part of the definition - as follows (for example):

  "Multi Protocol Label Switching (MPLS): an IETF working group 
   and the effort associated with the working group, including
   the technology (signaling, encapsulation, etc.) itself."

-----------------------------------------------------------------

Section 4 ("Header Compression over MPLS Protocol Overview"), 1st
paragraph, 4th sentence - "... such as frame relay ..." instead
of "... such frame relay ..." 

The sentence would actually read better if this part were in
parens (from "such as ..." to "... ATM PVCs") instead of being
comma separated.

-----------------------------------------------------------------

Next to last sentence, bottom of page 9, there is a reference to
further description of parameters in "Section 4."

I suspect this is supposed to be "Section 5" - both because this
text (on half of page 6, all of pages 7, 8 and 9, and most of 
page 10) is in Section 4 - and because Section 5 does actually 
include quite a bit of text on "parameters."

--
Eric Gray

_______________________________________________
Audio/Video Transport Working Group
avt@ietf.org
https://www1.ietf.org/mailman/listinfo/avt