Subject: Re: Addressing doc

From: Igor Bryskin <[email-masked]>
Date: Sat, 16 Apr 2005 14:31:26 -0700 (PDT)

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? You are saying that it should a stable
IP address of the controller managing the next hop.
Where the processing controller is supposed to get
this stable IP address from? All that it has is a
numbered or unnumbered next hop TE link ID. It is not
guaranteed that numbered TE link ID is a routable
address, however, it could be easily resolved to TE
Router ID. In case of unnumbered TE link the TE Router
ID is a part of the link ID. It is also guaranteed
that TE Router ID is a stable routable IP address of
the controller advertising the TE link. Hence, the
recommendation makes a lot of sense to me – extract TE
Router ID from unnumbered link ID ERO subobject or
resolve numbered TE link ID into TE Router ID, set it
as destination in IP header of the RSVP Path message
and forward the packet –the message will arrive at the
controller managing next hop no matter how many actual
IP hops the packet will make. In fact, that’s how the
control plane and data plane separation needs to be
supported.

Cheers,
Igor

--- [email-masked] wrote:
> 
> this document is not ready as it prevents usage of
> the control channel
> separation as defined in Section 8 of RFC 3473 (but
> also representation of
> complex nodes)
> 
> i point out here the sentences from where this can
> be deduced:
> 
> "  A Path message is sent to the next hop node.  It
> is RECOMMENDED that
>    the TE router ID of the next hop node be used as
> an IP destination
>    address in the packet that carries the RSVP-TE
> message. "
> 
> combined with the following statements
> 
> "  ... an unnumbered link is identified by the
>    combination of TE Router ID and a node-unique
> Interface ID."
> 
> "  It is RECOMMENDED that the IP tunnel endpoint
> address in the Session
>    Object [RFC3209] be set to the TE Router ID of
> the egress since the
>    TE Router ID is a unique routable ID per node."
> 
> [...]
> 
> "  It is RECOMMENDED that the IP tunnel sender
> address in the Sender
>    Template Object [RFC3209] specifies the TE Router
> ID of the ingress
>    since the TE Router ID is a unique routable ID
> per node."
> 
> therefore, usage of the TE Router ID should be
> reviewed, such that it does
> not recommends the source and destination of IP
> packets to be the TE Router
> ID but simply a stable reachable control plane IP
> address of the
> next/previous hop
> 
> also, there is a sentence in this document
> 
> "  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. "
> 
> my response to this is of course if you use it like
> proposed in this
> document this problem occurs
> 
> ps:
> 
> section 5.1.2 of this document is unclear wrt
> section 1.1 of
>
<http://www.ietf.org/internet-drafts/draft-ietf-isis-gmpls-extensions-19.txt>

__________________________________ 
Do you Yahoo!? 
Plan great trips with Yahoo! Travel: Now over 17,000 guides!
http://travel.yahoo.com/p-travelguide

---

From: "Ong, Lyndon" <[email-masked]>
Date: Tue, 19 Apr 2005 19:23:55 -0400

Hi Dimitri, et al,
 
This is exactly the kind of issue that the addressing draft can bring out - the addressing draft
is the compilation of interpretations that a number of implementations have made when testing together
at Isocore - if these interpretations are not fully correct ones, the draft should be modified to
document this, for the benefit of  future implementation and testing.
 
I agree with you on the text that should be removed from the document.  After the text is removed,
(and perhaps some explanatory text added)
it then seems to me to be a good idea to make this into a WG draft.
 
Cheers,
 
Lyndon

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]On Behalf Of [email-masked]
Sent: Sunday, April 17, 2005 7:11 AM
To: Igor Bryskin
Cc: [email-masked]; Kireeti Kompella; [email-masked]
Subject: Re: Addressing doc

igor, i mentioned this because when some implement - for whatever purpose - a subset of capabilities and draw recommendations from this partial set, these should not by any means retrofit to the complete set of capabilities this protocol suite delivers or imply recommendations that would prevent from using its full set

coming to the below you have been mentioned on what this so-called separation does imply is that for constructing - and LMP can be used in helping this construction but this is also not mandatory - the TE topology make use of the TE router ID for the identification unnumbered interfaces and (abstract) nodes, (numbered interfaces are also part of this class of information - but obviously does not require the use of the TE Router ID) afterwards any control plane message exchange can make use of the IP control plane topology as long as these messages are exchanged between control plane entities that have initially advertized (i.e. as owner of) this information

hope this clarifies,

- dimitri.

Igor Bryskin <[email-masked]>
Sent by: [email-masked]
04/17/2005 05:50 MST

To: Dimitri PAPADIMITRIOU/BE/ALCATEL@ALCATEL
cc: Dimitri PAPADIMITRIOU/BE/ALCATEL@ALCATEL, Kireeti Kompella <[email-masked]>, [email-masked]
bcc: 
Subject: Re: Addressing doc

Dimitri,

I think we are in agreement here. The only thing I
disagree with is your statement that the document is
not ready to be WG document for the reasons you have
provided. I am not the author of this document and I
let the authors tell what they think. However, the
whole point of the document, as far as I understand
it, is not to mandate something, rather, to provide a
set of recommendations based on the interop tests
experience, so that interoperability between different
vendors would be easier to achieve. Hence, they do not
need to spell out word RECOMMEND in every clause.

