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

If we say that the OAM channel is associated with the containing LSP,
then we could have a tandem connection as currently defined (1:1 with an
LSP) while having the benefits of 1 OAM channel for N contained LSPs.  

>-----Original Message-----
>From: Huub van Helvoort [mailto:hhelvoort@chello.nl] 
>Sent: Tuesday, December 02, 2008 1:16 AM
>To: Sprecher, Nurit (NSN - IL/Hod HaSharon)
>Cc: 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
>
_______________________________________________
Mpls-interop mailing list
Mpls-interop@ietf.org
https://www.ietf.org/mailman/listinfo/mpls-interop