RE: Addressing doc

["Richard Rabbat" <richard.rabbat@us.fujitsu.com>]

Igor,

That's what the draft wanted to say. Thanks for putting it so well. 

We didn't mention LMP because we wanted the draft not to be specific only to
transport. We'll update the wording as I said in a next revision to reflect
the 2 modes of operation. 

Best,
Richard.


> -----Original Message-----
> From: owner-ccamp@ops.ietf.org 
> [mailto:owner-ccamp@ops.ietf.org] On Behalf Of Igor Bryskin
> 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" <dbrungard@att.com>
> To: "Diego Caviglia" <Diego.Caviglia@marconi.com>; "Igor 
> Bryskin <i_bryskin"
> <i_bryskin@yahoo.com>
> Cc: "ccamp" <ccamp@ops.ietf.org>
> 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: owner-ccamp@ops.ietf.org [mailto:owner-ccamp@ops.ietf.org] 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,
>           my two cents to the discussion.
> 
> In line.
> 
> Regards
> 
> Diego
> 
> 
> 
> Igor Bryskin <i_bryskin@yahoo.com>@ops.ietf.org on 16/04/2005 23.31.26
> 
> Sent by:    owner-ccamp@ops.ietf.org
> 
> 
> To:    Dimitri.Papadimitriou@alcatel.be, Kireeti Kompella
>        <kireeti@juniper.net>
> cc:    ccamp@ops.ietf.org
> 
> Subject:    Re: Addressing doc
> 
> 
> 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]
> 
> 
> 
> 
> 
> 
> 
> 
>