Subject: RE: GMPLS issues (was - GMPLS Last Calls)

From: [email-masked]
Date: Tue, 12 Jun 2001 15:27:31 -0500

Bala,
Thanks for your reply.  Sorry it took so long to reply back. Please see 
in-line.

Thanks,
Ananth

bala>> > 1) Type of legacy equipment needing NSAP addresses 
bala>> > (also, is
bala>> > this optical network element or client equipment?)
bala>> > 2) Rough estimate of number of UNI ports needing NSAP address 
bala>> > (2002, 2005, and 2010)
bala>> > 3) Description of application in which this legacy equipment 
bala>> > will use UNI
bala>> > signaling
bala>I don't recall seeing any response. furthermore, the NSAP
bala>requirement was not unanimously endorsed by all carriers (at
bala>the OIF). 

From our OIF representatives, although it was not unanimously endorsed, 
there was a significant demand for NSAP support. Well, NSAP is the main 
non-IP type of addressing that is required. The general requirement is 
to be able to support non-IP addresses (probably have an address 
translation from non-IP addresses to routable addresses).

bala>It would also be nice if you can give some insight on
bala>the timeline in which you need various features, and whether
bala>the current GMPLS developments are inadequate within
bala>that timeline. (We can always have a progression of features).

NSAP support will be needed always (e.g. support for legacy DCC that 
uses NSAP).  So the timeframe requirement is now. 

Ananth>2) GMPLS is being defined based on assumptions about proprietary 
Ananth>transmission planes without those assumptions being specified. 
How can 
Ananth>we be sure that the control plane support is correct? How can we 
be 
Ananth>sure that it can be combined with other features?  Assumptions 
Ananth>regarding the transmission plane that can affect the control 
plane must 
Ananth>be clearly documented. This creates the additional related 
problem that 
Ananth>there is not a clear inter-working defined for interaction 
between 
Ananth>standard/proprietary control planes/transmission planes.

bala>BR: I get the feeling you're referring to the 
concatenation/transperency
bala>issues discussed recently. While the debate has been hot, there's
bala>no show stopper here. Several suggestions are being considered for
bala>clarifying standard/non-standard features supported.

The concatenation/transparency issues are a concern.  In addition, 
management features such as manual protection switching, protection 
switching configuration, billing support (e.g. usage collection) etc 
need to be supported too.

Ananth>3) Assuring separation of the control plane from the data plane 
Ananth>continues to arise.. When the control plane fails it should not 
affect 
Ananth> existing connections.  Also if connections in progress are 
affected 
Ananth>then they should not leave partially setup connections - they 
should 
Ananth>fail gracefully informing the initiator. The GMPLS architecture 
Ananth>document mentions this separation, but it's not clear how the 
GMPLS 
Ananth>signaling specifications reflect the implications of this 
decoupling.  

bala>BR: This issue has been discussed for the OIF UNI signaling (GMPLS
bala>based, as you know), and solutions in the RSVP/LDP space have been
bala>proposed (some drafts may be written).
bala>This is also not a show stopper by any means.

Don't understand how the OIF UNI addresses this. Our concerns are more 
with respect to the NNI (internal separation of control and data). If 
this is not addressed, it is definitely a showstopper.  According to 
our OIF representatives, the OIF is looking at the IETF to specify 
these protocols.

To be specific, existing connections shouldn't be impacted when the 
control plane fails.

Ananth>4) Support for NSAP addresses and in general support such that 
control 
Ananth>plane addressing is independent of clients and vice versa.  Also 
Ananth>scalable naming/addressing scheme such as proposed in OIF.

bala>BR: NSAP, see my initial comments. The OIF is not dealing with
bala>names/resolution, etc. This has been decided to be out of the
bala>scope of UNI signaling, and considered as a separate function.

Address translation of some form (for e.g. NSAP address translation) 
should be supported. See comment at the beginning of the email.

