Subject: RE: Optical link bundling. Was Re: Draft Minutes From Pittsburgh

From: John Drake <[email-masked]>
Date: Wed, 18 Oct 2000 18:16:42 -0700

Neil,

I'm not sure how you justify the second half of this assertion.  

Clearly the authors of the relevant I-Ds as well as other interested
parties have recognized the first part of your assertion since the
GMPLS work began. 

Thanks,

John

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
Sent: Wednesday, October 18, 2000 5:44 PM
To: [email-masked]
Cc: [email-masked]
Subject: RE: Optical link bundling. Was Re: Draft Minutes From
Pittsburgh

SNIP                                       

	BTW nested LSPs also fit this model.......but this has not been
recognised yet.

	Neil

---

From: [email-masked]
Date: Thu, 19 Oct 2000 10:21:39 +0100

John Drake wrote:

> I'm not sure how you justify the second half of this assertion. [NH=> that
> BTW nested LSPs also fit this model.......but this has not been recognised
> yet. ] 
> 
	NH=> This is based on requiring to have independence between layer
networks and that overhead which is relevant only to a given layer network
has fixed/known points of generation/termination.  This is not so much an
issue for GMPLS (ie a philosophy of a common control-plane across L1/2/3)
but more about nested LSPs from a user-plane perspective and, specifically,
the OH fields in the shim header.  Let me give you 3 examples of what I
mean, and all stem from the "server layer trails = client layer links"
relationship between layer networks:

	-	TTL:  A link connection between 2 nodes in layer N is 1 hop
in layer N.  The fact that there may be a further LSP (ie trail), at layer
N-1, serving this link connection and having its own X label swapping links
connections should not be known to layer N.  This relationship can recurse.
One should therefore not try and predict the TTL at Layer N (in terms of
some prior decrement for the single link connection) due to nested (latent)
LSPs (and their hops) below it.  This may become quite important when
considering (future) inter-domain LSPs, eg when a private network running
MPLS want to tunnel its LSPs across one or more intervening operator MPLS
domains.  Prior guessing of TTLs would also be a potential problem when one
considers restoration, ie the server LSP hop count may change, but the
client remains at 1 hop.  In essence, the TTL of LSP N is relevant only to
LSP N and should not make any assumptions about hops in any server LSPs.

	-	Pipe vs Uniform model:  Here I am considering the Exp bits.
Again consider a private network tunnel across one of more operators
networks.  The private network may want to keep its own Exp LSP codings
which may not have any relationship to how the operators use these bits.  So
all the private network may require from the operator(s) is some LSP SLA
that covers some notions of 'effective LSP BW' and LSP survivability.

	-	PHP:  If an LSP is supposed to run across LSR1-2-3-4, but
PHP is done at LSR 3 then this terminates the LSP header at LSR3.  So in
reality the trail does not extend to LSR4.  This may cause some problems
when one wants to associate consistent functional processing (ie defect
handling, restoration between 2 points, client/server adaptation, etc) with
a known trail termination point.

	John, I hope the above is clear as to what my concerns are.  Which,
in summary, can be stated as we really ought to have some rules governing
where trail OH is generated and terminated and those rules ought to be
employed consistently.

	Alex.....I also saw you tagged mail on this too this morning, wrt to
saying that nested LSP has been thought about.  I think you are talking
about the control-plane aspacts (and I agree its has been here) whilst I am
talking about the user-plane aspects here (in terms of where OH
functionality is consistently generated/terminated and processed).

	Enjoyed the debate.....thanks for all comments.

	Neil

---

From: John Drake <[email-masked]>
Date: Thu, 19 Oct 2000 09:58:27 -0700

Bala,

I think that there's a big difference between the service interface offered
to a user (aka the front end) and the interface that a service device uses
to attach to the rest of the network (aka the back end).  There's no reason
why the back end couldn't be GMPLS in peer mode even if the front end was
something silly like ATM UNI.

Thanks,

John 

