Re: [PWE3] Working group last call and IPR call for dynamic Multi-Segment PW drafts

["Dutta, Pranjal K (Pranjal)" <[e-mail]>]

Hi Mathew,
               Looks good to me and I can't add more.
Thanks,
Pranjal

-----Original Message-----
From: Bocci, Matthew (Matthew) 
Sent: Wednesday, September 12, 2012 10:44 AM
To: Dutta, Pranjal K (Pranjal); Yaakov Stein; [e-mail]
Subject: Re: [PWE3] Working group last call and IPR call for dynamic Multi-Segment PW drafts

Pranjal,

Thanks. Here's some proposed test to replace that first paragraph in
Section 6.2.1:

"In order to enable the QoS objectives for a PW to be met on a segment, a
PSN tunnel 
   must be selected that can support at least the required class of service
   and that has sufficient bandwidth available.

    
   PW QoS objectives can thus be met where the next hop for a PW segment
is explicitly 
   configured at each PE, whether the PE is a T-PE or an S-PE in the case
of a segmented 
   PW without dynamic path selection (as per RFC6073). In these cases, it
is possible to
   explicitly configure the bandwidth required for a PW so that the T-PE
or S-PE can
   reserve that bandwidth on the PSN tunnel.

   
   Where dynamic path selection is used and the next-hop is therefore not
explicitly 
   configured by the operator at the S-PE, a mechanism is required to
signal the bandwidth
   for the PW from the T-PE to the S-PEs. This is accomplished by
including an OPTIONAL
   PW Bandwidth TLV.  The PW Bandwidth TLV is specified as follows:"

Regards

Matthew



On 03/09/2012 17:24, "Dutta, Pranjal K (Pranjal)"
<[e-mail]> wrote:

