Subject: [PWE3] draft-medved-pwe3-of-config-00.txt posted, review please

From: David Meyer <[email-masked]>
Date: Tue, 3 Jul 2012 10:11:14 -0700

Folks,

"MPLS-TP PseudoWire Configuration using OpenFlow 1.3" has just been
posted. Looking forward to your review.

--dmm (for Jan, dward, and Andrew)

---

From: "Andrew G. Malis" <[email-masked]>
Date: Tue, 3 Jul 2012 14:14:18 -0400

Dave, Jan, Andrew,

An interesting draft. I have a few comments, with my WG chair hat off:

1. An editorial comment, there's no "-" or internal uppercase "W" in
"Pseudowire", which is the proper spelling (I saw at least three
different spellings in the draft).

2. Section 1.3 states: "PWs are
   configured as bi-directional paths over the MPLS-TP network, usually
   by an external management platform.  At present no open standards
   exist to provision these PWs, and therefore there is a reliance on
   vendor specific provisioning platforms."

Certainly, there's nothing that prevents the use of T-LDP for PW use
in MPLS-TP networks, this is already documented in section 5.2 of RFC
6373.

Speaking of which, you should also have a table in your draft similar
to the table in section 5.2 that shows how your draft meets the
MPLS-TP control plane requirements listed in section 2 of RFC 6373.

You may also wish to read draft-cao-pwe3-mpls-tp-pw-over-bidir-lsp,
which specifies useful functionality in this area.

In any case, you should be clear that this is an alternative control
plane to T-LDP.

3. Section 4: In addition to RFC 6423, you may wish to include a
reference to draft-ietf-pwe3-vccv-for-gal, which defines the VCCV mode
for use with MPLS-TP. You may also wish to reference RFC 5860.

Cheers,
Andy

On Tue, Jul 3, 2012 at 1:11 PM, David Meyer <[email-masked]> wrote:
> _______________________________________________
> pwe3 mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/pwe3

---

From: Alexander Vainshtein <[email-masked]>
Date: Wed, 4 Jul 2012 05:05:24 +0000

Andy and all,

I've looked up the draft in question, and I have some comments/questions in addition to Andy's:

  1.  The PWE3 WG has defined multiple MIBs that can be used for PW setup and teardown by a      management application (MPLS-TP or not). IMO the draft should indicate that the method proposed there is an alternative not just to PW signaling via T-LDP (as Andy has said) but also to static PW setup using these MIBs.
  2.  The wording of the draft seems to suggest a difference between the head-end PE and the tail-end one, e.g., as in he following fragment: "Although the Virtual OF switch is the same a both the head-end and tail-end nodes, the group table is only used at the head-end node, where a Fast Failover group is set up for each pair of ports that correspond to the primary-backup Transport LSP pair.  At the tail-end node, only flows are set up." I do not understand how does this (and similar) fragments deal with the fact of PWs being inherently bidirectional.
  3.  The PWs run in MPLS (or MPLS-TP) tunnels in order to improve scalability of P routers, because the same tunnel between a given pair of PEs can be shared by multiple PW instances. It is not clear from the text how such sharing can be accommodated in the proposed OF switch model.
  4.   Reference to RFC 6423 suggests that OAM discussion in the draft is PW OAM and OAM for Tunnel LSPs. Does this imply that the protection actions are triggered by the PW-level OAM, and, what is supposed to happen if a pair of T-LSPs is shared by multiple PW instances?
  5.  The text defining the OF switch and its matching rules is not clear. In particular, it seems to imply that PW labels are checked from being received from a specific T-LSP (as a port of the OF switch). IMHO this a clear contradiction to the MPLS (and MPLS-TP) data plane as defined in RFC 3031, and to the fact that PW labels are allocated from the per-platform label space (as per RFC 4447).

My 2c,

     Sasha

________________________________________
From: [email-masked] [[email-masked]] on behalf of Andrew G. Malis [[email-masked]]
Sent: Tuesday, July 03, 2012 8:14 PM
To: David Meyer; Jan Medved; Andrew McLachlan
Cc: [email-masked]
Subject: Re: [PWE3] draft-medved-pwe3-of-config-00.txt posted, review please

Dave, Jan, Andrew,

Cheers,
Andy

