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

I agree with you that currently TC is 1:1, but I can see no reason why
we can not extend it to scale better and use it for multiple LSPs that
cross the same part of physical path (i.e. segment) and have the same
constraints........
I agree that we should think also about a better name......
F2F meeting can really help 

-----Original Message-----
From: ext Huub van Helvoort [mailto:hhelvoort@chello.nl] 
Sent: Tuesday, December 02, 2008 11:16
To: Sprecher, Nurit (NSN - IL/Hod HaSharon)
Cc: ext Ben Niven-Jenkins; Adrian Farrel; mpls-interop@ietf.org
Subject: Re: [Mpls-interop] Who will be in Geneva?

Hi Ben and Nurit,

We definitly have to have a f-2-f discussion about TC, I think
there is still some confusion.

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

TC is 1:1 related to a single LSP, this is how TC is defined
in the Transport environment. A TC can be created either by
stacking or by using the MEG level methodology (also used in
the transport ethernet)

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

The TC aggregate is not a TC anymore, it should IMHO be referred
to as a tunnel.

Cheers, Huub.

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

-- 
================================================================
                   http://www.van-helvoort.eu/
================================================================
Always remember that you are unique...just like everyone else...

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