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

[Spencer Dawkins <[e-mail]>]

The AD gets to pick, but I do see small revisions handled with RFC Editor notes.

And thanks!

Spencer
  ----- Original Message ----- 
  From: Andrew G. Malis 
  To: Spencer Dawkins 
  Cc: [e-mail] ; [e-mail] ; [e-mail] ; Jerry Ash ; Mark Townsley ; ext Cullen Jennings ; General Area Review Team ; [e-mail] ; Andrew Malis 
  Sent: Thursday, February 08, 2007 12:06 AM
  Subject: Re: Gen-ART Last Call Review of draft-ietf-avt-hc-over-mpls-protocol-07



  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 
      To: Spencer Dawkins 
      Cc: [e-mail] ; [e-mail] ; [e-mail] ; Jerry Ash ; Mark Townsley ; ext Cullen Jennings ; General Area Review Team ; Andrew Malis ; [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