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

From: "Ash, Gerald R \(Jerry\), ALABS" <[email-masked]>
Date: Sat, 5 Nov 2005 15:33:15 -0600

Magnus,

Thanks for the comments.  See responses in line.

> -----Original Message-----
> From: Magnus Westerlund [mailto:[email-masked]] 
> 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
[email-masked]
https://www1.ietf.org/mailman/listinfo/avt

---

From: Magnus Westerlund <[email-masked]>
Date: Mon, 07 Nov 2005 15:19:11 +0100

Hi,

See inline. Issues not commented on are removed.

> enable HC session configuration."

I think using the references where possible is right. However I do 
question if you can actually use for example the RFC 3241 in manner you 
do. Because if you look in RFC 3241 some problems do arise.

First of all RFC 3241 seems to assume that everything goes over PPP and 
that the PPP frame type is used for demultiplexing of large and small 
CIDs. Also the demultiplexing of uncompressed packets are indicated by 
the PPP frame type field. This while your draft indicates that 
compressed packets are put directly over the PW created. Thus further 
clarifications are needed on these usage.

I think there is need for you to sit down with some header compression 
experts and get all the details of how the negotiation of HC options and 
the actual transport over the mapping will happen. I would recommend 
that you hunt down Carsten Borman ([email-masked]) which is here at the 
IETF meeting and who wrote RFC 3241 to discuss what is needed.

> the PW is created and how the HC context is established.

I am not certain about the conflicting requirements. But you are correct 
about the issues that some understand PWs and some header compression. 
But my understanding of the situation is that you haven't managed to 
make the issues clear between both groups.

> a figure), and are mostly consistent in length.

Yes, I think the page breaks are at logical places. However varying page 
lengths are a bit annoying and one could expect that what ever tool you 
use produce equal length pages.
> Section 4.  I certainly think so.

As I haven't read these references I will not claim that these are not 
sufficient. I was commenting on the language usage that I don't think 
suits a normative description. The implementors shouldn't need to model 
themselves they should be able to follow a description of how to do it.

> 10-15 (TO BE ASSIGNED BY IANA).

So the answer is that the same control octet is used for all the 
different types of PWs that has HC. And any additions to the control 
octet would be applicable to any of the PWs for HC?

> http://www1.ietf.org/mail-archive/web/pwe3/current/msg07685.html.

Okay, I got a little more context from Allison Mankin and I will 
therefore accept this.

Cheers

Magnus Westerlund

Multimedia Technologies, Ericsson Research EAB/TVA/A
----------------------------------------------------------------------
Ericsson AB                | Phone +46 8 4048287
Torshamsgatan 23           | Fax   +46 8 7575550
S-164 80 Stockholm, Sweden | mailto: [email-masked]