-----Original Message-----
From: Bala Rajagopalan [mailto:[email-masked]]
Sent: Thursday, October 19, 2000 9:42 AM
To: John Drake
Cc: [email-masked]'; [email-masked]; [email-masked];
[email-masked]; [email-masked]
Subject: Re: [IP-Optical] RE: Optical link bundling. Was Re: Draft
MinutesFrom Pittsburgh

Hello,

John Drake wrote:

>
>
> For example, a few years ago, one would build an IP service using routers
> mesh connected in an overlay on top of a PNNI  transport network.  This
was
> perceived as an exquisitely painful way of doing things and led directly
to
> the development of MPLS.  I.e., extend the IP control plane to support
> traffic engineering and then have the ATM switches implement MPLS.  This
> eliminates the artificial overlay boundary between IP routers and ATM
> switches.  (On the other hand, there would still be operational benefits
to
> using MPLS to control the ATM switches even if the network owner wished to
> maintain this overlay boundary.)

In the case of IP over optical,
I would just like to add that once you do have an IP-centric control
plane within optical networks, you could have routing between IP and
optical network that in fact supports the overlay model, alleviating the
scalability concerns that arise with IP over ATM model described above.

It's then a question of the coupling between the IP and optical control
planes. This can be as loose or tight as you want, for example, supporting
a UNI that separates the control planes, or the peer model without any
separation.

I do agree that if  you considered other types of clients,  the
peer model constructs don't seem  practical.

regards,

--

Bala Rajagopalan
Tellium, Inc.
2 Crescent Place
P.O. Box 901
Oceanport, NJ 07757-0901
Tel: (732) 923-4237
Fax: (732) 923-9804
Email: [email-masked]

---

From: [email-masked]
Date: Thu, 19 Oct 2000 18:14:07 +0100

Hi Bala,

I agree totally with what you said.  I think I perhaps gave the impression
to Alex and John that I am against an IP-centric control plane.  This is not
the case - I'm not against any type of control plane just yet.

My first point is that we have to fully understand the requirements of the
optical layer before we decide upon which protocols to use for it.  My
second point is as you stated - the peer model is impractical for an
operator who wants to have a multi-client OTN (whether the control plane is
IP-centric or not).  I would like to see some more debate on both these
points, because I'm sure there are many keeping quite who have strong views
on both.

Regards,
Darren.

-----Original Message-----
From: Bala Rajagopalan [mailto:[email-masked]]
Sent: 19 October 2000 17:42
To: John Drake
Cc: [email-masked]'; [email-masked]; [email-masked];

Hello,

was
to
to

regards,

--

Bala Rajagopalan
Tellium, Inc.
2 Crescent Place
P.O. Box 901
Oceanport, NJ 07757-0901
Tel: (732) 923-4237
Fax: (732) 923-9804
Email: [email-masked]

_______________________________________________
IP-Optical mailing list
[email-masked]
http://lists.bell-labs.com/mailman/listinfo/ip-optical

---

From: John Drake <[email-masked]>
Date: Thu, 19 Oct 2000 10:33:22 -0700

Whatever

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
Sent: Thursday, October 19, 2000 10:21 AM
To: John Drake; [email-masked]
Cc: [email-masked]; [email-masked]; [email-masked];
[email-masked]
Subject: RE: [IP-Optical] RE: Optical link bundling. Was Re: Draft
Minutes From Pittsburgh

Hi John,

At the risk of sounding repetitous ...

>> There's no reason why the back
>> end couldn't be GMPLS in peer mode

I believe there is a reason.  And I've yet to be convinced otherwise by
anyone.  The way I see it, peer model = single control plane.  Single
control plane = common addressing, signalling, & routing.  Common addressing
= only possible if the OTN has a single client.  This has been explained in
the recent "server layer trails = client layer links" links discussions =>
i.e. common addressing not possible in a multi-client OTN => i.e. peer model
impractical in a multi-client OTN.  I think this fundamental issue has to be
recognised.

Regards,
Darren.

