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

["Sprecher, Nurit (NSN - IL/Hod HaSharon)" <[e-mail]>]

And then will we have 'path segment PW (psp)?
We need a general term that identifies a segment of a path (either of
LSP or of a MS-PW)..........
BR,
Nurit

-----Original Message-----
From: ext Drake, John E [mailto:[e-mail]] 
Sent: Tuesday, December 02, 2008 17:41
To: Adrian Farrel; [e-mail]; Sprecher, Nurit (NSN - IL/Hod
HaSharon)
Cc: [e-mail]
Subject: RE: [Mpls-interop] Who will be in Geneva?

Adrian,

Upon reflection, do we really need either the term 'tandem connection'
or the term 'path segment tunnel'?  We have the terms 'hierarchical
LSP', 'containing LSP', and 'contained LSP'.  All we are talking about
is adding an OAM channel to an LSP.

That said, how about 'path segment LSP (PSL)' which is defined to be a
containing hierarchical LSP with an associated inband OAM channel?

Thanks,

John

>-----Original Message-----
>From: Adrian Farrel [mailto:[e-mail]] 
>Sent: Tuesday, December 02, 2008 7:22 AM
>To: Drake, John E; [e-mail]; Sprecher, Nurit (NSN - 
>IL/Hod HaSharon)
>Cc: [e-mail]
>Subject: Re: [Mpls-interop] Who will be in Geneva?
>
>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