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

[Sami Boutros <[e-mail]>]

Hi Greg/Adrian,

Few comments inline..
At 10:13 AM 10/5/2011, Greg Mirsky wrote:
>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;
Sami: we can extend the applicability to this if the WG is ok with 
that, given that the MIP will be bidirectional.

>    * query the WG on introducing explicit UnLock operation to MPLS-TP OAM set
Sami: I don't think that adding an explicit UnLock is justifiable, 
given that (1) the UnLock message itself may not get through if the 
LSP is out of service.(2) The need of the lock message is for getting 
an LSP out of service in a coordinated way within a tight window, 
however an LSP coming out of service will not be fully operational 
except after other OAM functions like cc-cv will declare the LSP UP.

>    * I accept proposed updates to LB applicability statement

Sami: I accepted all the editorial texts below and will be making the 
changes as soon as the WG last call ends in the newer version 08.

Thanks,

Sami

>    * 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 
><<mailto:[e-mail]>[e-mail]> 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
>
>
>_______________________________________________
>mpls mailing list
>[e-mail]
>https://www.ietf.org/mailman/listinfo/mpls