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

Sure, thanks for the text. --dmm

________________________________________
From: Andrew G. Malis [amalis@gmail.com]
Sent: Friday, July 13, 2012 05:28
To: Andrew McLachlan (amclachl); David Meyer (dmm); Jan Medved (jmedved)
Cc: Alexander Vainshtein; pwe3 (pwe3@ietf.org); Yaakov Stein (yaakov_s@rad.com)
Subject: Re: [PWE3] I-D Action: draft-medved-pwe3-of-config-01.txt

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 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.
>
>
> _______________________________________________
> pwe3 mailing list
> pwe3@ietf.org
> https://www.ietf.org/mailman/listinfo/pwe3