-----Original Message-----
From: John Drake [mailto:[email-masked]]
Sent: 19 October 2000 17:58
To: 'Bala Rajagopalan'
Cc: [email-masked]'; [email-masked]; [email-masked];
[email-masked]; [email-masked]
Subject: RE: [IP-Optical] RE: Optical link bundling. Was Re: Draft
Minutes From Pittsburgh

Bala,

Thanks,

John 

-----Original Message-----
From: Bala Rajagopalan [mailto:[email-masked]]
Sent: Thursday, October 19, 2000 9:42 AM
To: John Drake
Cc: [email-masked]'; [email-masked]; [email-masked];

Hello,

was
to
to

regards,

--

Bala Rajagopalan
Tellium, Inc.
2 Crescent Place
P.O. Box 901
Oceanport, NJ 07757-0901
Tel: (732) 923-4237
Fax: (732) 923-9804
Email: [email-masked]

---

From: John Drake <[email-masked]>
Date: Thu, 19 Oct 2000 10:46:29 -0700

Upon reflection, it appears that you're equating the peer model with snake
handling

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
Sent: Thursday, October 19, 2000 10:21 AM
To: John Drake; [email-masked]
Cc: [email-masked]; [email-masked]; [email-masked];

Hi John,

Regards,
Darren.

-----Original Message-----
From: John Drake [mailto:[email-masked]]
Sent: 19 October 2000 17:58
To: 'Bala Rajagopalan'
Cc: [email-masked]'; [email-masked]; [email-masked];

Bala,

Thanks,

John 

-----Original Message-----
From: Bala Rajagopalan [mailto:[email-masked]]
Sent: Thursday, October 19, 2000 9:42 AM
To: John Drake
Cc: [email-masked]'; [email-masked]; [email-masked];

Hello,

was
to
to

regards,

--

Bala Rajagopalan
Tellium, Inc.
2 Crescent Place
P.O. Box 901
Oceanport, NJ 07757-0901
Tel: (732) 923-4237
Fax: (732) 923-9804
Email: [email-masked]

---

From: Kireeti Kompella <[email-masked]>
Date: Thu, 19 Oct 2000 10:55:27 -0700 (PDT)

> = only possible if the OTN has a single client.

I don't agree with this last statement: why is this the case?

I see a perfectly viable network with a single control plane for
"internal use" AND a UNI interface for other "external" clients.
Partition the lambdas in the optical network into "for internal use"
and "for external use", if that's what is required -- use some policy
mechanism, or do it by configuration.  If the "external clients" are
IP-based, just don't share your addresses with them.  In today's IP
networks, IGP addresses are not shared across external BGP sessions.
Or use IGP areas to isolate addresses.

However, the point of GMPLS is NOT a peer model.  It is an IP-based
control plane, leveraging existing work, and the flexibility of a
peer or overlay or hybrid model.

Kireeti.

---

From: "Manfredi, Albert E" <[email-masked]>
Date: Thu, 19 Oct 2000 13:55:00 -0400

Seems to me, Darren, that most in the IETF _do_ expect the OTN to have
primarily one client: IP. This would also track with other efforts, such as
diffserv, enum, and VoIP, in which any non-IP-centric signaling is relegated
to the edges (or up in the layer structure, such as H.323).

Wasn't the biggest problem with ATM deployment that its clients were almost
exclusively IP, while its signaling structure was absolutely not? The early
adopters were not what had been intended by design, IMO.

In the late 1980s, maybe traffic loads were not favoring IP. The common
wisdom now is that they do favor IP.

Bert
[email-masked]

---

From: Paul Joseph <[email-masked]>
Date: Thu, 19 Oct 2000 14:53:54 -0700

>  a UNI that separates the control planes, or the peer model 

Not sure what you mean here - terminology seems all different - MPLS in
itself separates the control plane from the user plane - that fact that we
use an IP control plane with an Optical or ATM data plane makes that evident
- the peer model is a peering at the IP level and the UNI just provides a
form of signalling between the 2 peers - so they are one and the same thing
- once you have decided to use MPLS.

Paul

---

From: [email-masked]
Date: Thu, 19 Oct 2000 23:52:04 +0100

John,

