MIME-Version: 1.0
In-Reply-To: <6C4D4E30-0040-4F0A-A703-0E0A7F84639D@cisco.com>
References: <20120711051239.19562.70082.idtracker@ietfa.amsl.com>
 <F9336571731ADE42A5397FC831CEAA0209AA00@FRIDWPPMB001.ecitele.com>
 <6C4D4E30-0040-4F0A-A703-0E0A7F84639D@cisco.com>
From: "Andrew G. Malis" <amalis@gmail.com>
Date: Fri, 13 Jul 2012 08:28:43 -0400
Message-ID: <CAK+d4xswDdOVg9hhyYKnwn7r+41d17N1V==yudRk_Dkwppy2Bw@mail.gmail.com>
To: "Andrew McLachlan (amclachl)" <amclachl@cisco.com>,
 "David Meyer (dmm)" <dmm@cisco.com>,
 "Jan Medved (jmedved)" <jmedved@cisco.com>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
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

Andrew et al,

I still don't like the following sentence in the first paragraph of section=
 1.3:

   At present no open standards
   exist to provision these PWs, and therefore there is a reliance on
   vendor specific provisioning platforms.  It should be noted that
   there exists alternative methods for the static provisioning of PWs,
   including via SNMP ([RFC5601]).

Are you claiming that RFC 5601 isn't an open standard?

I would much prefer something like:

The static PW provisioning method in this document is presented as an
alternative to the existing method of provisioning static PWs via SNMP
([RFC5601]) or via vendor-specific provisioning platforms. PWs may of
course also be dynamically signaled via a control plane if desired
([RFC4447]).

Thanks,
Andy

On Fri, Jul 13, 2012 at 4:48 AM, Andrew McLachlan (amclachl)
<amclachl@cisco.com> wrote:
>
> 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 thi=
s will be down to the switch vendors implementation.
>
> "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.
>
> 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.
>
> 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=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 th=
e 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 MPL=
S 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 menti=
oned 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 pr=
otection 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 archit=
ecture
> (which, as per RFC 3985, clearly distinguishes between PW endpoints and P=
SN tunnels) could be created?
> IMHO and FWIW, without such a model using OpenFlow for control of PW endp=
oints 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 direct=
ories.
>
>
>         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 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.
>
>
> _______________________________________________
> pwe3 mailing list
> pwe3@ietf.org
> https://www.ietf.org/mailman/listinfo/pwe3