>Hi Mathew,
>           
>"I think the issue is really manual configuration of the PW at each PE
>(whether that is a T-PE, or an S-PE in the case of a segmented PW without
>dynamic path selection as in RFC 6073) enables explicit configuration
>(and hence reservation) of the BW for a PW against the PSN tunnel for the
>next hop. "
>
>You have hit the right point. I think we generalized SS-PW as a whole in
>the dyn-ms-pw draft but
>actually the text was referring to the provisioning model in RFC 6073.
>
>Thanks,
>Pranjal  
>
>-----Original Message-----
>From: Bocci, Matthew (Matthew)
>Sent: Monday, September 03, 2012 8:13 AM
>To: Dutta, Pranjal K (Pranjal); Yaakov Stein; [e-mail]
>Subject: Re: [PWE3] Working group last call and IPR call for dynamic
>Multi-Segment PW drafts
>
>Yaakov, Pranjal,
>
>I do agree that the paragraph at the start of section 6.2.1 could be more
>clearly writhed. I think the issue is really manual configuration of the
>PW at each PE (whether that is a T-PE, or an S-PE in the case of a
>segmented PW without dynamic path selection as in RFC 6073) enables
>explicit configuration (and hence reservation) of the BW for a PW against
>the PSN tunnel for the next hop.
>
>As soon as we dynamically select the S-PEs along the path of an MS-PW,
>and automatically instantiate the Pws at each S-PE, we need a way to
>signal the BW requirements of the PW from the T-PE to the S-Pes along the
>PWs path. 
>
>I also agree that the first sentence about selecting the PSN tunnel could
>be expanded. In order to support the QoS requirements of a PW, a PSN
>tunnel must be selected that supports at least the CoS of the PW, and has
>sufficient BW available for the PW.
>
>I'll propose some revised text to the list shortly.
>
>Thanks,
>
>Matthew
>
>
>On 03/09/2012 02:28, "Dutta, Pranjal K (Pranjal)"
><[e-mail]> wrote:
>
>>Hi Yakov,
>>          Pls. refer my responses inline.
>>
>>-----Original Message-----
>>From: [e-mail] [mailto:[e-mail]] On Behalf Of
>>Yaakov Stein
>>Sent: Wednesday, August 29, 2012 11:43 PM
>>To: [e-mail]
>>Subject: Re: [PWE3] Working group last call and IPR call for dynamic
>>Multi-Segment PW drafts
>>
>>These drafts are the logical outcome of making the PWE architecture
>>into a full-blown (layer) network, and were thus inevitable.
>>You can't define a network with addressing and switching and never
>>define the routing protocols to use it.
>>
>>So I definitely support the concept.
>>
>>However, I am a bit confused about some aspects.
>>
>>In draft-ietf-pwe3-dynamic-ms-pw-15 I read the following statement :
>>   In the SS-PW case the PW QoS requirements may easily be met by
>>   selecting a MPLS PSN tunnel at the S-PE that meets the PW QoS
>>   requirements.
>>
>>Is this true ?
>>
>><Pranjal> IMO, for SS-PW case it should have been "T-PE" instead of
>>"S-PE".
>>Looks like a typo to me. </Pranjal>
>>
>>In the present SS-PW architecture I can indeed TE the MPLS tunnel, but
>>unless I only place a single PW in that tunnel there is no way of
>>reserving BW for a particular PW.
>>Yes, you can place a single PW into each tunnel, but the whole idea of
>>the PWE architecture was to enable scaling by NOT doing that (not to
>>mention making it redundant to use 2 labels) and that is not what is
>>implied in Figure 1.
>>
>><Pranjal> I think Figure 1 probably is just generalization of PW
>>principles without re-defining in this doc on how PW works. A SS-PW
>>indeed can reserve BW on a RSVP-TE Tunnel thru CAC module. Thus the
>>cumulative BW usage on a RSVP-TE Tunnel is accounted for all PWs (and
>>other applications)that shares the tunnel.
>>Further, RSVP-TE tunnel may use Auto-BW etc to provide elasticity on
>>whenever required. </Pranjal>
>>
>>And what is the solution suggested here ?
>>A new "MS-PW Bandwidth Signalling" TLV with TSPECs for each direction.
>>How is this TLV used ?
>>   In the forward direction, after a next hop selection is determined, a
>>   T/S-PE SHOULD reference the forward SENDER_TSPEC object to determine
>>   an appropriate PSN tunnel towards the next signaling hop.
>>Yes, that makes sense. But then
>>   When an S/T-PE receives a PW Bandwidth TLV, once the PW next hop is
>>   selected, the S/T-PE MUST request the appropriate resources from the
>>PSN.
>>How do we request resources for a particular PW in a tunnel ?
>>
>><Pranjal> This essentially means - at each S-PE select a PSN tunnel to
>>next-hop that meets the criteria specified in MS-PW BW TLV. If no such
>>tunnel is found then S-PE would release the mapping to sender with
>>appropriate status code.  </Pranjal>
>>
>>And if I am doing this, why can't I do it for the SS-PW case?
>>Can I define a MS-PW for the particular case of 1 segment and reserve
>>BW for the PW ?
>>
>><Pranjal> Yes, a SS-PW can and implementations (at least I know one)
>>have been doing so.
>>But in SS-PW case there is no need to signal the BW TLV since PSN
>>tunnel directly goes to remote T-PE.
>>
>>However, in dynamic MS-PW, a T-PE may not know in priori that next-hop
>>is a S-PE or T-PE for the PW(since it is PW Routing Table at each hop
>>that decides whether matching TAII route is local or remote). Thus even
>>though the "dynamic" PW may end up as SS-PW, It is possible that the
>>signaling initaited by a T-PE would indeed carry the BW TLV.
>>
>></Pranjal>
>>
>>Add to that the explicit routes in the other draft, and I am starting
>>to smell something I remember from a while back (and I like the smell).
>>However, if this is the way we are going, I would prefer to have the
>>aroma come in through the front door, rather than the kitchen window.
>>
>><Pranjal> Perhaps you might like to elaborate a bit more :-) on your
>>expectations. </Pranjal>
>>
>>Y(J)S
>>
>>_______________________________________________
>>pwe3 mailing list
>>[e-mail]
>>https://www.ietf.org/mailman/listinfo/pwe3
>>_______________________________________________
>>pwe3 mailing list
>>[e-mail]
>>https://www.ietf.org/mailman/listinfo/pwe3
>