RE: Addressing doc

["Ong, Lyndon" <Lyong@Ciena.com>]

Hi Deborah,

Oh no! :-0  The discussion has been contaminated by OIF!

Seriously, the draft does not mention "OIF" anywhere - you're welcome to
search through it.   The terminology (and any confusion)is all GMPLS, as
is 99% of the testing at Isocore.  I would also note that the authors of
the draft talked to a number of people within CCAMP to try and pin
down the usage of the TE Router ID and this appeared to be the most common
view at the time (however it was an incomplete sample, and importantly
did not include Dimitri and Igor's input).

The issue has nothing to do with the Gen_UNI, as far as I know, as this is
for separation of user and network addressing spaces (as Jonathan points
out).

Cheers,

Lyndon

  

-----Original Message-----
From: owner-ccamp@ops.ietf.org [mailto:owner-ccamp@ops.ietf.org]On
Behalf Of Brungard, Deborah A, ALABS
Sent: Wednesday, April 20, 2005 2:17 PM
To: Igor Bryskin; Diego Caviglia; Igor Bryskin <i_bryskin
Cc: ccamp
Subject: RE: Addressing doc


Hi Igor, (and Kireeti, Adrian)

A TE link with a routable control plane IP address? Routable within a
GMPLS control plane context or within a control (channel) plane context?
It's difficult to discuss as everyone is mixing terminology. GMPLS
carefully distinguishes a GMPLS LSR Router ID and TE link addresses (and
corresponding GMPLS routing) from control channel addressing (and
corresponding routing). Adrian explained this in the email link below.
Whereas OIF assumes a 1:1 association and flat routing of control
channel and data topology, and resulting in an implementation of using
the control channel addresses for their tunnel endpoints. Though then
one would have the same issue as OIF identified, how to carry the
"routable" network node address, resulting in Gen_UNI.

And the difficulty with the draft is that it cycles about then to say:
"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."

When as Dimitri said, the draft choose this 1:1 limitation as it's
implementation, it's not GMPLS.

My concern with the draft is that it has several of these statements,
mixing the discussion of control plane and data plane names/addresses
when it is referring to control plane="control channel names/addresses"
and data plane names/addresses="GMPLS control plane names/addresses of
the data plane". Not using proper GMPLS terms is resulting in a repeat
of last year's email discussion, and many other lengthy discussions e.g.
ASON, all resulting from confusing (GMPLS TE) ERO routing and
(signaling) control channel routing. And this draft's "mandate"
precludes separation of the address space of a GMPLS routing plane and
control channel routing plane which is the basis for GMPLS.

I don't think it is ready to be used as a basis for a ccamp draft as it
is not clear to me if this draft is based on OIF's signaling
implementation or if it needs to be first updated to be aligned with
GMPLS signaling terminology for readability. I'd prefer another re-spin
before deciding.

Deborah


-----Original Message-----
From: Igor Bryskin [mailto:ibryskin@movaz.com] 
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]