Yakov,
See embedded comment below.
Ewart
> -----Original Message-----
> From: Yakov Rekhter [mailto:yakov@juniper.net]
> Sent: Wednesday, October 31, 2001 8:19 PM
> To: Zhi-Wei Lin
> Cc: ccamp@ops.ietf.org
> Subject: Re: Moving right along ... Switching Type
>
>
> Zhi-Wei,
>
> > <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?
>
> Let me see if I understand your proposal. Consider the following
> example:
>
> R1---OXC1---OXC2----R2
>
> where the TE interface on R1 is a collection of GigE ports, and the TE
> interface on R2 is a collection of OC-48 ports. Are you saying that
> establishing an LSP between R1 to R2 makes sense ?
[EWART]: Correct. OXC1 may be capable of performing signal conversion or, more likely, there may be some intermediate non-GMPLS device between R1 & OXC1 that performs such a conversion (refer to e-mail entitled "Query on Encoding field wrt presence of technology conversion devices - OSPF-TE/ISIS-TE extensions", 23rd Oct., on which you were copied and which, for the benefit of those that were not, I have repeated below) because the OXC has no GigE interface port.
"Within the GMPLS related routing documents (draft-ietf-ccamp-ospf-gmpls-extensions & draft-ietf-isis-gmpls-extensions), there is an Encoding field contained in the Interface Switching Capability Descriptor sub-TLV of the Link/IS Reachability TLV.
My request for GMPLS to support FiberChannel is driven by a need for clients to be able to attach to the ASTN using FiberChannel. However, the ASTN devices at the edge (e.g. LSR A in the diagram below) may not be equipped with FiberChannel ports. In this situation, the FiberChannel coming from the client device (client A in the diagram below) has to pass through a technology conversion device that maps the FiberChannel to something which LSR A is capable of supporting. For example, there are devices readily available on the market today that map FiberChannel to POS. Client A is opaque to this conversion being done - when client A wants to establish an LSP on the FiberChannel link, it does so using FiberChannel based GMPLS signalling (i.e. LSP Enc. Type = FiberChannel, G-PID = FC-3) - the signalling is handled by LSR A, and not by the non-GMPLS savvy technology conversion device. Similarly, any signalling performed by LSR A to client A wrt this same link will use FiberChannel based GMPLS signalling, even though the link which manifests itself on a FiberChannel port on client A manifests itself on a SONET port on LSR A. However, in terms of the GMPLS signalling that LSR A propagates downstream, within a SONET based ASTN, this will be SONET based GMPLS signalling.
SONET SONET (LSP Enc. Type = SONET,
| G-PID = one of POS*)
| | | |
technology v v v v client A ------ conversion ------ LSR A ------- LSR B ------ LSR C ------- client B
^ device
| \-------------------------------/
| ASTN
FiberChannel
(LSP Enc. Type = FiberChannel,
G-PID = FC-3)
My question is that in the above instance, the LSP established between client A and client B will have an Encoding Type of FiberChannel from client A's perspective, and of type SONET from client B's perspective. How do the OSPF-TE/ISIS-TE extensions handle the above case?"
>
> Yakov.
>
>