[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Ethernet Control Plane [Was: Re: Frameformat in a l2cs gmpls rnvironment.]
Dimitri,
What I was trying to say here is that for the User how
TE Ethernet connection is established - via control or
management planes is of a little importance. Before
explaining how cool/elegant it could be provisioned
via GMPLS you need to answer IMO the following
questions:
1) What does it mean Traffic Engineered Ethernet
connection in the data plane and what is it good for?
For instance, we perfectly understand what does ATM
connection or TDM connection mean in the data plane
and can provide references to corresponding data plane
standards.
2) How does the label-aware Ethernet forwarder
co-exist with other Ethernet forwarders on the same
switch
3) What information is necessary to provision the
forwarding tables?
And so on.
Cheers,
Igor
--- dimitri papadimitriou <dpapadimitriou@psg.com>
wrote:
> hi igor,
>
> [snip - hint: igor i suggest you create a thread on
> control vs
> management plane]
>
> > My view wrt Ethertnet GMPLS is this. I have no
> doubts
> > that we can come up with mechanisms to dynamically
> > provision L2SC LSPs.
>
> ouf ;-)
>
> > My problem is the order of events.
> > It does not seem to me wise to come up with
> > some control plane framework and solution(s) and
> after
> > that think what we need to do in the data plane.
>
> actually, if this is the only problem you have, i
> should underline we do
> not have to initiate the definition of a specific
> forwarding paradigm so
> i am not necessarily sure about what you mean by the
> last part of the
> above sentence
>
> > It seems to me wiser to learn how to statically
> > provision such LSPs, see how useful they are, and
> only
> > after that design and develop ways to provision
> them
> > dynamically.
>
> i am not sure to follow how are you going to
> determine the benefit from
> dynamic provisioning by statically configure these
> LSPs ?
>
> > In other words, it is wiser to repeat what has
> been
> > done with TDM LSPs.
>
> wiser ? ... would you clarify ? don't you think it
> is more appropriate
> to receive feedback on the appropriateness of the
> use of GMPLS for the
> scenarios depicted in the problem statement document
> rather than digress
> on non-rational argument such as "wiser", "careful"
> or so... ?
>
> > Cheers,
> > Igor
> >
> >
> >
> >>A control-plane is useful in the major co-cs
> >>transport networks (mainly
> >>for S-PVCs and resilience) but its a minor player
> >>compared to role of
> >>the management-plane. The converse of course
> holds
> >>in a *traffic*
> >>carrying cl-ps IP network, esp when this is in
> the
> >>context of the
> >>public Internet.....but of course this isn't the
> >>case here and IP is
> >>only being used as the transport protocol in the
> OOB
> >>data-plane network
> >>that carries the control/management-plane
> protocols.
> >>
> >>
> >>These were points I wanted to make.....hopefully
> >>I've done a better job
> >>this time.
> >>
> >>regards, Neil
> >>
> >>
> >>
> >>-----Original Message-----
> >>From: Adrian Farrel [mailto:adrian@olddog.co.uk]
> >>Sent: 23 July 2005 00:08
> >>To: Harrison,N,Neil,IKM1 R
> >>Cc: ccamp@ops.ietf.org
> >>Subject: Re: Ethernet Control Plane [Was: Re:
> >>Frameformat in a l2cs
> >>gmpls rnvironment.]
> >>
> >>
> >>Hi Neil,
> >>
> >>I think John beat me off the blocks here, but...
> >>
> >>
> >>
> >>>>GMPLS assumes an IP control plane.
> >>>
> >>>An IP control-plane? There is actually no such
> >>
> >>animal. Just what
> >>
> >>>the heck does that REALLY mean in GMPLS say?
> >>
> >>
> >>Let me explain.
> >>Perhaps I should have said "IP-based control
> plane".
> >>I mean a control plane which:
> >>- uses IP as its network protocol
> >>- uses IP addresses to identify control plane
> >>resources
> >>- uses IP addresses to identify data plane
> resources
> >>within
> >> the control plane
> >>- uses protocols developed for use in the
> Internet.
> >>
> >>
> >>>I am not questioning IP as a cl-ps networking
> >>
> >>protocol *carrying*
> >>
> >>>a signalling protocol (RSVP-TE, or dare I mention
> >>
> >>PNNI, or any
> >>
> >>>signalling protocol yet to be invented) or a
> >>
> >>routing protocol
> >>
> >>>(OSPF or ISO or whatever)
> >>
> >>
> >>I am glad to hear it.
> >>
> >>
> >>>or even management protocols
> >>
> >>
> >>Fine, but not in the remit of CCAMP.
> >>
> >>
> >>>but an 'IP Control Plane' per se means absolutely
> >>
> >>nothing to me....
> >>
> >>Well, I think it should. I think the list of
> >>attributes that I have
> >>given above define a control plane based on IP.
> >>
> >>It is undoubtable that attempts have been made to
> >>use control planes
> >>based on other protocols. Some have been highly
> >>successful. Some have
> >>been less fortunate.
> >>
> >>
> >>>...nor should it to anyone else.
> >>
> >>
> >>I think folks who were around at the beginning of
> >>CCAMP and who were
> >>part of the debate with the IESG will be very
> >>familiar with where the
> >>IETF draws the line here.
> >>
> >>
> >>
> >>>I think some folks might need a reality check
> >>
> >>here....and also
> >>
> >>>on the self-assumed importance of a
> control-plane.
> >>
> >>Hint: It ain't
> >>
> >>>that important.....the management-plane (which
> may
> >>
> >>be using IP!)
> >>
> >>>however is.
> >>
> >>
> >>I am not sure how to interpret this.
> >>It may be that you think that control plane is bad
> >>per se, but you have
> >>said elsewhere that you think it has value - but
> >>much less than the
> >>management plane.
> >>It may be that you believe that CCAMP is willfully
> >>neglecting the
> >>management plane. This would, in fact, be true. It
> >>is not in CCAMP's
>
=== message truncated ===
__________________________________________________
Do You Yahoo!?
Tired of spam? Yahoo! Mail has the best spam protection around
http://mail.yahoo.com