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

RE: Addressing doc



Thanks, 
Richard.

> -----Original Message-----
> From: Adrian Farrel [mailto:adrian@olddog.co.uk] 
> Sent: Wednesday, June 01, 2005 8:47 AM
> To: Diego Caviglia; Dimitri.Papadimitriou@alcatel.be
> Cc: richard.rabbat@us.fujitsu.com; ccamp@ops.ietf.org; 
> shiomoto.kohei@lab.ntt.co.jp; rpapneja@isocore.com
> 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.
> >
> >
> >
> >
> >
> >
> >
> >
> >
> 
>