[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[AVT] Re: Comments on draft-ietf-avt-hc-over-mpls-protocol-01
Hi,
See inline. Issues not commented on are removed.
Ash, Gerald R (Jerry), ALABS wrote:
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."
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 (cabo at tzi.org) which is here at the
IETF meeting and who wrote RFC 3241 to discuss what is needed.
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.
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.
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.
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.
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.
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.
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).
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?
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.
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: magnus.westerlund at ericsson.com
_______________________________________________
Audio/Video Transport Working Group
avt at ietf.org
https://www1.ietf.org/mailman/listinfo/avt