Re: [mpls-tp] draft-bao-mpls-tp-path-transfer-reqs

Hi,

Note that RFC 3813 has objects such as mplsInSegmentOwner of type MplsOwner 
(see RFC 3811).

The "small amounts of signaling" would appear to be present in 
draft-ietf-ccamp-pc-spc-rsvpte-ext

I think that it is valuable to look at the applicability of these mechanisms 
to MPLS-TP, and it would be useful if you could try to identify specific 
features that cannot be provided by the existing mechanisms. Fundamentally, 
I don't see why this operation in MPLS-TP would be any different from any 
other transport network.

Cheers,
Adrian
----- Original Message ----- 
From: "Curtis Villamizar" <curtis@occnc.com>
To: "Zhi-Wei Lin" <zhiwlin@gmail.com>
Cc: <yang.faming@zte.com.cn>; <bao.yuanlin@zte.com.cn>; <mpls-tp@ietf.org>
Sent: Wednesday, April 14, 2010 6:52 AM
Subject: Re: [mpls-tp] draft-bao-mpls-tp-path-transfer-reqs

>
> In message 
> <l2s67ec4be61004110734pd9bfd1a8k4974c2e0e32482e6@mail.gmail.com>
> Zhi-Wei Lin writes:
>>
>>
>> Hi,
>>
>> In RFC 5654, section 2.4, req. #55 states:
>>
>>    55  An MPLS-TP control plane MUST provide a mechanism for dynamic
>>        ownership transfer of the control of MPLS-TP transport paths from
>>        the management plane to the control plane and vice versa.  The
>>        number of reconfigurations required in the data plane MUST be
>>        minimized (preferably no data-plane reconfiguration will be
>>        required).
>>
>> This seems to cover the general requirement of this draft. Can RFC 5654 
>> be
>> updated to include this, or does it need to be a separate document?
>>
>> Thanks
>> Zhi
>
>
> Zhi,
>
> Thanks.  That completely recovers the requirement.  Its there, now
> just a matter of meeting it.
>
> At the IETF77 mic I suggested that to do this (well) an implementation
> would need state that indicates whether LSR MIB objects (insegment,
> cross connect, outsegment) were allocated by CP or MP or in
> transition.  If allocated by CP or in transition, MP can't touch.
>
> If allocated by CP, it is easy enough through MP to indicate that an
> LSP should undergo transition.  When the CP state is taken down, these
> objects instead of being taken down would be moved from "transition"
> to MP control.
>
> The issue is going from MP to CP.  The MP can put objects into
> "transition" state.  The LSP signaling would need to specify the
> existing labels and then take them from transition to CP control.
> That is where standards work would be needed to define a small amount
> of signaling, unless we can find an existing mechanism to reuse/abuse.
>
> Curtis
>
>
>> On Sun, Apr 11, 2010 at 2:41 AM, Curtis Villamizar <curtis@occnc.com> 
>> wrote:
>>
>> >
>> > In message 
>> > <77ead0ec1003282150g33c96946mbfbd443481885609@mail.gmail.com>
>> > Vishwas Manral writes:
>> > >
>> > > Hi,
>> > >
>> > > I am very happy to see new inputs from different people and vendors.
>> > >
>> > > I looked at the draft and was wondering what is not covered in RFC
>> > > 5493 which is for GMPLS control plane/ MP which is probably the
>> > > control plane for MPLS-TP. Is there any MPLS-TP specific requirement?
>> > >
>> > > Thanks,
>> > > Vishwas
>> >
>> >
>> > Vishwas,
>> >
>> > Good point.  I've read this and forgot all about it.  It doesn't seem
>> > that a new requirements draft is needed at all.
>> >
>> > BTW- Your message may have been overlooked due to the 5 concurrent
>> > last calls related to MPLS-TP.
>> >
>> > Curtis
>
> _______________________________________________
> mpls-tp mailing list
> mpls-tp@ietf.org
> https://www.ietf.org/mailman/listinfo/mpls-tp
> 