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

[<[e-mail]>]

Very well put, Rolf.

It is also be considered, that the current SPME construct has some (mostly operational) deficiencies of it's own, as pointed out by draft-ietf-mpls-tp-temporal-hitless-psm.

Thanks,
Manuel

> -----Original Message-----
> From: [e-mail] [mailto:[e-mail]] On Behalf Of
> Rolf Winter
> Sent: Wednesday, December 05, 2012 5:23 PM
> To: Gregory Mirsky; [e-mail]
> Subject: Re: [mpls] 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).
>
> > 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).
>
> >
> >         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> >
> > >
> >
> _______________________________________________
> mpls mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/mpls