Subject: RE: draft-aissaoui-l2vpn-vpws-iw-oam-04.txt to WG?

From: [email-masked]
Date: Tue, 27 Sep 2005 08:16:22 +0100

> There was considerable support for making 
> draft-aissaoui-l2vpn-vpws-iw-oam-03.txt a WG document at the 
> past couple of IETFs.  We'd like to gauge the WG interest on 
> the mailing list. Please indicate your support or lack 
> thereof on the updated version 
> "draft-aissaoui-l2vpn-vpws-iw-oam-04.txt."
> 
> Shane & Vach
>

I'm going to say no....and for the following reasons (in summary):

1	There seems to be little understanding of the difference between
a client/server and peer-partition relationship between 2 layer
networks......OAM is but 1 facet here!......these are very different,
and the PW stuff is a mix-up of both.

2	This stuff ought to be only about client/server relationships.
And this has some key rules that must not be broken, eg
-	functional decoupling of client/server layers.....absolutely
critical for scaling and when different parties own the client and
server layer networks......broken
-	transparent carriage of all 3 planes of the client over the
*traffic* data-plane of the server (Note - it does not have to be same
server trail/flow per client plane component, but usually is for
practical considerations).....broken
-	defects must only be detected/handled at server data-plane
trail/flow termination points (broken) and a FDI must only be injected
into the client (via the adaptation function) IFF the client belongs to
the co mode....and in particular there must never be any mapping of
defects detected in the client layer to server layer OAM
indications.....broken.

3	The above was all true in the case of 1-hop PWs.....and where
one could (justifiably) claim the PW function was simply adaptation
between 2 layer networks.  With multi-hop PWs a new and completely
unnecessary layer network has been created (which now also generates a
complimentary unnecessary peer-partition i/w function for XoverPWoverIP
and XoverPWoverMPLS).  It's not clear to me this case has even been
recognised, let alone factored into the considerations here, ie there
will be 3 layer networks involved now, ie true client layer (and more
precisely this is a link-connection), PW layer (trail (co-ps) to the
client *but* this is, in turn, a link-connection to its server) and
server layer (either IP cl-ps flow or MPLS co-ps trail).  So things have
now changed significantly.

4	There are far too many and incompletely specified OAM mechanisms
involved at each level now and there are unclear behaviour relationships
between them.

All the above unclear thinking and architectural errors will lead to
(unnecessary) complexity and cost for operators.

regards, Neil

---

From: "Mustapha Aissaoui" <[email-masked]>
Date: Tue, 27 Sep 2005 10:24:16 -0400

Neil,
The authors of this draft have spent considerable time to address these
issues as much as possible.

At your request, we defined precise entry and exit criteria for defects on
both PW and AC. At your request, and at the request of a few service
providers, we provided the ability to carry defect notification inband in
the datapath using BFD. We also added the concept of direction to the PW
defect to align with Y.1712.

I am sure there is plenty of room for improvement. Therefore, I appreciate
specific comments on the sections of the document and if possible ways to
address them. This would be the best way to go forward.

Thanks,
Mustapha.

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]
> On Behalf Of [email-masked]
> Sent: Tuesday, September 27, 2005 3:16 AM
> To: [email-masked]; [email-masked]
> Subject: RE: draft-aissaoui-l2vpn-vpws-iw-oam-04.txt to WG?
>
> > draft-aissaoui-l2vpn-vpws-iw-oam-03.txt a WG document at the past
> > couple of IETFs.  We'd like to gauge the WG interest on the mailing
> > list. Please indicate your support or lack thereof on the updated
> > version "draft-aissaoui-l2vpn-vpws-iw-oam-04.txt."
> >
> > Shane & Vach
> >
>
> a client/server and peer-partition relationship between 2
> layer networks......OAM is but 1 facet here!......these are
> very different, and the PW stuff is a mix-up of both.
>
> critical for scaling and when different parties own the
> client and server layer networks......broken
> *traffic* data-plane of the server (Note - it does not have
> to be same server trail/flow per client plane component, but
> usually is for practical considerations).....broken
> trail/flow termination points (broken) and a FDI must only be
> injected into the client (via the adaptation function) IFF
> the client belongs to the co mode....and in particular there
> must never be any mapping of defects detected in the client
> layer to server layer OAM indications.....broken.
>
> one could (justifiably) claim the PW function was simply
> adaptation between 2 layer networks.  With multi-hop PWs a
> new and completely unnecessary layer network has been created
> (which now also generates a complimentary unnecessary
> peer-partition i/w function for XoverPWoverIP and
> XoverPWoverMPLS).  It's not clear to me this case has even
> been recognised, let alone factored into the considerations
> here, ie there will be 3 layer networks involved now, ie true
> client layer (and more precisely this is a link-connection),
> PW layer (trail (co-ps) to the client *but* this is, in turn,
> a link-connection to its server) and server layer (either IP
> cl-ps flow or MPLS co-ps trail).  So things have now changed
> significantly.
>
> involved at each level now and there are unclear behaviour
> relationships between them.
>