[AVT] RE: I-D ACTION:draft-ash-avt-hc-over-mpls-protocol-00.txt

["Ash, Gerald R \(Jerry\), ALABS" <gash at att.com>]

Hi Lars-Erik,

We really appreciate your thorough reviews and helpful suggestions.

> First of all, I must say you've done a great job with this update. The
> technical solution is starting to get in shape, and so also the draft
> itself. I just have a few issues that I believe should be given some
> additional attention, and I'll start with the least technical one:
> 
> * References
>   
>  - There is one incorrect reference to RFC 3409, which I think has
>    not much to do with this document. The correct document to refer
>    to is RFC 3241, "Robust Header Compression (ROHC) over PPP".
> 
>  - There is one invalid reference [IPCP], I guess it should be
>    [RFC1332]
> 
>  - As it is currently written, I believe [RFC3544] and [RFC3241]
>    would be normative for this document. I believe some other
>    references, e.g. some MPLS references, would also be normative.
> 
>  - There are many informative references, go through them and make
>    sure they all are actually bringing any value as informative to
>    this document (I am not sure about the MPLS references). It might
>    also make sense to group them based on content (HD vs MPLS, etc),
>    that would make it easier for the reader.

Agree to all the above suggestions.
 
> * Separation of functionality
> 
>   As previously discussed, I believe it would be useful to more
>   clearly separate negotiation/setup/signaling from encapsulation. As
>   it now stands, I am not sure I understand what purpose the 
>   separation of chapter 2 and chapter 3 serves. Chapter 2 is about
>   both setup and encapsulation, while chapter 3 is about setup only.

OK, perhaps we could map current Sections 2 and 3 into the following
sub-sections:

Section 2.1: link layer encapsulation type field  (current Section 2.2)
Section 2.2: PW and HC scheme negotiation/setup/signaling (current
Sections 2.1 and 3)
Section 3: procedures summary (from "In Figure 1 ..." in current Section
2)

If you have another suggested organization, please let us know.

> * Requirements fulfillment
> 
>   In chapter 1, it is said that the outlined solution fulfils the
>   requirements of [MPLS-HC-REQ]. I am not sure this listing is really
>   needed, neither do I think it is fully correct.
> 
>   a) is true, that is a design decision for this document
>   b) is also true, ok, it is the whole purpose of the document
>   c) is not really achieved by this document, but depends on the
>      header compression scheme used, and especially on how that
>      scheme is implemented. This document can not guarantee anything
>      in this regard, but it provides what it can to make this 
>      possible.  What this document do indeed provide, is the
>      mechanism to avoid  multiple compression/decompression cycles,
>      but that is b) above.
>   d) "signal context identification", I do not know what is meant
>      with that, neither do I know what standard protocols are referred
>      to, is it the MPLS PW mechanisms that are meant, and/or the
>      HC-over-PPP specifications (for the latter, see also below).

We can make it more clear that we meant to use existing CRTP, ECRTP or
ROHC procedures
to signal these natively.  The nice thing about the approach is that it
achieves functional separation from the PW signaling.

>   e) this is implementation dependent on HC-protocol level, and it
>      is out of control of this specification, which is dependent on
>      the HC scheme implementation(s). Or do PW provide means for 
>      in-order delivery?

Agreed that it is HC scheme dependent, however, PW does provide a means
for in-order delivery.

>   Overall, I do not see the point of listing these things here. I
>   think it is sufficient to say that the solution(s) outlined in
>   this document have been designed and chosen to address the
>   goals and requirements of [MPLS-HC-REQ].

We agree with your suggestion to replace the material with a statement
like the one above.
 
> * "Flow Setup", end of chapter 2 introduction
> 
>   - Is this really only about "setup"? It does not look so to me.
> 
>   - I believe this can be generalized so that it is HC-scheme
>     independent, should not be hard to do.

Agreed, we'll re-word to make it HC-scheme independent.
 
>   - It is not clear whether 2) is mandatory or not, i.e. is it
>     mandatory to have a bidirectional connection?

We think it is mandatory to have a bidirectional connection for
CRTP/ECRTP/ROHC with feedback channel, and also for voice signaling and
flow control (RTCP).
 
> * "Flow setup", last bullet, "Free up CID when flow terminates"
> 
>   - How can one ever know that a flow has terminated? For UDP-based
>     "flows", there is no such thing. Also, why should one free
>     CIDs, I agree CIDs should be re-usable, but if memory is
>     allocated for a certain number of CIDs, that memory should
>     last as long as the HC instance(s) is(are) alive. It is the
>     compressor that may choose to re-use a CID. This has been
>     thoroughly discussed in the ROHC WG, captured in chapter 7
>     of <draft-ietf-rohc-rtp-impl-guide-11.txt>.

Agreed.  <draft-ietf-rohc-rtp-impl-guide> has a nice discussion on CID
re-use, which we'll reference.

> * Link layer packet type field
> 
>   The requirement that link layers must provide packet type
>   identification for HC packets does not apply to ROHC. Therefore
>   I believe it is an improper design to require the extra
>   multiplexing byte (Pkt Typ field) for all schemes. There is
>   a negotiation of HC scheme done for the "channel", so why not
>   say that for schemes that can not identify their own packet
>   types, the extra byte is needed, as described. Or actually
>   negotiate whether to have this byte, independent of HC scheme
>   (although some require it).

Dynamic negotiation of the multiplexing byte may require a bit more work
and complexity than is desirable.  Since the gateways need to be
configured for each HC type anyway, we could follow this suggestion by
saying that the extra byte will be needed for those HC schemes that can
not identify their own packet type.  That is, an extra byte will be
added by default once a certain HC type is configured.
 
> * I think it makes sense to re-use the principles of RFC 3544 and
>   RFC 3241, but I also think this document will actually have to
>   define more specifically how the negotiation is done (with
>   similar principles as in 3544 and 3241). Both RFC 3544 and RFC
>   3241 are written as plug-ins to the PPP control protocol IPCP,
>   so just referring to them here where there is no PPP or IPCP
>   does not convince me about the completeness of the solution.

Are you suggesting that we provide a more detailed specification to
extend the use of IPCP or similar scheme for HC parameter negotiation
over MPLS?

> Rgds,
> /L-E

Thanks again,
Regards,
Jerry

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