Ananth>5) Since the control plane may be supported via multiple 
protocols, 
Ananth>clear statement of what is - and  isn't - covered in the GMPLS 
Signaling 
Ananth>Description, RSVP Extensions, LDP Extensions drafts is needed.

bala>BR: Don't understand this, but doesn't look like a major issue from
bala>your phrasing.

Recommend the development of applicability statements to cover this 
(otherwise, it is difficult to understand how the different pieces join 
together to form a coherent picture).

Ananth>6) Terminology is an issue (e.g., waveband switching, link)

bala>BR: Any inconsistencies can be taken care of easily.

Like your comment. Hope it is as easy as it sounds :-) Mapping of 
terminology between standards bodies and also between different drafts 
in the IETF can be painful. Agreed however, that this is not a 
show-stopper.

Ananth>7) Transaction support for connection set-up and release is 
needed for 
Ananth>connection oriented networks (e.g. crankback capability).

bala>BR: Internet drafts have already been written on crankback. I 
suggest
bala>that you please consider writing some drafts if there is something
bala>missing.

Aware of the "iwata-draft". Are there others? 

Ananth>8) Reliable message transfer 

bala>BR: Very much a part of signaling. the OIF work has considered this
bala>aspect also. 

'soft-state' signaling protocols may not be acceptable for the optical 
control plane.  Live channels must not be dropped as a result of 
signaling message delivery failures (e.g. timer refresh failures)

Ananth>9) Security concerns have not been fully addressed, particularly 
at the 
Ananth> architectural level.  The use of separate control network may 
Ananth>necessitate the need for 24 hour staff to protect against 
'Denial of 
Ananth>Service' attacks as currently happens for IP router networks. In 
Ananth>general, admission control issues need to be addressed.

bala>BR: Please elaborate on these, specifically, what's new in the
bala>context of GMPLS.

e.g. in the case of ATM UNI, if a user or users attempt too many call 
setups
simultaneously the switch control processor can become overloaded.  So, 
some form of call pacing/overload handling is needed.  Is there 
something similar in the GMPLS context for optical devices?

Ananth>10) The definition of transparency may be overly simplified.  
See 
Ananth>comments by Ben Mack-Crane:
Ananth>I think the debate on transparency indicates that the issue is 
not as 
Ananth>clear
Ananth>as we might think.  The OIF document you cite defines forms of 
Ananth>transparency
Ananth>that are very straightforward (flags 1,2) not the more complex 
forms in 
Ananth>the current GMPLS drafts (flags 3..10).  Also, these are easily 
Ananth>provided in
Ananth>O-E-O or O-O-O networks operating at the lambda level, but there 
is no
Ananth>standard for providing these over TDM multiplexed SONET/SDH 
links.

bala>BR: This is an ongoing topic of discussion. Doesn't break down
bala>the rest of the proposal.

Agreed.

Ananth>If two vendors implement the same signaling but different TDM 
Ananth>multiplexing, that 
Ananth>doesn't achieve interoperability.  Is there any way in the 
drafts to 
Ananth>determine the scope
Ananth>of application of the various signaling elements (that is, 
whether they 
Ananth>apply to UNI or NNI, whether they apply to specific network 
Ananth>layers/technologies)?

Ananth>11) One summary of additional items with issues includes:
Ananth>- SDH/SONET transparency.
Ananth>- SDH/SONET arbitrary concatenation, flexible concatenation.
Ananth>- AUG-X, TUG, STS Groups signal types and LSP capabilities.
Ananth>- All kinds of end-to-end protection/restoration for any layer, 
except 
Ananth>the IP layer.

bala>BR: Restoration is not actually covered in the current set of 
drafts.
bala>An earlier thread discussed this, and my suggestion is that this
bala>feature be dealt with separately.

Potential show-stopper for deployment if restoration is not covered. 
Would agree that it could be addressed separately, though.