> Upon reflection, it appears that you're equating the peer model with snake
	NH=> Can I suggest you go and have a chat to with those actually
responsible for P&L in operators, ie not the R&D bits....now this *is* snake
handling!  I think this may give you a good insight of the commercial
reality as to why we can't ignore the support (and not just short-term) of
various types of client networks.  Unfortunately I don't think you will hear
these people speaking on the list, so you would have to seek them out.

	I am however, somewhat surprised by the lack of operator's comments
on the list........maybe they are not tuned-in or maybe they are and don't
care (and, if so, then so be it)?

	Neil

---

From: [email-masked]
Date: Thu, 19 Oct 2000 23:52:07 +0100

> peer or overlay or hybrid model.
	The basic argument you are making here Kireeti (and one I saw John
Drake advocate) is that it makes sense not to re-invent the control-plane
(which has been the case historically) for every new user-plane
technology/PDU-type.  I strongly agree with this view.  However, exactly
*which* control-plane aspects one should use is a different question....and
this is essentially the point Darren Freeland was making, and against which
(it appears) some have already make decisions as to what is the right
solution without any real debate of the 'requirements'. 

	I have also tried to make the point (using technical arguments, and
not very successfully it seems) that there are *commercial* issues at play
here and we are not dealing with some greenfield site where an idealistic
solution is viable (even if right, and I am not sure it is)....the simple
fact is that operators like BT will have to support many types of different
client layer.  Ergo, a peer model for operators like ourselves is not
currently a viable option....it's as simple as that.

	Now lets return to the more technical aspects and arguments, since
we still have a duty (as engineers) to be forward looking and evaluate
proposals on their technical merits...even if accountants control the
near/medium-term.

	John (Drake) used the ATM/IP (and the mess of MPOA) as analogous to
the IP/OTN case....so the argument then develops into 'let's use the same
(control-plane) solution for everything' (which is essentially the GMPLS
philosophy).  The assumption in GMPLS is that the key facets of an
(historical) IP control-plane (ie v4 addressing, RSVP signalling (OK CR_LDP
too.....maybe even better for OTN) and an IGP such as OSPF) are the *right*
choices for an OTN (or indeed everything).

	I could now use a great deal of BW up explaining why ATM/IP and
OTN/IP are very different animals.......so I will be as brief as I can be,
and I apologise to any left wondering why I made any of the following points
(come back to me off-line if you need the detail):

	In the ATM/IP case there are compelling reasons to unify the
control-plane with the concept of MPLS....such as:
	-	to avoid the VoXX N^/2 type of gateway problem across
user/control/management/oss planes
	-	to unite a CO and CNLS transfer mode.....though currently
the CO aspect is network-only (so-called control-driven LSPs) due to, quite
correctly, the current predominant type of Internet traffic, ie
short-holding WWW.......but this may not always be the case, esp when clever
applications people start thinking how to use all the BW that the OTN will
provide........think video and possibly long-holding interactive sessions.
This could radically alter the required/dominant transfer mode, and indeed
the role of MPLS.
	{Aside: This could also solve the QoS issues as a by-product,
however it requires an open-mind to see the possibilities.  Hint:  The only
2 truly scalable networks I am aware of (both proved by existence) are the
PSTN and the Internet}
	-	to unify the addressing (the other 3 key facets of the
control-plane, ie routing/discovery technique, signalling protocol and the
special requirements of the signalling network itself are secondary to
addressing)......this is really why MPOA could never work (the details are
clearly more complex than I hint at here, but the essential problem is a
lack of address unification).

	IP and ATM as user-plane PDUs have quite a lot in common (esp at AAL
level):
	-	application interfacing
	-	relatively fast time-constants wrt to network demand
changes......and within this issue is the problem of TE
	-	small granularity user-plane PDU structures....allows
concepts of buffers and differential serving treatment of PDUs

	But as we go down the server layer stack the time-constants change,
