Subject: RE: Addressing doc

From: "Diego Caviglia" <[email-masked]>
Date: Wed, 27 Apr 2005 17:42:14 +0200

Richiard,
                     IMHO also a section (or sub-section) dedicated to LMP 
usage could be very useful in order to clarify how LMP can help in 
addressing resolution.

BR

D

Sent by:        [email-masked]
To:     "'ccamp'" <[email-masked]>
cc:     "'Kohei Shiomoto'" <[email-masked]>, "'Richard Rabbat'" 
<[email-masked]>, "'Rajiv Papneja'" <[email-masked]> 

Subject:        RE: Addressing doc

Hi all,
 
The editors have been having various discussions  with people about some 
oftheir issues  with this draft. In order to clarify a some  points here 
are some of thechanges that  we plan tomake to the next version  of the 
draft. We hope thiswill 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 
thedestination 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 thesender 
data plane address or the TE Router ID.
New  text:
   Alternatively, the tunnel sender address MAY also  be set to thesender 
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 
ininteroperability testing or in deployment have  applied this 
relationship. Whennew  implementations that include any other relationship 
between controlplane and data plane entities are encountered,  this 
document would beenhanced as  necessary.

---

From: "Rajiv Papneja" <[email-masked]>
Date: Wed, 27 Apr 2005 13:52:05 -0400

Hi Diego,

 We will certainly add text for LMP  as mentioned in earlier email
exchanges. 

 /R

  _____  

From: Diego Caviglia [mailto:[email-masked]] 
Sent: Wednesday, April 27, 2005 11:42 AM
To: [email-masked]
Cc: ""'ccamp'" <ccamp"; ""'Kohei Shiomoto'" <shiomoto.kohei"; ""'Rajiv
Papneja'" <rpapneja"
Subject: RE: Addressing doc

Richiard, 

BR 

D 

To:        "'ccamp'" <[email-masked]> 
cc:        "'Kohei Shiomoto'" <[email-masked]>, "'Richard
Rabbat'" <[email-masked]>, "'Rajiv Papneja'"
<[email-masked]> 

Hi all, 
  
The editors have been having various discussions  with people about some
oftheir issues  with this draft. In order to clarify a some  points here are
some of thechanges that  we plan tomake to the next version  of the draft.
We hope thiswill 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
thedestination data plane  address if the ingress knows that 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
ininteroperability testing or in deployment have  applied this relationship.
Whennew  implementations that include any other relationship between
controlplane and data plane entities are encountered,  this document would
beenhanced as  necessary.

---

From: "Adrian Farrel" <[email-masked]>
Date: Fri, 29 Apr 2005 13:07:59 +0100

All,

The opinion seems to be in favor.

There were some doubts raised, but these do appear to have been resolved
by agreements to modify the wording in a future revision.

Therefore, editors, please...
- Submit draft-ietf-ccamp-gmpls-addressing-00.txt
   Please do not make any changes to this version except
   - name and date
   - boilerplate to conform to idnits
- Please prepare a new revision of the draft *soon* that
   handles the textual changes recently discussed and agreed
- Continue to drive discussion and debate on the list about
   individual subsections.

Thanks,
Adrian