Subject: RE: I-D ACTION:draft-andersson-mpls-g-chng-proc-00.txt

From: [email-masked]
Date: Thu, 6 Mar 2003 18:51:47 -0000

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:[email-masked]]
> Sent: 06 March 2003 16:17
> To: [email-masked]
> Cc: [email-masked]; [email-masked]; [email-masked];
> [email-masked]
> 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
> 
> [email-masked] 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:[email-masked]]
> > 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:[email-masked]
> 
> 
> 
>

---

From: Gert Grammel <[email-masked]>
Date: Thu, 06 Mar 2003 20:56:41 +0100

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

---

From: Curtis Villamizar <[email-masked]>
Date: Thu, 06 Mar 2003 21:05:27 -0500

In message <[email-masked]>, Gert Grammel writes:
>  
>   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 ye t 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?

Please.  Don't use GMPLS or OSPF or IPv4 (or IPv6) or RSVP/TE.

ASON implemented over PNNI on SS7 would be perfect, but OSI, ATM or
X.25 would be just as good if you prefer those.  This would entirely
disentagle the IETF and ITU wrt ASON.

Curtis