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

OIF topic



Hi Deborah,
Thanks for reading our draft.

Kindly use this subject line to continue any discussion on the OIF topic.
Use the other subject line for a discussion of the addressing draft. 

The addressing draft is not a product of the OIF and does not talk about OIF
signaling.
I hope Lyndon's email clarified it.
Richard.

> -----Original Message-----
> From: owner-ccamp@ops.ietf.org 
> [mailto:owner-ccamp@ops.ietf.org] On Behalf Of Ong, Lyndon
> Sent: Thursday, April 21, 2005 12:56 AM
> To: Brungard, Deborah A, ALABS; Igor Bryskin; Diego Caviglia; 
> Igor Bryskin <i_bryskin
> Cc: ccamp
> Subject: RE: Addressing doc
> 
> 
> Hi Deborah,
> 
> Oh no! :-0  The discussion has been contaminated by OIF!
> 
> Seriously, the draft does not mention "OIF" anywhere - you're 
> welcome to
> search through it.   The terminology (and any confusion)is 
> all GMPLS, as
> is 99% of the testing at Isocore.  I would also note that the 
> authors of
> the draft talked to a number of people within CCAMP to try and pin
> down the usage of the TE Router ID and this appeared to be 
> the most common
> view at the time (however it was an incomplete sample, and importantly
> did not include Dimitri and Igor's input).
> 
> The issue has nothing to do with the Gen_UNI, as far as I 
> know, as this is
> for separation of user and network addressing spaces (as 
> Jonathan points
> out).
> 
> Cheers,
> 
> Lyndon
> 
>   
> 
> -----Original Message-----
> From: owner-ccamp@ops.ietf.org [mailto:owner-ccamp@ops.ietf.org]On
> Behalf Of Brungard, Deborah A, ALABS
> Sent: Wednesday, April 20, 2005 2:17 PM
> To: Igor Bryskin; Diego Caviglia; Igor Bryskin <i_bryskin
> Cc: ccamp
> Subject: RE: Addressing doc
> 
> 
> Hi Igor, (and Kireeti, Adrian)
> 
> A TE link with a routable control plane IP address? Routable within a
> GMPLS control plane context or within a control (channel) 
> plane context?
> It's difficult to discuss as everyone is mixing terminology. GMPLS
> carefully distinguishes a GMPLS LSR Router ID and TE link 
> addresses (and
> corresponding GMPLS routing) from control channel addressing (and
> corresponding routing). Adrian explained this in the email link below.
> Whereas OIF assumes a 1:1 association and flat routing of control
> channel and data topology, and resulting in an implementation of using
> the control channel addresses for their tunnel endpoints. Though then
> one would have the same issue as OIF identified, how to carry the
> "routable" network node address, resulting in Gen_UNI.
> 
> And the difficulty with the draft is that it cycles about then to say:
> "The reason why the TE Router ID must be a reachable IP address is
> because in GMPLS, control and data plane names /addresses are not
> completely separated."
> 
> When as Dimitri said, the draft choose this 1:1 limitation as it's
> implementation, it's not GMPLS.
> 
> My concern with the draft is that it has several of these statements,
> mixing the discussion of control plane and data plane names/addresses
> when it is referring to control plane="control channel 
> names/addresses"
> and data plane names/addresses="GMPLS control plane names/addresses of
> the data plane". Not using proper GMPLS terms is resulting in a repeat
> of last year's email discussion, and many other lengthy 
> discussions e.g.
> ASON, all resulting from confusing (GMPLS TE) ERO routing and
> (signaling) control channel routing. And this draft's "mandate"
> precludes separation of the address space of a GMPLS routing plane and
> control channel routing plane which is the basis for GMPLS.
> 
> I don't think it is ready to be used as a basis for a ccamp 
> draft as it
> is not clear to me if this draft is based on OIF's signaling
> implementation or if it needs to be first updated to be aligned with
> GMPLS signaling terminology for readability. I'd prefer 
> another re-spin
> before deciding.
> 
> Deborah
> 
> 
> -----Original Message-----
> From: Igor Bryskin [mailto:ibryskin@movaz.com] 
> 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]
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
>