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

["Adrian Farrel" <[e-mail]>]

The term that is crystallizing is "path segment tunnel" (PST)

Does that do the job?

Adrian

----- Original Message ----- 
From: "Drake, John E" <[e-mail]>
To: <[e-mail]>nl>; "Sprecher, Nurit (NSN - IL/Hod HaSharon)" 
<[e-mail]>
Cc: <[e-mail]>
Sent: Tuesday, December 02, 2008 3:13 PM
Subject: 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:[e-mail]]
>>Sent: Tuesday, December 02, 2008 1:16 AM
>>To: Sprecher, Nurit (NSN - IL/Hod HaSharon)
>>Cc: [e-mail]
>>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: [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
>>>
>>
>>--
>>================================================================
>>                   http://www.van-helvoort.eu/
>>================================================================
>>Always remember that you are unique...just like everyone else...
>>
>>_______________________________________________
>>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