ie they increase.  The slowest time-constants are associated with the duct
network...and this really is a network and it is a very important one.  This
is the ultimate expression of real TE (wireless/radio people might argue
with this, but the 'environment of physical occupancy' is the essential
feature) and this is where the availability bound of all client layers is
determined.  The OTN we should note, is just above the duct network, ie it
is dealing in coarse BW granularities and longish time-constants (compared
to its finer BW granularity client layers).

	So what are the essential features of the *user-plane* of the OTN?
	-	no practical buffering....so we can forget IP, ATM, FR, or
indeed any type of binary frame/packet/cell/PDU structure as being *an
essential driver*.  Or, perhaps put another more obvious way, the OTN
doesn't do DiffServ.
	-	it is CO/cct-sw and user-plane transparent....so it can't
identify PDU boundaries (I have heard some people say this about ATM, but
the PTI of the cell O/H in AAL5 does this)
	-	it will have (for commercial reasons) lots of legacy/new
client networks, and indeed peer coarse managed BW services, it will have to
support....and customers will also demand this, let alone being an operator
*must have*.

	So what does this mean wrt to its control-plane?
	-	well its addressing clearly has to be disjoint from any
client addressing space ('server layer trails = client layer links').  v4 is
already creaking in the IP layer.  v4 has also had to learn the lessons of
aggregation and the need for routing and topology to have close linkages (ie
CIDR and users having to take address stems from ISPs)  So why would v4 be
an 'obvious' choice for the OTN?
	-	we are dealing with a CO/cct-sw fabric whose clients, in
terms of PDU structure, are almost irrelevant....so what is the best
signalling protocol for this environment?  It is certainly not clear to me,
and I think many others, why RSVP would come out tops in any such
evaluation.
	-	routing/discovery.......I'm not sure what is best here for
the OTN.  But there is much to be learnt from both the Internet world and
the Telephony world on what would be the best solution here.  Though I have
to say here that I would want this restricted to an OTN layer problem since
I simply don't understand how, in an environment of multiple clients, I can
have any (for want of a better expression) a 'distributed/unified
routing/discovery protocol across multiple layers'...and with all the
scalability/client-priority/etc issues this throws up.

	So, in conclusion, to say that 'an IP control plane' (whatever that
actually means) is appropriate for the OTN simply does not compute with me
at the present time based on my own analysis of the problem-space.

	Neil

---

From: [email-masked]
Date: Fri, 20 Oct 2000 11:51:06 +0100

Hi Yangguang,

Yes, perhaps the choice of overlay or peer model should be left to operators
dependent on their business models.  I recall that there was a draft from
Lucent & Japan Telecom presented in Pittsburgh that touched on possible
business models for the OTN (draft-hayata-ipo-carrier-needs).  Perhaps these
need to be included in a new draft that fully considers operator
requirements for the optical layer ...

Regards,
Darren.

-----Original Message-----
From: Yangguang Xu [mailto:[email-masked]]
Sent: 19 October 2000 18:31
To: [email-masked]; [email-masked]
Subject: Re: [IP-Optical] RE: Optical link bundling. Was Re: Draft
MinutesFrom Pittsburgh

Hi,

Should peer/overaly model the choice of service providers according to their
business models?  

Yangguang 

