Subject: Re: Continued Poll for Adoption of Ethernet I-Ds

From: Igor Bryskin <[email-masked]>
Date: Tue, 8 Apr 2008 14:16:35 -0700 (PDT)

Hi Neil. Please, see my question in-line.
Regards,
Igor

----- Original Message ----
From: "[email-masked]" <[email-masked]>
To: [email-masked]; [email-masked]
Sent: Monday, April 7, 2008 4:57:57 PM
Subject: RE: Continued Poll for Adoption of Ethernet I-Ds

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.

IB>> I agree with what you are saying. What confuses me, though, is that 802.1ay prescribes allocating of certain range(s) of VLANIDs for the PBB-TE use, while allowing use of other VLANIDs for their native Ethernet purposes. I wonder why is that? Why not to say that all VLANIDs are available for the PBB-TE use. If what you are saying is correct (which, again, I believe you are), that is, PBB-TE and non-PBB-TE (say, PBB) are completely separate layer network, than VLANIDs are not shared between the two. 

What am I missing here?

Thanks,
Igor

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: [email-masked]
> [mailto:[email-masked]] On Behalf Of Adrian Farrel
> Sent: 07 April 2008 17:54
> To: [email-masked]
> 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" <[email-masked]>
> To: <[email-masked]>
> 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
> >
> >
> > 
> 
> 
> 
> 

      ____________________________________________________________________________________
You rock. That's why Blockbuster's offering you one month of Blockbuster Total Access, No Cost.  
http://tc.deals.yahoo.com/tc/blockbuster/text5.com

---

From: <[email-masked]>
Date: Wed, 9 Apr 2008 08:48:29 +0100

Hi Igor....please see in-line (have snipped mail to your question only)
 
Igor Bryskin  wrote 08 April 2008 22:17

IB>> I agree with what you are saying. What confuses me, though, is that
802.1ay prescribes allocating of certain range(s) of VLANIDs for the
PBB-TE use, while allowing use of other VLANIDs for their native
Ethernet purposes. I wonder why is that? Why not to say that all VLANIDs
are available for the PBB-TE use. If what you are saying is correct
(which, again, I believe you are), that is, PBB-TE and non-PBB-TE (say,
PBB) are completely separate layer network, than VLANIDs are not shared
between the two. 

What am I missing here?

Thanks,
Igor 
 
NH=> Excellent question.  I have made exactly this same observation in
the past.  In principle there is no reason why you cannot re-use all the
codepoints of each/every field in the traffic unit because, as stated,
although the traffic units look identical they do belong to quite
different layer networks.  I think there are 2 reasons for this:
 
-    Firstly, most IEEE folks are not familiar with, and therefore do
not use, functional architecture techniques to describe layer networks.
So this issue may not be so obvious to many folks in IEEE.  Further,
when we have QinQ techniques these are a form of sublayering (like we
find in nested LSPs in MPLS) and so we don't have distinct layer
networks here......and although folks may not describe it as such they
do recognise that one of the consequences of this (ie still a single
layer network) is that it affects scaling.  However, once we have the
.1ah stuff and MACinMAC (ie true client/server) then everyone
intuitively recognises we have quite disjoint layer networks.  So what I
am saying here is that for folks who don't have a strong background in
functional architecture, the observation you have made may not be so
obvious even though it is architecturally true.
 
-    Secondly, there could be practical/implementation reasons for doing
this (ie creating a split in VID codepoints) when dealing with COTS
Ethernet hardware.  Maybe some of the Ethernet hardware experts can
provide further clarification here.  
 
One thing this does provide however is a clear way to 'know' when
looking at a traffic unit in isolation exactly which layer network it
belongs to.
 
regards, Neil

---

From: "Don Fedyk" <[email-masked]>
Date: Wed, 9 Apr 2008 10:38:15 -0400

Hi Igor and Neil
 
See below,

	IB>> I agree with what you are saying. What confuses me, though,