Ananth>- The label set object (only used for lambda issues).
Ananth>- LSP encoding type, bandwidth encoding and GPID have to be 
simplified 
Ananth>accordingly.
Ananth>- MPLS extensions to control G.709 (since multiplexing, etc is 
not yet 
Ananth>defined).

bala>BR: A draft is forthcoming on this.

Have been made aware of this. Thanks.

Ananth>12) Support for paths across SONET/SDH gateways

bala>BR: Please clarify the issues/write drafts.

Quoting from Siegfried Giebl's email regarding 
<draft-ietf-ccamp-gmpls-sonet-sdh-00.txt>
"If I understand this document correctly, then you are completely
separating SONET and SDH signal types from each other,  thus making it
difficult to deal with paths across SONET/SDH gateways. As an 
alternative, I
suggest you work only with entities of level STS-1 (STM-0) and higher. 
On the other hand why don't you go the full way and also add 64 kb/s 
channels ?"

Ananth> 13) Compatibility is required/desired with legacy SDH/SONET 
equipment 
Ananth>[and also legacy DWDM]

bala>BR: Same as above.

NSAP issue identified above. Elements within a link may not communicate 
using the signaling, i.e., legacy SDH/SONET equipment that does not 
participate in signaling (participate only in connectivity)

Thanks,
Ananth

---

From: John Drake <[email-masked]>
Date: Wed, 13 Jun 2001 07:59:15 -0700

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:[email-masked]]
Sent: Wednesday, June 13, 2001 7:33 AM
To: [email-masked]'; [email-masked];
[email-masked]
Cc: [email-masked]; [email-masked];
[email-masked]; [email-masked]; [email-masked];
[email-masked]; [email-masked]; [email-masked]
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)

---

From: John Drake <[email-masked]>
Date: Wed, 13 Jun 2001 08:20:12 -0700

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.

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.

Thanks,

John

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
Sent: Wednesday, June 13, 2001 6:09 AM
To: [email-masked]; [email-masked];
[email-masked]

> Where is the issue ? Why do we need NSAP addresses in GMPLS ?
> 
> Kind regards,
> 
> Eric
>
Eric, I understand your points on the 'management network'......that is, the
addressing of it's user-plane is a separate network to the user-plane
offered for cutsomer connections.  So let me concentrate on the 'external'
user-plane here in an attempt to answer your question.

Seems we have some choices in GMPLS at the moment:
Addressing - v4 or v6
Signalling - RSVP or CR-LDP
Routing - OSPF or IS-IS (but exterior is BGP only)

All these facets are, in principle, independent choices.  And, in
particular, since 'server layer trails = client layer links' then addressing
cannot be from the same space at a server and client layer.  The addressing
might have exactly the same format, but it comes from a different space, ie
address X at layer M is not = address X at layer M.

commercial as well as technical reasons - see the BT 'Freeland' requirements

regards, Neil

---

From: Lloyd Wood <[email-masked]>
Date: Wed, 13 Jun 2001 18:53:15 +0100 (BST)

On Wed, 13 Jun 2001, Robert Raszuk wrote:

> Lloyd,
> 
> I am afraid you have missed the point.

I rather think you missed mine.

> Please notice that RFC2026 clearly explains the requirements for a
> protocol to become a standard. It talks about the requirement for
> multiple implementations of the same protocol and not about
> multiple implementations of multiple protocols which could do the
> same thing.

I see my analogy between the sets of relationships of
implementations <-> standards
and
standards <-> underlying algorithms/principles/ideas
was lost on you...

> I agree with Yakov that having numerous IGPs, or TE signalling protocols
> is an IETF bug. 

You'd rather have IETF decree the choice of protocol by fiat? First
come is the winner? That's not the IETF. (Or at least, it didn't use
to be.) Redundancy and alternatives are good things.

> > If it wasn't for ISIS, OSPF would really suck. and vice versa.
> > Competition is Good.
> 
> Competition is good in the implementations of the same protocol between
> different vendors not betwen two groups of devlopers in the same
> company.

