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

["BOCCI Matthew" <[e-mail]>]

Now I find myself going in a circle! :)

I can accept that TCM is monitoring of a tandem connection, which has been defined to protect part of a path. But what if I want to monitor some part of a path of an LSP or MS-PW independently of end-to-end OAM, but not provision an explicit tandem connection to provide protection.

Is that still TCM, or is it something else?

Thanks

Matthew

> -----Original Message-----
> From: [e-mail] 
> [mailto:[e-mail]] On Behalf Of Sprecher, 
> Nurit (NSN - IL/Hod HaSharon)
> Sent: 02 December 2008 10:39
> To: VIGOUREUX MARTIN
> Cc: [e-mail]
> Subject: Re: [Mpls-interop] Who will be in Geneva?
> 
> 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
> 
_______________________________________________
Mpls-interop mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/mpls-interop