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

["Bocci, Matthew (Matthew)" <[e-mail]>]

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