(The company should have a single group working on a protocol.)

If you're talking about competing protocols with similar functionality
in a company, each with its own design group, the company can always
decide to only support the one it thinks is better, or that it can do
better.

It can make a market choice. Or split into two companies. We don't do
protocol design for the convenience of a single company -- do we?

> Having numerous protocols which do exactly the same thing just
> waists everybodys time and resources.

OSPF and IS-IS don't do _exactly_ the same thing.

Think about societal benefits - you're advocating a single protocol in
each area in the name of efficiency, which limits scope for
advancement. That puts rather too much faith in the original design of
that single protocol.

Short-term efficiency loss and duplication of effort turns out to be 
long-term development gain.

L.

> > Lloyd Wood wrote:
> > 
> > On Wed, 13 Jun 2001, Yakov Rekhter wrote:
> > 
> > > 1. Providing multiple choices for performing essentially the same
> > > thing, especially if these choices have similar characteristics,
> > > doesn't help to develop multi-vendor interoperable solutions.
> > >
> > > 2. The fact that in the IETF there are not one, but two link-state
> > > IGPs (OSPF and ISIS) is a bug, and not a feature.
> > >
> > > 3. The same applies for MPLS signalling (CR-LDP vs RSVP).
> > 
> > Beg to differ. (and you mean RSVP-TE)
> > 
> > The IETF insists on at least two interoperable implementations of
> > anything to consider it for a standard. This allows the standard to be
> > proven, and to have a concept of the underlying standard that is
> > separate to any single implementation, while allowing choice of
> > competing implementations. Each implementation can be evaluated on its
> > merits; this exerts pressure on the implementations, and allows
> > debugging and improvement of the implementations with respect to the
> > underlying standard.
> > 
> > Similarly, going up a level of abstraction, having more than one
> > standard fulfil an implementation of a set of ideas increases
> > understanding of the underlying principles, independent of each
> > standard and its implementations, while allowing choice of competing
> > standards as expressed in their implementations. Each standard can be
> > evaluated on its merits; this exerts pressure on the standards, and
> > allows debugging and improvement of the standards with respect to the
> > underlying principles and algorithms.
> > 
> > If it wasn't for ISIS, OSPF would really suck. and vice versa.
> > Competition is Good.
> > 
> > L.
> > 
> > and I see just having BGP as a problem.

<[email-masked]>PGP<http://www.ee.surrey.ac.uk/Personal/L.Wood/>

---

From: [email-masked]
Date: Wed, 13 Jun 2001 14:07:09 -0500

Eric and others,
I think the NSAP support issue is being misunderstood. The requirement 
is to support non-IP  addresses at the edge (this may include NSAP) and 
translate/encapsulate to a routable IP address in the core (a la in a 
VPN scenario, where non-unique, non-IP addresses may be supported). 
i.e, support just IP-based routing in the optical control plane.
hope this helps clarify.

Ananth

-----Original Message-----
From: Eric.Mannie [mailto:[email-masked]]
Sent: Wednesday, June 13, 2001 5:32 AM
To: Nagarajan, Ananth; BRaja
Cc: Alanqar, Wesam; ccamp; Ferris, Tammy; Jones, Mark L.; mpls; Neir,
Lynn

Hello Ananth,

>uses NSAP).  So the timeframe requirement is now. 

Could you clarify the relationship between GMPLS and NSAP addresses ?

You can run several protocol stacks in parallel over the same control
channel. For instance, if your control channel is Ethernet, you can 
have an
IP stack and any other kind of stack using any other kind of addresses. 
The
two runs in parallel. 

The different stacks run in parallel in a "ship in the night" mode. The 
fact
that you have for instance a TMN stack using NSAP addresses is 
completely
orthogonal with a GMPLS stack.

Speaking about my DCN: we have one DCN for both our transmission 
network and
our IP network. The ADM's are managed using TMN only, DWDM equipment's 
are
managed using SNMP and TMN, IP routers are managed using SNMP only.
Everything uses the same DCN.