John Drake wrote:
> 
> Darren,
> 
> GMPLS allows, but does not require, multiple types of hierarchically
related
> LSPs to exist in a single instance of a link state database.  If a network
> owner decides to have MPLS devices supporting multiple types of LSPs in
the
> same instance of a link state database, then his network is an
instantiation
> the peer model.
> 
> From my perspective, the focus of the peer model is to facilitate how a
> network owner constructs his network most efficiently and not how he
> represents it to his customers.  The latter is typically done using
multiple
> service definitions.
was
to
to
> GMPLS just extends this concept to encompass other types of transport
> networks.
> 
> Thanks,
> 
> John
> 
> Sent: Thursday, October 19, 2000 2:53 AM
> To: [email-masked]; [email-masked]
> Cc: [email-masked]; [email-masked]
> Subject: [IP-Optical] RE: Optical link bundling. Was Re: Draft Minutes
> From Pittsburgh
> 
> Hi Alex,
> 
> >>> - "server layer trails (in an OTN) = client layer links", and
> >>> networks operators *will* have to support multiple client
> >>> layers for a very long time...including some large BW servives
> >>> directly off the L1 fabric.
> >>>
> >>> This is a really important point.  It is a fundamental
> >>> characteristic of a layered network architecture.
> >
> > [AZ] Got it. I didn't realize what layers you meant.
> 
> This is the first time I have actually seen anyone on the MPLS or IPO
lists
> publicly acknowledge the "client layer links = server layer trails" fact.
I
> assume then that you now also acknowledge the single control plane 'Peer'
> model as being impractical?  Okay, using a single 'best of breed' routing
> protocol and a single 'best of breed' signalling protocol across the IP
and
> optical layers may be feasible (I stress may), but it follows from the
above
> simple concept (as Neil Harrison stated before) that the addresing scheme
> used by the optical layer cannot be related to any particular clients (ie
> not from the same addressing space in terms of possible trail connectivity
> at layer network access points).  Sure this would not be the case if IP
was
> the only client of the optical layer, but (*reality check*), operators
WILL
> still be making most of their revenue from non-IP clients for a long time
to
> come, and therefore an optical transport network WILL have to support
> multiple clients.
> 
> Are we now seeing a realisation of this in the IETF?  I think it's obvious
> that what was defined as the 'Overlay' model in
> draft-awduche-mpls-te-optical-02.txt and
> draft-many-ip-optical-framework-01.txt must be developed first.
> 
> Cheers,
> Darren.
>

---

From: Kireeti Kompella <[email-masked]>
Date: Fri, 20 Oct 2000 09:20:44 -0700 (PDT)

Hi Darren,

> Perhaps you missed my point.  I didn't say the point of GMPLS is a peer
> model (I have read the draft) - I questioned the assumption that IP-centric
> control protocols will be appropriate for an optical (or indeed any) control
> plane.

Could you clarify what you mean by "IP-centric control protocols":
a) IP control protocols (such as OSPF, RSVP, CR-LDP), or
b) control protocols aimed at serving an IP infrastructure?

> As far as I can see (having read the IPO framework, the MPLambdaS,
> and the Generalised MPLS drafts I hasten to add), this assumption has been
> made without giving full consideration to the requirements of the particular
> networks the protocols will be applied to.  My interest is the OTN, so
> that's what I've been focussing on.

Why I ask the above question is that there is a UNI based on IP
control protocols (draft-gray-mpls-rsvp-oif-uni-ext-00.txt), which
caters to non-IP uses of the OTN, and whose underlying model is the
overlay model.  This draft is in response to the *OIF*'s requirements
for an optical UNI.

So, if your objection is to the IP-centricity of the GMPLS approach
(which is debatable), you may find the above UNI more suitable to
your needs.

However, if your objection is to the use of IP control protocols,
that's a different issue.  Note that the IETF is unlikely to be the
right venue for discussing say PNNI as a control plane for the OTN.

For what it's worth, the MPLS control plane is IP-based, but serves
non-IP uses quite well.  There is an upcoming foo-over-MPLS BOF that
illustrates this point.

[...]

> I think a new draft is in order,

Very possibly.

> but I get the feeling many won't like it.

That hardly matters.  If it makes sense to service providers, the
vendors will come around :-)

One thing though is to better articulate what is broken with the
current approach.  If it's not the "peer vs. overlay" model that's
the issue, then like you say, I've missed your point, and would
like to understand what the real problem is.

Kireeti.

---

From: "Fu, James" <[email-masked]>
Date: Fri, 20 Oct 2000 09:24:26 -0700

Darren:
 
        You have issued some concerns about the IP-centric control plane for
optical networks.  Some of them are legitimate questions. However, you tried
too hard to convince everybody to agree with you in a whole. It won't
happen.  We suggest you take some concrete approaches rather than by
questioning the whole thing.

1) IETF framework is kind of requirement that you are talking about. It is
not perfect and  is working in progress. We prefer you putting some addition
requirement and enhancement into the framework.

