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

As I may have said before, we must be very careful with the term "segment".
It has a completely different meaning almost.

RFC 4873 segment protection does not use hierarchy. This is for the 
"obvious" reason that you cannot do hierarchy in most/many switching 
technologies.

RFC 4090 protection does use hierarchy and protects what many might call a 
segment.

A
----- Original Message ----- 
From: "Sprecher, Nurit (NSN - IL/Hod HaSharon)" <nurit.sprecher@nsn.com>
To: "Sprecher, Nurit (NSN - IL/Hod HaSharon)" <nurit.sprecher@nsn.com>om>; "ext 
Ben Niven-Jenkins" <benjamin.niven-jenkins@bt.com>om>; "Adrian Farrel" 
<adrian@olddog.co.uk>uk>; <mpls-interop@ietf.org>
Sent: Monday, December 01, 2008 11:59 PM
Subject: RE: [Mpls-interop] Who will be in Geneva?

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; mpls-interop@ietf.org
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: mpls-interop-bounces@ietf.org
[mailto:mpls-interop-bounces@ietf.org] On Behalf Of ext Ben
Niven-Jenkins
Sent: Tuesday, December 02, 2008 00:17
To: Adrian Farrel; mpls-interop@ietf.org
Subject: Re: [Mpls-interop] Who will be in Geneva?

Adrian,

On 27/11/2008 22:27, "Adrian Farrel" <adrian@olddog.co.uk> 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
Mpls-interop@ietf.org
https://www.ietf.org/mailman/listinfo/mpls-interop

_______________________________________________
Mpls-interop mailing list
Mpls-interop@ietf.org
https://www.ietf.org/mailman/listinfo/mpls-interop