Subject: Re: [PWE3] Remote Loopback Control

From: Ron Cohen <[email-masked]>
Date: Wed, 5 May 2010 14:14:57 +0300

Hi Sami, all,

Taking out the OAM loopback and handling only data loopback is a great
simplification.

I think there is room for additional simplifications of the draft. Non
mandatory options can always be added later. Here are few notes in this
direction.

1. Why is Loopback Echo needed? I think it replicates already existing
functionality (VCCV echo)

2. Is separate lock and loopback operations really needed? I'm not familiar
with different lock and loopback operations in TDM world - you simply
request loopback. Why is it needed here?

3. Why is 'Null operation' needed? It adds a lot of 'null' processing
options.

4. I suggest that Authentication and timestamping options will be taken out
of the draft. I don't see a reason to handle authentication specifically for
loopback control.

When is the next version of the draft expected?

Best,
Ron

On Thu, Apr 29, 2010 at 8:46 PM, Sami Boutros <[email-masked]> wrote:

>  Hi Ron,
>
>
> At 08:54 AM 4/29/2010, Ron Cohen wrote:
>
> Hi Carlos, all,
>
> Thanks for the reference. Indeed the problem I described is covered in
> the much larger scope of loopback control addressed in this draft.
>
> The concerns I have after a quick read are:
>
> - The scope being tied with MPLS TP. I want to make sure that the
> solution is valid regardless of transport (IP, MPLS, etc).
>
>
> The mechanisms in the draft apply MPLS-TP LSPs, bi-directional
> RSVP-TE tunnels, pseudowires (PW), and Multi-segment PWs.
>
>
>
> - Simplicity: The loopback control mechanisms defined in this draft do
> not seem to be overly complex, as a small subset of the described
> protocols can be used for the specific SATOP loopback problem.
> However, it is not clear to me from the draft which subset is going to
> be mandated for minimal implementation, which hopefully should not be
> too far from the subset required for the SATOP problem.
>
>
> The draft defines 2 functions which are loopback and Lock, Lock to take
> the LSP/PW out of service, then perform the loopback function.
>
> We originally had an OAM loopback defined but we are taking this out of
> the draft, and the draft will only cover DataPacket loopback.
>
>
> Can you elaborate more on the status of the draft ?
>
>
> We re-published the draft last March.
>
> Thanks,
>
> Sami
>
> Can you address my concerns? Any other relevant concerns?
>
> What are the best next steps?
> Best,
> Ron
>
>
>
> On Thu, Apr 29, 2010 at 4:20 PM, Thomas D. Nadeau <[email-masked]>
> wrote:
> >
> >    This draft does indeed seem like a reasonable place to start from.
> >
> >    --Tom
> >
> >
> >
> > On 4/29/10 9:07 AM, "Carlos Pignataro" <[email-masked]> wrote:
> >
> >> Group,
> >>
> >> Would < http://tools.ietf.org/html/draft-boutros-mpls-tp-loopback-03>,
> >> "Operating MPLS Transport Profile LSP in Loopback Mode", be relevant to
> >> this discussion?
> >>
> >> --->8---
> >> 1. Introduction
> >> ...
> >>    The mechanisms in this document apply to asso-
> >>    ciated bidirectional paths as defined in [7], which include MPLS-TP
> >>    LSPs, bi-directional RSVP-TE tunnels, pseudowires (PW), and Multi-
> >>    segment PWs.
> >> --->8---
> >>
> >> Thanks,
> >>
> >> -- Carlos.
> >>
> >> On 4/27/2010 5:50 AM, Ron Cohen wrote:
> >>> Hi pwe3ers,
> >>>
> >>> Assume the following setup:
> >>>
> >>> DS1---CES-A---SATOP-PW---CES-B---DS1
> >>>
> >>> A DS1 SATOP pseudo-wire is setup up between two network elements CES A
> and B.
> >>>
> >>> There is a need, coming from the field, to set (and release) the
> >>> remote side of the pseudo-wire to loopback state. That is, to be able
> >>> to ask CES-A for remote loopback on CES-B, i.e. being able to test
> >>> from CES-A the correct operation of the SATOP-PW.
> >>>
> >>> I discussed this issue with Sasha, to check whether he is also
> >>> familiar with the request to support this feature and to consult how
> >>> to best use or extend the pw protocol suite for this purpose.
> >>>
> >>> I guess the first question to the group is whether others have also
> >>> seen the need for remote loopback control (for SATOP and other pw-s).
> >>>
> >>> Best,
> >>> Ron
> >>> _______________________________________________
> >>> pwe3 mailing list
> >>> [email-masked]
> >>> https://www.ietf.org/mailman/listinfo/pwe3
> >>>
> >> _______________________________________________
> >> pwe3 mailing list
> >> [email-masked]
> >> https://www.ietf.org/mailman/listinfo/pwe3
> >
> >
> >
> >
> _______________________________________________
> pwe3 mailing list
> [email-masked]
>  https://www.ietf.org/mailman/listinfo/pwe3
>
>
>

