Re: Moving right along ...

[Maarten Vissers <mvissers@lucent.com>]

Eric,

What you refer to as "our own model" is already developed by ITU-T SG15... it is
in G.8080 (ex. G.ason) and other ASON related recommendations which will be
approved later this week. We are also entering the next phase in ASON
development; a phase in which protocol specific details will be defined. A
proposal to use PNNI as a basis is accepted... and expected in the near future
is a proposal to use also GMPLS as a 2nd protocol version... but if I understand
your message, GMPLS wouldn't fit the ASON model... :-(

It's good to know this beforehand... no need then to consider this further...
feels as if I wasted my time in enhancing GMPLS SDH/SONET and OTN details over
the last 10 months... hope it's different however.

Regards,

Maarten
PS. when I wrote my reply to Yanhe there was no frustation... and their isn't
today either...


"Mannie, Eric" wrote:
> 
> Hi Maarten and Zhi,
> 
> I have the feeling that you are inventing a new model with a new protocol.
> This is not how GMPLS works. I understand your frustrations and I have the
> feeling that your ideas should be addressed somewhere else rather than
> trying to change a model that we are finalizing and that we got from the
> MPLS model.
> 
> There are maybe 1000 ways of designing a control plane for transmission
> networks. I would suggest that you first develop your own model and then
> that we compare the two.
> 
> Please, don't forget that we have here to be constructive in terms of GMPLS.
> We have final discussions about the core GMPLS signaling, this is not the
> beginning but the end of an (intermediate) phase.
> 
> Ok, GMPLS doesn't do everything. It doesn't do coffee and doesn't clean your
> house :-) We know it. Personally, I don't believe in the ultimate model and
> protocol that will do everything and that will take 10 years to be
> specified, with abstract protocols, meta-models, etc.
> 
> By the way, personally I don't see any benefit of defining these
> meta-models, abstract models and abstract protocols. It is hard to
> understand for non super-expert and it is a complete loss of time for the
> readers. I prefer practical solutions.
> 
> I am also seeing discussions that we already have many times in the past. I
> don't see any benefit of having them again, and again, and again. If we
> continue like this we will all implement a tool to answer automatically with
> our previous e-mails :-)
> 
> Ok, there is a small set of people that don't like the way that GMPLS is
> designed and defined (always the same 4 or 5 people by the way) - that's
> 100% your right guys and I respect it. In comparison with the hundreds
> (thousands ?) of people that are working on GMPLS and implementing it, this
> is a great achievement !
> 
> So, I ask you the question: what do you want to achieve personally at this
> stage ? Don't you think that sometimes it is needed to finish one step,
> before going to the next one ?
> 
> Kind regards,
> 
> Eric
> 
> -----Original Message-----
> From: Maarten Vissers [mailto:mvissers@lucent.com]
> Sent: Monday, October 22, 2001 11:07 PM
> To: Yanhe Fan
> Cc: 'Zhi-Wei Lin'; John Drake; Kireeti Kompella; ccamp@ops.ietf.org
> Subject: Re: Moving right along ...
> 
> Yanhe,
> 
> The situation Zhi describes is one that will be very typical in the optical
> (SDH/SONET) network in the coming years. We will most likely see islands of
> switched subnetworks interconnected via the existing SDH/SONET non-switched
> networks. By means of management actions, links (GMPLS: link bundles) will
> be
> setup between an edge node in one switched subnetwork and an other edge node
> in
> the next switched subnetwork. In G.805 terminology, these links are so
> called
> serial compound links.
> 
> The switched subnetworks will treat these serial compound links as normal
> links,
> "ignoring" the intermediate non-switched nodes they traverse. These links
> will
> contain a fixed set of link connections, which are identified by their
> respective endpoints at nodes A and Z (i.e. SNPa - SNPz).
> The server signal that carries the e.g. 5 STS1 link connections in the link
> at A
> can be an OC12, whereas this can be an OC48 at Z.
> 
> During discovery or by means of provisioning both A and Z nodes get aware of
> the
> 5 sTS1 link connections as tuples of e.g.
> 
>         SNPa             SNPz
> -----------------------------------
> - port Ai/trib T1 - port Zj/trib Ta     (STS1 link connection #1)
> - port Ai/trib T2 - port Zj/trib Tb     (STS1 link connection #2)
> - port Ai/trib T3 - port Zj/trib Tc     (STS1 link connection #3)
> - port Ai/trib T4 - port Zj/trib Td     (STS1 link connection #4)
> - port Ai/trib T5 - port Zj/trib Te     (STS1 link connection #5)
> 
> As both ends of the link build up this same relation information, it is
> possible
> to use as link connection identifier only one of the two SNPs. E.g. node A
> identifies the STS1 link connection #1 by means of "Ai/T1" and sends this
> info
> to node Z. Node Z receiving this Ai/T1 converts this locally into "Zj/Ta".
> Vice
> versa, node Z will refer to STS1 link connection #1 as "Zj/Ta" and when
> received
> by node A, this will be converted into Ai/T1.
> 
> For GMPLS this implies that the GMPLS label doesn't identify the timeslot at
> both ends of the link connection, only the timeslot at the sending end. The
> receiving end needs to convert this then into its local timeslot number.
> 
> Regards,
> 
> Maarten
> 
> Yanhe Fan wrote:
> >
> > Hi Zhi,
> >
> > What B does is breaking the label association between A and C by crossing
> > connect
> > the time slots.
> >
> > If the cross connect performed by B is fixed (in your case), what needs to
> > do is
> > just to rebuild the label association by configuration or a protocol such
> as
> > LMP;
> > If the cross connect is not fixed but dynamic, the best thing to do is to
> > make B
> > a GMPLS speaker.
> 
> Tell this to the 1.000.000+ SDH/SONET network elements in today's transport
> network... no chance... those will stay non-switched...
> 
> >
> > Yanhe
> >
> > -----Original Message-----
> > From: Zhi-Wei Lin [mailto:zwlin@lucent.com]
> > Sent: Friday, October 19, 2001 6:01 PM
> > To: Yanhe Fan
> > Cc: John Drake; Kireeti Kompella; ccamp@ops.ietf.org
> > Subject: Re: Moving right along ...
> >
> > Hi Yanhe,
> >
> > Maybe there is some misunderstanding. Node B is strictly not GMPLS. It
> > is simply part of the network that made up the "dumb" pipe. And because
> > the control plane control channel is separate, A and C can be adjacent
> > without ever knowing who B is or that even B existed. From A and C's
> > point of view, the network looks like:
> >
> >   A ----- C
> >
> > Think of the case of how a BGP sees an area. If an area is made up of:
> >
> >   A -- B -- C
> >
> > and B is internal router, does BGP "see" B?
> >
> > Zhi
> >
> > Yanhe Fan wrote:
> >
> > > Hi, Zhi
> > >
> > >
> > >>For the label value for SONET/SDH or the label description in the
> > >>generic draft, the label is defined as directly representing the
> > >>"timeslot". Now if I have a control plane controlled transport network
> > >>that goes through a ADM that is not control plane controlled, as:
> > >>
> > >>
> > >>+--------+               +--------+               +--------+
> > >>|        | ---1--------- |        | ----1-------- |        |
> > >>|        | ---2--------- |        | ----2-------- |        |
> > >>|  A     | ---3--------- |   B    | ----3-------- |   C    |
> > >>|        | ---4--------- |        | ----4-------- |        |
> > >>|        | ---5--------- |        | ----5-------- |        |
> > >>+--------+               +--------+               +--------+
> > >>
> > >>Now imagine A and C is part of GMPLS, but B is just a legacy ADM. So at
> > >>A you have labels 1,2,3,4,5 (imagine these as in the SUKLM format) and C
> > >>has labels 1,2,3,4,5 incoming.
> > >>
> > >>Now imagine that at B, it actually has a fixed cross-connect that
> > >>connects A-1 (A's timeslot #1) to C-2 (C's incoming timeslot #2), A-2 to
> > >>C-3, A-3 to C-4, A-4 to C-5, A-5 to C-1.
> > >>
> > >>Now when A GMPLS sends a message to C, the label it uses is "1".
> > >>However, the connection/LSP associated with timeslot "1" is actually the
> > >>label of timeslot "2" at C. </z>
> > >>
> > >
> > > In this case, you're trying to use GMPLS to setup an LSP cross a node
> (B)
> > > which can't understand GMPLS.
> > >
> > > Now imagine A, B and C are all OXCs, can you setup an LSP A-B-C by using
> > > GMPLS if B can't understand GMPLS?
> > >
> > > Now imagine A and B are LSRs, and B is a conventional router (can't
> > > understand
> > > MPLS), can you setup an LSP A-B-C?
> > >
> > > Now imagine A, B and C are ATM switches, can you setup a svc if B can't
> > > understand PNNI at all?
> > >
> > > My point is that in order to make you case work, some additional work
> need
> > > to
> > > be done besie simply using GMPLS as singnaling protocol, becase some
> node
> > on
> > > the path is not GMPLS speakers. A and C needs the info of time slot
> > aligment
> > >
> > > between them. This can be done by some configurations, some link
> > management
> > > protocls (LMP maybe) etc. As long as A and C have this piece of info,
> > > eveything
> > > works fine.
> > >
> > > Yanhe
> > >
begin:vcard 
n:Vissers;Maarten
tel;cell:+31 62 061 3945
tel;fax:+31 35 687 5976
tel;home:+31 35 526 5463
tel;work:+31 35 687 4270
x-mozilla-html:FALSE
org:Optical Network Group;Lucent Technologies Nederland
version:2.1
email;internet:mvissers@lucent.com
title:Consulting Member of Technical Staff
adr;quoted-printable:;;Botterstraat 45=0D=0A=0D=0A;1271 XL Huizen;;;The Netherlands
fn:Maarten Vissers
end:vcard