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

[Rolf Winter <[e-mail]>]

Hi Greg,

I still do not see how the loopback example applies to per-interface MIP addressing alone. There has to be a return path, full stop. Independent of _any_ OAM constructs. I can answer the question you had, which was:

"I've realized I'm not sure whether MPLS-TP OAM allows MIP on LER/T-PE nodes, i.e. where MEPs reside.".

The OAM framework is quite explicit on this (at the end of section 3.4):

"A node hosting a MEP can also support per-interface Up MEPs and per-interface MIPs on either side of the forwarding engine."

I think we should focus on the draft mentioned in the subject line instead of questioning things that the MPLS-TP OAM framework explicitly allows. If you like to continue that discussion (which is fine by me) we really should change the subject line.

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]]
> Sent: Donnerstag, 6. Dezember 2012 00:42
> To: Rolf Winter; [e-mail]
> Subject: RE: working group last call on draft-ietf-mpls-tp-mip-mep-map
> 
> Hi Rolf,
> please find my notes in-lined below and tagged by GIM>>.
> 
>         Regards,
>                 Greg
> 
> -----Original Message-----
> From: Rolf Winter [mailto:[e-mail]
> <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]> <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]>
> > > <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]> > <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]> >
> > > > <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]> > <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]> > <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> >
> > > > <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> > >
> > >
> >
>