---

From: "Thomas D. Nadeau" <[email-masked]>
Date: Wed, 05 May 2010 08:00:05 -0400

On 5/5/10 7:14 AM, "Ron Cohen" <[email-masked]> wrote:

> TOM: After our experience with VCCV and all of the options there, I¹d agree
> with you Ron that keeping things to a small set of mandatory bits is the way
> to go; otherwise, we invite interop issues down the road.
> 
> TOM: I¹d agree that there is no sense in reinventing things, but I think the
> intent was to extend this for use in the MPLS-TP space.  I would prefer to
> recycle existing mechanisms as much as possible, however, so we might want to
> go and revisit this.
> 
> with different lock and loopback operations in TDM world - you simply request
> loopback. Why is it needed here? 
> 
> 3. Why is 'Null operation' needed? It adds a lot of 'null' processing options.
> 
> 4. I suggest that Authentication and timestamping options will be taken out of
> the draft. I don't see a reason to handle authentication specifically for
> loopback control. 
> 
> TOM: I think authentication is needed (at least in theory) to obviate
> spoofing. Although in practice, I don¹t think it will be used much.
> 
>     --Tom
> 
> 
>>> On Thu, Apr 29, 2010 at 4:20 PM, Thomas D. Nadeau <[email-masked]> wrote:
>>>> >
>>>>> >> Would < http://tools.ietf.org/html/draft-boutros-mpls-tp-loopback-03
>>>>> <http://tools.ietf.org/html/draft-boutros-mpls-tp-loopback-03> >,
>>>>>> >>> A DS1 SATOP pseudo-wire is setup up between two network elements CES
>>>>>> A and B.
>>>>>> >>>

---

From: Sami Boutros <[email-masked]>
Date: Thu, 06 May 2010 22:42:10 -0700

At 05:00 AM 5/5/2010, Thomas D. Nadeau wrote:

>On 5/5/10 7:14 AM, "Ron Cohen" 
><<[email-masked]>[email-masked]> wrote:
>
>Hi Sami, all,
>
>Taking out the OAM loopback and handling only data loopback is a 
>great simplification.
>
>I think there is room for additional simplifications of the draft. 
>Non mandatory options can always be added later. Here are few notes 
>in this direction.
>
>TOM: After our experience with VCCV and all of the options there, 
>I'd agree with you Ron that keeping things to a small set of 
>mandatory bits is the way to go; otherwise, we invite interop issues 
>down the road.
>
>1. Why is Loopback Echo needed? I think it replicates already 
>existing functionality (VCCV echo)
>
>TOM: I'd agree that there is no sense in reinventing things, but I 
>think the intent was to extend this for use in the MPLS-TP space.  I 
>would prefer to recycle existing mechanisms as much as possible, 
>however, so we might want to go and revisit this.

Agreed folks, next revision of the draft would have this echo function removed.

>2. Is separate lock and loopback operations really needed? I'm not 
>familiar with different lock and loopback operations in TDM world - 
>you simply request loopback. Why is it needed here?

The lock is needed to take the MPLS-TP LSP out of service before 
performing the loopback operation.

>3. Why is 'Null operation' needed? It adds a lot of 'null' processing options.

This will be removed as well with the echo function, only the set 
full loopback will remain.

>4. I suggest that Authentication and timestamping options will be 
>taken out of the draft. I don't see a reason to handle 
>authentication specifically for loopback control.

Authentication is an optional TLV, and I agree the timestamp should 
be out of scope too.

>TOM: I think authentication is needed (at least in theory) to 
>obviate spoofing. Although in practice, I don't think it will be used much.
>
>     --Tom
>
>

In a month or so.

Thanks,

Sami

>Best,
>Ron
>
>
>On Thu, Apr 29, 2010 at 8:46 PM, Sami Boutros 
><<[email-masked]>[email-masked]> wrote:
>Hi Ron,
>
>
>On Thu, Apr 29, 2010 at 4:20 PM, Thomas D. Nadeau 
><<[email-masked]>[email-masked]> wrote:
> >
> > On 4/29/10 9:07 AM, "Carlos Pignataro" 
> <<[email-masked]>[email-masked]> wrote:
> >
> >> Group,
> >>
> >> Would < 
> <http://tools.ietf.org/html/draft-boutros-mpls-tp-loopback-03>http://tools.ietf.org/html/draft-boutros-mpls-tp-loopback-03 
> >>> A DS1 SATOP pseudo-wire is setup up between two network 
> elements CES A and B.
> >>>
> >>> <[email-masked]>[email-masked]
> >> <[email-masked]>[email-masked]
><[email-masked]>[email-masked]