This e-mail message is intended for the recipient only and contains information which is CONFIDENTIAL and which may be proprietary to ECI Telecom. If you have received this transmission in error, please inform us by e-mail, phone or fax, and then delete the original and all copies thereof.

---

From: Alexander Vainshtein <[email-masked]>
Date: Wed, 4 Jul 2012 05:16:16 +0000

Hi all again,

One more comment (forgot to include it in the original email) added at the end of the list in blue.

Regards,

     Sasha

________________________________
From: Alexander Vainshtein
Sent: Wednesday, July 04, 2012 7:05 AM
To: Andrew G. Malis; David Meyer; Jan Medved; Andrew McLachlan
Cc: [email-masked]; Mishael Wexler; Rotem Cohen; Gideon Agmon; Andrew Sergeev; Idan Kaspit; Vladimir Kleiner
Subject: RE: [PWE3] draft-medved-pwe3-of-config-00.txt posted, review please

Andy and all,

  6.  In order to assign PW labels, the management application needs the information about the pool of unused MPLS labels on each of the PE devices. The methods for obtaining such information using the OpenFlow tehnique are not mentioned in the draft.

My 2c,

     Sasha

Dave, Jan, Andrew,

Cheers,
Andy

---

From: Yaakov Stein <[email-masked]>
Date: Thu, 5 Jul 2012 05:39:43 +0000

In addition to Andy's remark on "pseudowire"

G.ach and G-ach should be GACH or G-ACh.

To answer one of Sasha's questions,

the terms head-end and tail-end refer to the protection switching,

which is not limited to bidirectional switching.

I don't understand why this use case is the first one being addressed.

Static configuration of LSPs can obviously be done using OpenFlow,

and perhaps a document explaining this would be useful (if perhaps somewhat trivial).

I think that the case for using OpenFlow (instead of T-LDP) for PWs is not as clear.

PW setup as a host of interface parameters that need to be specified,

that OpenFlow would be hard-pressed to address.

The particular uses being described here seem to be an academic exercise

to show that OpenFlow can (barely) accomplish some very specific tasks.

Finally, I wholeheartedly agree with Sasha's added remark

that this solution would seem to be limited to OpenFlow-only solutions

and not to hybrid ones, because of a fundamental clash between the

the on-switch label generator and controller label binding.

Y(J)S

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of David Meyer
Sent: Tuesday, July 03, 2012 20:11
To: [email-masked]
Subject: [PWE3] draft-medved-pwe3-of-config-00.txt posted, review please

Folks,

pwe3 mailing list

[email-masked]

---

From: David Meyer <[email-masked]>
Date: Thu, 5 Jul 2012 06:37:44 -0700

Thanks Andrew. Working on the next rev and will incorporate your
suggestions/comments.

---dmm

---

From: David Meyer <[email-masked]>
Date: Fri, 6 Jul 2012 07:43:05 -0700

Hey Andy,

> different spellings in the draft).

Fixed, thanks.

> MPLS-TP control plane requirements listed in section 2 of RFC 6373.

This is part of what wasn't well stated in the draft. We're not
proposing a new TP control plane, rather just a way of provisioning
PWs over existing MPLS-TP control planes.
> In any case, you should be clear that this is an alternative control

As mentioned above, its not an alternate control plane.

> for use with MPLS-TP. You may also wish to reference RFC 5860.

Still thinking about this one.

Thanks for the comments. New (clearer) revision should be out by Monday.

--dmm

---

From: David Meyer <[email-masked]>
Date: Fri, 6 Jul 2012 07:59:46 -0700

Alexander,

On Tue, Jul 3, 2012 at 10:05 PM, Alexander Vainshtein
<[email-masked]> wrote:
> The PWE3 WG has defined multiple MIBs that can be used for PW setup and
> teardown by a      management application (MPLS-TP or not). IMO the draft
> should indicate that the method proposed there is an alternative not just to
> PW signaling via T-LDP (as Andy has said) but also to static PW setup using
> these MIBs.

As I mentioned, the draft did not intended to provide an alternate
control plane; hopefully that will be clear in the next rev. I'll add
some text around the point you make WRT MIBs above.

> The wording of the draft seems to suggest a difference between the head-end
> PE and the tail-end one, e.g., as in he following fragment: "Although the
> Virtual OF switch is the same a both the head-end and tail-end nodes, the
> group table is only used at the head-end node, where a Fast Failover group
> is set up for each pair of ports that correspond to the primary-backup
> Transport LSP pair.  At the tail-end node, only flows are set up." I do not
> understand how does this (and similar) fragments deal with the fact of PWs
> being inherently bidirectional.

