[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
AW: Moving right along ...
Eric,
may be I was not clear when I asked for common labels:
A STM-4 signal with higher order VC-3 and lower order VC-11 is identical to
a STS-12 with STS-1 SPEs and VT1.5-SPEs. They have the same multiplex
structure and recent SDH and SONET equipment that supports such signals can
accept both with out problems.
The same applies to a STM-16 with higher ordr VC-4 and a STS-48 with
STS-3c-SPEs.
However with the the current defintion we would get different SUKLM values
for SDH and SONET. That is what should be avoided.
You mentioned one/two stage multiplexing. This is an implementation issue.
The result always has to look like two-stage multiplexing, for SDH and
SONET.
The current proposal is based on one-stage multiplexing for SONET and
two-stage multiplexing for SDH. This is the differenc.
My original propsoal uses two stage multipelxing for both (align the SONET
label to the SDH label).
You said that it will result in problems forSONET in case of forwarding
adjacencies that are not STS-3xN (e.g. STS-4). Ok, but the current proposal
has the same problem for SDH AU3s when you use a forwarding adjacency that
is not 3xN AU-3 (e.g. 4 AU-3).
So we have to use the one-stage approach for both SONET and SDH in order to
avoid the problem.
Again we are back to the same SUKLM structure for SONET and SDH.
Regards
Juergen
> -----Ursprüngliche Nachricht-----
> Von: owner-tsg15q11@itu.int [mailto:owner-tsg15q11@itu.int]Im Auftrag
> von Mannie, Eric
> Gesendet: Mittwoch, 24. Oktober 2001 14:56
> An: 'tsg15q11@itu.ch'; 't1x15@t1.org'
> Betreff: FW: Moving right along ...
>
>
> Dear All,
>
> I had the feeling that the information is passing transformed
> from the IETF
> to the ITU-T. So, I am forwarding you this e-mail.
>
> Kind regards,
>
> Eric
>
> -----Original Message-----
> From: Mannie, Eric
> Sent: Wednesday, October 24, 2001 1:50 PM
> To: ccamp@ops.ietf.org
> Cc: kireeti@juniper.net
> Subject: RE: Moving right along ...
>
>
> Dear All,
>
> Let me strongly clarify something about the SDH/SONET label. I started to
> see and receive comments from people that obviously didn't read the text
> carefully, or get lost due to "non-technical" comments.
>
> Let's kill the rumor.
>
> 1. The draft defines ONE label format: SUKLM
>
> As explained in the draft the SONET multiplexing structure is seen as a
> subset of the SDH one. It is also said that S, L and M have a similar
> meaning for SONET and SDH. U and K are not significant for SONET. This is
> why we have on single label format for "SDH/SONET".
>
> 2. We claimed since the beginning that our goal was to have a
> common format
> for both:
>
> This is why this format was accepted, discussed and enhanced, and this was
> beginning of year 2000!
>
> 3. SDH and SONET have and will continue to have two different multiplexing
> structures:
>
> - because there is no TUG-3 equivalent in SONET.
> - because there is no VT-3 equivalent in SDH.
>
> This is a fact.
>
> So it results, that the label for SONET and SDH can be as similar as
> possible, given these two limitations. They will NEVER be completely
> identical because this is not physically possible. The proposal of Juergen
> doesn't change that.
>
> The only difference between the current text and the proposal of
> Juergen is
> that:
>
> - the current text uses the single stage interleaving approach of SONET.
> - Juergen's proposal uses the two-stage interleaving approach of SONET.
>
> That's the only difference. I already explained the reasons why
> we used the
> single stage interleaving approach.
>
> So please, don't tell me that "some people want to align the labels...",
> this is we made almost two years ago.
>
> 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,
> >
> >
> >
> >
>