RE: Continued Poll for Adoption of Ethernet I-Ds

[<[e-mail]>]

Adrian,  Here is my view (with some brief rationale):

> draft-imajuku-ccamp-ethernet-gmpls-req-01.txt

Notionally support.  One concern I have revolves around the implications
of this para:

"4.1.3 Hybrid operation with legacy Ethernet

   The solution should take into consideration the operational scenario
   that GMPLS controls Ethernet LSPs over PBB-TE and Legacy Ethernet
   hybrid networks. This morphs of network architecture is possible
   considering evolution scenario of Ethernet. In such networks, legacy
   Ethernet functionality such as Spanning Tree Protocol (SPT),
   Link Aggregation [IEEE802.3], and so on must co-exist with PBB-TE
   functionality.

   The solution must not prevent the simultaneous existence of GMPLS
   controlled Eth-LSPs and PBB[IEE802.1ah] or PB[IEE802.1ad] with
   native Ethernet Layer2 control protocols on same node and interface."

We must avoid the mistake that different network modes (ie cl-ps or
co-ps or co-cs) can somehow 'co-exist' in the same DP layer network (and
also have the same CP).  More specifically, native Ethernet is cl-ps and
PBB-TE is co-ps....so even though the base DP traffic unit of these 2
different network modes looks the same they MUST exist in their own
layer network space.  This requires that some (lower) server layer
network should create *different resource partitions* (in either space,
freq or time dimensions) for each client layer network mode type.

Aside=> For the case of private network services (which also includes
'network builder' transport services, ie how one creates client layer
network topology) we are ultimately dealing with a time varying
aggregate of message/file/stream applications.....these may not even be
supported in the immediate client layer network, but there will
ultimately be a 'very top' layer network that does support these.  So in
the server layer network what we have to deal with are (latent)
abstractions of such time varying application aggregates.  In such cases
the key behaviour that the server network must provide to the client
network is one of transparency, ie a client/server layer network
relationship must provide full functional decoupling of the client and
server layer networks.  This is not simply a technically driven
requirement but it also has commercial and (in some cases) regulatory
drivers.  Although this is a necessary condition (at least for
reachability isolation of different client service instances) it is not
generally sufficient for client service cases which require resource
isolation (ie the traffic behaviour of client service instance X cannot
impact the traffic behaviour experienced by client service instance Y).
To satisfy the latter requirement the server layer network (i) must
provide connections (ie only p2p or p2mp constructs allowed - which is
also a necessary condition) and (ii) the server layer resources should
not be overbooked (for a full sufficiency condition).  Although not all
client cases need this (strong resource isolation) service from the
server layer network, the server layer network must nevertheless have
the capability of providing it.

All these requirements are forced to be met when the server layer
technology belongs to the co-cs mode.  However, care is required when
the server layer network belongs to the co-ps mode (eg PBB-TE), eg don't
violate the rules of a connection.  And of course these requirements
cannot be assured in the cl-ps mode as this does not, by definition,
provide connections.


> draft-fedyk-gmpls-ethernet-pbb-te-02.txt

Support.  Couple of small points:
-	OAM activation/deactivation (ie CV flow) needs to be
synchronised to whatever CP or MP mechanism sets-up/tears-down ESPs for
obvious operational reasons.  Further, the CP (if ESP signalled) or MP
(if ESP provisioned) needs to tell ESP DP sink trail termination point
of the expected B-MAC SA.
-	Although IDs major on security from the perspective of malicious
attacks (on the DP/CP/MP) there is also an aspect of security related to
defects, ie customer traffic leaking from one connection into another
connection under misconnectivity defects.  A major advantage for
operators and their customers of using domain-unique (non-swapped)
labels is that misconnectivity defects are very unlikely to propagate,
and in any case are always detectable at a connection trail termination
point due to the B-MAC SA in each traffic unit. This benefit exists
without running any OAM at all.....indeed, one only requires a CV OAM
flow in PBB-TE to detect simple breaks such that they can be
distinguished from a quiescent traffic case.  This results in a
significant opex benefit since it means operators only need to run OAM
on important connections and not all connections (which is the case for
label-swapping if misconnectivity defects must be detected).  Maybe this
'security benefit' should be mentioned in the security section?


> draft-berger-ccamp-gmpls-mef-uni-02.txt
> draft-berger-ccamp-gmpls-ether-svcs-01.txt

