RE: Moving LSP ownership between control plane and management plane

["Stephen Shew" <sdshew@nortel.com>]

See below.

> -----Original Message-----
> From: Diego Caviglia [mailto:Diego.Caviglia@marconi.com] 
> Sent: Wednesday, July 20, 2005 07:33
> To: Shew, Stephen [CAR:QT30:EXCH]
> Cc: ccamp@ops.ietf.org
> Subject: Re:
> 
> 
> 
> Hi Stephen,
>             my answers in line.
> 
> Regards
> 
> Diego
> 
> 
> 
> "Stephen Shew" <sdshew@nortel.com>@ops.ietf.org on 20/07/2005 12.22.49
> 
> Sent by:    owner-ccamp@ops.ietf.org
> 
> 
> To:    "\"ccamp\" <ccamp"
> cc:
> 
> Subject:
> 
> 
> Diego, my suggestion for this draft is that it separate the 
> mechanism (not setting the cross connects specified in an 
> ERO), from the reason for doing so.  This is because the 
> mechanism could be used for more than just CP<->MP handoff. 
> [dc] Hmmm I've defined that application mainly for two reason:
> 1     up to my knowledge that is the 'killer application' for 
> this kind of
> protocol modification
> 2     my understanding of CCAMP is that a good motivation needs to be
> provided to modify GRSVP-TE and this leads to point 1

I have no issue with the motivation.  I just think there are more
scenarios for creating control plane state for an existing cross
connection.

> If you do this then the bit should be renamed something like 
> "cross-connection exists" and if set, then the signaling 
> protocol does not tell the cross connection to set/release 
> it. [dc] That is how it works apart for the name of the flag.

I realize that. What I'm suggesting is that the name reflect an action
rather than one of several possible purposes.

> Did you consider a generalization of this where in the ERO, 
> each element has this type of flag?  If so, you could use the 
> mechanism to say replace two LSPs where the tail of one is 
> next to the head of the other, with a single LSP.  The action 
> would be to signal an ERO containing connection details of 
> each LSP that have the flag on, and where they join, have the 
> flag off. [dc] If I've understood corretly your point, what 
> you are saying is a little bir different from what the ID 
> proposes.  I mean in your exaple you have two different LSPs 
> that already have some control plane information associated 
> with them and you want to splice them together.  In this case 
> you have to replace the CP information while the ID proposes 
> to add CP information to a XC that don't have it.  Do you 
> agree with that?

The suggestion was that there are other scenarios in which establishment
of new LSP state for an existing cross connection is useful.  In the
MP->CP case, the MP initially holds state for the connection and before
the action is completed, both MP and CP hold state.  In the two LSP
example above, two entities in the CP hold state about the same
connection.  I see these two cases as similar in that the general case
is about multiple entities holding state for the same resource.


> 
> Stephen
> 
> 
> > -----Original Message-----
> > From: owner-ccamp@ops.ietf.org [mailto:owner-ccamp@ops.ietf.org] On 
> > Behalf Of Diego Caviglia
> > Sent: Wednesday, July 20, 2005 05:44
> > To: Diego.Caviglia@marconi.com
> > Cc: ""Dimitri.Papadimitriou" <Dimitri.Papadimitriou"; 
> "ccamp" <ccamp; 
> > "gnewsome" <gnewsome; "adrian" <adrian
> > Subject: RE: Moving LSP ownership between control plane and 
> management 
> > plane
> >
> >
> >
> > Sorry for this but may be not all have read the ID, I hope 
> that having 
> > the text help the discussion.
> >
> > Regards
> >
> > Diego
> >
> >
> >
> >
> >    Network Working Group
> >    Internet Draft
> > Diego Caviglia
> >    Document: draft-caviglia-mp2cpcp2mp-02.txt             Marconi
> >    Proposed Status: Updates RFC 3473
> > Dino Bramanti
> >
> >   Marconi
> >    Expires: December 2005
> > Nicola Ciulli
> 
> <snip>
> 
> 
> 
> 
> 
> 
> 
>