Subject: RE: Addressing doc

From: "Brungard, Deborah A, ALABS" <[email-masked]>
Date: Wed, 20 Apr 2005 10:57:36 -0500

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: [email-masked] [mailto:[email-masked]] 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 <[email-masked]>@ops.ietf.org on 16/04/2005 23.31.26

Sent by:    [email-masked]

To:    [email-masked], Kireeti Kompella
       <[email-masked]>
cc:    [email-masked]

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]

---

From: "Igor Bryskin" <[email-masked]>
Date: Wed, 20 Apr 2005 13:19:35 -0400

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" <[email-masked]>
To: "Diego Caviglia" <[email-masked]>; "Igor Bryskin <i_bryskin"
<[email-masked]>
Cc: "ccamp" <[email-masked]>
Sent: Wednesday, April 20, 2005 11:57 AM
Subject: RE: Addressing doc

Deborah

-----Original Message-----

Igor,

In line.

Regards

Diego

Dimitri,

---

From: "Richard Rabbat" <[email-masked]>
Date: Wed, 20 Apr 2005 15:48:20 -0400

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.

> From: [email-masked] 
> [mailto:[email-masked]] 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

---

From: dimitri papadimitriou <[email-masked]>
Date: Thu, 21 Apr 2005 13:11:52 +0200

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:

> .

---

From: "Igor Bryskin" <[email-masked]>
Date: Thu, 21 Apr 2005 09:45:46 -0400

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

Igor

----- Original Message ----- 

From: "dimitri papadimitriou" <[email-masked]>

To: "Richard Rabbat" <[email-masked]>

Cc: "'Igor Bryskin'" <[email-masked]>; "'Brungard, Deborah A, ALABS'"
<[email-masked]>; "'Diego Caviglia'" <[email-masked]>;
"'ccamp'" <[email-masked]>

Sent: Thursday, April 21, 2005 7:11 AM

---

From: dimitri papadimitriou <[email-masked]>
Date: Thu, 21 Apr 2005 16:25:24 +0200

igor

> 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

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

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

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