No problems with the IDs themselves, as they are only attempting to
satisfy externally perceived requirements....but I do have a concern
with the external requirements.

When we talk about UNIs (and E-NNIs) we should be clear that we are
actually dealing with public network services and the horizontal
peer-partitioning of a single layer network between different operator
and customer parties, ie this is NOT the same as the private 'network
builder' case (briefly discussed previously) since that is based on a
vertical client/server relationship between different layer networks.  A
critical issue (usually overlooked in my experience) here is the
importance in being clear about the 'end-system message/file/stream
application to first layer network adaptation functions'.  Ethernet does
not currently define such adaptation functions for message/file/stream
applications (IP does of course with UDP, TCP and RTP respectively).  I
don't really want to go into all the detail here, but I simply want to
make the point that before folks get too carried away defining UNIs/NNIs
(for any network technology) they should be clear that this signifies a
clear intention to develop public network services and requires careful
attention to the end-system to first layer network adaptation
functions.....so it's not simply about defining interworking between CP
signalling or routing functions, or even DP OAM functions say.
Therefore, as you might guess, whilst we in IETF/CCAMPs may quite easily
define UNIs/E-NNIs for the DP (OAM) and CP say, we should also be
cognizant of the ultimate implications of the direction MEF and ITU are
taking here.

Aside=> A slight twist on the above is where folks have considered E-NNI
peer interworking between *different* technologies.  This recently came
up in the ITU wrt T-MPLS OAM in draft G.8114 which was undergoing AAP.
G.8114 contained a proposal to peer interwork T-MPLS and Ethernet
networks simply because they had both been 'bestowed' with similar, and
IMO far too complex, DP OAM.  It should be self-evident that it is not
sensible to try and interwork 2 technologies that belong to different
network modes (simply because there will be significant functional
component mismatch across the DP and CP), but in any case there are no
end-system application to first layer network adaptations functions
defined for either of these technologies (noting that if these were
defined they would be required to either (i) pass transparently between
the 2 network peer partitions at the interworking point if common or
(ii) there would have to be interworking cases defined if not common).
It was quite evident that no thought had been given to these matters
whatsoever in G.8114 and so we requested that the interworking proposal
was removed.  Later, and as most folks probably know by now, the AAP
progress of G.8114 was stopped anyway due to larger concerns that IETF
had on T-MPLS in general. 

regards, Neil 



> -----Original Message-----
> From: [e-mail]
> [mailto:[e-mail]] On Behalf Of Adrian Farrel
> Sent: 07 April 2008 17:54
> To: [e-mail]
> Subject: Continued Poll for Adoption of Ethernet I-Ds
> 
> 
> Hi,
> 
> We have seen some good support for these I-Ds and no
> objections, but I don't 
> think we have seen anything like the level of support that 
> was evident in 
> the room in Philadelphia. We haven't seen support from more 
> than half of the 
> authors of the documents.
> 
> So, please, if you haven't already done so, give an
> indication of whether or 
> not you support each of these four documents becoming working 
> group drafts. 
> Remember, you can be in favor of some and not other if you like.
> 
> Thanks,
> Adrian
> 
> ----- Original Message -----
> From: "Adrian Farrel" <[e-mail]>
> To: <[e-mail]>
> Sent: Thursday, March 27, 2008 9:23 PM
> Subject: Polling for Adoption of Ethernet I-Ds
> 
> 
> > Hi,
> >
> > From Philadelphia, we have four candidate I-Ds for adoption as CCAMP

> > working group documents.
> >
> > Please express your opinions.
> >
> > Note that acceptance of these I-Ds does not mean that the
> discussion
> > about
> > the architecture is done. I think we made some progress on
> that topic in
> > Philadelphia, and I think the authors took on the task of
> making some
> > updates of semantics and for clarity, but I expect the
> discussion may go
> > on for a while.
> >
> > draft-imajuku-ccamp-ethernet-gmpls-req-01.txt
> > draft-fedyk-gmpls-ethernet-pbb-te-02.txt
> > draft-berger-ccamp-gmpls-mef-uni-02.txt
> > draft-berger-ccamp-gmpls-ether-svcs-01.txt
> >
> > Thanks,
> > Adrian
> >
> >
> > 
> 
> 
> 
>