Re: [Mpls-interop] Who will be in Geneva?

["Sprecher, Nurit (NSN - IL/Hod HaSharon)" <[e-mail]>]

First, protection switching in MPLS-TP is independent of the control plane...we can have protection switching even in the absence of a CP. 
Second, GMPLS segment protection really uses LSP hierarchy for protecting a segment......
TC (or what ever name you select) provides you a clean architectural way to initiate and terminate messages for a part of a path (segment). This can be used for OAM, protection and maybe other purposes in the future as well.
Nurit

-----Original Message-----
From: ext Martin Vigoureux [mailto:[e-mail]] 
Sent: Tuesday, December 02, 2008 12:51
To: Sprecher, Nurit (NSN - IL/Hod HaSharon)
Cc: ext Ben Niven-Jenkins; Adrian Farrel; [e-mail]
Subject: Re: [Mpls-interop] Who will be in Geneva?

Well, that is exactly what I am saying ...
the TCs you mention are for doing OAM
In GMPLS one does not need any TC to do segment recovery.

-m

Sprecher, Nurit (NSN - IL/Hod HaSharon) a écrit :
> Somehow I find my self in a circle (I need ring protection :-))
> We have been in this discussion many times...........
> To protect a part of a path we need to define a TC for the working and the protection part (two TCs . If we want we can run OAM over the TC and use it as a trigger for a protection switching. OAM will need to run over each of the TC (TCM :-)). These TCs will be used also for sending the PSC (APS) messages....
> 
> -----Original Message-----
> From: ext Martin Vigoureux [mailto:[e-mail]] 
> Sent: Tuesday, December 02, 2008 12:34
> To: Sprecher, Nurit (NSN - IL/Hod HaSharon)
> Cc: ext Ben Niven-Jenkins; Adrian Farrel; [e-mail]
> Subject: Re: [Mpls-interop] Who will be in Geneva?
> 
> Nurit, all
> 
> as stated in Minneapolis, I believe, at least for clarity, that we
> should not directly link TC to P&R.
> TCM is an OAM related concept not a resiliency one.
> 
> -m
> 
> Sprecher, Nurit (NSN - IL/Hod HaSharon) a écrit :
>> BTW, isn't it (TC/lsp-hierarchy) the same principle as we have in GMPLS
>> segment protection?
>>
>> -----Original Message-----
>> From: Sprecher, Nurit (NSN - IL/Hod HaSharon) 
>> Sent: Tuesday, December 02, 2008 01:46
>> To: ext Ben Niven-Jenkins; Adrian Farrel; [e-mail]
>> Cc: Sprecher, Nurit (NSN - IL/Hod HaSharon)
>> Subject: RE: [Mpls-interop] Who will be in Geneva?
>>
>> Hi Ben
>> Scalability of TC (or whatever we call it) is basically if you have 1:1
>> mapping between TC and LSP. But if you have 1:n mapping TC and many LSPs
>> the main concern can be solved. 
>> If you define TC in reasonable areas (e.g. across a domain in a
>> multi-domain network) and the TC aggregate multiple LSPs then IMO the
>> construction of TC is the cleanest one and works well with OAM and with
>> protection.
>> Best regards,
>> Nurit
>>
>> -----Original Message-----
>> From: [e-mail]
>> [mailto:[e-mail]] On Behalf Of ext Ben
>> Niven-Jenkins
>> Sent: Tuesday, December 02, 2008 00:17
>> To: Adrian Farrel; [e-mail]
>> Subject: Re: [Mpls-interop] Who will be in Geneva?
>>
>> Adrian,
>>
>> On 27/11/2008 22:27, "Adrian Farrel" <[e-mail]> wrote:
>>> I ended up with a modest list of MPLS-TP design team folk willing to
>>> squander their evenings in Geneva working on drafts. Must be that the
>> Swiss
>>> night life is too exciting!
>> Or that there is no Q.Whisky in SG15 ;-)
>>
>>> Lastly, I would like to see if I can understand the issues with the
>> OAM
>>> techniques proposed. Can we continue to use TTL? Does the idea of
>> using
>>> nesting for all OAM segments really hold up? Is the OAM cart in danger
>> of
>>> driving the protection hobbyhorse (pardon my mixed metaphore).
>> I'm no OAM expert (I leave that to Tom :-) ) but I am yet to be
>> convinced by
>> nesting all OAM segments for the reason that it sounds complicated and
>> that
>> means to me that it will be expensive to run and to scale.  It also
>> sounds
>> like I'd have to have my network constructed in a particular way to be
>> able
>> to use OAM which means even in the best run network I will at some point
>> not
>> be able to run OAM when I need it (and the customer is screaming at me)
>> because the network wasn't constructed correctly (either by design or
>> actual
>> configuration != design).
>>
>> Ben
>>
>> _______________________________________________
>> Mpls-interop mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/mpls-interop
>> _______________________________________________
>> Mpls-interop mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/mpls-interop
>>
> 
_______________________________________________
Mpls-interop mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/mpls-interop