[Gen-art] Re: Gen-ART Last Call Review of draft-ietf-avt-hc-over-mpls-protocol-07

["Andrew G. Malis" <[e-mail]>]

Spencer,

Works for me. Generally, is there another spin of a draft following a
gen-art review, or can the changed be handled by instructions to the RFC
editor?

Jerry, if you're going to do another rev, my new contact information is:

Andrew G. Malis
Verizon Communications
40 Sylvan Road
Waltham, MA  02451
USA
Email: [e-mail]

Cheers,
Andy

On 2/7/07, Spencer Dawkins <[e-mail]> wrote:
>
>  Hi, Andy (and the rest of the crew)
>
> That's what I thought was happening, based on comments in the ID tracker.
> This one is easy, I think.
>
> OId:
>
> The following PW type values have been set aside for
>   assignment by IANA:
>
> New:
>
> IANA has set aside the following PW type values for assignment:
>
> May they always be so easy, if this works for you :-)
>
> Thanks,
>
> Spencer
>
> ----- Original Message -----
> *From:* Andrew G. Malis <[e-mail]>
> *To:* Spencer Dawkins <[e-mail]>
> *Cc:* [e-mail] ; [e-mail] ;
> [e-mail] ; Jerry Ash <[e-mail]> ; Mark Townsley<[e-mail]>; ext
> Cullen Jennings <[e-mail]> ; General Area Review Team<[e-mail]>; Andrew
> Malis <[e-mail]> ; [e-mail]
> *Sent:* Wednesday, February 07, 2007 4:11 PM
> *Subject:* Re: Gen-ART Last Call Review of
> draft-ietf-avt-hc-over-mpls-protocol-07
>
>
> Spencer,
>
> Thanks for your review.  Please note that I'm no longer at Tellabs -
> Jerry, we can put in my new contact info in a note to the RFC Editor,
> assuming we don't need to do another rev. If we do, we can put in my new
> contact info there.
>
> As the primary editor, I'll let Jerry speak to the nits.  However, I can
> reply regarding your comments on sections 5.1 and 5.2.  In these cases,
> IANA actually has already reserved the included values for this draft, and
> we're just reflecting the fact that IANA has already reserved them - we're
> really not requesting the assignments, since they've already been done.  If
> you can suggest a less confusing way to reflect that, we can put it in.  The
> references to the other RFCs are where ROHC is specified, ECRTP is
> specified, etc.
>
> Thanks again,
> Andy
>
> On 2/7/07, Spencer Dawkins <[e-mail]> wrote:
> >
> > I have been selected as the General Area Review Team (Gen-ART)
> > reviewer for this draft (for background on Gen-ART, please see
> > http://www.alvestrand.no/ietf/gen/art/gen-art-FAQ.html).
> >
> > Please resolve these comments along with any other Last Call comments
> > you may receive.
> >
> > Document: draft-ietf-avt-hc-over-mpls-protocol-07
> > Reviewer: Spencer Dawkins
> > Review Date: 2007-01-30
> > IETF LC End Date: 2007-07-07
> > IESG Telechat date: (not known)
> >
> > Summary: This document is on the right track for publication as Proposed
> >
> > Standard. I had some questions (please see below), but the quality
> > seemed
> > very good (thanks for that).
> >
> > I'd like to see some work on my comments in 5.1, 5.2 (especially 5.2.1),
> > and
> > 5.3. I had some comments on clarity in section 6, but these were
> > more-than-nits-but-not-problems.
> >
> > Thanks!
> >
> > Spencer
> >
> > Comments:
> >
> > 1. Introduction
> >
> >   Voice over IP (VoIP) typically uses the encapsulation
> >   voice/RTP/UDP/IP.  When MPLS labels [RFC3031] are added, this becomes
> >   voice/RTP/UDP/IP/MPLS-labels.  MPLS VPNs (e.g., [RFC2547]) use label
> >   stacking, and in the simplest case of IPv4 the total packet header is
> >   at least 48 bytes, while the voice payload is often no more than 30
> >   bytes, for example.  When IPv6 is used, the relative size of the
> >   header in comparison to the payload is even greater.  The interest in
> >   header compression (HC) is to exploit the possibility of
> >   significantly reducing the overhead through various compression
> >   mechanisms, such as with enhanced compressed RTP (ECRTP) [RFC3545]
> >   and robust header compression (ROHC) [RFC3095], and also to increase
> >   scalability of HC.  MPLS is used to route HC packets over an MPLS
> >   label switched path (LSP) without compression/decompression cycles
> >   at each router.  Such an HC over MPLS capability can increase
> >   bandwidth efficiency as well as the processing scalability of the
> >   maximum number of simultaneous compressed flows that use HC at each
> >   router.  Goals and requirements for HC over MPLS are discussed in
> >   [RFC4247].  The solution put forth in this document using MPLS
> >   pseudowire (PW) technology has been designed to address these goals
> >   and requirements.
> >
> > Spencer (Nit): I think the last sentence is actually "The solution using
> > MPLS pseudowire
> > (PW) technology put forth in this document has been designed to address
> > these goals and requirements." (the solution wasn't actually put forth
> > using
> > MPLS PW technology :-)
> >
> > 2. Contributors
> >
> >   Besides the editors listed in Section 12, the following people
> >   contributed to the document:
> >
> > Spencer (Nit): I like the use of this section, but it seems odd to have
> > it
> > so far from the acknowledgements section. I'm not sure if IESG has an
> > agreed
> > sense of taste for placement or not. Cullen?
> >
> > 3. Terminology
> >
> >   PSN Tunnel Signaling: Used to set up, maintain, and tear down the
> >   underlying PSN tunnel
> >
> > Spencer (Nit): s/Used/A protocol used/ (all of the other definitions
> > look
> > like complete sentences, this one is a fragment)
> >
> > 5.1 MPLS Pseudowire Setup & Signaling
> >
> >   This specification defines new PW type values to be carried within
> >   the FEC object to identify HC PWs for each HC scheme.  The PW type is
> >   a 15-bit parameter assigned by IANA, as specified in the [RFC4446]
> >   registry, and MUST be used to indicate the HC scheme being used on
> >   the PW.  The following PW type values have been set aside for
> >   assignment by IANA:
> >
> >   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]
> >
> > Spencer: "have been set aside for assignment by IANA", with RFC
> > references,
> > confused me badly here. I read this text as saying that these values
> > were
> > set aside IN [RFC3095], etc, which was wrong. Perhaps "IANA is requested
> > to
> > assign the following new PW type values:"?
> >
> >   The PW control word enables distinguishing between various packets
> >   types (e.g., uncompressed, UDP compressed, RTP compressed,
> >   context-state, etc.).  However, the PW control word indications are
> >   not unique across HC schemes, and therefore the PW type value allows
> >   the HC scheme to be identified.
> >
> > 5.2 Header Compression Scheme Setup, Negotiation, & Signaling
> >
> >   Pseudowire Interface Parameter Sub-TLV type values are specified in
> >   [RFC4446].  Two code-points have been reserved, as follows:
> >
> >   Parameter ID Length        Description                     References
> >   0x0D      up to 256 bytes  ROHC over MPLS configuration    RFC 3241
> >   0x0F      up to 256 bytes  CRTP/ECRTP/IPHC HC over MPLS    RFC 3544
> >                              configuration
> >
> > Spencer: Again, something like "IANA is requested to assign these new
> > code-points" would help me with what seems to be ambiguous text.
> >
> > 5.2.1 Configuration Option Format [RFC3544]
> >
> >   Both the network control protocol for IPv4, IPCP [RFC1332] and the
> >   IPv6 NCP, IPV6CP [RFC2472] may be used to negotiate IP HC parameters
> >   for their respective protocols.  The format of the configuration
> >
> > Spencer (Nit): I understand what you're saying with "their respective
> > protocols", but I don't think what you're saying, and what I'm hearing,
> > is
> > actually what these words mean. Perhaps "their respective controlled
> > protocols"? That would be unambiguous.
> >
> >   option is the same for both IPCP and IPV6CP.  This configuration
> >   option MUST be included for ECRTP, CRTP and IPHC PW types and MUST
> >   NOT be included for ROHC PW types.
> >
> > Spencer: Is it obvious what the decompressor does if it sees this
> > configuration option for ROHC PW types? It may be - I'm just asking. I'd
> > have the same question elsewhere (in 5.2.2, for example), but will only
> > ask
> > it here.
> >
> > 5.2.3 Enhanced RTP-Compression Suboption [RFC3544]
> >
> >   To use the enhanced RTP HC defined in [RFC3545], a
> >   new sub-option 2 is added.  Sub-option 2 is negotiated instead of,
> >   not in addition to, sub-option 1.  This suboption MUST be included
> >
> > Spencer: is it obvious what the decompressor does if it sees a
> > compressor
> > specifying sub-option 1 AND sub-option 2?
> >
> >   for ECRTP PWs (0x001B) and MUST NOT be included for other PW types.
> >
> >   MAX_HEADER
> >
> >      NOTE: The four ROHC profiles defined in RFC 3095 do not provide
> >      for a MAX_HEADER parameter.  The parameter MAX_HEADER defined by
> >      this document is therefore without consequence in these profiles.
> >      Other profiles (e.g., ones based on RFC 2507) can make use of the
> >      parameter by explicitly referencing it.
> >
> > Spencer: is there any statement you can make about the largest header
> > that
> > can be compressed in these profiles? Even if not, it might be good to
> > say so
> > explicitly - I don't know what "without consequence" says about what
> > implementations may encounter in practice.
> >
> > 5.4 Packet Reordering
> >
> >   Packet reordering for ROHC is discussed in [RFC4224], which is a
> >   useful source of information.  In case of lossy links and other
> >   reasons for reordering, implementation adaptations are needed to
> >   allow all the schemes to be used in this case.  Although CRTP is
> >   viewed as having risks for a number PW environments due to reordering
> >
> > Spencer (Nit): "a number of PW environments" ("of" is missing)
> >
> >   and loss, it is still the protocol of choice in many cases.  In these
> >   circumstances, it must be implemented and deployed with care.  IPHC
> >   should use TCP_NODELTA, ECRTP should send absolute values, ROHC
> >   should be adapted as discussed in [RFC4224].  An evaluation and
> >   simulation of ECRTP and ROHC reordering is given in [REORDER-EVAL].
> >
> > Spencer (Probably a Nit): It wasn't obvious to me whether these
> > recommendations are sufficient to "implement and deploy with care", or
> > whether additional precautions must be taken. Even putting these
> > recommendations in a numbered list immediately after "deployed with
> > care"
> > would be sufficient, if these recommendations are sufficient.
> >
> > 6. HC Pseudowire Setup Example
> >
> >   The Label Mapping message sent from R4/HD to R1/HC would be almost
> >   identical to the one sent in the opposite direction, with the
> >   following exceptions
> >
> > Spencer (Nit): missing a colon here...
> >
> >   As soon as either R1/HC or R4/HD had both transmitted and received
> >   Label Mapping Messages with the same PW Type and PW ID, it could
> >
> > Spencer: "it" is not entirely clear here. "It" usually refers to one
> > thing
> > (in my mind), and the subject of the sentence is two things ("either
> > R1/HC
> > or R4/HD"). Mumble. Would it help to say that each ROHC endpoint
> > considers
> > the PW established when it has seen both packets?
> >
> >   consider the PW established.  R1/HC could send ECRTP packets using
> >   the label it received in the Label Mapping Message from R4/HD, Lr4,
> >   and could identify received ECRTP packets by the label it had sent to
> >   R4/HD, Lr1.  And vice versa.
> >
> >   The following 3 RTP packets from this flow would be sent as
> >
> > Spencer: "following" is not entirely clear here. Suggest "next"?
> >
> >   COMPRESSED_UDP_8, to establish the absolute and delta values of the
> >   IPv4 identifier and RTP timestamp fields.  These packets would use
> >   the same ECRTP CID as the previous 3 FULL_HEADER packets.  The MPLS
> >   and PW headers at the beginning of these packets would be formatted
> >   as follows:
> >
> >
> >
> > _______________________________________________
> > Ietf mailing list
> > [e-mail]
> > https://www1.ietf.org/mailman/listinfo/ietf
> >
>
>

_______________________________________________
Gen-art mailing list
[e-mail]
https://www1.ietf.org/mailman/listinfo/gen-art