For the TMN only equipment's we route CLNS using IS-IS and we don't use 
IP
at all, it is pure OSI. For simplicity, we put MAC addresses (of the ADM
Ethernet interfaces) into the NSAP addresses. You could put an IP 
address
inside the NSAP address if you have a dual stack running on the box, 
that
will even be simpler.

For the DWDM equipment's we use SNMP and TMN. Each box has an IP 
address and
I have to check what we do for the TMN stack. I think that it is 
transported
over IP, maybe using RFC1006. If I remember correctly we only configure 
an
IP address on the DWDM box. In that case, I presume that TSAP's are 
build
using this IP address.

For the IP routers that we want to manage we use SNMP (full IP stack), 
and
it doesn't care about TMN and NSAP addresses. We use IS-IS and OSPF for 
the
routing in the DCN.

The small Cisco routers in the DCN forward and route both CLNS and IP.
Indeed we use IS-IS in the dual mode for CLNS and IP. These DCN routers 
and
their operations are independent of the nodes that we want to 
manage/control
- of course.

It works fine! Anyway, in a real DCN you will have new and old 
equipment's
and you will need to support both. This is completely independent of the
GMPLS stack. I could do VoIP using SIP (IP telephony signaling) over the
DCN, do I have to use NSAP addresses in my VoIP stack because there is 
some
TMN application that runs there as well ? No, of course.

For instance, you run OSPF-TE between two new core ION backbone switches
over an IP tunnel out-of-band using the DCN. GMPLS OSPF-TE packets and 
GMPLS
RSVP-TE messages are encapsulated over IP and these IP packets are
transported over the IP DCN using any kind of tunnelling scheme (IP in 
IP,
GRE, etc). The "external" IP packets are routed using IS-IS in the DCN. 
The
GMPLS OSPF-TE ignores the DCN IS-IS and vice-versa. 

So the GMPLS control plane runs completely independently of all the 
other
stacks that are already running.

Kind regards,

Eric

---

From: [email-masked]
Date: Wed, 13 Jun 2001 23:40:50 +0100

Hi John,

You observed 13 June 2001 16:20
> for a PNNI based solution, although a PNNI based solution might be a
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.
> its bandwidth advertisements are tightly coupled to ATM 
NH=> But PNNI seems as though it can more easily adapted to the required
job.  It has certain features that make it quite attractive like:
-	mature/tested, already deployed and understood
-	proven carrier-strength
-	multiple interfaces already specified, ie UNI, E-NNI, I-NNI, AINI
-	separate link and signalling protocols, eg SSCOP keepalives separate
from signalling, allows more physical interfaces not just connections per
interface
-	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;
-	support for address translation
-	supports S-PVC-type service
-	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;
-	good for phased migration (this is an importnat issue for
operators);
-	centralised route computation may be better for OTNs.....this would
be allowed;
-	separate signalling and routing means just signalling part can be
used
-	etc

It would, however, need some minor additional work to adapt it for SDH/OTN
as you note......like BW advertisements.
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.

Regards, Neil

---

From: [email-masked]
Date: Wed, 13 Jun 2001 23:40:46 +0100

Hi Eric.....many thanks for your comments....couple of observations:
<snipped>
> here working on GMPLS at the IETF, not on PNNI at the ATM 
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. 
> important distinctions between the two control planes than 
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.
> prefer, or that could come from another standardization body.
NH=> I don't want to do this either.
> 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). 
> 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?
> centric control plane. This is going in the opposite 
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

---

From: [email-masked]
Date: Wed, 13 Jun 2001 23:40:52 +0100

Good points Lloyd.....I have never seen a technical comparison of potential
solutions.....let alone a statement of requirements from carriers against
which to make this comparison (except the drafts from MCI/WCom and BT to the
12/00 mtg, which seem to have been ignored by some).

regards, Neil

