|
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
============================================================
|