Hi Deborah,
The GMPLS Tunnel ID is not an SNPP Name or a PC SCN Address -- it's used
to identify a connection instance, so it just needs to be a unique value
within the signaling context.
Please also understand that my comments are not related to the
addressing draft which is the real subject of this thread, but rather to
clarify the OIF protocol architecture.
Jonathan Sadler
-----Original Message-----
From: Brungard, Deborah A, ALABS [mailto:dbrungard@att.com]
Sent: Wednesday, April 20, 2005 5:02 PM
To: Sadler, Jonathan B.; Igor Bryskin; Diego Caviglia; Igor Bryskin
Cc: ccamp
Subject: RE: Addressing doc
Thanks Jonathan -
And what is used for the GMPLS tunnel ids? Controller IDs?
My interpretation also, the Gen_UNI provides for separation of signaling
and network addresses. Whereas using the addressing draft
recommendations prevents use of the corresponding GMPLS procedures.
Deborah
-----Original Message-----
From: Sadler, Jonathan B. [mailto:Jonathan.Sadler@tellabs.com]
Sent: Wednesday, April 20, 2005 5:44 PM
To: Brungard, Deborah A, ALABS; Igor Bryskin; Diego Caviglia; Igor
Bryskin
Cc: ccamp
Subject: RE: Addressing doc
Hi Deborah,
Just a clarification on the OIF protocol architecture:
- the OIF does not assume a 1:1 association of Transport Names (called
SNPPs in ASON) and Control Addresses (called Protocol Controller SCN
Addresses in ASON). The OIF protocols use Unnumbered mode objects
containing SNPP identifiers when referencing transport resources. PC
SCN Addresses are only used to identify neighboring Protocol
Controllers, e.g. in IP headers.
- the TNAs in the Gen_UNI (called UNI Transport Resource Names in ASON)
separate the Transport Names used by Network Users to identify endpoints
from the Service Provider SNPPs. This allows for many operational
scenarios to be supported, including allowing the Service Provider to
rearrange their signaling or transport network addressing, without
customer impact.
Hope this helps,
Jonathan Sadler
-----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 4: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]
============================================================
The information contained in this message may be privileged
and confidential and protected from disclosure. If the reader
of this message is not the intended recipient, or an employee
or agent responsible for delivering this message to the
intended recipient, you are hereby notified that any reproduction,
dissemination or distribution of this communication is strictly
prohibited. If you have received this communication in error,
please notify us immediately by replying to the message and
deleting it from your computer. Thank you. Tellabs
============================================================
============================================================
The information contained in this message may be privileged
and confidential and protected from disclosure. If the reader
of this message is not the intended recipient, or an employee
or agent responsible for delivering this message to the
intended recipient, you are hereby notified that any reproduction,
dissemination or distribution of this communication is strictly
prohibited. If you have received this communication in error,
please notify us immediately by replying to the message and
deleting it from your computer. Thank you. Tellabs
============================================================