Subject: [Tsvwg] AD Evaluation Comments on draft-ietf-tsvwg-rsvp-dste-03

From: Francois Le Faucheur <[email-masked]>
Date: Sat, 8 Jul 2006 11:55:06 -0400

Hello,

This is to announce that a new version of the draft (-04) will be  
posted as soon as I-D posting is reopen, to address the AD (Magnus)  
Evaluation comments.
These comments and proposed resolution are included below for  
information/comments.

Cheers

Francois

>>>
>>> 1. Page 5:
>>>      - There is exactly one reservation per MPLS-TE tunnel, whereas
>>>         RFC 2746 permits many reservations per tunnel.
>>>
>>> The reservation here refered too is the aggregate reservation  
>>> the  MPLS-TE tunnel represents? This is not 100% clear, but is  
>>> clearly  not end-to-end reservations.
>> With MPLS-TE Tunnel, there is a single simple case, which is one   
>> single aggregate reservation per tunnel.
>> In RFC2746, several modes are permitted.
>> One permitted mode is where you also have a single Aggregate   
>> reservation shared by all the flows carried over teh tunnel (Type  
>> 2  tunnels).
>> Another permitted mode is actually that you establish one  
>> reservation  per E2E flow (even if all the flows share the same  
>> tunnel). In that  case you need a technique to multiplex flows  
>> over the tunnel and to  bind a reservation to each multiplex.  
>> (This is Type 3 tunnels). The  multiplexing technique of RFC2746  
>> is to use UDP encaps over tunnel  with different UDP ports for  
>> each reservation.
>> "
>>        3. The (logical) link may be able to make reservations for
>>           individual end-to-end data flows.  We refer to this case  
>> as a
>>           type 3 tunnel. Note that the key feature that distinguishes
>>           type 3 tunnels from type 2 tunnels is that in the type  
>> 3  tunnel
>>           new tunnel reservations are created and torn down  
>> dynamically
>>           as end-to-end reservations come and go.
>> "
>> Because RFC2746 wanted to support all these options, it got a bit   
>> more complicated.
>> The sentence you quote from our draft is trying to say that,  
>> unlike  RFC2746, we do not need to support a mode with one  
>> reservation per  E2E flow. We only want to support a mode with one  
>> single aggregate  reservation per Tunnel.
>> If you feel this needs clarification, perhaps we coudl rephrase  
>> into  something like:
>> "There is exactly one aggregate reservation per MPLS-TE tunnel,   
>> whereas RFC 2746 permits a model where one reservation is  
>> established  on the tunnel path for each  E2E flow".
>
> Yes, I think the above proposed sentence is easier to understand  
> and I would suggest that you use that instead.
>
>
>>> 3. Page 10-11:
>>>
>>>    Whether final or tentative, the Aggregator makes a mapping  
>>> decision
>>>    and selects a TE tunnel. Before forwarding the E2E Path message
>>>    towards the receiver, the Aggregator SHOULD update the ADSPEC   
>>> inside
>>>    the E2E Path message to reflect the impact of the MPLS TE  
>>> cloud  onto
>>>    the QoS achievable by the E2E flow. This update is a local   
>>> matter and
>>>    may be based on configured information, on information  
>>> available in
>>>    the MPLS TE topology database, on the current TE tunnel path, on
>>>    information collected via RSVP-TE signaling, or combinations of
>>>    those.
>>>
>>> When is it possible to to break the SHOULD in the above  
>>> paragraph.  And what effects does that have. I basically ask why  
>>> this is not a  MUST.
>> In practise, the notion of One Pass With Advertisement (OPWA) is  
>> not  commonly used. Ie applications typically know what they want  
>> to  reserve and don't take into account information gathered in  
>> the  Adsepc. So while it is desirable that the Adsepc be updated  
>> so that,  in the future, apps that want to take into account netk  
>> info  dynamically can do so, most deployments will live very  
>> happily even  if the Adspec is not updated.
>> Seemed that a "SHOULD" was the right level.
>
> Okay, I am not questioning the SHOULD's existence in this case.  
> However I think the paragraph would be helped with some sentence or  
> two what the impact of not following the SHOULD is. I think it is  
> quite important so that the one that is thinking of breaking the  
> should can receive some guidance on the impact of that decision.
>
>
>>> 4. Page 11:
>>>    To send the E2E Path message, the Aggregator MUST address it   
>>> directly
>>>    to the Deaggregator by setting the destination address in the IP
>>>    Header of the E2E Path message to the Deaggregator address. The
>>>    Router Alert is not set in the E2E Path message.
>>>
>>>    Optionally, the Aggregator MAY also encapsulate the E2E Path   
>>> message
>>>    in an IP tunnel or in the TE tunnel itself.
>>>
>>> Why must the PATH message be changed if it is encapsulated in a   
>>> tunnel that ends at the deaggregator? Is it for consistency or   
>>> something else?
>> Consistency is one reason.
>> Another reason is that with MPLS TE , if Pen-Ultimate Hop Popping  
>> is  used, the Pen-Ultimate hop would expose the PAth message and  
>> if it  had Router Alert it woudl intercept it when it shouldn't  
>> (as it  should only be seen by teh Ultimate Hop ie teh Deaggregtor/ 
>> Tail-end).
>
> Okay, I simple liked to have a motivation as I didn't fully  
> understand the reason for this procedure. No change needed.
>
>>> 5. Section 8.
>>>
>>> I am bit concerned about describing in what I interpret as being   
>>> normative language a procedure for something that is not listed  
>>> as  a normative reference nor is yet as stable as this document.
>> Good point. How about we move this to an Appendix?
>> This would be quite easy as the text is not mandating anything   
>> really, it is just saying that teh "RSVP over TE" can be combined   
>> with RSVP Proxy and illustrates how teh two would play together.
>
> Yes, please do that and you might consider tweaking the text to  
> explain more clearly upfront that this is just a informational  
> strawman of how this could work.
>
>>> 6. Appendix A:
>>> "The bandwidth request takes into account VoIP header compression,
>>>    where applicable."
>>>
>>> Are you refering to RSVP header compression hints (RFC 3006) or   
>>> something else? A reference may be in order here.
>> Yes that was referring to RFC3006.
>> I think we could either:
>> 	-(A) get rid of this sentence altogether as it is pretty much   
>> orthogonal to what is discussed in Appendix A (it is basically   
>> regular RSVP operations).
>> 	-(B) Add a reference + tweak the text because right now it sounds  
>> a  bit like the requested bandwidth would be lowered in case of   
>> compression, while the way it works is that the requested  
>> bandwithd  is teh same but there is a hint that the admitted  
>> bandwidth can be  reduced at every hop.
>> Personnaly I favor (A), but either is fine.
>
> I agree with A, it has impact on what is presented in that text.
>
>>> 7. Page 27:
>>> "     - When GW1 receives the SIP response message and learns  
>>> the  codec
>>>         to be used, it knows how much bandwidth is required for the
>>>         call."
>>>
>>> I would like to protest against it being the codecs that  
>>> determine  the bit-rate of the session. For example the SDP may  
>>> express that  an RTP session uses PCM/8kHz sampling and still say  
>>> that the  maximum session bandwidth is 256kbit/s. That due to  
>>> that it knows  up to 4 simultaneous flows may be used in the  
>>> session.
>>>
>>> I would change it to:
>>>      - When GW1 receives the SIP response message with the SDP, it
>>>        determines how much bandwidth is required for the call.
>> sounds good.
> Good
>
> 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]