[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Moving right along ...
Hi Zhi,
I still don't understand the following you claim to be an "uninformed
reader which would like to know what SDH/Sonet is all about" but after
you are defending the Juergen's proposal.
How can an uninformed reader defend a technical solution for which he
requests more clarifying text to be become informed ? Are you an
technically informed uninformed reader ;-) ?
Please clarify your position,
Dimitri.
"Mannie, Eric" wrote:
>
> Hello Zhi,
>
> > From one uninformed reader to another... and of course my desire to add
> > clarifying text to the document to help uninformed reader like myself
> >understand what SONET/SDH is all about...
>
> Is this a joke ? May I remind you that you and your colleagues where more
> than deeply involved in the SDH/SONET drafts, and also that you are listed
> among the co-authors of that draft. I am surprised to see that you are
> uninformed :-)
>
> Kind regards,
>
> Eric
>
> -----Original Message-----
> From: Zhi-Wei Lin [mailto:zwlin@lucent.com]
> Sent: Wednesday, October 24, 2001 9:11 AM
> To: Irfan Lateef
> Cc: kireeti@juniper.net; ccamp@ops.ietf.org
> Subject: Re: Moving right along ...
>
> Hi Irfan, good summary! I think (b) is probably right for some. I don't
> see (c) as been the case...
>
> From one uninformed reader to another, I think the quote you had was a
> frustrated person stating what he thinks was implied by another
> frustrated person's statement (am I putting words in anyone's mouth?).
>
> From what I understand G.ason and G.dcm is developed to describe the
> process and the minimal requirements needed to support a basic switched
> transport service. GMPLS is a protocol specific implementation that will
> likely meet many of the requirements, and may have some minor areas that
> it does not meet. Then the question to ask (as with any requirements and
> architecture work -- I'm sure we all have architects in our company) is:
> how critical are the requirements that may not be met and what changes
> are needed to GMPLS (if any) in order to meet them?
>
> The last few email exchanges I think has been process related: why are
> things added to GMPLS, who has authority to add. Why can't we make GMPLS
> drafts more clear to people reading these drafts?
>
> Of course there were also some fundamental issues, such as Juergen's
> desire to align the labels (which I agree with), Yangguang's question of
> why we are taking a fundamentally different approach for recovery since
> the "transport world" has done it one way for a long time and now it's
> suddenly changed & and authors not willing to discuss why the
> "traditional" way is not desired, and of course my desire to add
> clarifying text to the document to help uninformed reader like myself
> understand what SONET/SDH is all about (which is probably purely
> political rambling...)
>
> Zhi
>
> Irfan Lateef wrote:
>
> > A view from the side lines
> > -------------------------------
> >
> > First, on the lighter side I have the following suggestion.
> > we should change the subject line to any of the following,
> > a. Stubbornly stuck - refusing to move forward
> > b. Political Ramblings
> > c. Serious Trouble
> > d. Ugly email war among adults behaving like kids
> > I vote for (b)
> >
> > Now on the serious side, I have a few questions.
> >
> > 1. Does the chair of this WG think that this email thread is a necessary
> > democratic step in the process.
> >
> > 2. If not, then why isn't somebody stepping in with a summary of issues
> > and resolving them. Isn't there any arbitration process.
> >
> > 3. If the protocols are designed to be flexible to accomadate future
> changes,
> > why aren't the authors treating "some of the" requests as part of the
> flexibility
> >
> > and getting along.
> >
> > 4. I feel the authors were treating last call as a formality and are not
> ready
> > to accept changes because it is a last call. Then what is the real
> intent of
> > last call.
> >
> > 5. There seems to be a real disconnect between the needs of,
> > a. vendors and service providers
> > b. data vendors and transport vendors
> > If GMPLS is for at least this three groups, then the issues need to be
> > resolved to the satisfaction of this small set.
> > (I personally agree with not spending 10 years trying to develop a
> panacea for
> > all)
> >
> > 6. And finally it is alarming to me to note the following assertion.
> > "GMPLS wouldn't fit the ASON model... :-( "
> > Can someone clarify the true import of this statement. My
> understanding was
> > GMPLS is
> > the only thing on which ITU,OIF and IETF are on the same page. Can you
> please
> > correct
> > me on this and clarify as am a truly "uninformed" person on this.
> >
> > Regards,
> > Irfan Lateef
> >
> > Maarten Vissers wrote:
> >
> >
> >>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
> >>>>>
> >>>>>
> >
> > --
> > Irfan Lateef
> > Village Networks Inc,
> >
> >
> >
> >
begin:vcard
n:Dimitri;Papadimitriou Dimitri
tel;home:+32 2 3434361
tel;work:+32 3 2408491
x-mozilla-html:FALSE
url:http://www.alcatel.com
org:Alcatel Bell;IPO NA (NSG) - Antwerpen
version:2.1
email;internet:dimitri.papadimitriou@alcatel.be
title:Optical Networking R&S - Senior Engineer
adr;quoted-printable:;;Francis Wellesplein, 1=0D=0AB-2018 Antwerpen;;;;BELGIUM
fn:Papadimitriou Dimitri
end:vcard