[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: I-D ACTION:draft-andersson-mpls-g-chng-proc-00.txt
Neil,
I know that you've had a hard time in the past with your arguments. To comment
to some of them:
1. I never understood why you were so emotional on overlay models as compared
to peer but at the same time advocate to use PNNI (Peer Network to Network
Interface) as an alternative.
2. The addressing issue you've raised is related to UNI which was so far
(until recently) not part of the CCAMP work. So I don't see here that you
were forced to use IPv4 Addresses.
3. About RSVP vs. PNNI I am not religious, why not using SS7? In any case I
don't think that the IETF is the right place to discuss on PNNI. Honestly I
don't know which one is 'better' but I don't believe that it is always the
best protocol that will win at the end. If you have one why do you need yet
another one (and in IETF we had already two ;-)?
4. I don't see your point on running a routing protocol on L1/0 why no just
using RSVP-TE signaling and omit OSPF?
5. About the access to centralized databases and management system I believe a
solution could be found once the specific aplication and communications
requrements are clear. I don't see GMPLS excluding this at all.
As an observation I'd like to say that all your arguments are equally valid
applicable to any Layer technology and not specific to L1/0. I say this because
it seems to me that Mark understood that there are very specific L1/0 points
which are under 'hot discussion'. I am not aware of those, but you may want to
correct me there.
Regards
Gert
neil.2.harrison@bt.com wrote:
> Gert....its not a nice feature if you don't want to use the forced
> functional component set.
>
> Ignoring the commercial vertical (client/server) and horizontal (same layer
> partitioning) requirements for functional decoupling, there are certain
> behaviours an operator may wish to use at L1/0 that are different to those
> the operator may wish to use in a L3/2 network. Operators may want the
> freedom to choose what they consider (whether others agree with them or not)
> what they perceive as best-of-breed components. For example, why should an
> operator be forced to use v4 addressing for the user-plane access points at
> L1/0? Why should they be forced to use RSVP-TE signalling if they believe
> pnni signalling is better? Why should they be forced to run a routing
> protocol at L1/0 (they may want discovery aspects however and the ability to
> hold a routing cache) when they need access to centralised records (eg duct
> records), and moreover they want their management system to retain
> absolute/overriding control? It's not clear to me operators have such
> degrees of freedom here.
>
> regards, Neil
>
> > -----Original Message-----
> > From: Gert Grammel [mailto:Gert.Grammel@alcatel.de]
> > Sent: 06 March 2003 16:17
> > To: Mark.Jones@mail.sprint.com
> > Cc: dwfedyk@nortelnetworks.com; gash@att.com; ccamp@ops.ietf.org;
> > mpls@UU.NET
> > Subject: Re: I-D ACTION:draft-andersson-mpls-g-chng-proc-00.txt
> >
> >
> > Mark,
> >
> > please don't forget that due to the 'Generalization' of GMPLS
> > you are free to do
> > the split at any application level you wish. This was always
> > the advantage of
> > the GMPLS approach compared to the ITU-T model where
> > initially each layer had
> > its own control plane. So the fact that in theory you could
> > use a single control
> > plane for all your network means also that you are able to
> > stop where you want.
> > Nice feature isn't it?
> >
> > Regards
> >
> > Gert
> >
> > Mark.Jones@mail.sprint.com wrote:
> >
> > > I agree with the separation of GMPLS into the two
> > applications. There
> > > does not appear to be any significant move to collapse the
> > management or
> > > signaling for L3/2 and L1/0 at this time, given the different models
> > > that apply for them and the infrastructures in our
> > companies that manage
> > > them. The plan for addressing the two applications need not be the
> > > same.
> > >
> > > The L3/2 application is near and dear to the heart of the IETF. The
> > > L1/0 application is of interest to those who wish to collapse the
> > > management into a single layer. In my opinion, the IETF might also
> > > address this approach, given the IETF participants are the ones in
> > > support of this collapsed management or at least common protocol
> > > solution for what is today two signaling layers. However, as stated
> > > before, the collapse approach is not realistic today for a
> > > multi-service, multi-protocol network.
> > >
> > > On the other hand, the L1/0 application requirements and models have
> > > been defined and are best understood at the ITU-T. Ideally, the
> > > protocol expertise at the IETF would be applied to the
> > ITU-T model and
> > > requirements to address the L1/0 application, but attempts
> > to do that
> > > have been met with great resistance in the past. Perhaps that was a
> > > result of the fact that GMPLS implementations were not separated out
> > > into the two different applications. However, I don't think it is
> > > realistic to expect the IETF experts to be motivated to
> > understand the
> > > ITU-T models and requirements, given the application is
> > outside of their
> > > primary area of interest. That said, I believe the IETF
> > should reach an
> > > agreement on how to work with outside groups that develop "major
> > > extensions" to the protocol.
> > >
> > > Mark Loyd Jones
> > > Optical Transport and Networking
> > > Sprint - Wireline Technology Development
> > > 913-794-2139
> > >
> > >
> > > -----Original Message-----
> > > From: dwfedyk [mailto:dwfedyk@nortelnetworks.com]
> > > Sent: Thursday, March 06, 2003 7:49 AM
> > > To: gash
> > > Cc: mpls; ccamp
> > > Subject: Re: I-D ACTION:draft-andersson-mpls-g-chng-proc-00.txt
> > >
> > > Along the lines of Jerry's comments.
> > >
> > > When we put together GMPLS the first drafts were under specified
> > > intentionally to capture the essence of GMPLS. We put aside many
> > > arguments saying lets specify at a high level and fill in
> > the details
> > > later. The discussions on this thread are in two major veins one
> > > attempting to fill the details and the other containing and
> > controlling
> > > the changes. GMPLS needs to be specified more accurately and in my
> > > opinion it needs to be decomposed to a more layered
> > approach. I think
> > > if we applied GMPLS at at some layers (L3/2), (L1/L0) for example,
> > > independently but self similar it would offer a mechanism to move
> > > forward where some legacy systems could be specified to be GMPLS
> > > friendly. For example signaling for Layer 3/2 can be
> > tunneled through
> > > the a lower layer. We already have some work in this direction.
> > > Similarly traffic engineering information for L1/L0 in a
> > TE database
> > > would need different attributes than a the TE database at L3/2. I
> > > don't think you want to burden a L3/L2 system with these
> > attributes in
> > > an overlay model. The expertise for these layer is not all
> > contained in
> > > the IETF. I think we should put a plan forward to make this happen
> > > within the IETF process. After this was accomplished I think some
> > > people are thinking of collapsing layers even more but the logical
> > > partitioning of layers may help keep the protocols and databases
> > > simpler. Right now were are treating GMPLS like a big
> > bowl of jelly
> > > when it should look more like a layer cake.
> > >
> > > Regards,
> > > Don
> >
> > --
> > Alcatel Optical Network Division Gert Grammel
> > Network Strategy phone: +49 711 821 47368
> > Lorenzstrasse 10 fax: +49 711 821 43169
> > D-70435 Stuttgart mailto:Gert.Grammel@alcatel.de
> >
> >
> >
> >
--
Alcatel Optical Network Division Gert Grammel
Network Strategy phone: +49 711 821 47368
Lorenzstrasse 10 fax: +49 711 821 43169
D-70435 Stuttgart mailto:Gert.Grammel@alcatel.de