RE: Closing the GELS Mailing List

["Don Fedyk" <dwfedyk@nortel.com>]

Dmitri 

Quoting from GMPLS RFC 3945 seems far more applicable given we are
talking a Generalized label switch router (LSR).

"2. Layer-2 Switch Capable (L2SC) interfaces:

      Interfaces that recognize frame/cell boundaries and can switch
      data based on the content of the frame/cell header.  Examples
      include interfaces on Ethernet bridges that switch data based on
      the content of the MAC header and interfaces on ATM-LSRs that
      forward data based on the ATM VPI/VCI. "

Don 

-----Original Message-----

point is: 

whether the ethernet frame header fields can be interpreted as "labels"
that follows label switching rules applicable to an LSR and what are the
implications on forwarding component behaviour when considering such
"label encoding"


note: per 3031 a label is: a short fixed length physically contiguous
identifier which is used to identify a FEC, usually of local
significance. 
 
-d.
> -----Original Message-----
> From: neil.2.harrison@bt.com [mailto:neil.2.harrison@bt.com] 
> Sent: Friday, September 07, 2007 8:07 PM
> To: PAPADIMITRIOU Dimitri; adrian@olddog.co.uk; 
> zali@cisco.com; Attila.Takacs@ericsson.com; 
> ccamp@ops.ietf.org; gels@rtg.ietf.org
> Cc: rcallon@juniper.net
> Subject: RE: Closing the GELS Mailing List
> 
> Dimitri wrote 07 September 2007 16:36 in response to Adrian <snipped>
> 
> > > 
> > > This is also something we would expect to describe within
> > > CCAMP although 
> > > "what is a label" would come to us from the data plane 
> > specification.
> > 
> > do i interpreet correctly your statement that if the 
> > specification that CCAMP is going to receive from IEEE does 
> > not speak about "label" and its encoding there will be no 
> > place to discuss any "label processing" and "label 
> > distribution" protocol in IETF - being domain-wide or link-local
> > -
> > 
> > in that case, isn't the .1Q specification outside scope of 
> > this effort since not referring - as of today at least - to 
> > any "label" semantic as part of the Ethernet frame header 
> > information field ?
> > 
> > thanks,
> > -d.
> 
> What do you think a MAC DA, MAC SA and VID are?  These are 
> all 'labels'.
> 
> You also have to remember that the nature of the labels required in a
> traffic unit are determined by the type of the network mode one is
> dealing with.
> 
> In the co-cs and co-ps modes we have a construction known as a
> 'connection'.  This implies specific architectural requirements....but
> the most significant, for this discussion at least, is that a 
> connection
> must have a single source.  What this means is that one does 
> not have to
> incorporate a SA label in a co mode traffic unit....under defect-free
> conditions it is redundant information as the connection 
> itself provides
> the source information.  {Compare this to the cl-ps mode 
> which does not
> have connections...here having a SA in the traffic unit is essential}
> 
> Ergo why co-cs and co-ps mode technologies to date that respect the
> requirements of a connection have only focussed on incorporating a DA
> (forwarding) label.  Further, these forwarding labels only need to be
> distinct in resolving some number (N say) of different client layer
> (link-connection) instances within a server layer (network connection)
> resource partition.  However, there are advantages from 
> having both a SA
> and DA label in a co-ps traffic unit that are network unique and not
> just link-connection unique (ie not swapped)....the inherent 
> robustness
> under misconnectivity defects (without any adjunct OAM flow) is one of
> these.  And of course, these are the nature of the native labels one
> already gets in Ethernet due to its cl-ps mode origins.  So why would
> one even contemplate not using these since they are already there?
> 
> The VID label is slightly different in that one can consider it as a
> 'route discriminator label' and a local extension to the SA 
> or DA, ie it
> provides the ability to identify disjoint paths between nodal end
> points.
> 
> The mere fact IEEE may not refer to the above quantities as 'labels'
> does not change the fact that this is what they are.  So I'm not clear
> what your real point is here.
> 
> regards, Neil
>