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

Re: Addressing doc

igor

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 two above point are not under discussion - what's your exact point ? these are consequence of the compliance to RFC 3630

· 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.

the notions of representation of a data plane endpoint in the control plane and data plane endpoints have been detailed in ASON documents and LMP transport, which very precisely explains the related aspects - the confusion in your text comes from the fact you are overlookng the fact that GMPLS does accommodate data plane technologies and operations providing their own addressing space or borrowing values from the one e.g. LMP provides based on the use of an IP-based control plane i.e. interface ID uses IPv4, IPv6, or unnumbered interface IDs.

Having said that nothing mandates using TE RTR ID as a destination of RSVP message IP packets. 

of course the above issues are decoupled, as explained here below

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)


examples have been remember to you by deborah, and are also detailed in
several documents provided that details several aspects of this problem

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]













.





.