I've cleaned this up. The distinction was in the description, not the
functionality.  Thanks for point this out.

> The PWs run in MPLS (or MPLS-TP) tunnels in order to improve scalability of
> P routers, because the same tunnel between a given pair of PEs can be shared
> by multiple PW instances. It is not clear from the text how such sharing can
> be accommodated in the proposed OF switch model.

Humm, here is nothing that stops the "transport virtual port" from
sharing transport labels if that is appropriate. Perhaps I'm not
understanding your point?

>  Reference to RFC 6423 suggests that OAM discussion in the draft is PW OAM
> and OAM for Tunnel LSPs. Does this imply that the protection actions are
> triggered by the PW-level OAM, and, what is supposed to happen if a pair of
> T-LSPs is shared by multiple PW instances?

That wasn't the intention; will clean up the text.

> The text defining the OF switch and its matching rules is not clear. In
> particular, it seems to imply that PW labels are checked from being received
> from a specific T-LSP (as a port of the OF switch). IMHO this a clear
> contradiction to the MPLS (and MPLS-TP) data plane as defined in RFC 3031,
> and to the fact that PW labels are allocated from the per-platform label
> space (as per RFC 4447).

Again, this wasn't the intention. I'll have a look at how we might
clean this up.

Thanks for the comments.

--dmm

---

From: Alexander Vainshtein <[email-masked]>
Date: Fri, 6 Jul 2012 18:29:37 +0000

David,
Please see a couple of comments inline below. Hopefully they clarify my position.

I have snipped some fragments of your response to make the remaining text more readable.

Regards,
     Sasha

________________________________________
From: David Meyer [[email-masked]]
Sent: Friday, July 06, 2012 4:59 PM
To: Alexander Vainshtein
Cc: Andrew G. Malis; Jan Medved; Andrew McLachlan; [email-masked]; Mishael Wexler; Rotem Cohen; Gideon Agmon; Andrew Sergeev; Idan Kaspit; Vladimir Kleiner
Subject: Re: [PWE3] draft-medved-pwe3-of-config-00.txt posted, review please

Alexander,

[[Sasha]] Well, MIBs are not part of control plane (at least, for me), but of the Management Plane - and, to the best of my understanding, so is OpenFlow. But putting terminology aside, the PWE3 MIBs provide a certain abstract model of the PW endpoints that is integrated with the existing model for MPLS etc. 
Your draft seems to offer an alternative abstract model that seems to mix PW and MPLS functionality. 

--- snipped --

> The PWs run in in MPLS (or MPLS-TP) tunnels in order to improve scalability of

[[Sasha]] What is important is that multiple PWs sharing a common MPLS tunnel LSP are fate-sharing in the PSN core, and the model should IMHO reflect this fact explicitly. E.g., the protection switch is applied to tunnel LSPs, not to individual PWs. This affects both the management aspects (e.g., failures of individual PWs sharing a tunnel LSP should be suppressed when the tuneel LSP fails) and the data plane (e.g., the time it takes to complete a protection switch triggered by the tunnel LSP failure should not depend upon the number of PWs using this tunnel LSP). IMHO and FWIW the model where each PW uses its individual "transport virtual ports" does not make this easy (if at all possible) even if you allow sharing of labels between thee ports. Or do I miss something?

---

From: David Meyer <[email-masked]>
Date: Fri, 6 Jul 2012 11:35:58 -0700

Excellent comments/clarifications Sasha. Thanks, really appreciate it
and I'll work this into the next rev (working on that now).

--dmm

---

From: "Andrew G. Malis" <[email-masked]>
Date: Fri, 6 Jul 2012 14:47:58 -0400

Dave,

One other comment that just occurred to me as you're working on your
update - the current revision of the draft obviously only works with
single-segment PWs, but that's not explicitly stated anywhere, other
than being alluded to in the title of figure 1. You may wish to make
that restriction explicit, unless you do intend to include MS-PWs in a
future revision, in which case that should be made clear as well.

Cheers,
Andy

---

From: David Meyer <[email-masked]>
Date: Fri, 6 Jul 2012 12:18:03 -0700

Thanks Andy, will definitely do that. --dmm