WRT TE Router ID. Of course, IFF there is some
knowledge or mechanism to translate TE addresses into
control plane IP addresses, any of next hop IP
addresses could be used as destination in RSVP Path
message IP packet. In this case IHMO  Te Router ID
does not even have to be routable, and full separation
between TE and control plane name spaces could be
achieved. I think LMP could help to do this. However,
one cannot mandate using LMP for every link in every
layer, especially, for IP/MPLS layer(s).

Igor

--- [email-masked] wrote:

>
> igor, my point is that if you recommend
>
> and
> combination of TE Router
>   ID and a node-unique Interface ID."
>
> then it is clear that the following occurs
>
>   because in GMPLS, control and data plane
> names/addresses are not
>   completely separated. "
>
> and the only change that needs to be done in this
> document in section 4.3
>
> "It is RECOMMENDED that a stable
>    control plane IP address of the next/previous hop
> node be used as an
>    IP destination address in RSVP-TE message.
>
>    A Path message is sent to the next hop node. It
> is RECOMMENDED that
> message."
> is to remove the second paragraph, as there is
> nothing that mandates that
> communication between adjacent controllers should
> achieved through TE
> router ID (note: reading the document you will see
> that the section 5.2.1
> is indeed
> not completed just for this reason)
>
> in fact, this boils down to say that the TE router
> ID is not mandatorily
> used for hop-by-hop exchange of control messages as
> i can build adjacencies
> between neighboring nodes using the base IP routing
> topology, (by the way
> from where all restrictions that are pointed here
> below come from ?)
>
> thanks,
> - dimitri.
> ---
>
> Dimitri,
>
> recommendation makes a lot of sense to me ? extract
> TE
> and forward the packet ?the message will arrive at
> the
> IP hops the packet will make. In fact, that's how
> the
< http://www.ietf.org/internet-drafts/draft-ietf-isis-gmpls-extensions-19.txt>

__________________________________________________
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around
http://mail.yahoo.com

---

From: "Diego Caviglia" <[email-masked]>
Date: Wed, 20 Apr 2005 10:49:20 +0200

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

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

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 07:35:31 -0700 (PDT)

Hi, Diego,

See my comment in-line.

Igor

Diego Caviglia <[email-masked]> wrote: 

Igor, 

In line. 

Regards 

Diego 

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

Dimitri,

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

IB>> You are absolutely right. However, as I said in one of previous emails, one cannot mandate using LMP for every link in every layer (especially, in PSC layer). Hence, taking advantage of the fact that TE Rtr ID is guaranteed to be routable IP address and the fact that any link ID (numbered or unnumbered) could be always resolved into the advertising TE Rtr ID, the recommendation to set the TE Rtr ID as the destination of the IP packet with the RSVP Path message is IHMO a good one. Having said that nothing prevents, of course, from using any IP address of the controller managing the next hop (which could be known via LMP, configuration, etc.)

Igor

---

From: "Brungard, Deborah A, ALABS" <[email-masked]>
Date: Wed, 20 Apr 2005 16:17:23 -0500

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

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,

In line.

Regards

Diego

Dimitri,

[dc] What about usage of the control channel addresses?  I mean having
LMP

---

From: "Sadler, Jonathan B." <[email-masked]>
Date: Wed, 20 Apr 2005 16:43:37 -0500

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

Deborah

-----Original Message-----
From: Igor Bryskin [mailto:[email-masked]] 
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,

Igor

----- Original Message ----- 
From: "Brungard, Deborah A, ALABS" <[email-masked]>
To: "Diego Caviglia" <[email-masked]>; "Igor Bryskin
<i_bryskin"
<[email-masked]>

Deborah

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

Igor,

In line.

Regards

Diego

Dimitri,

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

---

From: "Brungard, Deborah A, ALABS" <[email-masked]>
Date: Wed, 20 Apr 2005 17:01:31 -0500

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:[email-masked]] 
Sent: Wednesday, April 20, 2005 5:44 PM
To: Brungard, Deborah A, ALABS; Igor Bryskin; Diego Caviglia; Igor
Bryskin
Cc: ccamp

Hi Deborah,

Hope this helps,

Jonathan Sadler

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

Deborah

-----Original Message-----
From: Igor Bryskin [mailto:[email-masked]] 
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,

Igor

----- Original Message ----- 
From: "Brungard, Deborah A, ALABS" <[email-masked]>
To: "Diego Caviglia" <[email-masked]>; "Igor Bryskin
<i_bryskin"
<[email-masked]>

Deborah

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

Igor,

In line.

Regards

Diego

Dimitri,

---

From: "Sadler, Jonathan B." <[email-masked]>
Date: Thu, 21 Apr 2005 09:59:11 -0500

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

Deborah

-----Original Message-----
From: Sadler, Jonathan B. [mailto:[email-masked]] 
Sent: Wednesday, April 20, 2005 5:44 PM
To: Brungard, Deborah A, ALABS; Igor Bryskin; Diego Caviglia; Igor
Bryskin
Cc: ccamp

