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

[Brian E Carpenter <[e-mail]>]

Andy,

On 2007-02-08 07:06, Andrew G. Malis wrote:
> 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?

Generally, it depends ;-) The document shepherd should advise you on this.
A few small edits are often handled by a note to the RFC Editor, but
if that gets clumsy, a new spin may be appropriate.

     Brian
> 
> 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

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