2) IP centric control plane could borrow some Telecom ideas, like something
positive from you and BT, etc.

  In reality, IP centric control plane is a very good choice, maybe not the
best one.   

Sorrento Networks

James Fu 

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
Sent: Friday, October 20, 2000 3:40 AM
To: [email-masked]
Cc: [email-masked]; [email-masked]; [email-masked]
Subject: RE: [IP-Optical] RE: Optical link bundling. Was Re: Draft
Minutes From Pittsburgh

Hi Kireeti,

plane.  As far as I can see (having read the IPO framework, the MPLambdaS,

The IPO framework document starts out in the introduction by saying that
"there is wide consensus in the industry that the optical control plane
should be IP-centric".  I would question this 'wide consensus'.  There is a
few (very basic) requirements set out in the introduction, but nothing that
justifies thoroughly the choice of IP-centric control protocols for the OTN.

The MPL(ambda)S document does the same - we're told in the intro that the
optical control plane will be based on the MPLS TE control plane model.  The
only justification that is given for this is the reuse of existing
protocols.  Cool - why not reuse PNNI then?  I'm not advocating one or the
other yet - what I am saying is that the requirements of the OTN (or any
other network in the case of GMPLS) should be fully considered in the first
place.  The choice (and extensions) of control plane protocols should then
be made to fit these requirements.

The other problem I have with the MPL(ambda)S philosophy is its clear bias
towards the 'peer' option.  Sure, the 'overlay' option is described, but it
is not fully discussed - we are simply told that "to understand the
drawbacks of this approach ... one need look no further than the experience
with IP over ATM".  This is a whole discussion in itself which Neil Harrison
has touched on in his reply to you.  ATM is not the OTN.  This aside, my
point is that the peer model is clearly advocated over the overlay model -
but there is no mention to the effect the peer model would have on an
operator who has a multi-client environment.  There is also a clear
reluctance on this list to recognise the problems the peer model may bring.

I think a new draft is in order, but I get the feeling many won't like it.

Regards,
Darren.

---

From: [email-masked]
Date: Fri, 20 Oct 2000 17:55:05 +0100

Hi Kireeti,

> b) control protocols aimed at serving an IP infrastructure?

I mean (a) - questioning the assumption that these will be used for the OTN
control plane.  I think it makes sense to fully consider OTN requirements
before we decide upon which protocols will best meet these requirements.  I
don't believe that operators requirements have been discussed enough here to
justify the assumption of (a) for the OTN.  Note that I would also be
questioning this if people were working on extensions to any other
particular set of control protocols, without working to an agreed set of
requirements! 

> overlay model.  This draft is in response to the *OIF*'s requirements

I was not aware of this ID.  Thanks.  I will have a look at it when I'm back
in the office Monday morning.

> right venue for discussing say PNNI as a control plane for the OTN.

I am not objecting to the use of any particular control protocols ... yet.
My point is that we have to have more discussion on operators requirements
before we can decide.

> non-IP uses quite well.  There is an upcoming foo-over-MPLS BOF that

I read the draft - looking forward to the BOF :)

> vendors will come around :-)

Thanks for the encouragement.  I think I've made my point for now.  I would
like to hear (on the list) opinions from other vendors though.  Otherwise,
I'll keep quite(ish) until I have an ID to contribute :)

> like to understand what the real problem is.

My first concern is as discussed above.  My second is the validity of the
peer model for an operator such as ourselves with multi-client requirements.
I have noted the proposal highlighted by John Drake that we could have an
overlay based model at the UNI, and a peer based one at the NNI.  This is
something I have to consider in more detail.  I am still not convinced on
common addressing across client and server layers ('server layer trails =
client layer links').  If someone can convince me otherwise, I'm willing to
listen.

Have a good weekend.

Darren.

---

From: [email-masked]
Date: Fri, 20 Oct 2000 18:04:56 +0100

Hi James,
 
> However, you tried too hard to convince everybody to agree 
> with you in a whole. It won't happen. 
 
I realise this :)
 
