|
And me too Ben/Igor. But go look at MPLS when folks DID define a
data-plane here....don't anyone dare tell me 'this is good' (or the PW stuff it
spawned) because I know otherwise.
reqards, Neil
Igor,
I, too, am baffled by the notion of requirements for
control of an unspecified data plane.
Regards,
Ben
Dimitri,
The question is simple: is it possible today to
statically provision L2LSPs that could, say, support e2e QoS? If not,
may be it is to early to discuss aspects of dynamic provisioning of such
LSPs? Is it possible/reasonable, in your opinion, to "detail how forwarding information can be exchanged
via the control plane (and then installed)" without having in mind "a
specific forwarding behavior"?
How do you know which forwarding information
is needed for the forwarding nobody has defined yet?
The other question is do we need at all
e2e QoS, route control, fast recovery? Sounds like exciting idea, but does
all that commercially make sense? So, I guess, we need two
things before we can move forward:
a) validation of the idea by the
providers;
b) definition of the data plane
behavior;
Igor
----- Original Message -----
Sent: Friday, July 22, 2005 12:21
PM
Subject: Re: Frameformat in a l2cs
gmpls rnvironment.
igor - i am not sure which point they
exactly have - the purpose of this document is to detail how forwarding
information can be exchanged via the control plane (and then installed)
not to define a specific forwarding behaviour
thanks,
- dimitri.
"Igor Bryskin" <ibryskin@movaz.com>
Sent by: owner-ccamp@ops.ietf.org
07/22/2005 11:10 AST
To: "Mack-Crane, T. Benjamin" <Ben.Mack-Crane@tellabs.com>,
"Adrian Farrel" <adrian@olddog.co.uk>, Pär
Mattsson <per@defero.se>, "Loa
Andersson" <loa@pi.se>
cc: <ccamp@ops.ietf.org>
bcc:
Subject: Re:
Frameformat in a l2cs gmpls rnvironment.
Hi,
I think Ben and Juergen have a point here. There is nothing
that could be dynamically provisioned that could not be also provisioned
by management. In other words data plane is the King here. We need data
plane standard(s) on how we encode a label, whether we need a label stack
or not, how the labeled traffic is supposed to be treated, how
labeled traffic co-exist with non-label traffic, etc. This is something
that not for CCAMP to define. Take for example TDM networks. GMPLS only
provides a way to dynamically provision G.707 networks. Hence there is a
need in parallel standardization activities in ITU. Only after that we can
discuss how all that could be dynamically provisioned, that is the aspects
of control plane.
Igor
----- Original Message
-----
From: Mack-Crane, T.
Benjamin
To: Adrian Farrel ; Pär Mattsson ; Loa
Andersson
Cc: ccamp@ops.ietf.org
Sent: Friday, July 22,
2005 10:23 AM
Subject: RE: Frameformat in a
l2cs gmpls rnvironment.
Hi,
I think Juergen has
raised an important question. How frames are labeled (and the
related data plane forwarding behavior) is not defined by the control
plane. The control plane serves to provision the data plane, not
define it. In the framework draft it is not clear what data plane
standards are covered by the stated control plane requirements. Some
references should be supplied. In any case, the labeling and
forwarding behavior should be defined by these referenced standards,
not by GMPLS.
(I am assuming definition of new data plane
standards is out of scope for CCAMP.)
Regards,
Ben
From: owner-ccamp@ops.ietf.org
[mailto:owner-ccamp@ops.ietf.org] On Behalf Of Adrian
Farrel
Sent: Friday, July 22, 2005 8:37 AM
To: Pär
Mattsson; Loa Andersson
Cc:
ccamp@ops.ietf.org
Subject: Re: Frameformat in a l2cs gmpls
rnvironment.
Hi,
It is always refreshing how engineers jump
straight to a discussion of the solution :-)
Perhaps we can assume
that the framework draft is a good representation of the problem space,
and that we are ready to start discussing the solutions.
One
(perhaps the only?) significant question to answer is how the frames will
be labelled. This question is one we must come to as soon as we are
confident that the requirements need to be addressed at all.
As has
been pointed out, there are several possibilities and to pick from these
we need to understand:
1. Do we need to support explicit label
stacking?
Note that this is not supported in TDM, LSC or
FSC.
2. Do we need to be able to control (perhaps through
an
external signaling controller) existing hardware
and
install LSPs through existing networks?
3. Do we
need to support existing function simultaneous to
the
support of GMPLS L2 LSPs?
I think that from a chair's perspective I
can give some limited guidance.
A. These questions must be raised
and answered in the framework I-D
B. The answer to question 3 is "yes".
This means that the use of labels
must not significantly
deplete any namespace used to support other
function.
C. CCAMP is chartered to look at the control of transport
networks. This
includes Metro, but I am unsure about
Campus. It does not cover
signaling to the
desktop.
Thanks,
Adrian
----- Original Message -----
From: "Pär Mattsson" <per@defero.se>
To: "Loa Andersson" <loa@pi.se>
Cc: <ccamp@ops.ietf.org>
Sent: Friday, July 22, 2005 11:41 AM
Subject: Re:
Frameformat in a l2cs gmpls rnvironment.
> > Per and
Dimitri,
> >
> > I would like to come down stronger than
that, for me it is
> > a very strong requirement that the same
switch can handle
> > both VLANs and GMPLs trafic correctly. I
can't dsee how that
> > could be done if using the VLAN tpid to
indicate GMPLS
> > traffic.
>
> If you ever want
that same switch to handle traffic for a directly
> connected
host (not to uncommen) you would want that to use normal
> ethernet
macaddress switching. So of course you do not want to have to
>
choose between vlan and gmpls, you would want both at the same
time.
>
> /per
>
>
> >
> >
/Loa
> >
> > Pär Mattsson wrote:
> >>>hi
par, one of the possibilities that has been considered to cope
with
> >>>this requirement is to use a dedicated TPID for
the Ethernet labeled
> >>>frames; this would allow
differentiated processing with non-labeled
>
>>>framesthanks.
> >>
> >>
>
>> That seems to make more sence. If that frame is to be sized like
a
> >> 802.1q
> >> frame. There is not that much
space left to a label. Or is the demand to
> >> use
jumboframes ?
> >> Has there been any discussion on
labelstacking, and mainly where to
> >> place
> >>
the information?
> >>
> >> Regards.
>
>> Per
> >>
> >>
> >>
>
>
> >
> > --
> > Loa Andersson
>
>
> > Principal Networking Architect
> > Acreo
AB
phone: +46 8 632 77 14
> > Isafjordsgatan
22
mobile: +46 739 81 21 64
> > Kista,
Sweden
email: loa.andersson@acreo.se
>
>
loa@pi.se
>
>
>
>
>
>
============================================================
The information contained in this message
may be privileged
and
confidential and protected from disclosure. If the reader
of this message is not the intended
recipient, or an employee
or
agent responsible for delivering this message to the
intended recipient, you are hereby notified
that any reproduction,
dissemination or distribution of this communication is
strictly
prohibited. If you
have received this communication in error,
please notify us immediately by replying to
the message and
deleting it
from your computer. Thank you. Tellabs
============================================================
============================================================
The information contained in this message may be privileged
and confidential and protected from disclosure. If the reader
of this message is not the intended recipient, or an employee
or agent responsible for delivering this message to the
intended recipient, you are hereby notified that any reproduction,
dissemination or distribution of this communication is strictly
prohibited. If you have received this communication in error,
please notify us immediately by replying to the message and
deleting it from your computer. Thank you. Tellabs
============================================================
|