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

RE: Addressing doc



Hi Deborah,

?? happy that you chose to keep a copy of the iw draft around,
given that it expired last fall :o)  However, your copy may
be different from mine, mine only has a reference to 3209 when
discussing the extended tunnel ID in the SESSION object, not the 
end point address.  Not sure what you see being paraphrased.

Also I suspect that RFC 3209 is referenced in the
addressing draft because it gives the format and rules for using 
the SESSION object, while RFC 3473 does not discuss the SESSION object.  
Maybe you're thinking of the RSVP_HOP object?

I did not think that "data plane" was used to reference anything
in the GMPLS control plane within the addressing draft, but
if you've found points where you think "control plane" and "data
plane" are being used incorrectly, please point them out to the
authors so that these can be clarified in the next version.  It
can get very confusing in GMPLS.

Cheers,

Lyndon 



-----Original Message-----
From: Brungard, Deborah A, ALABS [mailto:dbrungard@att.com]
Sent: Friday, April 22, 2005 11:55 AM
To: Ong, Lyndon; Igor Bryskin; Diego Caviglia; Igor Bryskin <i_bryskin
Cc: ccamp
Subject: RE: Addressing doc


Hi Lyndon,

Glad to hear it is not on G7713.1 INNI. As I noted the terminology is
confusing on it's references to control plane (when referencing the
control channel) and data plane (when referencing the GMPLS control
plane) e.g. as the following in 4.2.1 on the Session Object:
"It is recommended that the ..end point address in the Session Object
[RFC3209] be set to the TE Router ID of the egress...alternatively, the
tunnel end point address MAY also be set to the destination data plane
address if the ingress knows that address or the TE Router ID."

Which is a paraphrase of the recommendation in
draft-ong-ccamp-3473-3474-iw-01. Including the reference to [RFC3209]
instead of RFC3473 (which recommends the use of the destination data
plane address in the Session). Hopefully this text will be aligned with
3473 in it's respin.

Thanks,
Deborah



-----Original Message-----
From: Ong, Lyndon [mailto:Lyong@Ciena.com] 
Sent: Thursday, April 21, 2005 12:56 AM
To: Brungard, Deborah A, ALABS; Igor Bryskin; Diego Caviglia; Igor
Bryskin <i_bryskin
Cc: ccamp
Subject: RE: Addressing doc

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]