> We suggest you take some concrete approaches rather than by questioning
the whole thing. 
 
Indeed.  Watch this space.  Enough from me for the time being though, it's
now 6pm Friday night over here :)
 
Regards,
 
Darren.       

-----Original Message----- 
From: [email-masked] [ mailto:[email-masked]
<mailto:[email-masked]> ] 
Sent: Friday, October 20, 2000 3:40 AM 
To: [email-masked] 
Cc: [email-masked]; [email-masked]; [email-masked] 
Subject: RE: [IP-Optical] RE: Optical link bundling. Was Re: Draft 
Minutes From Pittsburgh 

Hi Kireeti, 

Regards, 
Darren. 

_______________________________________________ 
IP-Optical mailing list 
[email-masked] 
http://lists.bell-labs.com/mailman/listinfo/ip-optical
<http://lists.bell-labs.com/mailman/listinfo/ip-optical>

---

From: "Osama Aboul-Magd" <[email-masked]>
Date: Fri, 20 Oct 2000 14:21:09 -0400

You may also consider the draft on LDP extensions for optical UNI
<draft-mpls-aboulmagd-ldp-opical-uni-00.txt.

Regards;

Osama Aboul-Magd
ASON Standards and Architecture
Nortel Networks
P.O. Box 3511, Station "C"
Ottawa, ON, Canada
K1Y - 4H7
Tel: 613-763-5827
e.mail: [email-masked]

---

From: [email-masked]
Date: Fri, 20 Oct 2000 22:05:41 +0100

Hi Alex, you observered:
> So, maybe it would be more constructive if you document your assumptions,
> understanding of the current situation, required functionality and
> concerns you have. This would be very valuable, I guess, and would
> let people express their opinion. Such a document could serve as
> a basis for [hopefully] more productive discussion.
> 
> If e-mail does not work out, I think we can always schedule a BOF-like
> meeting (not necessarily at an IETF one). Face-to-face always works
> better.
> 
	NH=>This activity has been ongoing in BT for some time and we are
currently formulating our requirements for the OTN.  We have already
mentioned many of our concerns/views on the list.  If complete in time for
the next IETF we may try and bring something along to help shape the
framework.  We are also already active with other operators/vendors and
working on G.ason in the ITU....which is starting with a 'requirements
capture' phase for the OTN control-plane.  Always willing to talk face-face.
	Neil

---

From: [email-masked]
Date: Mon, 23 Oct 2000 14:35:30 +0100

Thanks Osama :-)

-----Original Message-----
From: Osama Aboul-Magd [mailto:[email-masked]]
Sent: 20 October 2000 19:21
To: [email-masked]; [email-masked]
Cc: [email-masked]; [email-masked]; [email-masked]
Subject: RE: [IP-Optical] RE: Optical link bundling. Was Re: Draft Minutes
From Pittsburgh

Regards; 

Osama Aboul-Magd

---

From: [email-masked]
Date: Mon, 23 Oct 2000 17:42:47 -0500

I believe you will find that carriers are already working on 
requirements in T1X1 and the ITU-T.  The OIF Carrier group document 
served as a catalyst to get the requirements on paper.  That has 
triggered carrier work on requirements in T1X1 and elsewhere for 
inclusion in IETF and ITU-T documents.  We don't need another group to 
work this issue.

The best results will come from carrier/vendor interaction to develop 
acceptable requirements.

Mark Loyd Jones
Sprint
Technology Planning & Integration
913-534-5247
[email-masked]

> From: azinin [mailto:[email-masked]]
> Sent: Friday, October 20, 2000 6:25 PM
> To: yxue
> Cc: azinin; darren.freeland; braja; jdrake; neil.2.harrison; mpls;
> ip-optical
> Yong,
> Friday, October 20, 2000, 2:26 PM, Yong Xue <[email-masked]> wrote:
> 
> [...]
> 
> > I think the carrier
> >  should form
> >  a group and come up with a control plane  protocol requirements
> 
> [...]
> 
> I believe such a document would be very valuable.
> 
> Alex.
> 
> 
>