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

Eric,

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

At 5/17/2006 18:17 -0400, Gray, Eric wrote:
>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.

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.

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

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

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

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

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

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

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

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

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

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:
>==============
>
>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".

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.

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

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

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

Sounds reasonable.

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

Thanks again!

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

Agree.

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

Thanks again for the careful read!!!

Cheers,
Andy

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