RE: GMPLS issues (was - GMPLS Last Calls)

[neil.2.harrison@bt.com]

Hi John.....You could do this, but I don't believe this is pertinent to what
I was discussing.  See my response to Eric.

Regards, Neil

> -----Original Message-----
> From: John Drake [mailto:jdrake@calient.net]
> Sent: 13 June 2001 15:59
> To: 'Mannie, Eric'; 'neil.2.harrison@bt.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)
> 
> 
> Also, an ATM service using NSAP addresses for customer ports 
> could be built
> on top of a GMPLS core using IP addresses internally.  The ATM service
> delivery switches could use the GMPLS core to provison 
> lighpaths between
> themselves and then run
> PNNI as an overlay network for purposes of exchanging NSAP 
> reachability
> information. 
> 
> -----Original Message-----
> From: Mannie, Eric [mailto:Eric.Mannie@ebone.com]
> Sent: Wednesday, June 13, 2001 7:33 AM
> To: 'neil.2.harrison@bt.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)
> 
> 
> Hello Neil,
> 
> >Given that the layers have to be decoupled in the general case (for
> >commercial as well as technical reasons - see the BT 'Freeland'
> requirements
> >draft to 12/00 mtg) then there seems to be no reason why an 
> operator could
> >not use NSAPs for the access points of SDH or OTNs if he so 
> wished.  And,
> >given this choice, that operator might also prefer to use PNNI as the
> >signalling/routing solution too.  So, the issue seems not one of
> >'necesssity' but simply choice......though there may be 
> certain technical
> >benefits of choosing 1 solution over another.  I don't 
> believe there is
> >anything technically wrong with saying this and giving 
> operators/vendors a
> >choice here is there?.....if there is please point out the problems.
> 
> If somebody wants to use PNNI, it is not our business. The 
> choice between a
> GMPLS control plane and a PNNI control plane is not in our 
> scope. We are
> here working on GMPLS at the IETF, not on PNNI at the ATM 
> Forum and not on
> G.ASON at the ITU-T.
> 
> GMPLS comes with IPv4 and IPv6 addresses and PNNI comes with 
> NSAP addresses.
> I don't think that somebody will choose a control plane only 
> because it uses
> IP or NSAP addresses, this doesn't make sense to me. There 
> are much more
> important distinctions between the two control planes than 
> the format of the
> addresses.
> 
> Technically I don't see arguments to adapt GMPLS to NSAP 
> addresses, or to
> AppleTalk addresses or to any kind of addresses that some people could
> prefer, or that could come from another standardization body.
> 
> If technically there is a clear benefit of using NSAP 
> addresses instead of
> IP addresses in GMPLS that should be demonstrated by 
> somebody. Up to now
> nobody made it (I think that when somebody wants to modify an 
> existing work
> in a standardization body this has to be justified with 
> technical reasons,
> not just by a personal preference). So I presume that there 
> is today no
> technical argument to use NSAP addresses in GMPLS.
> 
> Even if any benefit is demonstrated, that should be balanced with the
> disadvantages of supporting it and finaly the IETF should 
> decide if they
> want to adapt their protocols to other addressing schemes. 
> Personally, I
> don't think that this make sense.
> 
> Moreover, GMPLS is IP centric and this is one of its driving 
> forces. I don't
> see the interest of transforming an IP centric control plane 
> in a less IP
> centric control plane. This is going in the opposite 
> direction of what we
> are trying to do.
> 
> Kind regards,
> 
> Eric
> 
> Eric Mannie
> EBONE (GTS)
>