[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: RS-DT Wrap-Up Statements
Hi Igor,
I support you on both points, and I believe
Dimitri's writeup is intended to allow the
separation of routing and signaling controllers.
The issue of the router ID or link ID being
routable seems to be ingrained in 3477, at
the same time I am also uncomfortable about
this requirement, if the transport node
does not support PSC.
Cheers,
Lyndon
-----Original Message-----
From: Igor Bryskin [mailto:ibryskin@movaz.com]
Sent: Wednesday, November 24, 2004 8:29 AM
To: dpapadimitriou@psg.com; dimitri.papadimitriou@alcatel.be
Cc: dimitri.papadimitriou@alcatel.be; ccamp@ops.ietf.org
Subject: Re: RS-DT Wrap-Up Statements
dimitri, see in-line
----- Original Message -----
From: "dimitri papadimitriou" <dpapadimitriou@psg.com>
To: "Igor Bryskin" <ibryskin@movaz.com>
Cc: <dimitri.papadimitriou@alcatel.be>; <ccamp@ops.ietf.org>
Sent: Wednesday, November 24, 2004 11:02 AM
Subject: Re: RS-DT Wrap-Up Statements
> igor - see in-line:
>
> Igor Bryskin wrote:
>
> > Dimitri,
> >
> > Do you think it is reasonable/practical to separate routing controller
from
> > signaling controller and consider scenarios such as a single routing
> > controller manages (provides advertisements) for several transport nodes
> > with each of the latter having a dedicated signaling controller for TE
> > tunnel provisioning?
>
> this is a "functional" separation - in the basic association Si <-> Ri
> <-> i, we retrieve the canonical LSR (note i will change the word "can"
> by "may" in the below informational statement)
IB>> Separation could be physical, not just functional. Consider, for
instance, a transport network built of WXCs that do not have own control
plane. In this case a routing controller managing one or several such WXCs
could advertise their resources, while separate signaling controllers with
the help of PCE(s) could compute and signal TE paths for them.
>
> > Also, how in your opinion a signaling controller knows which address to
send
> > Path message for the next hop along the path.
> > Possible options:
> > a) ID of a numbered link is routable or RouterID in unnumbered ERO
> > sub-object (which is transport node ID) is routable;
>
> several points here:
> 1. we refer to a "TE Router_ID" per RFC 3477 recommendation
> 2. we should indicate these "identifiers" are TE reachable in the scope
> of the covered application
> 3. even if relevant the scope of this is related to routing
>
> > b) necessary binding (neighbor linkID=> neighbor signaling address,
neighbor
> > nodeID=> neighbor signaling address) is provided via LMP
>
> in the case of multiple association an additional information is
> required that falls beyond the scope of routing and that could be
> achieved using LMP
>
IB>> Personally, I don't like the assumption that transport node IDs and
linkIDs of numbered links are routable (especially in the context of non-PSC
networks) and prefer relying on LMP or some other neighbor auto--discovery
mechanism.
Igor
> hope this clarifies,
> - thanks.
>
> > Thanks,
> > Igor
> >
> >