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

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

Hi,
We are talking about TC and not TCM :-)
TC (until we have a better name) is used for OAM as well as for protection. 
Best regards,
Nurit

-----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