RE: GMPLS issues (was - GMPLS Last Calls)

[John Drake <jdrake@calient.net>]

Comments in line

-----Original Message-----
From: neil.2.harrison@bt.com [mailto:neil.2.harrison@bt.com]
Sent: Wednesday, June 13, 2001 3:41 PM
To: jdrake@calient.net; Eric.Mannie@ebone.com;
ananth.nagarajan@mail.sprint.com; BRaja@tellium.com
Cc: wesam.alanqar@mail.sprint.com; ccamp@ops.ietf.org;
Tammy.Ferris@mail.sprint.com; mark.jones@mail.sprint.com; mpls@UU.NET;
lynn.neir@mail.sprint.com; andy.bd.reid@bt.com; alan.mcguire@bt.com
Subject: RE: GMPLS issues (was - GMPLS Last Calls)


Hi John,

You observed 13 June 2001 16:20
> 
> Niel,
> 
> I think that the point that Eric was trying to make is that 
> the IETF isn't
> the correct venue
> for a PNNI based solution, although a PNNI based solution might be a
> perfectly fine thing.
NH=> Many thanks for acknowledging this.......and as both a signalling
expert and co-author of the PNNI specification your view should carry some
weight.


JD:  Um, I was just trying to be nice.  I don't have any idea of it
could actually work, and it is, shall we say, a stabilized protocol.


> 
> From a technical perspective, unless things have changed in 
> the past several
> years, the issues
> with using PNNI are its lack of support for 
> pre-emption/priority and make
> before break, and that
> its bandwidth advertisements are tightly coupled to ATM 
> service categories.
NH=> But PNNI seems as though it can more easily adapted to the required
job.  


JD:  This sounds suspiciously like an assertion.


It has certain features that make it quite attractive like:
-	mature/tested, already deployed and understood
-	proven carrier-strength


JD:  I think the whole point of GMPLS is that the same could be said of
the IP suite of protocols.


-	multiple interfaces already specified, ie UNI, E-NNI, I-NNI, AINI


JD:  What are E-NNI and I-NNI?  Also, at least when I looked at AINI, it
had lots of problems with looping behavior and I don't know if they were
fixed.

-	separate link and signalling protocols, eg SSCOP keepalives separate
from signalling, allows more physical interfaces not just connections per
interface


JD:  The same is provided by LMP wrt routing and signalling protocols, and
link bundling provides better scalability wrt more physical interfaces than
PNNI which doesn't have a similar concept. 


-	supports crankback.....something now slated to be addded to
RSVP/CR-LDP I assume?
-	supports static routed interfaces (AINI)....seems essential for
inter-operator case;


JD:  GMPLS has this.


-	support for address translation


JD:  Not clear what you're referring to.


-	supports S-PVC-type service


JD:  GMPLS has this.


-	Logical Group Node concept provides powerful features, eg hides
interior behaviour, allows centralised signalling and/or path computation,
border nodes not burdened with higher layers, supports any topology, each
peer group can have a different internal behaviour, etc;


JD:  I think you're referring to peer groups.  In practice they were pretty
nasty to configure properly, and I don't think they have all of the
attributes
you've given them.  


-	good for phased migration (this is an importnat issue for
operators);


JD:  Given that ATM, like IP, is a service, I don't see why there would be 
any reason to prefer PNNI over GMPLS. 


-	centralised route computation may be better for OTNs.....this would
be allowed;


JD:  PNNI doesn't have this intrinsically and GMPLS would support it just
as easily. 


-	separate signalling and routing means just signalling part can be
used


JD:  I think that PNNI signalling and routing are much more tightly coupled
than their GMPLS counterparts.  Further, Eric Mannie designed in specific
support in GMPLS for signalling only deployments.


-	etc

It would, however, need some minor additional work to adapt it for SDH/OTN
as you note......like BW advertisements.


JD:  It's only minor until you actually start to work out the details.


BTW- we have significant experience of trying to run multiple pre-emption
schemes and found it not so useful.  So this is one aspect we would want,
and if it was present we would want to be able to turn it off.


JD:  GMPLS has only a single pre-emption scheme.


Regards, Neil