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

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]













.