Re: [PWE3] I-D Action: draft-medved-pwe3-of-config-01.txt

Hi Sasha

Thank you for your comments, apologies for my late reply, I was traveling yesterday.

"per-PW OAM engines as generators of triggers for protection switching" - it's not the intention to 'spin up' a new Engine per PW, we will edit and make this clearer in the next version of the draft. The OAM Engine could be either 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 Hop 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 occur the label and SA/DA headers would be added by the output packet processor. 

Whilst this this draft is only currently only aimed at the PW, and we are still relying on existing mechanisms for the LSP and subsequent encaps for them, totally understand your concerns we will review the draft again before the next version to see if we can make better distinction between PW endpoints 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 the 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=1.

     <Payload>        \
     <Payload-SA>      - PW payload
     <Payload-DA>     /
     <PW Label, S=1>  - 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=1>  - PW label
     <T Label, S=0>   - 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.  
This is required because OpenFlow can only push MPLS labels  onto the top of a label stack encapsulated in an existing Ethernet   header.
<end quote>

The problem (as I see it) is that "the outer transport (Ethernet) header" MUST 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 implies that it must be reconfigured every time the egress port and/or the Next Hop LSR change (e.g., in a protection switch). As I have already mentioned in my comments on the -00 version of the draft such behavior does not scale up.

The scalability problem of the proposed model do not end here. The draft still seems to consider per-PW OAM engines as generators of triggers for protection 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 different model of the PW endpoint that better agrees with the PWE3 architecture 
(which, as per RFC 3985, clearly distinguishes between PW endpoints and PSN tunnels) could be created? 
IMHO and FWIW, without such a model using OpenFlow for control of PW endpoints 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 directories.

	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=draft-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 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.