From: "Andrew McLachlan (amclachl)" <amclachl@cisco.com>
To: Alexander Vainshtein <Alexander.Vainshtein@ecitele.com>
Thread-Topic: I-D Action: draft-medved-pwe3-of-config-01.txt
Thread-Index: AQHNXyPoTOcM0MAQFEm4M8vD4MnHUZclvAsQgAGB54A=
Date: Fri, 13 Jul 2012 08:48:00 +0000
Message-ID: <6C4D4E30-0040-4F0A-A703-0E0A7F84639D@cisco.com>
References: <20120711051239.19562.70082.idtracker@ietfa.amsl.com>
 <F9336571731ADE42A5397FC831CEAA0209AA00@FRIDWPPMB001.ecitele.com>
In-Reply-To: <F9336571731ADE42A5397FC831CEAA0209AA00@FRIDWPPMB001.ecitele.com>
Accept-Language: en-US
Content-Language: en-US
Content-Type: text/plain; charset="us-ascii"
Content-ID: <923A5ACE098D7D44B4478A122F4D220E@cisco.com>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Cc: "pwe3 \(pwe3@ietf.org\)" <pwe3@ietf.org>,
 "David Meyer \(dmm\)" <dmm@cisco.com>,
 "Jan Medved \(jmedved\)" <jmedved@cisco.com>,
 "Yaakov Stein \(yaakov_s@rad.com\)" <yaakov_s@rad.com>
Subject: Re: [PWE3] I-D Action: draft-medved-pwe3-of-config-01.txt
Precedence: list

Hi Sasha

Thank you for your comments, apologies for my late reply, I was traveling y=
esterday.

"per-PW OAM engines as generators of triggers for protection switching" - i=
t's not the intention to 'spin up' a new Engine per PW, we will edit and ma=
ke this clearer in the next version of the draft. The OAM Engine could be e=
ither linecard based or more central on a switch, RP for example, but this =
will be down to the switch vendors implementation.

"the OF switch-based model of the PW endpoint proposed in the draft implies=
 that it must be reconfigured every time the egress port and/or the Next Ho=
p LSR change " - The intention is for the output/group port (ff) to be pre-=
provisioned to know the primary/second path information, should a failure o=
ccur the label and SA/DA headers would be added by the output packet proces=
sor.=20

Whilst this this draft is only currently only aimed at the PW, and we are s=
till relying on existing mechanisms for the LSP and subsequent encaps for t=
hem, totally understand your concerns we will review the draft again before=
 the next version to see if we can make better distinction between PW endpo=
ints and the PSN piece.

andrew


On 12 Jul 2012, at 16:12, Alexander Vainshtein wrote:

Hi all,
I've looked up a new version of the draft and I have several issues with th=
e proposed mode of operation as described in Figure 4 in Section 2.1:

<quote>
A packet initially arrives at the AC with the following headers
     and payload. This packet becomes the PW payload.

     <Payload>        \
     <Payload-SA>      - PW payload
     <Payload-DA>     /

     Next, the iPProc adds the Transport header.

     <Payload>        \
     <Payload-SA>      - PW payload
     <Payload-DA      /
     <T-SA, T-DA>     - Transport header

     The Virtual OF switch then pushes on PW label with S=3D1.

     <Payload>        \
     <Payload-SA>      - PW payload
     <Payload-DA>     /
     <PW Label, S=3D1>  - PW label
     <T-SA, T-DA>     - Transport header

     Finally, the oPProc pushes the Transport label and switches the
     packet onto the Transport LSP.

     <Payload>        \
     <Payload-SA>      - PW payload
     <Payload-DA>     /
     <PW Label, S=3D1>  - PW label
     <T Label, S=3D0>   - Transport label
     <T-SA, T-DA>     - Transport header

                 Figure 4: Input Encapsulation Sequence
<end quote>

It is further explained in the beginning of Section 2.1 that :

<quote>
The iPProc encapsulates arriving  packets on the Attachment Circuit in the =
outer transport (Ethernet)   header. =20
This is required because OpenFlow can only push MPLS labels  onto the top o=
f a label stack encapsulated in an existing Ethernet   header.
<end quote>

The problem (as I see it) is that "the outer transport (Ethernet) header" M=
UST match the egress port (SA) and Next Hop LSR (DA) in order for the MPLS =
data plane to operate properly.
I.e., the OF switch-based model of the PW endpoint proposed in the draft im=
plies that it must be reconfigured every time the egress port and/or the Ne=
xt Hop LSR change (e.g., in a protection switch). As I have already mention=
ed in my comments on the -00 version of the draft such behavior does not sc=
ale up.

The scalability problem of the proposed model do not end here. The draft st=
ill seems to consider per-PW OAM engines as generators of triggers for prot=
ection switching.
Just mentioning that

<quote>
  The OAM function for Transport LSPs is out of scope for this revision
  of this document.  However, PW-OAM mechanisms described in this
  document could also applicable to Transport LSP-OAM.
<end quote>

and

<quote>
  Note that in addition to the OAM Engine, the Virtual OF Switch MAY
  use other liveness monitoring mechanisms for the virtual port Fast
  Failover groups, which are out of scope of this document.
<end quote>

is not really helpful.

I am pretty near ignorant with regard to OpenFlow, but I wonder whether a d=
ifferent model of the PW endpoint that better agrees with the PWE3 architec=
ture=20
(which, as per RFC 3985, clearly distinguishes between PW endpoints and PSN=
 tunnels) could be created?=20
IMHO and FWIW, without such a model using OpenFlow for control of PW endpoi=
nts would be highly problematic.

My 2c,
    Sasha

-----Original Message-----
From: i-d-announce-bounces@ietf.org [mailto:i-d-announce-bounces@ietf.org] =
On Behalf Of internet-drafts@ietf.org
Sent: Wednesday, July 11, 2012 8:13 AM
To: i-d-announce@ietf.org
Subject: I-D Action: draft-medved-pwe3-of-config-01.txt


A New Internet-Draft is available from the on-line Internet-Drafts director=
ies.


	Title           : MPLS-TP Pseudowire Configuration using OpenFlow 1.3
	Author(s)       : Jan Medved
                         Andrew McLachlan
                         David Meyer
	Filename        : draft-medved-pwe3-of-config-01.txt
	Pages           : 20
	Date            : 2012-07-10

Abstract:
  This document describes a method by which MPLS-TP Pseudowires (PW)
  can be configured in an LER using OpenFlow 1.3.  In addition to the
  configuration of PWs this document also specifies how to enact OAM
  for these PWs using standard IETF conventions defined by the GAL
  label method.  The primary goal of this document is to provide a
  simple and yet flexible method for configuring PWs using standardized
  tools from the emerging SDN toolkit.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-medved-pwe3-of-config

There's also a htmlized version available at:
http://tools.ietf.org/html/draft-medved-pwe3-of-config-01

A diff from previous version is available at:
http://tools.ietf.org/rfcdiff?url2=3Ddraft-medved-pwe3-of-config-01


Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

_______________________________________________
I-D-Announce mailing list
I-D-Announce@ietf.org
https://www.ietf.org/mailman/listinfo/i-d-announce
Internet-Draft directories: http://www.ietf.org/shadow.html
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

This e-mail message is intended for the recipient only and contains informa=
tion 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, p=
hone or fax, and then delete the original and all copies thereof.