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

From: "Dutta, Pranjal K (Pranjal)" <[email-masked]>
Date: Sun, 2 Sep 2012 21:15:25 +0530

I am not aware of any IPR. 

Thanks,
Pranjal

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Andrew G. Malis
Sent: Tuesday, August 28, 2012 11:10 PM
To: [email-masked]
Subject: [PWE3] Working group last call and IPR call for dynamic Multi-Segment PW drafts

PWE3ers,

This begins a two-week working group last call for
https://tools.ietf.org/html/draft-ietf-pwe3-dynamic-ms-pw-15 and
https://tools.ietf.org/html/draft-ietf-pwe3-mspw-er-01 . Please send
comments on these two drafts by replying to this message and including
the pwe3 list. The chairs would appreciate indications that the drafts
have been read and agreement that they are ready to send to the IESG,
even if you don't have other comments.

Coincidentally, we are also polling for knowledge of any IPR that
applies to these drafts, to ensure that IPR has been disclosed in
compliance with IETF IPR rules (see RFCs 3979, 4879, 3669 and 5378 for
more details).

If you are listed as a document author or contributor please respond
to this email whether or not you are aware of any relevant IPR. The
drafts will not be forwarded to the IESG until a response has been
received from each author and contributor.

If you are on the PWE3 WG email list but are not listed as an author
or contributor, then please explicitly respond only if you are aware
of any IPR that has not yet been disclosed in conformance with IETF
rules.

Note that there have already been two IPR disclosures on
draft-ietf-pwe3-dynamic-ms-pw, #998 and #1810. These do not need to be
re-disclosed.

This WG last call will conclude on 12 September 2012.

Thanks,
Andy

On Tue, Aug 28, 2012 at 1:13 PM, Bocci, Matthew (Matthew)
<[email-masked]> wrote:
> All,
>
> The following two drafts related to dynamic Multi-Segment PWs have recently
> been updated:
>
> draft-ietf-pwe3-dynamic-ms-pw-15.txt
> draft-ietf-pwe3-mspw-er-01.txt
>
> Speaking as a co-author, the technical content of these drafts has been
> relatively stable for a long time. These drafts have been developed in the
> working group over many years.
>
> I think these are now ready for working group last call.
>
> Regards
> Matthew
_______________________________________________
pwe3 mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/pwe3

---

From: "Dutta, Pranjal K (Pranjal)" <[email-masked]>
Date: Mon, 3 Sep 2012 06:58:32 +0530

Hi Yakov,
          Pls. refer my responses inline. 

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Yaakov Stein
Sent: Wednesday, August 29, 2012 11:43 PM
To: [email-masked]
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

---

From: "Bocci, Matthew (Matthew)" <[email-masked]>
Date: Mon, 3 Sep 2012 17:13:17 +0200

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)"
<[email-masked]> wrote:

>These drafts are the logical outcome of making the PWE architecture into
>a full-blown (layer) network, and were thus inevitable.
>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.
>
>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>
>
>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.
>

---

From: "Dutta, Pranjal K (Pranjal)" <[email-masked]>
Date: Mon, 3 Sep 2012 21:54:49 +0530

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; [email-masked]
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.

Thanks,

Matthew

On 03/09/2012 02:28, "Dutta, Pranjal K (Pranjal)"
<[email-masked]> wrote:

>These drafts are the logical outcome of making the PWE architecture 
>into a full-blown (layer) network, and were thus inevitable.
><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.
><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>
>
>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).

---

From: Wen Lin <[email-masked]>
Date: Wed, 5 Sep 2012 15:40:29 -0400

When BGP is used for advertising PW address information, I think we shall specify in the section 6.1.3 that it MUST have one or more route targets associated with it since the NRLI is for L2VPN with a an AFI equals to L2VPN(25).

Thanks,
Wen

---

From: "Aissaoui, Mustapha (Mustapha)" <[email-masked]>
Date: Thu, 6 Sep 2012 21:25:42 +0000

Hi Andy,
I am not aware of any IPR against the below drafts.

Regards,
Mustapha.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Andrew G. Malis
Sent: Tuesday, August 28, 2012 11:10 PM
To: [email-masked]
Subject: [PWE3] Working group last call and IPR call for dynamic Multi-Segment PW drafts

PWE3ers,

Thanks,
Andy

---

From: "Bocci, Matthew (Matthew)" <[email-masked]>
Date: Wed, 12 Sep 2012 19:44:15 +0200

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)"
<[email-masked]> 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. "
>
>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. 
>

---

From: "Dutta, Pranjal K (Pranjal)" <[email-masked]>
Date: Wed, 12 Sep 2012 23:16:39 +0530

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; [email-masked]
Subject: Re: [PWE3] Working group last call and IPR call for dynamic Multi-Segment PW drafts

Pranjal,

Regards

Matthew