> From: Lloyd Wood [mailto:[email-masked]]
> Sent: 13 June 2001 17:51
> To: Yakov Rekhter
> Cc: [email-masked]
> Subject: Re: GMPLS issues (was - GMPLS Last Calls)
> 
>

---

From: [email-masked]
Date: Wed, 13 Jun 2001 23:40:51 +0100

Hello Yakov.....

> 
> Please note that there is a way to carry NSAPs in IPv6 addresses,
> although it does not support all types of NSAPs.  (see rfc1888 for
> more details). Please also note that GMPLS supports IPv6 (as well
> as IPv4). Finally, please note that a "perfect" solution (the one
> that addresses all the requirements of everyone) is a *non* goal
> for GMPLS.
NH=> That is a fair point.  Indeed, it is looking at a best fit from our
perspective that is driving us......and I feel sure our position would be
reflected by many large/established carriers.  But you need to talk to the
right people in those carriers to get the true view.......I suspect these
people will not be tracking any of this discussion nor have looked at the
issues in depth yet.
> > And,
> Few points:
NH=> Agreed.  But who calls the shots here?
> 4. Suggesting yet another routing/signalling protocol, in addition
> to GMPLS, is adding yet another bug (not a feature).
NH=> Some bugs are better than others I guess.
> 
> 5. I understand that BT submitted a contribution to the ITU
> suggesting PNNI as (yet another) routing/signalling for optical 
> cross connects.
NH=> Better bug?

regards, Neil

---

From: [email-masked]
Date: Wed, 13 Jun 2001 23:40:48 +0100

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

> From: John Drake [mailto:[email-masked]]
> Sent: 13 June 2001 15:59
> To: 'Mannie, Eric'; [email-masked]';
> [email-masked]; [email-masked]

---

From: "Don Fedyk" <[email-masked]>
Date: Wed, 13 Jun 2001 20:13:02 -0400

Neil

You have made some pretty far reaching arguments. We also evaluated 
these schemes when we started GMPLS. It is my opinion we chose the 
route because we thought the IP-MPLS synergy in routing was strong. 
We run OSPF or IS-IS + BGP and we kill the overhead of having two 
routing systems with all the ills that go with it. There was also 
as John Drake mentioned more flexibility in adoption of capabilities. 
We tried once to put these in ATM and were shut down. Only after 
several years crank back solutions were introduced with still with 
some inflexible resistance.

Next we looked at the signaling protocols and we fought hard to get 
flexibility and a connection oriented behavior. It is my opinion that 
CR-LDP was the best suited for this and we still use this model 
but we have conceded at present to talking to most of the routers 
with RSVP-TE. The signaling protocol is really not most of the 
work it is the flexibility we were striving for and with the 
exception of refresh the two protocols stay closely in synch.

As far as addressing everyone seem to agree that we can add 
external addresses that have nothing to do with the core addressing 
so this is not about addressing. 

It is my opinion the best place to do this work has been the IETF 
over the last few years and here we use IP protocols. It has been 
the most responsive to the work to date. I don't see this suddenly 
changing and while you are right about it will look a lot like ATM 
when we get through that is because it is a connection oriented problem.

Don

---

From: John Drake <[email-masked]>
Date: Wed, 13 Jun 2001 17:12:50 -0700

Comments in line

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
Sent: Wednesday, June 13, 2001 3:41 PM
To: [email-masked]; [email-masked];

Hi John,

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.

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.

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.

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. 

JD:  GMPLS has this.

JD:  Not clear what you're referring to.

JD:  GMPLS has this.

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.  

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

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

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

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

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

Regards, Neil

---

From: <[email-masked]>
Date: Thu, 21 Jun 2001 17:03:25 -0700

regards, Neil

---

From: <[email-masked]>
Date: Thu, 21 Jun 2001 17:03:19 -0700

Bala,

Thanks,
Ananth

Agreed.

bala>BR: Same as above.

Thanks,
Ananth