[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: Moving right along ... Switching Type
To handle the case where the path of an LSP transits one or more TE links
which are advertised as having more than one of the following switching
capabilities (PSC, TDM, LSC, FSC) and the LSP is requesting a switching
capability of (PSC, LSC, or FSC).
Dimitri's proposal also works just fine when the path of an LSP transits
links which have only one advertised switching capability.
-----Original Message-----
From: manoj juneja [mailto:manojkumarjuneja@hotmail.com]
Sent: Wednesday, October 31, 2001 6:07 PM
To: John Drake; dimitri.papadimitriou@alcatel.be
Cc: zwlin@lucent.com; Ben.Mack-Crane@tellabs.com; kireeti@juniper.net;
ccamp@ops.ietf.org
Subject: RE: Moving right along ... Switching Type
Hi John,
If the switching type advertised in the link state database is say
Lambda or Fiber then why we need to carry this in signalling ?
Regards,
manoj.
>From: John Drake <jdrake@calient.net>
>To: 'manoj juneja' <manojkumarjuneja@hotmail.com>,
>dimitri.papadimitriou@alcatel.be
>CC: zwlin@lucent.com, Ben.Mack-Crane@tellabs.com, kireeti@juniper.net,
>ccamp@ops.ietf.org
>Subject: RE: Moving right along ... Switching Type
>Date: Wed, 31 Oct 2001 17:43:07 -0800
>
>Not exactly. When the switching type advertised in the link state database
>is TDM, then
>the signalling request doesn't require a switching type with a value of TDM
>
>-----Original Message-----
>From: manoj juneja [mailto:manojkumarjuneja@hotmail.com]
>Sent: Wednesday, October 31, 2001 5:32 PM
>To: dimitri.papadimitriou@alcatel.be
>Cc: zwlin@lucent.com; John Drake; Ben.Mack-Crane@tellabs.com;
>kireeti@juniper.net; ccamp@ops.ietf.org
>Subject: Re: Moving right along ... Switching Type
>
>
>Hi Dimitri,
> This means that switching type is not valid when LSP
>encoding
>
>type is SDH/SONET. Is this true ?
>
>Thank You for ur help.
>
>Regards,
>manoj.
>
> >From: Dimitri Papadimitriou <dimitri.papadimitriou@alcatel.be>
> >To: manoj juneja <manojkumarjuneja@hotmail.com>
> >CC: zwlin@lucent.com, jdrake@calient.net, Ben.Mack-Crane@tellabs.com,
> >kireeti@juniper.net, ccamp@ops.ietf.org
> >Subject: Re: Moving right along ... Switching Type
> >Date: Thu, 01 Nov 2001 01:30:49 +0100
> >
> >Hi Manoj,
> >
> >When Traffic_Parameters are used to create VC-4-Xc LSP for
> >instance, Switching Type would take a default value without
> >significance on the node switching capability preference since
> >inferred by the Traffic_Parameters. So when creating SDH/Sonet
> >LSP the Switching Type value will be ignored.
> >
> >PS: better to rephrase the below sentence as follows:
> > > >The usage of this field is thus optional and can (when applicable)
> > > >only be considered when traffic parameters are not defined.
> >
> >Hope this clarifies,
> >
> >- dimitri.
> >
> >manoj juneja wrote:
> > >
> > > Hi Dimitri,
> > > Are SDH/SONET traffic params in SNDER_TSPEC optional ? As
> > > per my understanding these are mandatory as it gives information
> > > regarding SDH/SONET label allocation (i.e. signal type, NCC, NVC, RCC
> > > etc). If SDH/SONET traffic parameters are not present then how can I
> > > determine these fields i.e. NCC, NVC, RCC, signals etc. from switching
> > > type ?
> > >
> > > Please correct me if I am wrong.
> > >
> > > Regards,
> > > manoj.
> > >
> > > >From: Dimitri Papadimitriou <dimitri.papadimitriou@alcatel.be>
> > > >To: Zhi-Wei Lin <zwlin@lucent.com>
> > > >CC: John Drake <jdrake@calient.net>, "'Ben Mack-Crane'"
> > > ><Ben.Mack-Crane@tellabs.com>, Kireeti Kompella
><kireeti@juniper.net>,
> > > >ccamp@ops.ietf.org
> > > >Subject: Re: Moving right along ... Switching Type
> > > >Date: Wed, 31 Oct 2001 23:52:16 +0100
> > > >
> > > >Hi,
> > > >
> > > >We have two approaches either "traffic-parameters" are used
> > > >(in SENDER_TSPEC) then i think the Switching Type capability
> > > >is useless or they aren't then such field could be optionaly
> > > >used when applicable (some examples are given in the routing
> > > >document).
> > > >
> > > >Wouldn't be the right way to proceed by defining an "unknown"
> > > >or "unspecified" value used when "traffic-parameters" are
> > > >included within the Path Message and optional use the ones
> > > >proposed in the current version of the specification when they
> > > >aren't. This field is thus optional and MUST only be used when
> > > >traffic parameters are not defined. I think this solves both
> > > >approaches.
> > > >
> > > >I think that also some additional text is needed in order to
> > > >clarify the semantic; the following one can be proposed (after
> > > >having discussed with some individuals):
> > > >"The Switching Type field is provided to allow nodes having
> > > >multiple switching layer capabilities to indicate their
> > > >preference. This field should only be used to indicate the
> > > >link switching preference but not end-to-end switching
> > > >preference".
> > > >
> > > >Notice that some proposal concerning the applicability scope
> > > >have been proposed but never really committed within the I-D.
> > > >
> > > >Cheers,
> > > >- dimitri.
> > > >
> > > >Zhi-Wei Lin wrote:
> > > > >
> > > > > Hi John,
> > > > >
> > > > > > <z>The section you mentioned, from what I can tell, is an
>example
> >list
> > > > > > of some possible combinations of different equipment functions.
>I
> >see
> > > > > > them as examples. But as I said, from routing perspective, it
>may
> >make
> > > > > > sense but not signaling. What you've pointed out is the routing
> > > >document...
> > > > > > From signaling perspective, if I removed the switching
>capability
> > > > > > field, there is nothing lost...do you agree?
> > > > > >
> > > > > >
> > > > > > JD: No. I will try again. What you have to demonstrate is that
> >for
> > > >all
> > > > > > possible combinations of switching capabilities supported on a
> >link,
> > > >an
> > > > > > intermediate node can deduce, from other fields in the Path
> >message,
> > > >what
> > > > > > switching capability is desired.
> > > > > >
> > > > >
> > > > > <z>Wow...ok...so I have to list all the different combinations of
> > > > > different switching capabilities on each side and the possible
> > > > > connections and then demonstrate that what switching capability is
> > > > > desired can be deduced...hmmm...can't I just say that whatever the
> > > > > encoding type says and the sender_tspec says is what the switching
> >type
> > > > > used (I'm lazy, it takes too long to run through all the
> > > >combinations)</z>
> > > > >
> > > > > >
> > > > > > And if I removed the switching capability field, then it opens
>the
> > > >door
> > > > > > for the possibility where somewhere within my network I might
> >change
> > > >the
> > > > > > switching type in order to satisfy a request (because the
> >switching
> > > >type
> > > > > > requested is non-existent or exhausted).</z>
> > > > > >
> > > > > >
> > > > > > JD: Please give an example of where substituting one value of
> > > >switching
> > > > > > capability for another in the middle of an LSP makes sense.
> > > > > >
> > > > >
> > > > > <z>Well, for example, you have a SONET network that can provide
> >STS-48c,
> > > > > and it goes through an all-optical network that can provide OCh1
> >(2.5G
> > > > > service). In the SONET network it switches the STS-48c layer,
>while
> >in
> > > > > OTN network it switches the OCh layer. This is very similar to
> >E1/VC-12
> > > > > connection, where one part of network may work PDH-based and
> >switching
> > > > > E1 while another part may be SDH-based and switching VC-12, but
>the
> > > > > connection or service is essentially the same. They're not really
> > > > > client-server layers but similar layers from different
> > > >technologies...</z>
> > > > >
> > > > > > <z>I think it does make sense. I think you have to assume that
> >within
> > > > > > the switched transport network there will be many kinds of
> >interfaces
> > > > > > connecting to the transport network. If you can't offer this
> > > >capability,
> > > > > > then essentially what you've done is segment the transport
>network
> > > >into
> > > > > > sub-networks based on what interfaces they have and only the
> >like-type
> > > > > > interfaces can connect to each other. If you look at the IP
>world,
>
> >you
> > > > > > might have a switch with 100 Mbps and another with 10 Mbps
> >connected
> > > > > > together and talking to each other without a problem. This is
> > > >capability
> > > > > > that is also needed, where one end could be 1 Gbps Ethernet and
> > > >another
> > > > > > end is 10 Gbps Ethernet. But one end can also be an OC-48 SONET
> >(no
> > > > > > reason to restrict this). What really matters is that the
>service
> >is
> > > > > > delivered. Granted there will be some inefficiencies in this,
>but
> > > >that's
> > > > > > really a policy decision whether users are willing to accept
>this
> >type
> > > > > > of connection.</z>
> > > > > >
> > > > > >
> > > > > > JD: What you're describing here is PSC LSPs and they work just
> >fine.
> > > >What
> > > > > > you were describing in your previous example was an LSP, one end
> >of
> > > >which
> > > > > > was
> > > > > > PSC and the other end of which was TDM. And that doesn't make
> >sense.
> > > > > >
> > > > >
> > > > > <z>Maybe this is one where we need to ask individuals with
> >operational
> > > > > experience and have some experience with service provisioning
> >whether
> > > > > having one end with Ethernet and another end with OC-48 sounds
>like
> >a
> > > > > configuration that makes sense?
> > > > >
> > > > > Again, the point here is that if this doesn't make sense, then
> > > > > essentially what you have is multiple switched networks, each
> >serving
> > > > > one particular type of customer interface, i.e., a switched
>network
> >for
> > > > > 1 Gb Ethernet, a switched network for OC-48, etc.
> > > > >
> > > > > Is this one of those "violent agreements" where we're
>concentrating
> >on
> > > > > two different levels but saying the same thing?</z>
> > > ><< dimitri.papadimitriou.vcf >>
> > >
> > > _________________________________________________________________
> > > Get your FREE download of MSN Explorer at
> >http://explorer.msn.com/intl.asp
> ><< dimitri.papadimitriou.vcf >>
>
>
>_________________________________________________________________
>Get your FREE download of MSN Explorer at http://explorer.msn.com/intl.asp
_________________________________________________________________
Get your FREE download of MSN Explorer at http://explorer.msn.com/intl.asp