[AVT] RE: Comments on draft-ietf-avt-hc-over-mpls-protocol-01

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

Magnus,

Thanks for the comments.  See responses in line.

> -----Original Message-----
> From: Magnus Westerlund [mailto:magnus.westerlund at ericsson.com] 
> Sent: Monday, October 31, 2005 5:36 AM
> To: IETF AVT WG; Ash, Gerald R (Jerry), ALABS
> Subject: Comments on draft-ietf-avt-hc-over-mpls-protocol-01
> 
> Hi,
> 
> I have reviewed the draft and have these comments:
> 
> 1. In general I think the draft needs a serious editing round. It is 
> lacking structure, is confusing and repetitive. In general it doesn't 
> read at all as an protocol specification. It is a solution proposal 
> which has grown (badly). I would recommend a serious rewrite of the 
> document to make it more readable and clear.

The draft follows Lars-Erik's suggested outline
http://www1.ietf.org/mail-archive/web/avt/current/msg05530.html.  I
agree with your specific comments below regarding making the protocol
specifications more normative, more self-contained, eliminating
repetition, etc.
 
> 2. I also think the incorporation of the usage of Pseudo 
> Wires are not consistently done either. Some parts seems to be
> lacking discussion on pseudo wires where I expect it. It might be my
> lack of knowledge about how MPLS and pseudo wires relate.

The following paragraph from the I-D is perhaps an example of what
you're talking about:

"An MPLS PW allows protocol data units for various link-layer protocols
to be encapsulated and carried over an MPLS network.  The PW is set up
by a PW signaling protocol [PW-SIG], and the Interface Parameters
Sub-TLV [IANA, PW-SIG] is used to convey HC configuration information
including HC session setup and HC parameter negotiation.  Mechanisms and
principles for HC session setup and HC parameter negotiation, as
described for HC-over-PPP mechanisms [RFC3241, RFC3544], are reused to
enable HC session configuration."

This is terse as a result of various comments we've received to give
references and not to describe how a PW is set up and not to describe
how the HC context is established.  For example, we've received comments
to take out details on PW protocol (suggestions from Andy Malis to
'remove [PW-SIG] details', and from Stewart Bryant to 'remove interface
parameter Sub-TLV details'
http://www1.ietf.org/mail-archive/web/avt/current/msg05722.html).  You
comment below 'information that header compressors can generally handle
multiple packet flows are fine, but can be left as simple informative
note'.  You also comment 'I am also missing ... the process that is
needed to make the different HC work...[and] how the initial setup
signalling for the HC is accomplished.'

So we have a conflict of recommendations, because some people are
familiar with header compression but not MPLS pseudo wires, and other
people are familiar with MPLS pseudo wires, but not familiar with header
compression.  Since this document requires an understanding of both
topics, we'll try to strike a balance and give more explanation of how
the PW is created and how the HC context is established.
 
> 3. The draft has inconsistent page lengths. Please use draft writing 
> tools that ensure a consistent page length.

IMO the page breaks occur at logical places (e.g., not in the middle of
a figure), and are mostly consistent in length.

> 4. In regards to section 4 I find this section confusing. It is
> barely more detailed then the text in section 3 and contains a lot of 
> repetitions. The text is written in informative descriptions rather
> than normative statements on how things shall be done.

Agreed, need to add more 'MUSTs' and normative statements.  We'll
eliminate the repetitions, valid comment.
 
> 5. I also think it focus a lot on the wrong things. It talks a lot on 
> context identifiers which is an header compressor to header 
> decompressor internal thing, while instead being quite thin on the 
> important parts. Sure the information that header compressors can
> generally handle multiple packet flows are fine, but can be left as
> simple informative note. I am missing clear text on how the actual
> signalling for establishing is done. 

See my comments above on your comment #2.

> I find sentences like the following clear 
> indications that things aren't fully baked yet. Section 4.1, first 
> paragraph: "See [PW-SIG] for an explanation of PW signaling, and 
> [PW-HDLC-PPP] for a PW type that can be modeled for the 
> application in this document."
> 
> The use of the word modeled for the application in this document part 
> indicates to me that there is need to describe in detail how this
> should be accomplished. I at least are expecting interoperable 
> protocol, not a solution outline that manufacturers go implement
> after their own head.

The [PW-HDLC-PPP] reference is really a throw-away.  It was there just
to show that we were following a precedent.  I think it'll be fine to
remove the phrase ", and [PW-HDLC-PPP] for a PW type that can be modeled
for the application in this document".  As you say, the key test is
whether interoperable implementations can be built based on the text in
Section 4.  I certainly think so.
 
> 6. I am also missing the sections with text explaining the 
> variations of the process that is needed to make the different
> HC work. Especially in regards how the initial setup signalling for
> the HC is accomplished. I don't think it is sufficient to reference
> the ROHC or CRTP over PPP specs to accomplish that.

As per my comments your comment #2 above, we'll include more details.
 
> 7. Section 4.2, what is the scope of the control octet and 
> how does it relates to the different types of pseudo wires for HC?
> To my understanding the control octet will be applicable to several 
> of the HC mechanisms, however is it guaranteed that they will be the 
> same for all of them. Especially if future extensions are develops.
> Thus should the registry for the control octet field be done on a per
> pseudo wire basis?

The control octet is used for cRTP, ECRTP, IPHC, and reuses the coding
in RFC 3544 http://www.ietf.org/rfc/rfc3544.txt?number=3544, Section 4.
For reasons explained in the draft (to avoid being mistaken for IP, as
discussed in [ECMP-AVOID]), ROHC must also use a control octet with the
upper nibble set to 0000, even if the rest of the octet isn't used (we
could just set the entire octet to MBZ, must be zero).  IMO we don't
need to define more packet types: we've specified a registry for values
10-15 (TO BE ASSIGNED BY IANA).
 
> 8. Section 7, The pseudo wire registration. First of all I think the 
> registration should be done by this document as it is this 
> that defines the need for pseudo wires and how they are used when 
> established. I also find it strange that another draft registers
> these values prior to agreement on this document.

There was much discussion about PW registrations both on the PWE3 and
AVT lists.  Most everyone seemed to agree and I would say consensus is
to accept the registrations, as also pointed out in Andy Malis' post on
the PWE3 list
http://www1.ietf.org/mail-archive/web/pwe3/current/msg07685.html.

> 9. Normative references. I have problems with one of the normative 
> references. [MPLS-HC-REQS]: This is an informative document 
> that guides this solution development process. But it nothing that
> this specification requires for implementation. It is informative
> and of historic nature what requirements that was used for the
> protocol.
> 
> 10. Informative references: I noticed RFC 3985 is present in both the 
> normative and the informative list.

OK, we'll fix the above.

Thanks,
Jerry

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