Re: [mpls] working group last call on draft-ietf-mpls-tp-mip-mep-map

[Gregory Mirsky <[e-mail]>]

Hi Rolf,
please find my notes in-lined below and tagged by GIM>>.

        Regards,
                Greg

-----Original Message-----
From: Rolf Winter [mailto:[e-mail]]
Sent: Wednesday, December 05, 2012 12:23 AM
To: Gregory Mirsky; [e-mail]
Subject: RE: working group last call on draft-ietf-mpls-tp-mip-mep-map

Hi Greg,

see inline.

NEC Europe Limited | Registered Office: NEC House, 1 Victoria Road, London W3 6BL | Registered in England 2832014


> Hi Rolf,
> I'll think that per MEG MIPs, even though they are on the same LSP/PW,
> in MPLS-TP, IMHO, belong in fact to different MEG Levels, hence
> different SPMEs. If such interpretation is acceptable, then we can
> have multiple MIPs but only one MIP per MEG Level (even though no such
> construct was introduced in MPLS-TP OAM model, unfortunately IMHO).

Again, I don't see why to force this, what this would actually gain, why to introduce an artificial constraint and force people to manage MEG levels as opposed to multiple MIPs per MEG. You can implement it this way if you wish but I do not see a compelling argument why to force it (and therefore disallow something that _all_ RFCs have allowed to date).

GIM>> Yes, some architectural constrcts, paradigms have to be enforced. Support of multiple MIPs on a given LSP/PW on particular LSR/(S-)PE through use of SPME, IMHO, acceptable solution to the requirement. And as I've been writing previous sentense I've realized I'm not sure whether MPLS-TP OAM allows MIP on LER/T-PE nodes, i.e. where MEPs reside. Ethernet OAM, AFAIK, makes such combination optional, but not a requirement.

> And I think that distinction, if any, between in-, out- and nodal MIP
> should not be required for unidirectional MPLS-TP constructs as it is
> not practical since Loopback mode can not be exercised as there's no
> return path via data plane. Thus examples with p2mp scenarios are not
> applicable, IMHO, to this discussion.

A return path will be out of band, yes. But if you proclaim that if there is no data plane return path and therefore in- and out- MIP distinction is useless that doesn't compute at my end. I mean, if MIP functionality is useful in any scenario, the distinction can help operators to do a better OAM job (and I believe restricting the discussion to loopback is not helpful here either).

GIM>> RFC 6435 states in Section 4.1 Operational Prerequisites:
   Obviously, for the loopback function to operate, there are several
   prerequisites:

   -  There must be a return path, so the transport path under test must
      be bidirectional.

I read it that out of band return path would not suffice the abovementioned requirement to use MPLS-TP loopback. Perhaps another packet transport can work, but not MPLS-TP.

