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

RE: Addressing doc




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:        owner-ccamp@ops.ietf.org

To:        "'ccamp'" <ccamp@ops.ietf.org>
cc:        "'Kohei Shiomoto'" <shiomoto.kohei@lab.ntt.co.jp>, "'Richard Rabbat'" <richard.rabbat@us.fujitsu.com>, "'Rajiv Papneja'" <rpapneja@isocore.com>

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.