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

["Drake, John E" <[e-mail]>]

Okay, that's fine. 

>-----Original Message-----
>From: Adrian Farrel [mailto:[e-mail]] 
>Sent: Tuesday, December 02, 2008 7:56 AM
>To: Sprecher, Nurit (NSN - IL/Hod HaSharon); Drake, John E; 
>[e-mail]
>Cc: [e-mail]
>Subject: Re: [Mpls-interop] Who will be in Geneva?
>
>I suggested "tunnel" to convey the hierarchical business.
>
>PSL does not clearly show whether it is a segment of an LSP, 
>or an LSP that contains a segment of an LSP. I believe that 
>PST helps resolve that.
>
>Further, Nurit's question is answered by PST.
>
>A
>
>----- Original Message -----
>From: "Sprecher, Nurit (NSN - IL/Hod HaSharon)" 
><[e-mail]>
>To: "ext Drake, John E" <[e-mail]>om>; "Adrian Farrel" 
><[e-mail]>co.uk>; <[e-mail]>
>Cc: <[e-mail]>
>Sent: Tuesday, December 02, 2008 3:43 PM
>Subject: RE: [Mpls-interop] Who will be in Geneva?
>
>
>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