Re: Moving right along ... Switching Type

[Ben Mack-Crane <Ben.Mack-Crane@tellabs.com>]

Dimitri,

I am still trying to understand the semantics of Switching
Type.  Your proposal MIGHT work in some situations, but it 
is not so useful to propose solutions until we understand 
what Switching Type means.  I am worried that it means
different things to different people, or has different meaning
in different situations.

It would be a mistake to simply gloss over this by saying
sometimes we use it and sometimes we don't.

Regards,
Ben

Dimitri Papadimitriou wrote:
> 
> 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>