Re: Moving right along ... Switching Type

[Zhi-Wei Lin <zwlin@lucent.com>]

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>