From: "David Meyer (dmm)" <dmm@cisco.com>
To: "Andrew G. Malis" <amalis@gmail.com>,
 "Andrew McLachlan (amclachl)" <amclachl@cisco.com>,
 "Jan Medved (jmedved)" <jmedved@cisco.com>
Thread-Topic: [PWE3] I-D Action: draft-medved-pwe3-of-config-01.txt
Thread-Index: AQHNXyPoTOcM0MAQFEm4M8vD4MnHUZclvAsQgAGB54CAAD2sgP//uW96
Date: Fri, 13 Jul 2012 13:15:42 +0000
Message-ID: <5EA033561A7C374F82DF1FC7F9079BAF0D205B@xmb-rcd-x09.cisco.com>
References: <20120711051239.19562.70082.idtracker@ietfa.amsl.com>
 <F9336571731ADE42A5397FC831CEAA0209AA00@FRIDWPPMB001.ecitele.com>
 <6C4D4E30-0040-4F0A-A703-0E0A7F84639D@cisco.com>,
 <CAK+d4xswDdOVg9hhyYKnwn7r+41d17N1V==yudRk_Dkwppy2Bw@mail.gmail.com>
In-Reply-To: <CAK+d4xswDdOVg9hhyYKnwn7r+41d17N1V==yudRk_Dkwppy2Bw@mail.gmail.com>
Accept-Language: en-US
Content-Language: en-US
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Cc: "pwe3 \(pwe3@ietf.org\)" <pwe3@ietf.org>,
 "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

Sure, thanks for the text. --dmm=0A=
=0A=
________________________________________=0A=
From: Andrew G. Malis [amalis@gmail.com]=0A=
Sent: Friday, July 13, 2012 05:28=0A=
To: Andrew McLachlan (amclachl); David Meyer (dmm); Jan Medved (jmedved)=0A=
Cc: Alexander Vainshtein; pwe3 (pwe3@ietf.org); Yaakov Stein (yaakov_s@rad.=
com)=0A=
Subject: Re: [PWE3] I-D Action: draft-medved-pwe3-of-config-01.txt=0A=
=0A=
Andrew et al,=0A=
=0A=
I still don't like the following sentence in the first paragraph of section=
 1.3:=0A=
=0A=
   At present no open standards=0A=
   exist to provision these PWs, and therefore there is a reliance on=0A=
   vendor specific provisioning platforms.  It should be noted that=0A=
   there exists alternative methods for the static provisioning of PWs,=0A=
   including via SNMP ([RFC5601]).=0A=
=0A=
Are you claiming that RFC 5601 isn't an open standard?=0A=
=0A=
I would much prefer something like:=0A=
=0A=
The static PW provisioning method in this document is presented as an=0A=
alternative to the existing method of provisioning static PWs via SNMP=0A=
([RFC5601]) or via vendor-specific provisioning platforms. PWs may of=0A=
course also be dynamically signaled via a control plane if desired=0A=
([RFC4447]).=0A=
=0A=
Thanks,=0A=
Andy=0A=
=0A=
On Fri, Jul 13, 2012 at 4:48 AM, Andrew McLachlan (amclachl)=0A=
<amclachl@cisco.com> wrote:=0A=
>=0A=
> Hi Sasha=0A=
>=0A=
> Thank you for your comments, apologies for my late reply, I was traveling=
 yesterday.=0A=
>=0A=
> "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 thi=
s will be down to the switch vendors implementation.=0A=
>=0A=
> "the OF switch-based model of the PW endpoint proposed in the draft impli=
es 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 pr=
e-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 proc=
essor.=0A=
>=0A=
> 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 befo=
re the next version to see if we can make better distinction between PW end=
points and the PSN piece.=0A=
>=0A=
> andrew=0A=
>=0A=
>=0A=
> On 12 Jul 2012, at 16:12, Alexander Vainshtein wrote:=0A=
>=0A=
> Hi all,=0A=
> 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:=0A=
>=0A=
> <quote>=0A=
> A packet initially arrives at the AC with the following headers=0A=
>      and payload. This packet becomes the PW payload.=0A=
>=0A=
>      <Payload>        \=0A=
>      <Payload-SA>      - PW payload=0A=
>      <Payload-DA>     /=0A=
>=0A=
>      Next, the iPProc adds the Transport header.=0A=
>=0A=
>      <Payload>        \=0A=
>      <Payload-SA>      - PW payload=0A=
>      <Payload-DA      /=0A=
>      <T-SA, T-DA>     - Transport header=0A=
>=0A=
>      The Virtual OF switch then pushes on PW label with S=3D1.=0A=
>=0A=
>      <Payload>        \=0A=
>      <Payload-SA>      - PW payload=0A=
>      <Payload-DA>     /=0A=
>      <PW Label, S=3D1>  - PW label=0A=
>      <T-SA, T-DA>     - Transport header=0A=
>=0A=
>      Finally, the oPProc pushes the Transport label and switches the=0A=
>      packet onto the Transport LSP.=0A=
>=0A=
>      <Payload>        \=0A=
>      <Payload-SA>      - PW payload=0A=
>      <Payload-DA>     /=0A=
>      <PW Label, S=3D1>  - PW label=0A=
>      <T Label, S=3D0>   - Transport label=0A=
>      <T-SA, T-DA>     - Transport header=0A=
>=0A=
>                  Figure 4: Input Encapsulation Sequence=0A=
> <end quote>=0A=
>=0A=
> It is further explained in the beginning of Section 2.1 that :=0A=
>=0A=
> <quote>=0A=
> The iPProc encapsulates arriving  packets on the Attachment Circuit in th=
e outer transport (Ethernet)   header.=0A=
> This is required because OpenFlow can only push MPLS labels  onto the top=
 of a label stack encapsulated in an existing Ethernet   header.=0A=
