Re: Moving right along ... Switching Type

[Sudheer Dharanikota <sudheer@nayna.com>]

Hi Maarten:

Following ASON model... I have noticed the assumption that a set of
 access groups will form a subnet if and only if they at at the same
layer. With this in mind I have few comments below...

Maarten Vissers wrote:

> In a layered network approach (e.g. ASON), the switching type is obsolete... the
> routing is performed within a single layer network, using the links (ITU-T term)
> that are available in that layer network.
>

What do you mean switching type is obsolete? Does this mean you do not consider
it in G.7713 (DCM document)?

>
> >From a layer network's perspective, nodes have just a single switching
> capability (i.e. of that layer network)... nodes who do not have that switching
> capabiltiy are invisible... and nodes with this and other switching capabilities
> will only be presented with this layer network's switching capability; the other
> switching capabilities are invisible.
>

Does this mean a port  (to be precise an interface - IETF terminology) on a node
with multiple switching capabilities (reconfigurable adaptation functions :-)) will
be part of multiple subnetworks?

>
> Perhaps a additional sentence should be added to clarify that the switching type
> is obsolete for the case of a layered network approach.
>

I would not do this in such a hurry :-)

Regards,

sudheer

>
> Regards,
>
> Maarten
>
> 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>