>
>         Regards,
>                 Greg
>
> -----Original Message-----
> From: Rolf Winter [mailto:[e-mail]
> <mailto:[e-mail]> ]
> Sent: Tuesday, December 04, 2012 12:00 AM
> To: Gregory Mirsky; [e-mail]
> Subject: RE: working group last call on draft-ietf-mpls-tp-mip-mep-map
>
> Hi Greg,
>
> you might not be convinced but there are operators that have asked for
> this functionality based on operational experience.
>
> Quoting the OAM framework RFC:
>
> " Once a MEG is configured, the operator can enable/disable the MIPs on
>    the nodes within the MEG.  All the intermediate nodes and possibly
>    the end nodes host MIP(s).  Local policy allows them to be enabled
>    per function and per MEG.  The local policy is controlled by the
>    management system, which may delegate it to the control plane.  A
>    disabled MIP silently discards any received OAM packets."
>
> Clearly having multiple MIPs per LSP is allowed as per the OAM
> framework. I think however the sentence "All the intermediate nodes
> and possibly the end nodes host MIP(s)" should really be ""All the
> intermediate nodes and possibly the end nodes can host MIP(s)" (Is
> this worth filing an errata?). I don't see why one wants to
> arbitrarily restrict the number of MIPs per LSP. BTW, as you mention,
> the support of multiple MIPs in Ethernet is optional. Quoting the OAM
> framework
> again:
>
> "Support of per-interface or per-node MIPs is an implementation
> choice."
>
> So where's the difference?
>
> Best,
>
> Rolf
>
> NEC Europe Limited | Registered Office: NEC House, 1 Victoria Road,
> London W3 6BL | Registered in England 2832014
>
>
> > -----Original Message-----
> > From: Gregory Mirsky [mailto:[e-mail]
> > <mailto:[e-mail]> ]
> > Sent: Montag, 3. Dezember 2012 21:47
> > To: Rolf Winter; Loa Andersson; [e-mail]
> > Cc: [e-mail]; [e-mail]; draft-ietf-
> > [e-mail]
> > Subject: RE: working group last call on draft-ietf-mpls-tp-mip-mep-
> map
> >
> > Hi Rolf,
> > I've been thinking about that requirement for some time and am not
> > convinced that such requirement, support multiple MIP per LSP/PW on
> > given LSR/PE, exists. AFAIK, in Ethernet OAM only support of single
> > MIP per MD/MEG Level is required and support of multiple MIPs is
> optional.
> > True, multiple MIPs of different MD/MEG Levels might be enabled on a
> > node but in MPLS-TP we use SPME to model MD/MEG Levels and thus such
> > MIPs are on different LSPs. As for p2mp case, I'm not sure how dat-
> > plane loopback can be used on uni-directional construct.
> >
> >         Regards,
> >                 Greg
> >
> > -----Original Message-----
> > From: Rolf Winter [mailto:[e-mail]
> > <mailto:[e-mail]> <mailto:[e-mail]
> > <mailto:[e-mail]> > ]
> > Sent: Monday, December 03, 2012 12:15 PM
> > To: Gregory Mirsky; Loa Andersson; [e-mail]
> > Cc: [e-mail]; [e-mail]; draft-ietf-
> > [e-mail]
> > Subject: RE: working group last call on draft-ietf-mpls-tp-mip-mep-
> map
> >
> > Hi Greg,
> >
> > But that's the whole point of the document. There can be multiple
> > in- and out-MIPs per LSP plus in the P2MP case there can be multiple
> > out- MIPs per node. It cannot be based local configuration. There
> > has to
> be
> > information inside the OAM frame to address the respective MIP.
> > Section
> > 4 of the document has a (I believe) pretty good example of this.
> >
> > Best,
> >
> > Rolf
> >
> > NEC Europe Limited | Registered Office: NEC House, 1 Victoria Road,
> > London W3 6BL | Registered in England 2832014
> >
> >
> > > -----Original Message-----
> > > From: Gregory Mirsky [mailto:[e-mail]
> > > <mailto:[e-mail]>
> > > <mailto:[e-mail]
> > > <mailto:[e-mail]> > ]
> > > Sent: Montag, 3. Dezember 2012 19:20
> > > To: Rolf Winter; Loa Andersson; [e-mail]
> > > Cc: [e-mail]; [e-mail]; draft-
> ietf-
> > > [e-mail]
> > > Subject: RE: working group last call on
> > > draft-ietf-mpls-tp-mip-mep-
> > map
> > >
> > > Hi Rolf,
> > > Do you envision that multiple MIPs, both in- and out-, required to
> be
> > > supported on a given LSP/PW? I think that     only single MIP
> > required
> > > per LSP/PW on an LSR/PE node. If that is the case, then there
> > > might
> > be
> > > no apparent need to explicitly address in- and out- MIP as such
> > > distinction becomes part of local configuration.
> > >
> > >        Regards,
> > >                Greg
> > >
> > > -----Original Message-----
> > > From: [e-mail] [mailto:[e-mail]
> > > <mailto:[e-mail]> <mailto:[e-mail]
> > > <mailto:[e-mail]> > ] On Behalf Of Rolf Winter
> > > Sent: Monday, December 03, 2012 5:42 AM
> > > To: Loa Andersson; [e-mail]
> > > Cc: [e-mail]; [e-mail]; draft-
> ietf-
> > > [e-mail]
> > > Subject: Re: [mpls] working group last call on draft-ietf-mpls-tp-
> > mip-
> > > mep-map
> > >
> > > Loa,
> > >
> > > These have been mentioned:
> > >
> > > 1. CV between a MEP and a MIP
> > > 2. traceroute over an MPLS-TP LSP and/or an MPLS-TP PW containing
> > MIPs
> > > 3. data-plane loopback configuration at a MIP 4. diagnostic tests
> > >
> > > Best,
> > >
> > > Rolf
> > >
> > > NEC Europe Limited | Registered Office: NEC House, 1 Victoria
> > > Road, London W3 6BL | Registered in England 2832014
> > >
> > >
> > > > -----Original Message-----
> > > > From: Loa Andersson [mailto:[e-mail] <mailto:[e-mail]>
> > > > <mailto:[e-mail] <mailto:[e-mail]> > ]
> > > > Sent: Freitag, 30. November 2012 11:41
> > > > To: [e-mail]
> > > > Cc: [e-mail]; Martin Vigoureux;
> > > > draft-ietf-mpls-tp- [e-mail];
> > > > [e-mail]
> > > > Subject: Re: working group last call on
> > > > draft-ietf-mpls-tp-mip-mep-
> > > map
> > > >
> > > > Authors,
> > > >
> > > > Can you plese give me an indication of which OAM functions the
> > > > separation of in and out MIPs are intended for?
> > > >
> > > > /Loa
> > > >
> > > >
> > > >
> > > > On 2012-11-14 16:16, Loa Andersson wrote:
> > > > >
> > > > > Working Group,
> > > > >
> > > > > This is to start a 2 week working group last call on
> > > > > draft-ietf-mpls-tp-mip-mep-map.
> > > > >
> > > > > Please send your comments to the mpls working group mailing
> list
> > > > > ([e-mail]).
> > > > >
> > > > > Please send both technical comments, and if you are happy with
> > the
> > > > > document as is also indications of support.
> > > > >
> > > > > This working group last call will end on November 28.
> > > > >
> > > > > /Loa
> > > > > for the wg co-chairs
> > > > >
> > > > >
> > > >
> > > > --
> > > >
> > > >
> > > > Loa Andersson                         email:
> > > [e-mail]
> > > > Sr Strategy and Standards Manager            [e-mail]
> > > > Ericsson Inc                          phone: [phone]
> > > >                                               [phone]
> > > _______________________________________________
> > > mpls mailing list
> > > [e-mail]
> > > https://www.ietf.org/mailman/listinfo/mpls
> > > <https://www.ietf.org/mailman/listinfo/mpls>
> > > <https://www.ietf.org/mailman/listinfo/mpls
> > > <https://www.ietf.org/mailman/listinfo/mpls> >
> >
>