Subject: Re: [mpls] Comments on draft-ietf-mpls-tp-li-lb-07.txt

From: "Adrian Farrel" <[email-masked]>
Date: Wed, 5 Oct 2011 21:37:17 +0100

Ack to all of that.
 
Adrian
 
From: Greg Mirsky [mailto:[email-masked]] 
Sent: 05 October 2011 18:13
To: [email-masked]
Cc: [email-masked]
Subject: Re: [mpls] Comments on draft-ietf-mpls-tp-li-lb-07.txt
 
Hi Adrian,
yes we're! And I'll try to summarize it below instead of in-lining:
*	query the WG on applicability of the LB on "coincidental" bidirectional
MIP on associated bi-directional LSP;
*	query the WG on introducing explicit UnLock operation to MPLS-TP OAM set
*	I accept proposed updates to LB applicability statement
*	In regard to our discussion of management plane role in setting MEP or
MIP into a loopback state (Section 4, p.4, second to last para). I agree with
the proposed version for the first sentence but will re-word the second:
NEW
  The management plane must ensure that the two MEPs are locked before
  performing the loopback function.
NEWER
  The management plane must ensure that the two MEPs are locked before it
requests
  setting MEP or MIP in the loopback state.
END
*	I feel that we're implicitly view and refer to an MPLS Section as
bidirectional construct even though it is not. In case of this document I'd
propose to explicitly refer to bidirectional MPLS Section where necessary.

Regards,
Greg

On Wed, Oct 5, 2011 at 3:43 AM, Adrian Farrel <[email-masked]> wrote:
Hi again Greg,

We are converging.

I've cut out the bits where we have reached conclusions.

>>> Introduction, third para.
>>> Applicability of the Loopback is limited, comparing to previous versions,
>>> to bi-directional co-routed LSP, PW and MPLS Section. I agree that
>>> statement of applicability in previous versions was bit too cumbersome
>>> but this one excludes bi-directional associated LSP at all. I think that
>>> Loopback can be used on this construct at MIP that are on forward
>>> and reverse direction of given bi-directional associated MPLS-TP LSP.
>>> And I think that MPLS Section is not necessarily a bi-directional co-
>>> routed object.
>
> GIM>> But then PW and MPLS Section have been referred twice -
> after co-routed LSP, then after associated LSP. Or intention was to apply
> co-routed and associated to PW and MPLS Section? Would making the
> last sentence to "It can also be applied at a MEP on an associated
> bidirectional LSP" be sufficient? But still, MIPs that are on forward
> and reverse direction of an associated bi-directional LSP are excluded.
> I believe that previous versions tried to include such MIPs since these
> are required to be aware of directions and their correlation. Is this
> change intentional?
You're right. I mangled the original  text in my enthusiasm to have something I
could parse :-)
I think there are two issues:

1. extraneous mention of PW and Section in the last sentence

OLD (v7)
  - The loopback function allows an operator to set a specific node on
    a transport path into loopback mode such that it returns all
    received data. Loopback can be applied at a Maintenance Entity
    Group End Point (MEP) or a Maintenance Entity Group Intermediate
    Point (MIP) on a co-routed bidirectional LSP, PW or MPLS
    Section. It can also be applied at a MEP on an associated
    bidirectional LSP, PW or MPLS Section.
NEW
  - The loopback function allows an operator to set a specific node on
    a transport path into loopback mode such that it returns all
    received data. Loopback can be applied at a Maintenance Entity
    Group End Point (MEP) or a Maintenance Entity Group Intermediate
    Point (MIP) on a co-routed bidirectional LSP, on a PW, or on an
    MPLS Section. It can also be applied at a MEP on an associated
    bidirectional LSP.
END

2. Discussion of loopback at "coincident" MIPs on associated bidirectional LSPs.
This is a question for the WG not for me (I am only trying to provide an
editorial service!).
Would you mind raising this as a separate thread so that the WG spot and debate
the issue?

>>> Section 4, p.4, second to last para. I think that management plane
>>> sets in or requests Loopback on specific MP but not performs it.
>>
>> The two sentences in this paragraph are directly copied from the
>> previous revision with the only change to drop "MUST" to lower case.
>>
>> Not sure what to say here since the WG clearly agreed to this text
>> before. I think the intention was to say that a control plane is not
>> required in order to achieve loopback.
>
>GIM>> What if the first sentence says:
>
> A management plane can be too used to set a MEP or MIP along a
> transport path in Loopback.
Well, I don't like "too" because this document doesn't actually mention any way
to set loopback using the control plane.

So what about:

OLD (v7)
  The Loopback can be performed using a management plane. Management
  plane must ensure that the two MEPs are locked before performing the
  loopback function.
NEW
  The management plane can be used to configure the Loopback function.
  The management plane must ensure that the two MEPs are locked before
  performing the loopback function.
END

>>> Definition given in Section 4.1 is broader than one in the Introduction.
>>> Personally I like the latter better though I think that it can be expanded
>>> to include MIPs on bi-directional associated LSP that are on forward and
>>> reverse direction of it.
>>
>> I think it is the same definition.
>> See the paragraph quoted above and compare with:
>>  - The node in loopback mode must be on both the forward and return
>>    paths. This possible for all MEPs and MIPs on a co-routed
>>    bidirectional LSP, PW, or MPLS Section, but is only
>>    possible on for MEPs on associated bidirectional LSPs, PW,
>>    or MPLS Sections.
>> ...which seems to exclude the MIPs on assoc bidir as you say.
Same two issues:

1.
OLD (v7)
  - The node in loopback mode must be on both the forward and return
    paths. This possible for all MEPs and MIPs on a co-routed
    bidirectional LSP, PW, or MPLS Section, but is only
    possible on for MEPs on associated bidirectional LSPs, PW,
    or MPLS Sections.
NEW
  - The node in loopback mode must be on both the forward and return
    paths. This possible for all MEPs and MIPs on a co-routed
    bidirectional LSP, on a PW, or on an MPLS Section, but is only
    possible on for MEPs on associated bidirectional LSPs.
END

2. You will raise associated bidir MIPs on the mailing list

>>> I'll note that service could not be restored faster than in 3.5 seconds
>>> according to described procedure. Is that desired behavior?
>>
>> That is a good question for the WG. It was my assumption (from the
>> previous revision) that rapid unlocking and turn-up was not a
>> requirement or it would have been included.
>>
>> If the WG now wants to include it, it will need to examine the use of an
>> unlock OAM message. This could be done using a new message or a flag
>> on the existing lock message. It could be achieved by tweaking this
>> document or introducing a new document.
>
> GIM>> I'd support explicit UnLock OAM message. I think that it is required
> if LI/LB expected to work in heterogeneous network (without defined
> UnLock message or flag request to UnLock is proprietary, in my view).
OK. Well, this is another technical, not editorial, change.
So I am not really in a position to discuss it.
Would you mind creating a separate thread for this one as well?
That way the WG can decide what it wants to do.

Many thanks for the thorough and thoughtful review.

Adrian