[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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



> Markus,
> 
> The router would specify LSC in the generalized label request.  The
> Router/OXC links are PSC at the router end and LSC at the OXC end.
> 
> Thanks,
> 
> John

Good, this is what I expected. But as I said the spec seems to be
in conflict with this interpretation. How about we change 
the sentence:

    Nodes MUST verify that the type indicated in the Switching Type
    parameter is supported on the corresponding incoming interface.

to:

    Transit nodes MUST verify that the type indicated in the Switching Type
    parameter is supported on the corresponding incoming interface.

I guess egress nodes could check that the Switching Type parameter is
supported on the far end of the incoming link.

Thanks,
Markus


> -----Original Message-----
> From: Markus Jork [mailto:mjork@avici.com]
> Sent: Monday, December 17, 2001 1:39 PM
> To: Lou Berger
> Cc: ccamp@ops.ietf.org
> Subject: Re: Moving right along ... generalized-rsvp-te-05 
> 
> 
> 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 
> 
> 
> 
>