is that 802.1ay prescribes allocating of certain range(s) of VLANIDs for
the PBB-TE use, while allowing use of other VLANIDs for their native
Ethernet purposes. I wonder why is that? Why not to say that all VLANIDs
are available for the PBB-TE use. If what you are saying is correct
(which, again, I believe you are), that is, PBB-TE and non-PBB-TE (say,
PBB) are completely separate layer network, than VLANIDs are not shared
between the two. 
	
	What am I missing here?
	
	Thanks,
	Igor 
	 
	NH=> Excellent question.  I have made exactly this same
observation in the past.  In principle there is no reason why you cannot
re-use all the codepoints of each/every field in the traffic unit
because, as stated, although the traffic units look identical they do
belong to quite different layer networks.  I think there are 2 reasons
for this:
	 
	-    Firstly, most IEEE folks are not familiar with, and
therefore do not use, functional architecture techniques to describe
layer networks.  So this issue may not be so obvious to many folks in
IEEE.  Further, when we have QinQ techniques these are a form of
sublayering (like we find in nested LSPs in MPLS) and so we don't have
distinct layer networks here......and although folks may not describe it
as such they do recognise that one of the consequences of this (ie still
a single layer network) is that it affects scaling.  However, once we
have the .1ah stuff and MACinMAC (ie true client/server) then everyone
intuitively recognises we have quite disjoint layer networks.  So what I
am saying here is that for folks who don't have a strong background in
functional architecture, the observation you have made may not be so
obvious even though it is architecturally true.
	 
	-    Secondly, there could be practical/implementation reasons
for doing this (ie creating a split in VID codepoints) when dealing with
COTS Ethernet hardware.  Maybe some of the Ethernet hardware experts can
provide further clarification here.   

Disclaimer I'm not a hardware expert but Neil is correct there is
currently no "context" within an Ethernet Frame that could separate the
PBB B-VID space and the PBB-TE B-VID space. If  these spaces used
overlapping B-VID values there would be know way to know by looking at
the Frame.  In fact one of the attractions of PBB-TE is that it can
reuse the existing forwarding HW because it essentially forwards on
(B-VID+MAC DA).  A result is a switch cannot tell the context
implicitly. 

	One thing this does provide however is a clear way to 'know'
when looking at a traffic unit in isolation exactly which layer network
it belongs to. 

Between the PBB B-MAC (server) and the PBB C-MAC  (client) it is clear
looking at a frame.   Between PBB and PBB-TE the B-VID space
partitioning in the management (and control plane) is the only thing
that separates the behavior.  
 
Regards,
Don 

	regards, Neil

---

From: "Nurit Sprecher" <[email-masked]>
Date: Wed, 9 Apr 2008 23:02:01 +0300

Hi all,

So maybe this is something to be commented to the IEEE........they
operate hybrid PBB/PBB-TE networks. 

In this draft we provide a control plane to the dataplane that is
defined by the IEEE, and specifically we define a control plane for
PBB-TE as defined by the IEEE 802.1Qay. 

Nurit

________________________________

From: [email-masked] [mailto:[email-masked]] On
Behalf Of ext Don Fedyk
Sent: Wednesday, April 09, 2008 17:38
To: [email-masked]; [email-masked]; [email-masked];
[email-masked]
Subject: RE: Continued Poll for Adoption of Ethernet I-Ds

Hi Igor and Neil

See below,

	What am I missing here?
	
	Thanks,
	Igor 

Regards,

Don 

	regards, Neil

---

From: "Attila Takacs" <[email-masked]>
Date: Thu, 10 Apr 2008 08:54:47 +0200

Hi all,
 
I do agree that a clear/single network operation mode is desirable in
practice, however, as Nurit pointed out, IEEE 802.1Qay is more
permissive in this regard. 
However, if every VLAN is allocated for PBB-TE, which is a valid
configuration in 802.1Qay, then the network will operate in a clear
co-ps mode without side effects due to parallel PBB operation.
 
On the other hand, I can imagine that in some cases having a PBB bridged
VLAN used, e.g.,to create connectivity for control traffic, would be
desirable and I do not see a problem with this until it does not carry
customer traffic.
 
