[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Addressing doc
Dimitri,
I'd like to summarize a couple of simple points:
· It is a fact that TE Router Address advertised in the top-level TE
RTR TLV must be a routable IP address;
· TE Router Address is a likely candidate to be used as TE RTR ID
(as a part, for instance, of unnumbered TE link ERO sub-object). Indeed,
what else can I use for this purpose if I compute a path over TE topology
built of unnumbered TE links?
· The conclusion: TE RTR ID (a transport node name) is also a
routable IP address (a controller address in DCN space). Hence, control
plane and TE name (or data plane name space, because TE name is a data plane
name as far as control plane is concerned) spaces are not completely
separate in GMPLS, and this fact could be (and recommended to be) taken
advantage of. Having said that nothing mandates using TE RTR ID as a
destination of RSVP message IP packets. If you have an entity/protocol like
LMP which maintains control plane/TE name bindings, you can use any valid
control plane name (IP address) to be used instead of TE RTR ID. However, it
is worth remembering that usage of LMP is not mandatory.
The bottom line is that I don't understand what makes you draw such
conclusions as:
(e.g. preclude complex node
> representation and/or allow exchanging IP control messages over channels
> logically or physically disjoint from the data bearer channels)
Igor
----- Original Message -----
From: "dimitri papadimitriou" <dpapadimitriou@psg.com>
To: "Richard Rabbat" <richard.rabbat@us.fujitsu.com>
Cc: "'Igor Bryskin'" <ibryskin@movaz.com>; "'Brungard, Deborah A, ALABS'"
<dbrungard@att.com>; "'Diego Caviglia'" <Diego.Caviglia@marconi.com>;
"'ccamp'" <ccamp@ops.ietf.org>
Sent: Thursday, April 21, 2005 7:11 AM
Subject: Re: Addressing doc
> richard, all,
>
> just to clarify
>
> - the TE Router ID can be used to identify unnumbered reachable points,
> in this case, the IP topology of the control plane, can for inst. be
> built from the IP routing topology and the TE information exchanged
> across this topology provides the needed information to retrieve the
> next hop, the need for LMP is not mandatory, what, it delivers is the
> facilitation of the construction, and injection into the local database
> of the these TE links (note: the CC used by LMP can be common to RSVP
> and the IGP) as well as all other goodies provided by LMP
>
> - the TE Router ID can also be used as source and destination for
> RSVP-TE packets - for. inst. CCAMP produced a document on TE Router ID
> based Hello messages - in this case the TE Router ID plays the same role
> as for any MPLS LSR, as long as numbered interfaces can be reached from
> this address (for unnumbered it is obviously the case) - in this context
> the role of LMP is the same wrt level from which we speak about the
> process here
>
> from this, the discussion point was simply that assuming the second
> alternative it is indeed obvious that the statement made as part of the
> document under discussion "The reason why the TE Router ID must be a
> reachable IP address is because in GMPLS, control and data plane
> names/addresses are not completely separated." is first assuming a
> specific usage of the TE router ID and secondly it is not control vs
> data plane address space separation issue but an IP control plane vs TE
> information identification issue (e.g. preclude complex node
> representation and/or allow exchanging IP control messages over channels
> logically or physically disjoint from the data bearer channels)
>
> hope this clarifies,
> - dimitri.
>
> Richard Rabbat wrote:
>
> > Igor,
> >
> > That's what the draft wanted to say. Thanks for putting it so well.
> >
> > We didn't mention LMP because we wanted the draft not to be specific
only to
> > transport. We'll update the wording as I said in a next revision to
reflect
> > the 2 modes of operation.
> >
> > Best,
> > Richard.
> >
> >
> >
> >>-----Original Message-----
> >>From: owner-ccamp@ops.ietf.org
> >>[mailto:owner-ccamp@ops.ietf.org] On Behalf Of Igor Bryskin
> >>Sent: Wednesday, April 20, 2005 1:20 PM
> >>To: Brungard, Deborah A, ALABS; Diego Caviglia; Igor Bryskin
> >><i_bryskin
> >>Cc: ccamp
> >>Subject: Re: Addressing doc
> >>
> >>
> >>Hi Deborah,
> >>
> >>An ERO describing a path dynamically computed on a graph built of TED
> >>contains TE link IDs (numbered and/or unnumbered) rather than
> >>control plane
> >>IP addresses.
> >>Hence, there are two choices:
> >>a) use some mechanism (e.g. LMP) to resolve next hop TE link
> >>ID into next
> >>hop controller IP address;
> >>b) use TE link IDs that are guaranteed to be routable
> >>addresses. TE Rtr ID
> >>is guaranteed to be routable. Any TE link ID (numbered or
> >>unnumbered) could
> >>be resolved to its local TE Rtr ID. That's where (as far as I
> >>understand)
> >>the recommendation comes from.
> >>
> >>Igor
> >>
> >>----- Original Message -----
> >>From: "Brungard, Deborah A, ALABS" <dbrungard@att.com>
> >>To: "Diego Caviglia" <Diego.Caviglia@marconi.com>; "Igor
> >>Bryskin <i_bryskin"
> >><i_bryskin@yahoo.com>
> >>Cc: "ccamp" <ccamp@ops.ietf.org>
> >>Sent: Wednesday, April 20, 2005 11:57 AM
> >>Subject: RE: Addressing doc
> >>
> >>
> >>These threads are a return to one year ago and confusing control plane
> >>and (logical) data plane addressing:
> >>https://psg.com/lists/ccamp/ccamp.2004/msg00335.html
> >>As the demo was on OIF UNI and GMPLS, the confusion is
> >>understandable as
> >>OIF uses different terminology, appendix 1 in the ason-signaling draft
> >>provides a comparison:
> >>ftp://ftp.isi.edu/internet-drafts/draft-ietf-ccamp-gmpls-rsvp-
> >>te-ason-03
> >>.txt
> >>
> >>Below, not sure the context of your reference to non-local in this
> >>scenario? Is the ERO following 3473/3477? The IP header is set to the
> >>next hop IP controller. One doesn't need LMP for resolving TE
> >>addresses
> >>- they are control plane "logical" addresses.
> >>
> >>Deborah
> >>
> >>-----Original Message-----
> >>From: owner-ccamp@ops.ietf.org [mailto:owner-ccamp@ops.ietf.org] On
> >>Behalf Of Diego Caviglia
> >>Sent: Wednesday, April 20, 2005 4:49 AM
> >>To: Igor Bryskin <i_bryskin
> >>Cc: ccamp
> >>Subject: Re: Addressing doc
> >>
> >>
> >>Igor,
> >> my two cents to the discussion.
> >>
> >>In line.
> >>
> >>Regards
> >>
> >>Diego
> >>
> >>
> >>
> >>Igor Bryskin <i_bryskin@yahoo.com>@ops.ietf.org on 16/04/2005 23.31.26
> >>
> >>Sent by: owner-ccamp@ops.ietf.org
> >>
> >>
> >>To: Dimitri.Papadimitriou@alcatel.be, Kireeti Kompella
> >> <kireeti@juniper.net>
> >>cc: ccamp@ops.ietf.org
> >>
> >>Subject: Re: Addressing doc
> >>
> >>
> >>Dimitri,
> >>
> >>Suppose a controller has just received an RSVP Path
> >>message that contains an ERO describing a path
> >>computed on the head-end (properly modified, of
> >>course, along the path). ERO is specified in terms of
> >>numbered or/and unnumbered TE links (and not IP
> >>addresses). Now the processing controller needs to
> >>forward the message to the controller that manages
> >>first non-local ERO sub-object. The question is what
> >>to set as destination in the IP header of the RSVP
> >>Path message?
> >>[dc] What about usage of the control channel addresses? I mean having
> >>LMP
> >>running between the two nodes the TNE is able to associate one or more
> >>Control Channels to the TE Link. In other words LMP is able
> >>to provide
> >>adress tanslation between the data plane addresses (TE Link)
> >>and control
> >>plane address (Control Channels).
> >>[CUT]
> >>
> >>
> >>
> >>
> >>
> >>
> >>
> >>
> >>
> >
> >
> >
> >
> > .
> >
>