> <end quote>=0A=
>=0A=
> 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 MPL=
S data plane to operate properly.=0A=
> 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 menti=
oned in my comments on the -00 version of the draft such behavior does not =
scale up.=0A=
>=0A=
> 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 pr=
otection switching.=0A=
> Just mentioning that=0A=
>=0A=
> <quote>=0A=
>   The OAM function for Transport LSPs is out of scope for this revision=
=0A=
>   of this document.  However, PW-OAM mechanisms described in this=0A=
>   document could also applicable to Transport LSP-OAM.=0A=
> <end quote>=0A=
>=0A=
> and=0A=
>=0A=
> <quote>=0A=
>   Note that in addition to the OAM Engine, the Virtual OF Switch MAY=0A=
>   use other liveness monitoring mechanisms for the virtual port Fast=0A=
>   Failover groups, which are out of scope of this document.=0A=
> <end quote>=0A=
>=0A=
> is not really helpful.=0A=
>=0A=
> 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 archit=
ecture=0A=
> (which, as per RFC 3985, clearly distinguishes between PW endpoints and P=
SN tunnels) could be created?=0A=
> IMHO and FWIW, without such a model using OpenFlow for control of PW endp=
oints would be highly problematic.=0A=
>=0A=
> My 2c,=0A=
>     Sasha=0A=
>=0A=
> -----Original Message-----=0A=
> From: i-d-announce-bounces@ietf.org [mailto:i-d-announce-bounces@ietf.org=
] On Behalf Of internet-drafts@ietf.org=0A=
> Sent: Wednesday, July 11, 2012 8:13 AM=0A=
> To: i-d-announce@ietf.org=0A=
> Subject: I-D Action: draft-medved-pwe3-of-config-01.txt=0A=
>=0A=
>=0A=
> A New Internet-Draft is available from the on-line Internet-Drafts direct=
ories.=0A=
>=0A=
>=0A=
>         Title           : MPLS-TP Pseudowire Configuration using OpenFlow=
 1.3=0A=
>         Author(s)       : Jan Medved=0A=
>                          Andrew McLachlan=0A=
>                          David Meyer=0A=
>         Filename        : draft-medved-pwe3-of-config-01.txt=0A=
>         Pages           : 20=0A=
>         Date            : 2012-07-10=0A=
>=0A=
> Abstract:=0A=
>   This document describes a method by which MPLS-TP Pseudowires (PW)=0A=
>   can be configured in an LER using OpenFlow 1.3.  In addition to the=0A=
>   configuration of PWs this document also specifies how to enact OAM=0A=
>   for these PWs using standard IETF conventions defined by the GAL=0A=
>   label method.  The primary goal of this document is to provide a=0A=
>   simple and yet flexible method for configuring PWs using standardized=
=0A=
>   tools from the emerging SDN toolkit.=0A=
>=0A=
>=0A=
> The IETF datatracker status page for this draft is:=0A=
> https://datatracker.ietf.org/doc/draft-medved-pwe3-of-config=0A=
>=0A=
> There's also a htmlized version available at:=0A=
> http://tools.ietf.org/html/draft-medved-pwe3-of-config-01=0A=
>=0A=
> A diff from previous version is available at:=0A=
> http://tools.ietf.org/rfcdiff?url2=3Ddraft-medved-pwe3-of-config-01=0A=
>=0A=
>=0A=
> Internet-Drafts are also available by anonymous FTP at:=0A=
> ftp://ftp.ietf.org/internet-drafts/=0A=
>=0A=
> _______________________________________________=0A=
> I-D-Announce mailing list=0A=
> I-D-Announce@ietf.org=0A=
> https://www.ietf.org/mailman/listinfo/i-d-announce=0A=
> Internet-Draft directories: http://www.ietf.org/shadow.html=0A=
> or ftp://ftp.ietf.org/ietf/1shadow-sites.txt=0A=
>=0A=
> This e-mail message is intended for the recipient only and contains infor=
mation which is CONFIDENTIAL and which may be proprietary to ECI Telecom. I=
f 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.=0A=
>=0A=
>=0A=
> _______________________________________________=0A=
> pwe3 mailing list=0A=
> pwe3@ietf.org=0A=
> https://www.ietf.org/mailman/listinfo/pwe3=0A=