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

Re: Addressing doc



adrian - ok - i think we are in sync.

"Adrian Farrel" <adrian@olddog.co.uk>
06/01/2005 16:46
Please respond to "Adrian Farrel"

To: "Diego Caviglia" <Diego.Caviglia@marconi.com>, Dimitri PAPADIMITRIOU/BE/ALCATEL@ALCATEL
cc: <richard.rabbat@us.fujitsu.com>, <ccamp@ops.ietf.org>, <shiomoto.kohei@lab.ntt.co.jp>, <rpapneja@isocore.com>
bcc:
Subject: Re: Addressing doc


Hi,

> would it be possible that you refine the notion of "address translation"
in the context of the
> present LMP discussion as i am not necessarily sure something specific
needs to considered
> beside what the LMP transport document already provides (Section 4.3 for
inst.)

If there is additional function required, it won't be in the addressing
draft.
If there is guidance to operators or implementors it can be in the
addressing draft (even if it is only a restatement of what is found in
another draft or RFC).

Cheers,
Adrian


>
> thanks,
>
> - dimitri.
>
>
>
> "Diego Caviglia" <Diego.Caviglia@marconi.com>
> Sent by: owner-ccamp@ops.ietf.org
> 06/01/2005 15:09 ZE2
>
> To: richard.rabbat@us.fujitsu.com
> cc: ccamp@ops.ietf.org, shiomoto.kohei@lab.ntt.co.jp,
rpapneja@isocore.com
> bcc:
> Subject: RE: Addressing doc
>
>
>
>
> Hi Richard,
> I think that some text that explain how LMP can be
> used to translate between TE links and control plane addresses should be
> very valuable.
>
> BTW if you think that the explanation is out of the scope of the ID may
be
> some text that highlights that  LMP is one of the protocols that could
be
> used to do address translation between  TE links and control plane
> addresses can be enough.
>
> Diego
>
>
>
>
>
> "Richard Rabbat" <richard.rabbat@us.fujitsu.com>@ops.ietf.org on
01/06/2005
> 02.38.08
>
> Sent by:    owner-ccamp@ops.ietf.org
>
>
> To:    "'Diego Caviglia'" <Diego.Caviglia@marconi.com>, "'\"\"'ccamp'\"
> <ccamp\"'"
> cc:    <richard.rabbat@us.fujitsu.com>, "'\"\"'Kohei Shiomoto'\"
> <shiomoto.kohei\"'", "'\"\"'Rajiv Papneja'\" <rpapneja\"'"
>
> Subject:    RE: Addressing doc
>
>
>
> Hi  Diego,
>
> We're  currently working on an update to
> draft-ietf-ccamp-gmpls-addressing-00.txt. I  was wondering if you have
any
> ideas w/r to your request below? Are you looking  for an explanation of
how
> LMP could be used or simple text that highlights that  LMP is one of the
> protocols that could be used to do address translation between  TE links
> and control plane addresses?
>
> Richard.
>
> -----Original Message-----
> From: Diego Caviglia  [mailto:Diego.Caviglia@marconi.com]
> Sent: Wednesday, April 27, 2005  8:42 AM
> To: richard.rabbat@us.fujitsu.com
> Cc: ""'ccamp'"  <ccamp" ""'Kohei Shiomoto'" <shiomoto.kohei" ""'Rajiv
> Papneja'"  <rpapneja"
> Subject: 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.
>
>
>
>
>
>
>
>
>