RE: GMPLS issues (was - GMPLS Last Calls)

[neil.2.harrison@bt.com]

Hi Eric.....many thanks for your comments....couple of observations:
<snipped>
> 
> 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.
NH=>We have to consider that the control-plane is composed of 3 principlly
independent  facets (ie addressing, signalling and routing) and it unfair to
group them under a generic banner or forum heading.  We really should be
striving for best current practice here. 
> 
> 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.
NH=> The addressing is almost an irrelevance......the addressing used can be
anything provided it meets the requirements specified in the Freeland draft.
Clearly we would re-use an existing addressing scheme, and v6 and NSAPs look
good.  v4 does not look so good.
> 
> 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.
NH=> I don't want to do this either.
> 
> 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.
NH=> Focusing on addressing here is a distraction......the attributes of an
address that are required are that (i) it should be large enough for any
possible growth, (ii) able to be properly structured to follow topology (for
sensible hierarchical and aggregation reasons....so some 'wasted' space is
not a bad thing) and (ii) that addresses are decoupled wrt cross-layer
allocation (server layer trails = client layer links.....it can't be put
more direct/obvious than that I think). 
> 
> 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.
NH=> I really think the addressing aspect is a bit of a
distraction.......the key issues are all about the choice of signalling
protocol and how the routing aspects are used.  I cannot believe that a
signalling protocol like RSVP whose orgins are from a Rx-controlled,
multicast, IP, soft-state, etc environment is better fit than PNNI.  This is
not an attack of RSVP per se, it is all about re-using best available
protocols for a given job.  As Jon Crowcroft said at the NSIS BOF at the
last mtg:
"Don't fix signaling protocols via new requirements, but give a new
direction in signaling requirements. PNNI specifications are excellently
written, 3G handoff is excellent, Q.2931 is excellent. Don't start fixing
RSVP until you have read all these protocols. We should not reinvent the
wheel and waste the time of the IETF.
[See ref: http://www.ietf.org/proceedings/01mar/index.html NSIS BOF]
It is my opinion that all you will end up doing is re-inventing PNNI, eg
recent crankback drafts.  Sure you can do this but why waste the time of the
IETF on this?
> 
> 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.
NH=> I don't really want to get into this area, so I will be as brief as
possible....there is no IP in the SDH or OTN user-plane and, for us at
least, the client and SDH/OTN networks must be decoupled.  Sure you can
force an IP oriented solution but that is by choice....it is certainly not
forced by any technical or commercial necessity.  Please also note that a
significant (around 50% in some cases) of our SDH traffic demands actually
come from 'native' managed BW customers.....so these are not even client
networks (ie neither IP nor something else) that are under our management
domain.  These observations lead us to the conclusion that if a
control-plane is to be introduced (and please note this is not a sure-fire
certainty for SDH in any case for us....and I would urge operators to look
at their billing, OSS and current operational practices before reaching any
conclusions here) it should be chosen on best current practice principles.
Further, we cannot see any good business case for SVCs in either SDH or
OTNs....S-PVCs maybe.  Has anyone really talked to operators about
this....offering SVCs at SDH/OTN trail levels I mean?  I would be amazed if
valid business cases could be constructed......so if any operators out there
know how to do this, we would be very keen to understand the arguments.
So....observing that we are dealing with CO/cct-sw networks it would seem to
make sense to us to use a signalling protocol that was designed to control
such a fabric...and all I am saying here is that PNNI appears to be a better
fit than RSVP (provided it is coupled with the right OSS/service
environment, eg S-PVC like services 1st).

regards, Neil