Subject: [PWE3] draft-ietf-avt-hc-over-mpls-protocol-05.txt

From: "Gray, Eric" <[email-masked]>
Date: Wed, 17 May 2006 18:17:42 -0400

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

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

---

From: "Andrew G. Malis" <[email-masked]>
Date: Thu, 18 May 2006 04:06:52 -0400

Eric,

Thanks for the good read and review.  Some comments in-line:

>perfectly reasonable behavior that does not appear to be required.

This draft uses LDP PW signaling to acquire a PW label for each 
compression context. Because RFC 4447 requires that PW labels be 
allocated from the per-platform label space, every compression 
context between a pair of LSRs will have a unique label.

We already have an IANA Considerations section that requests the 
assignment of these values.  And they have been reserved waiting for 
us.  The text on page 13 should probably say "The following PW type 
values have been set aside for assignment by IANA:"

Reasonable request (see the answer to one of your questions  below).

That's also reasonable to change this to a normative reference.

I don't know - I'll let one of the HC experts answer that one.

Absolutely provisioning may be used, as much as with any other 
PW.  We can probably use that reference to RFC 3031 here.  And 
probably RFC 3985 as well.

>MINOR COMMENTS:

I can agree for the physical layer.  However, I'm not aware of a link 
layer defined  for MPLS packets that doesn't have a header.

Thanks!  I'll let Jerry decide if he likes that better than the current one.

Sounds reasonable.

Thanks again!

Agree.

Thanks again for the careful read!!!

Cheers,
Andy