Hi Deborah,

Hope this helps,

Jonathan Sadler

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

Deborah

-----Original Message-----
From: Igor Bryskin [mailto:[email-masked]] 
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,

Igor

----- Original Message ----- 
From: "Brungard, Deborah A, ALABS" <[email-masked]>
To: "Diego Caviglia" <[email-masked]>; "Igor Bryskin
<i_bryskin"
<[email-masked]>

Deborah

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

Igor,

In line.

Regards

Diego

Dimitri,

---

From: Eiji Oki <[email-masked]>
Date: Sat, 23 Apr 2005 00:11:29 +0900

Yes.

Thank you.
Eiji

On Fri, 15 Apr 2005 15:22:04 -0700 (PDT)
Kireeti Kompella <[email-masked]> wrote:

> A new version of this draft has been posted as
> draft-shiomoto-ccamp-gmpls-addressing-01.txt .
> 
> Please reply to this email on whether or not you think this should be
> a CCAMP WG doc.  Adrian and I will gauge consensus based on the mail
> received until Fri April 22, 23:59 UTC.
> 
> Thanks,
> Kireeti.
> -------
>

---

From: "LE ROUX Jean-Louis RD-CORE-LAN" <[email-masked]>
Date: Fri, 22 Apr 2005 17:43:21 +0200

Hi,

This should be a WG doc.

Regards,

JL

>-----Message d'origine-----
>De : [email-masked] 
>[mailto:[email-masked]] De la part de Kireeti Kompella
>Envoyé : samedi 16 avril 2005 00:22
>À : [email-masked]
>Objet : Addressing doc
>
>
>Please reply to this email on whether or not you think this 
>should be a CCAMP WG doc.  Adrian and I will gauge consensus 
>based on the mail received until Fri April 22, 23:59 UTC.
>
>Thanks,
>Kireeti.
>-------
>
>

---

From: "Brungard, Deborah A, ALABS" <[email-masked]>
Date: Fri, 22 Apr 2005 13:54:57 -0500

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:[email-masked]] 
Sent: Thursday, April 21, 2005 12:56 AM
To: Brungard, Deborah A, ALABS; Igor Bryskin; Diego Caviglia; Igor
Bryskin <i_bryskin
Cc: ccamp

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

Deborah

-----Original Message-----
From: Igor Bryskin [mailto:[email-masked]] 
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,

Igor

----- Original Message ----- 
From: "Brungard, Deborah A, ALABS" <[email-masked]>
To: "Diego Caviglia" <[email-masked]>; "Igor Bryskin
<i_bryskin"
<[email-masked]>

Deborah

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

Igor,

In line.

Regards

Diego

Dimitri,

---

From: "Ong, Lyndon" <[email-masked]>
Date: Fri, 22 Apr 2005 15:49:53 -0400

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

Thanks,
Deborah

-----Original Message-----
From: Ong, Lyndon [mailto:[email-masked]] 
Sent: Thursday, April 21, 2005 12:56 AM
To: Brungard, Deborah A, ALABS; Igor Bryskin; Diego Caviglia; Igor
Bryskin <i_bryskin
Cc: ccamp

Hi Deborah,

Cheers,

Lyndon

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

Deborah

-----Original Message-----
From: Igor Bryskin [mailto:[email-masked]] 
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,

Igor

----- Original Message ----- 
From: "Brungard, Deborah A, ALABS" <[email-masked]>
To: "Diego Caviglia" <[email-masked]>; "Igor Bryskin
<i_bryskin"
<[email-masked]>

Deborah

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

Igor,

In line.

Regards

Diego

Dimitri,

---

From: Wataru Imajuku <[email-masked]>
Date: Sat, 23 Apr 2005 10:10:05 +0900

Hi, Kiretti

  Yes.

W. Imajuku

---------------------------------
Wataru Imajuku
@NTT Network Innovation Labs.
TEL +81-46-859-4315
FAX +81-46-859-5541

---

From: "Richard Rabbat" <[email-masked]>
Date: Tue, 26 Apr 2005 12:22:52 -0400

Hi all,
 
The editors have been having various discussions with people about some of
their issues with this draft. In order to clarify a some points here are
some of the changes that we plan to make to the next version of the draft.
We hope this will help to clarify the draft.
 
1. In section 4.2.1, previous text:
   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.
New text:
   Alternatively, the tunnel end point address MAY also be set to the
destination data plane address if the ingress knows that address.
 
2. In section 4.2.2 previous text:
   Alternatively, the tunnel sender address MAY also be set to the sender
data plane address or the TE Router ID.
New text:
   Alternatively, the tunnel sender address MAY also be set to the sender
data plane address.
 
3. at the end of the introduction, we will add wording to the last line to
that effect:
Various more complex deployment scenarios can be constructed but these are
currently out of scope as the only GMPLS implementations encountered in
interoperability testing or in deployment have applied this relationship.
When new implementations that include any other relationship between control
plane and data plane entities are encountered, this document would be
enhanced as necessary.