Re: Moving right along ... generalized-rsvp-te-05

[Markus Jork <mjork@avici.com>]

Lou,

I think there is still some confusion in the draft regarding
the switching type. Of course it could also be that the draft
is perfectly clear and I'm confused...

Quoting a response you gave to Manoj/Ben:

> > >
> > > >A Tunnel (FA) is a type
> > > >    of link, not a class of switching.  This adds to the
> > > >    confusion I've noted about the need for and use of Switching
> > > >    Type.
> >
> >Switching Type continues to be ill-defined.  I have heard that the real
> >definition is different from that given in the current drafts.  If the
> >signaling information is not clearly defined and it's use described, we
> >can hardly expect interoperability.
> 
> I can't speak for others.  My belief is that there is a very concrete 
> definition.   I thought the text in the draft was clear as well, but let me 
> try again:
> 
> 
>          Switching Type: 8 bits
> 
>          Indicates the type of switching that should be performed
>          on a particular link.  This field is needed for links that
>          advertise more than one type of switching capability.
>          This field contains one of the values advertised for the
>          corresponding link in the routing Switching Capability
>          field as defined in [GMPLS-RTG].
> 
> In other words, on links where one Switching Capability is advertised 
> (which will be all the time for most equipment) Switching Type is set to 
> the same value as advertised in routing.  On links where multiple Switching 
> Capabilities are advertised, Switching Type is set to the value advertised 
> in Switching Capability that matches the type of switching to be performed.
> 
> [I'll put the revised text in the next rev...]
> 

Let's look at the example of two IP routers connected to a cloud of
opaque OXCs:

R1 ----- OXC1 ----- OXC2 ----- R2
    LSC        LSC        PSC

OXC1 and OXC2 switch the Sonet stream from an incoming interface to
some outgoing interface, that's why links R1-OXC1 and OXC1-OCX2
are advertised as LSC in the IGP. Link OXC2-R2 is PSC because R2 looks
at the incoming IP packets. The encoding on the links is OC192.

Now I want to setup an LSP between R1 and R2. (This LSP is essentially
a "lightpath" through the optical cloud and will be advertised as FA
so that PSC LSPs can be tunneled through it later.)
What is the switching type requested in the Generalized Label Request
object? I would expect LSC.
But section 2.1 of draft-ietf-mpls-generalized-rsvp-te-06 says:

   A Generalized Label Request object is set by the ingress node,
   transparently passed by transit nodes, and used by the egress node.

This would suggest the switching type needs to be PSC.
But then the text in 2.1.1 says:

   Nodes MUST verify that the type indicated in the Switching Type
   parameter is supported on the corresponding incoming interface.  If
   the type cannot be supported, the node MUST generate a PathErr
   message with a "Routing problem/Switching Type" indication.

So when the Path message requested PSC, it would be rejected by OXC1
and OXC2. When it requested LSC it would be rejected by R2.
The transit nodes can't modify the switching type in the Path message
because they don't have enough knowledge to pick the right one.
How is this supposed to work?

thanks for any clarification,
Markus