[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: Closing the GELS Mailing List
don,
interesting 3 years ago you blaim me on the same list when i quoted this
definition when discussing applicability of GMPLS to Ethernet ;-)
the evolution of Ethernet forwarding components themselves leads to an
open issue today compared to the situation we observed a couple of years
ago. if this would not be true one would have not seen since this
definition has been written end 2000 in rfc3945 that there has been
lot's efforts in various bodies involved in Ethernet to incorporate as
part of that technology properties that would facilitate Ethernet
network operations -- and this due to its expected applicability in
environments for which that technology has not been initially designed
for -- and this is whole point actually (*)
back to the point: when that definition was written down it was
understood that adding GMPLS control plane to an Ethernet fowarding
plane would lead to address such expectations. nevertheless, we ack'ed
since the GELS BoF (held by Loa and myself) in 2005 that the
"combination" would be possible if one of the following conditions hold
- IEEE provides a data plane spec. that allows accommodating the fwd'ing
behaviour determined by GMPLS (and all related routing paradigms)
- IEEE ack's that some if its header's field can be processed
equivalently to a per-platform/link-local switching "label" with all its
resulting implications (if fact the answer was never totally clear at
the end)
- GMPLS evolves to sustain all control modes connectionless fwd'ing
would allow (this option was not even discussed)
=> hence, the question remains open. i would love to see progress on
that matter (at least that IEEE tells us yes or no) but for the time
being we're left with unilateral interpretations that are blocking real
progress from the std perspective (the problem is mainly not technical
... it is the problem that CCAMP faces each time its prefered control
plane protocol suite tries to cover a technology)
(*) it was felt 2 or 3 years ago that operators could help and provide
us with their expectation in that respect but no real outcome came out
of various tentatives to obtain such type of operational feedback
> -----Original Message-----
> From: Don Fedyk [mailto:dwfedyk@nortel.com]
> Sent: Friday, September 07, 2007 8:47 PM
> To: PAPADIMITRIOU Dimitri; neil.2.harrison@bt.com;
> 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
>
> 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
> >
>
>