I think we do not need to do anything in here; the level of permitted
coexistence of PBB and PBB-TE is a network operational issue, and it
does not really affect the GMPLS extensions much more than probably
adding support to ensure that the VLANs configured for PBB-TE are the
same throughout the network.
 
Best regards,
Attila

	From: [email-masked] [mailto:[email-masked]]
On Behalf Of Nurit Sprecher
	Sent: Wednesday, April 09, 2008 10:02 PM
	To: ext Don Fedyk; [email-masked]; [email-masked];
[email-masked]; [email-masked]
	Subject: RE: Continued Poll for Adoption of Ethernet I-Ds

	Hi all,

	So maybe this is something to be commented to the
IEEE........they operate hybrid PBB/PBB-TE networks. 

	In this draft we provide a control plane to the dataplane that
is defined by the IEEE, and specifically we define a control plane for
PBB-TE as defined by the IEEE 802.1Qay. 

	Nurit

	From: [email-masked] [mailto:[email-masked]]
On Behalf Of ext Don Fedyk
	Sent: Wednesday, April 09, 2008 17:38
	To: [email-masked]; [email-masked];
[email-masked]; [email-masked]
	Subject: RE: Continued Poll for Adoption of Ethernet I-Ds

	Hi Igor and Neil

	See below,

		IB>> I agree with what you are saying. What confuses me,
though, is that 802.1ay prescribes allocating of certain range(s) of
VLANIDs for the PBB-TE use, while allowing use of other VLANIDs for
their native Ethernet purposes. I wonder why is that? Why not to say
that all VLANIDs are available for the PBB-TE use. If what you are
saying is correct (which, again, I believe you are), that is, PBB-TE and
non-PBB-TE (say, PBB) are completely separate layer network, than
VLANIDs are not shared between the two. 
		
		What am I missing here?
		
		Thanks,
		Igor 

		-    Secondly, there could be practical/implementation
reasons for doing this (ie creating a split in VID codepoints) when
dealing with COTS Ethernet hardware.  Maybe some of the Ethernet
hardware experts can provide further clarification here.   

	Disclaimer I'm not a hardware expert but Neil is correct there
is currently no "context" within an Ethernet Frame that could separate
the PBB B-VID space and the PBB-TE B-VID space. If  these spaces used
overlapping B-VID values there would be know way to know by looking at
the Frame.  In fact one of the attractions of PBB-TE is that it can
reuse the existing forwarding HW because it essentially forwards on
(B-VID+MAC DA).  A result is a switch cannot tell the context
implicitly. 

		One thing this does provide however is a clear way to
'know' when looking at a traffic unit in isolation exactly which layer
network it belongs to. 

	Between the PBB B-MAC (server) and the PBB C-MAC  (client) it is
clear looking at a frame.   Between PBB and PBB-TE the B-VID space
partitioning in the management (and control plane) is the only thing
that separates the behavior.  

	Regards,

	Don 

		regards, Neil

---

From: <[email-masked]>
Date: Thu, 10 Apr 2008 09:43:02 +0100

Agreed Attila.....let's not get this out of proportion......the key
thing is to understand that we are dealing with different layer networks
in PBB (cl-ps) and PBB-TE (co-ps) networks and getting this right is
then largely a matter of good design and implementation.  If we want to
throw stones at the underlying arch issue I can think of another
technology close to home that provides a far richer set of problems in
this respect ;-)
 
regards, Neil

-----Original Message-----
From: Attila Takacs [mailto:[email-masked]] 
Sent: 10 April 2008 07:55
To: Nurit Sprecher; ext Don Fedyk; Harrison,N,Neil,DMF R;
[email-masked]; [email-masked]; [email-masked]
Subject: RE: Continued Poll for Adoption of Ethernet I-Ds

Hi all,

 
 
Best regards,
Attila

  _____  

Behalf Of Nurit Sprecher

Hi all,

Nurit

  _____  

Hi Igor and Neil

See below,

What am I missing here?

Thanks,
Igor 

Regards,

Don 

regards, Neil