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

From: Rolf Winter <[email-masked]>
Date: Mon, 3 Dec 2012 13:42:29 +0000

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:[email-masked]]
> Sent: Freitag, 30. November 2012 11:41
> To: [email-masked]
> Cc: [email-masked]; Martin Vigoureux; draft-ietf-mpls-tp-
> [email-masked]; [email-masked]
> 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
> > ([email-masked]).
> >
> > 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: [email-masked]
> Sr Strategy and Standards Manager            [email-masked]
> Ericsson Inc                          phone: +46 10 717 52 13
>                                               +46 767 72 92 13

---

From: Rolf Winter <[email-masked]>
Date: Mon, 3 Dec 2012 13:52:50 +0000

Hi,

sorry for the belated response. I checked with some of our HW people. Here's the gist of their response:

Of course they wouldn't like parsing TLVs but we established that fact already. Their answer to the problem is slightly different though. A TTL-expired OAM frame can simply be copied and forwarded to the out-MIPs where, if the frame is not intended for them, it can safely be dropped. In the P2MP case e.g. this needs to be done anyway, i.e. the implementation must behave in this exact way in either case. So there is at least one way to implement this at line rate without going back and changing a bunch of RFCs.

Best,

Rolf

> From: [email-masked] [mailto:[email-masked]] On Behalf Of
> Shahram Davari
> Sent: Mittwoch, 28. November 2012 18:46
> To: Pablo Frank
> Cc: [email-masked]
> Subject: Re: [mpls] working group last call on draft-ietf-mpls-tp-mip-
> mep-map
> 
> Pablo,
> 
> 
> 
> That was exactly my point. Let's use a flag to indicate in-MIP or out-
> MIP and then the offline processor can do MEPID lookup to determine
> whether this is a legitimate OAM packet or not.
> 
> 
> 
> Thx
> Shahram
> 
> 
> 
> From: Pablo Frank [mailto:[email-masked]]
> Sent: Wednesday, November 28, 2012 8:22 AM
> To: Shahram Davari
> Cc: [email-masked]
> Subject: Re: [mpls] working group last call on draft-ietf-mpls-tp-mip-
> mep-map
> 
> 
> 
> I think Shahram raises a very legitimate concern about how expensive
> this could be to implement in hardware.
> 
> 
> 
> As I understand it, the logic proposed by this draft is as follows:
> 
> 
> 
> At the ingress blade:
> 
> 
> 
> IF TTL-expired && GAL-is-present && GACh-type-is-X THEN
> 
>    Parse MIP-ID TLV
> 
>    Lookup MIP-ID
> 
>    IF MIP-is-egress, THEN
> 
>       forward normally (but note we must intercept it again on egress)
> 
>    ELSE
> 
>       punt to OAM processor
> 
> 
> 
> At the egress blade:
> 
> 
> 
> IF TTL-expired && GAL-is-present && GACh-type-is-X THEN
> 
>    Parse MIP-ID TLV
> 
>    Lookup MIP-ID
> 
>    IF MIP-is-egress, THEN
> 
>       punt to OAM processor
> 
>    ELSE
> 
>       drop
> 
> 
> 
> Note all this has to be done in the fast-path now at full line rate
> (and hardware guys hate TLVs).  Before, the only thing the fast-path
> had to do was look for TTL-expiry.
> 
> 
> 
> The only reason that ACH reserved bit was rejected (in Appendix A.4 of
> -03 version of doc) was because it also required a MIP-ID lookup.  But
> I don't see anything wrong with combining both mechanisms.  Ideally,
> hardware could rely on the reserved bit to do the initial filtering at
> full line-rate and then a presumably much more cost-efficient OAM
> hardware block could perform the MIP-ID lookup.  Instead of the complex
> logic above, the fast path gets a simple modification to TTL handling
> and the OAM block does the heavy lifting of dealing with ACH TLVs, etc.
> 
> 
> 
> This seems like a case where practicality should trump elegance.
> 
> 
> 
> regards,
> 
> Pablo
> 
> 
> 
> On Mon, Nov 26, 2012 at 11:48 AM, Shahram Davari <[email-masked]>
> wrote:
> 
> 
> 
> 	> Rolf,
> 	>
> 	> I am sure you know that TLVs are not Hardware friendly. And I
> think you agree with me that this draft requires deep parsing of all
> packets at line rate to get to the MIPID TLV.
> 	>
> 	> I still think the MIPID TLV is required to decide whether an
> OAM packet ended up  at the right MIP. But may be a simpler solution
> could be augmented to decide between In-MIP and Out-MIP. For example
> how about using one of the reserved bits in the ACH header.  This can
> easily be done in hardware with minimum complexity.
> 	>
> 	> Regards,
> 	> Shahram
> 	>
> 	>
> 	>
> 	> From: [email-masked] [mailto:[email-masked]] On
> Behalf Of Rolf Winter
> 	> Sent: Wednesday, November 21, 2012 12:13 PM
> 	> To: S. Davari; [email-masked]
> 	> Cc: [email-masked]
> 	> Subject: Re: [mpls] working group last call on draft-ietf-mpls-
> tp-mip-mep-map
> 	>
> 	> Hi,
> 	>
> 	>> Hi Adrian,
> 	>>
> 	>> You are right and I should have sent these types of comments
> before
> 	>> last call. I completely understand the procedure.
> 	>>
> 	>> One thing I didn't understand in your response is that you
> said in-MIP
> 	>> requires to do the MEPID lookup at line rate anyway. Why is
> that?
> 	>>
> 	>> My understanding is that before this draft,  the process would
> have
> 	>> been for the ingress to look at TTL and if it is expired then
> send the
> 	>> packet to OAM processor.
> 	>
> 	> Yes (and no). While I assume likely MIP functionality will be
> implemented on the ingress, the related RFCs are vague about the actual
> placement of the MIP function. See e.g. the OAM Framework (RFC 6371)
> "per-node MIPs (i.e., a single MIP per node in an unspecified location
> within the node)".
> 	>
> 	> Also, I think "before this draft" is not quite accurate in that
> is suggests there is no per-interface MIP addressing possible as of now.
> Take RFC 6426. In practice this is where part of the problem lies. We
> cannot really go back and change all this. There are other constraints.
> E.g. we have a requirement to address a single out-MIP out of a set of
> out-MIPs on a P2MP branch point.  So this was part of the constraints
> we worked with.
> 	>
> 	>>
> 	>> The MEPID that you suggest in this draft is very useful for
> filtering
> 	>> out leaked OAM frames from upstream. But lets leave lookup of
> the MEPID
> 	>> to the OAM processing module (at slower rate) and add an
> indicator to
> 	>> the OAM packet to indicate whether it should be taken out of
> the data
> 	>> path in the Ingress or egress.
> 	>>
> 	>> So can I suggest adding the following text to the draft:
> 	>>
> 	>> " In addition to the MEPID, which is used to ultimately accept
> or
> 	>> filter out received OAM packets, OAM packets  should have a
> simple
> 	>> indicator that identifies whether the OAM packet belongs to
> in-MIP or
> 	>> Out-MIP".
> 	>
> 	> We also have the question on where to retrofit those bits. I
> assume a TLV wouldn't work for the exact reasons you do not like to
> have to do a second lookup, since it would require some parsing. All
> these constraints and the ones outlined in the document led to where we
> are. In a sense this is a non-spec since it rather rules out a number
> of things that seem like a good idea at first but then have a catch of
> some sort.
> 	>
> 	> Best,
> 	>
> 	> Rolf
> 	>
> 	>>
> 	>>
> 	>>
> 	>> Regards,
> 	>> Shahram
> 	>>
> 	>>
> 	>> On Nov 21, 2012, at 1:16 AM, "Adrian Farrel"
> <[email-masked]>
> 	>> wrote:
> 	>>
> 	>>> <co-author mode>
> 	>>>
> 	>>> Hi Shahram,
> 	>>>
> 	>>> I am worried about the precedent of a comment like this
> during WG
> 	>> last call.
> 	>>> While comments that improve the document or point out
> fundamental
> 	>>> flaws are welcome whenever they arrive, points with the
> flavour "I
> 	>>> wouldn't have done it like this" that arrive this late in the
> process
> 	>> don't feel very constructive.
> 	>>> But I will leave the chair to worry about process and try to
> address
> 	>>> the technical points...
> 	>>>
> 	>>>> Identifying whether to terminate an OAM packet and process
> it in In-
> 	>> MIP vs.
> 	>>> Out-
> 	>>>> MIP requires line rate lookup, otherwise the OAM packet will
> not
> 	>> take
> 	>>>> the same path as data packets.  Therefore any MIP identifier
> that is
> 	>>>> proposed in this
> 	>>> draft
> 	>>>> requires one extra lookup and therefore adds significantly
> to cost.
> 	>>>
> 	>>> If I am not wrong, this is a feature of an out-MIP. If you
> decide to
> 	>>> implement out-MIPs, and if you want the OAM to follow exactly
> the
> 	>> same
> 	>>> path as the data, then it is a requirement that the out
> interface
> 	>>> inspects the packets (at line
> 	>>> rate) to determine whether they are OAM and targeted at the
> interface.
> 	>>>
> 	>>> We cannot change that aspect. All we can do is aim to make
> the lookup
> 	>>> as easy as possible.
> 	>>>
> 	>>>> Perhaps a
> 	>>>> similar method to Ethernet MDL/MEL (Maintenance Domain
> Level) may be
> 	>>>> used that requires only 3 bits and achieves the same result.
> 	>>>
> 	>>> Perhaps it could.
> 	>>> But before going there, why is the lookup in the current
> version of
> 	>>> the I-D arduous?
> 	>>>
> 	>>> Presumably you do not propose making any change to the way
> In-MIPs
> 	>> are
> 	>>> currently identified, so the lookups being done at line rate
> today on
> 	>>> the incoming interfaces will not be changed. If you are
> proposing
> 	>> such
> 	>>> a change, then the discussion is outside the scope of this I-
> D and
> 	>>> becomes a much wider question for the working group.
> 	>>>
> 	>>> This leaves me with the trade-off of enabling a *simpler*
> lookup on
> 	>>> the outgoing interfaces versus doing identical lookups on
> both
> 	>>> interfaces. My assumption was that if the incoming interface
> can do
> 	>>> the lookup at line rate, it is not hard to perform the same
> lookup on
> 	>>> the outgoing interface. Furthermore, there is a reduction in
> 	>> complexity by having fewer things to look up.
> 	>>>
> 	>>> Another possibility is that the full lookup could be done on
> the
> 	>>> incoming interface and the packet marked for easy
> interception on the
> 	>> outgoing interface.
> 	>>> The concern with this approach is that the packet would no
> longer be
> 	>>> being forwarded exactly as data because it would be being
> modified in
> 	>> flight.
> 	>>> Furthermore, in the case of P2MP, it is not enough to flag
> the packet
> 	>>> as a local Out-MIP and further identifier-based lookup is
> needed.
> 	>>>
> 	>>> Some of these issues were raised and discussed as the I-D
> progressed,
> 	>>> and some of the alternative solutions were tracked with their
> pros
> 	>> and
> 	>>> cons in Appendix A of the I-D (look at revision -03).
> 	>>>
> 	>>> Thanks,
> 	>>> Adrian
> 	>>>> From: [email-masked] [mailto:[email-masked]]
> On Behalf
> 	>>>> Of Adrian Farrel
> 	>>>> Sent: Monday, November 19, 2012 8:45 AM
> 	>>>> To: 't.petch'; 'Loa Andersson'; [email-masked]
> 	>>>> Cc: [email-masked]; [email-masked]
> <mailto:[email-masked]> ;
> 	>>> draft-ietf-mpls-tp-mip-
> 	>>>> [email-masked]
> 	>>>> Subject: Re: [mpls] working group last call on
> 	>>>> draft-ietf-mpls-tp-mip-mep-map
> 	>>>>
> 	>>>> Yeah, it's a boring draft. Did you expect me to co-author
> anything
> 	>> else?
> 	>>>>
> 	>>>> The point was that when I started the I-D lots of people
> were saying
> 	>>>> "it's complex" and "it can't be done" and "it won't be
> backward
> 	>> compatible".
> 	>>>>
> 	>>>> So the I-D says "here it is"
> 	>>>>
> 	>>>> A (sorry not to offer you excitement)
> 	>>>>
> 	>>>>> From: t.petch [mailto:[email-masked]]
> 	>>>>> Sent: 19 November 2012 12:38
> 	>>>>> To: Loa Andersson; [email-masked]
> 	>>>>> Cc: [email-masked]; [email-masked]
> <mailto:[email-masked]> ; MPLS-TP ad
> 	>>>>> hoc
> 	>>> team;
> 	>>>>> [email-masked]
> 	>>>>> Subject: Re: [mpls] working group last call on
> 	>>> draft-ietf-mpls-tp-mip-mep-map
> 	>>>>>
> 	>>>>> After getting to section 6 and its features (requirements!),
> I find
> 	>>>>> myself underwhelmed; is that it?  Well, I suppose so, it is
> 	>>>>> Informational and not Standards Track.
> 	>>>>>
> 	>>>>> Meanwhile, I suggest some editorial issues.
> 	>>>>>
> 	>>>>> Title
> 	>>>>> Handling MPLS-TP OAM Packets Targeted at Internal MIPs
> [Handling
> 	>>>>> MPLS-TP OAM Packets Targeted at Interface MIPs seems a more
> 	>>>>> informative statement unless and until you get to the
> definition of
> 	>>>>> Internal in s3; and s6, which is the crux of the document
> says The
> 	>>>>> preferred solution to per-interface MIP message handling is
> 	>>>>>  presented in this section]
> 	>>>>>
> 	>>>>> s1
> 	>>>>> two (or more) MIPs per node on both sides of the forwarding
> engine.
> 	>>>>> [two on both sides sounds like four in total to me; suggest
> 'one on
> 	>>>>> each side of the forwarding engine']
> 	>>>>>
> 	>>>>> s4
> 	>>>>>  o  CV between a MEP and a MIP
> 	>>>>> [expand CV on first use]
> 	>>>>>
> 	>>>>> s5
> 	>>>>> In-band OAM messages are sent using the G-ACh [RFC5586] for
> MPLS-TP
> 	>>>>>  LSPs and MPLS-TP PWs, respectively.
> 	>>>>> ['respectively' suggests to me that there should be two
> precedents,
> 	>>>>> not just RFC5586; the second paragraph specifies RFC5586
> for LSPs,
> 	>>>>> RFC6423/RFC4385 for PWs, in which case, strike this
> sentence as
> 	>>>>> redundant]
> 	>>>>>
> 	>>>>> s6
> 	>>>>> The appendix of this document contains a
> 	>>>>>  few solutions that the authors have discarded which have
> been
> 	>> left in
> 	>>>>>  the document for informational purposes.
> 	>>>>> [not any more they haven't!]
> 	>>>>>
> 	>>>>> The node itself is addresses
> 	>>>>> [The node itself is addressed]
> 	>>>>>
> 	>>>>> The identification information indside [The identification
> 	>>>>> information inside ]
> 	>>>>>
> 	>>>>> MIP identifiers are not know
> 	>>>>> [MIP identifiers are not known]
> 	>>>>>
> 	>>>>> reserved MIP address
> 	>>>>> [reserved MIP addressses or a reserved MIP address]
> 	>>>>>
> 	>>>>> Tom Petch
> 	>>>>>
> 	>>>>>
> 	>>>>> ----- Original Message -----
> 	>>>>> From: "Loa Andersson" <[email-masked]>
> 	>>>>> To: <[email-masked]>
> 	>>>>> Cc: <[email-masked]>; <mpls-
> [email-masked]>;
> 	>>>>> "MPLS-TP ad hoc team" <[email-masked]>;
> 	>>>>> <[email-masked]>
> 	>>>>> Sent: Wednesday, November 14, 2012 3:16 PM
> 	>>>>>
> 	>>>>>> Working Group,
> 	>>>>>>
> 	>>>> _______________________________________________
> 	>>>> mpls mailing list
> 	>>>> [email-masked]
> 	>>>> https://www.ietf.org/mailman/listinfo/mpls
> 	>>>
> 	>>>
> 	>>> _______________________________________________
> 	>>> mpls mailing list
> 	>>> [email-masked]
> 	>>> https://www.ietf.org/mailman/listinfo/mpls
> 	>> _______________________________________________
> 	>> mpls mailing list
> 	>> [email-masked]
> 	>> https://www.ietf.org/mailman/listinfo/mpls
> 	>
> 	> NEC Europe Limited | Registered Office: NEC House, 1 Victoria
> Road, London W3 6BL | Registered in England 2832014
> 	> _______________________________________________
> 	> mpls mailing list
> 	> [email-masked]
> 	> https://www.ietf.org/mailman/listinfo/mpls
> 	>
> 	>
> 
> 	_______________________________________________
> 	mpls mailing list
> 	[email-masked]
> 	https://www.ietf.org/mailman/listinfo/mpls
> 
>

---

From: "Shahram Davari" <[email-masked]>
Date: Mon, 3 Dec 2012 15:26:42 +0000

Hi Rolf,

Your HW guys are correct as long as the amount of data sent to the in-MIP processor is not much. But from your previous email to Loa I see that you want to also terminate CV at MIPs. CVs are fast and high bandwidth and blindly dumping them on a CPU or OAM processor  that may not be expecting them is like DoS attack. 

Regards,
Shahram

---

From: Gregory Mirsky <[email-masked]>
Date: Mon, 3 Dec 2012 18:20:04 +0000

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: [email-masked] [mailto:[email-masked]] On Behalf Of Rolf Winter
Sent: Monday, December 03, 2012 5:42 AM
To: Loa Andersson; [email-masked]
Cc: [email-masked]; [email-masked]; [email-masked]
Subject: Re: [mpls] working group last call on draft-ietf-mpls-tp-mip-mep-map

Loa,

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

---

From: Rolf Winter <[email-masked]>
Date: Mon, 3 Dec 2012 20:10:01 +0000

But the MIP that is addressed needs to be able to handle this _plus_ take an appropriate action and in the P2MP case this will always be the case since there are 2 or more out MIPs.

> From: Shahram Davari [mailto:[email-masked]]
> Sent: Montag, 3. Dezember 2012 16:27
> To: Rolf Winter
> Cc: Pablo Frank; [email-masked]
> Your HW guys are correct as long as the amount of data sent to the in-
> MIP processor is not much. But from your previous email to Loa I see
> that you want to also terminate CV at MIPs. CVs are fast and high
> bandwidth and blindly dumping them on a CPU or OAM processor  that may
> not be expecting them is like DoS attack.
> 
> 
> 
> Regards,
> Shahram
> 
> 
> > Of course they wouldn't like parsing TLVs but we established that
> fact already. Their answer to the problem is slightly different though.
> A TTL-expired OAM frame can simply be copied and forwarded to the out-
> MIPs where, if the frame is not intended for them, it can safely be
> dropped. In the P2MP case e.g. this needs to be done anyway, i.e. the
> implementation must behave in this exact way in either case. So there
> is at least one way to implement this at line rate without going back
> and changing a bunch of RFCs.
> >
> > Best,
> >
> > Rolf
> >
> > NEC Europe Limited | Registered Office: NEC House, 1 Victoria Road,
> > London W3 6BL | Registered in England 2832014
> >
> >
> >> From: [email-masked] [mailto:[email-masked]] On Behalf
> >> Of Shahram Davari
> >> draft-ietf-mpls-tp-mip- mep-map
> >>
> >> Pablo,
> >>
> >>
> >>
> >> That was exactly my point. Let's use a flag to indicate in-MIP or
> >> out- MIP and then the offline processor can do MEPID lookup to
> >> determine whether this is a legitimate OAM packet or not.
> >>
> >>
> >>
> >> Thx
> >> Shahram
> >>
> >>
> >>
> >> draft-ietf-mpls-tp-mip- mep-map
> >>
> >>
> >>
> >> -03 version of doc) was because it also required a MIP-ID lookup.
> >> But I don't see anything wrong with combining both mechanisms.
> >> Ideally, hardware could rely on the reserved bit to do the initial
> >> filtering at full line-rate and then a presumably much more
> >> cost-efficient OAM hardware block could perform the MIP-ID lookup.
> >> Instead of the complex logic above, the fast path gets a simple
> >> modification to TTL handling and the OAM block does the heavy
> lifting of dealing with ACH TLVs, etc.
> >>
> >>
> >>
> OAM
> >> packet ended up  at the right MIP. But may be a simpler solution
> said
> >> in-MIP
> >> implemented on the ingress, the related RFCs are vague about the
> >> actual placement of the MIP function. See e.g. the OAM Framework
> (RFC
> >> 6371) "per-node MIPs (i.e., a single MIP per node in an unspecified
> >> location within the node)".
> >>    >
> >> E.g. we have a requirement to address a single out-MIP out of a set
> >> of out-MIPs on a P2MP branch point.  So this was part of the
> >> constraints we worked with.
> >>    >
> >>    >>
> >> these constraints and the ones outlined in the document led to where
> >> we are. In a sense this is a non-spec since it rather rules out a
> >> number of things that seem like a good idea at first but then have a
> >> catch of some sort.
> >>    >
> >>    > Best,
> >>    >
> >>    > Rolf
> >>    >
> >>    >>
> >>    >>
> >>    >>
> >>    >> Regards,
> >>    >> Shahram
> >>    >>
> >>    >>
> during
> >> WG
> it
> >> in In-
> to
> >> cost.
> >> lookup
> interception
> >> on the
> >> packet
> On
> >> Behalf
> were
> >> saying
> for
> >> LSPs,
> sentence
> >> as
> >>    >>>>>> Please send your comments to the mpls working group
> mailing
> >> list
> >>    >>>>>> ([email-masked]).
> >>    >>>>>>

---

From: Rolf Winter <[email-masked]>
Date: Mon, 3 Dec 2012 20:14:51 +0000

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

> From: Gregory Mirsky [mailto:[email-masked]]
> Sent: Montag, 3. Dezember 2012 19:20
> To: Rolf Winter; Loa Andersson; [email-masked]
> 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
> 
> Rolf Winter
> 3. data-plane loopback configuration at a MIP 4. diagnostic tests
> 
> Best,
> 
> Rolf
>

---

From: Gregory Mirsky <[email-masked]>
Date: Mon, 3 Dec 2012 20:46:39 +0000

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:[email-masked]]
Sent: Monday, December 03, 2012 12:15 PM
To: Gregory Mirsky; Loa Andersson; [email-masked]
Cc: [email-masked]; [email-masked]; [email-masked]
Subject: RE: working group last call on draft-ietf-mpls-tp-mip-mep-map

Hi Greg,

Best,

Rolf

> Of Rolf Winter
> > Cc: [email-masked]; Martin Vigoureux;
> > draft-ietf-mpls-tp- [email-masked];
> > [email-masked]

---

From: "Shahram Davari" <[email-masked]>
Date: Mon, 3 Dec 2012 23:06:24 +0000

Rolf,

For clarity it is better to use an example. Assume that an LSR has 4 ports (A, B, C, D). Now assume that it receives packets  on a unicast  LSP-X from port A and forwards them to port B.  there can only be 3  configurations:

1) MIP on port A (In-MIP), or
2) MIP on port B (out-MIP), or
3) MEIP on Port A and B
 
A single OAM packet can be terminated and processed only by one of these MIPs. Now assume OAM packet (P) is meant for out-MIP (MIPID =port B). In your example, you are saying send a copy of the P to the CPU/Processor on Port A, and send a copy also to CPU/Processor on Port B. Port A CPU will drop the packet since the MIP-ID is not A.  The issue is that each CPU/processor has limited resources.  By sending all OAM MIP packets to both processor you are losing 1/2 of the capacity of each processor.  The practical solution is to have a simple indicator in the packet header that this OAM packet is meant for Out-MIP. Then port A just switches the OAM packet to Port B, and Port B terminates and sends it to its CPU/processor.

Lest get to P2MP example. Assume LSP-Y is a P2MP LSP that enters the chip from Port A and is sent to ports B, C, D.  Also assume that there is In-MIP on port A and out-MIPs of ports B, C (not D).  Now assume a  Multicast OAM packet is  meant for out-MIPs (B, C). In such case the OAM packet should not be sent to port A CPU/Processor. It is therefore multicast to ports B, C, D. Ports B, C send the OAM packet to their CPU. Port D drops the OAM packets and does not send it to its CPU, since there is no MIP configured for that MPLS label.

So the Pseudo-code is like this:

Ingress Port:

If packet is OAM and TTL=1
	If MIP is enabled
		If packet indicates In-MIP
			Send to local CPU
		Else
			Forward to egress port
		End
	Else
		Forward normally
	End
Else

Egress Port:

If packet is OAM and TTL=1
	If MIP is enabled
		If packet indicates In-MIP
			Drop  packet
		Else If packet indicates Out-MIP
			Send to local CPU
		End
	Else
		Drop packet
	End
End

Using this example could you please describe your reasoning for not requiring HW to identify In-MEP vs out-MIPs?

Thanks
Shahram

---

From: <[email-masked]>
Date: Tue, 4 Dec 2012 09:48:14 +0900

Hi Shahram,

First, as Rolf sent, we need in/out-MIP for
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
Here, CV means On-demand CV. You may misunderstand as Proactive CV.

Second, you wrote;
"The issue is that each CPU/processor has limited resources. 
 By sending all OAM MIP packets to both processor you are 
 losing 1/2 of the capacity of each processor. "
It depends on implementations,
and this issue could NOT be resolved by even your solution that uses ACH header to indicate in/out-MIP.
Let's consider P2MP case as you pointed out.
All OAM MIP packets for out-MIPs port(B, C) are sent to all out-MIPs.
This means that the OAM processor at port D loses its capacity.
If we consider the larger number of ports in the LSR which has 100 ports, for example,
All OAM MIP packets for out-MIPs port(B, C) are sent to all out-MIPs.
This means that the OAM processors at the other 98 ports lose those capacities.
Even if your solution using ACH header is applied,
it can reduce OAM packets only for in-MIP, which means only 1/101 effectiveness
in the case of P2MP for 100 ports.

Thanks,
Hideki Endo

---

From: "Shahram Davari" <[email-masked]>
Date: Tue, 4 Dec 2012 00:53:13 +0000

Hi Hideki,

I think you need to look at my p-code. F a MIP is not configured in the Egress port, then that egress port won't sent the OAM packet to its processor and drops it. So there is no issue with my proposed method.

Thx
Shahram

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] 
Sent: Monday, December 03, 2012 4:48 PM
To: Shahram Davari
Cc: [email-masked]; [email-masked]
Subject: Re:Re: [mpls] working group last call on draft-ietf-mpls-tp-mip-mep-map

Hi Shahram,

Second, you wrote;

Thanks,
Hideki Endo

---

From: "Shahram Davari" <[email-masked]>
Date: Tue, 4 Dec 2012 00:58:15 +0000

Hi,

Using MIP ID as the only method to filter OAM packets to CPU/Processor is not practical. There are many OAM PDUs such as BFD, LSP-Ping, RFC6374 LM/DM, etc. Each has its own format and the TLV can be anywhere. Using MIP ID as the only identifier requires unnecessarily parsing of all these different packet types at line rate in HW.

Why not just use a simple bit in the ACH header? We need a n indicator in a fixed location or the solution is not going to be practical in HW.

Thanks,
Shahram

-----Original Message-----
From: Shahram Davari 
Sent: Monday, December 03, 2012 4:53 PM
To: [email-masked]'
Cc: [email-masked]; [email-masked]
Subject: RE: Re:Re: [mpls] working group last call on draft-ietf-mpls-tp-mip-mep-map

Hi Hideki,

Thx
Shahram

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] 
Sent: Monday, December 03, 2012 4:48 PM
To: Shahram Davari
Cc: [email-masked]; [email-masked]
Subject: Re:Re: [mpls] working group last call on draft-ietf-mpls-tp-mip-mep-map

Hi Shahram,

Second, you wrote;

Thanks,
Hideki Endo

---

From: <[email-masked]>
Date: Tue, 4 Dec 2012 10:24:20 +0900

Hi Shahram,

Back and forth.
Here, let's focus on whether using MIP ID requires unnecessarily parsing in HW or not.

>I think you need to look at my p-code. F a MIP is not configured in the Egress port, then that egress port won't sent the OAM packet to its processor and drops it. So there is no issue with my propo…
Don't you consider the case when MIPs is configured in the Egress port B,C and D?
In the case of P2MP, we need to identify the only one out-MIP of these out-MIPs in port B,C and D.
In that case, your solution has low effectiveness as I pointed out.
Do I miss something?

Thanks,
Hideki Endo

---

From: "Puneet Agarwal" <[email-masked]>
Date: Tue, 4 Dec 2012 05:43:32 +0000

Hi hideki,

Is the determination that the mip identifier is present in the same location  always in the pdu or is it variable (based on oam msg type)?

Thx

Puneet

---

From: "S. Davari" <[email-masked]>
Date: Mon, 3 Dec 2012 22:00:29 -0800

Hi Hideki,

I think we have a fundamental problem statement difference. Based on your examples I think you are looking in to how to send an OAM packet only to a single out-MIP out of Nxout-MIPs in a P2MP LSP.

But I don't think this is architecturally sound or even required. Imagine there is no in-MIP at all. We want a multicast OAM packet behaves like a data packet and be replicated to all egress ports. Now if a MIP is configured in say 2 of the egress ports and not the other 98 ones, then the 98 egress ports will drop the OAM packet in HW and won't send them to their CPU. For the other 2 ports with Out-MIP, both will send the packets to their CPU and both CPUs have to process and respond such as with link trace reply or Loopback reply, etc.

Regards,
Shahram

---

From: "Shahram Davari" <[email-masked]>
Date: Tue, 4 Dec 2012 06:27:13 +0000

Hideki,

In summary your requirement is similar to Figure 7 , where you are going to bypass the normal forwarding  engine and do unicast forwarding of a multicast   OAM packet to a single outgoing port.  This kind of behavior is explicitly rejected in the draft.

Regards,
Shahram

---

From: Rolf Winter <[email-masked]>
Date: Tue, 4 Dec 2012 07:59:42 +0000

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

> Sent: Montag, 3. Dezember 2012 21:47
> 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
> 
> From: Rolf Winter [mailto:[email-masked]
> <mailto:[email-masked]> ]
> 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
> 
> > From: Gregory Mirsky [mailto:[email-masked]
> > <mailto:[email-masked]> ]
> > From: [email-masked] [mailto:[email-masked]
> > <mailto:[email-masked]> ] On Behalf Of Rolf Winter
> > > From: Loa Andersson [mailto:[email-masked] <mailto:[email-masked]> ]
> > <https://www.ietf.org/mailman/listinfo/mpls>
>

---

From: Rolf Winter <[email-masked]>
Date: Tue, 4 Dec 2012 08:28:44 +0000

Hi,

please see inline.

> Rolf,
> 
> For clarity it is better to use an example. Assume that an LSR has 4
> ports (A, B, C, D). Now assume that it receives packets  on a unicast
> LSP-X from port A and forwards them to port B.  there can only be 3
> configurations:
> 
> A single OAM packet can be terminated and processed only by one of
> these MIPs. Now assume OAM packet (P) is meant for out-MIP (MIPID =port
> B). In your example, you are saying send a copy of the P to the
> CPU/Processor on Port A, and send a copy also to CPU/Processor on Port
> B. Port A CPU will drop the packet since the MIP-ID is not A.  The
> issue is that each CPU/processor has limited resources.  By sending all
> OAM MIP packets to both processor you are losing 1/2 of the capacity of
> each processor.  The practical solution is to have a simple indicator
> in the packet header that this OAM packet is meant for Out-MIP. Then
> port A just switches the OAM packet to Port B, and Port B terminates
> and sends it to its CPU/processor.
> 
> Lest get to P2MP example. Assume LSP-Y is a P2MP LSP that enters the
> chip from Port A and is sent to ports B, C, D.  Also assume that there
> is In-MIP on port A and out-MIPs of ports B, C (not D).  Now assume a
> Multicast OAM packet is  meant for out-MIPs (B, C). In such case the
> OAM packet should not be sent to port A CPU/Processor. It is therefore
> multicast to ports B, C, D. Ports B, C send the OAM packet to their CPU.
> Port D drops the OAM packets and does not send it to its CPU, since
> there is no MIP configured for that MPLS label.

I don't think this is how it works. Quoting the OAM framework:

"In order to send an OAM packet to M leaves (i.e., a subset of all
 the leaves), the source MEP sends M different OAM packets targeted
 to each individual leaf in the group of M leaves.  Aggregating or
 subsetting mechanisms are outside the scope of this document."

I read the above in a way that you'd need to send two OAM frames in the scenario above. In other words D needs to drop packets at the rate that the others process it. In this case, a single bit is simply not enough to reduce the load all out-MIPs.

I personally think the pseudo-code is only correct for your scenario 3 BTW. But either way, my point was that the OAM CPUs - one way or the other - have to be able to process/drop OAM packets at the rate that they receive it in either case. Look at the egress port case and given the description of the OAM framework above, port B has to drop packets at the rate that port C receives them and vice versa. In your pseudo code at the egress the OAM frames will always end up in the "send to local CPU" else clause. 

I think what the WG needs to decide is:

a) do we want to go back and change a few RFCs and do a standards action on grabbing that reserved bit
b) go with the document as is and live with a deficiency that will, I guess, hit us in certain cases even with the bit

> Using this example could you please describe your reasoning for not
> requiring HW to identify In-MEP vs out-MIPs?
> 
> Thanks
> Shahram
> 
> But the MIP that is addressed needs to be able to handle this _plus_
> take an appropriate action and in the P2MP case this will always be the
> case since there are 2 or more out MIPs.
> 
> > > sorry for the belated response. I checked with some of our HW
> people.
> > Here's the gist of their response:
> > >
> > >> Behalf Of Shahram Davari
> > >> I think Shahram raises a very legitimate concern about how
> > >> expensive this could be to implement in hardware.
> > >>
> > >>
> > >>
> > >> (and hardware guys hate TLVs).  Before, the only thing the
> > >> fast-path had to do was look for TTL-expiry.
> > >>
> > >>
> > >>
> > >> The only reason that ACH reserved bit was rejected (in Appendix
> A.4
> > >> of
> > >> think you agree with me that this draft requires deep parsing of
> > >> all packets at line rate to get to the MIPID TLV.
> > >>    >
> > >> could be augmented to decide between In-MIP and Out-MIP. For
> > >> example how about using one of the reserved bits in the ACH header.
> > >> This
> > can
> > >> draft-ietf-mpls- tp-mip-mep-map
> > >>    >
> > >>    > Hi,
> > >>    >
> > >>    >> Hi Adrian,
> > >>    >>
> > >>    >> My understanding is that before this draft,  the process
> > >> would have
> > >>    > Also, I think "before this draft" is not quite accurate in
> > >> that is suggests there is no per-interface MIP addressing possible
> > >> as of
> > now.
> > >>    >> " In addition to the MEPID, which is used to ultimately
> > >> accept or
> > >> have to do a second lookup, since it would require some parsing.
> > >> All these constraints and the ones outlined in the document led to
> > >> where we are. In a sense this is a non-spec since it rather rules
> > >> out a number of things that seem like a good idea at first but
> then
> > >> have a catch of some sort.
> > >>    >
> > >>    > Best,
> > >>    >
> > >>    > Rolf
> > >>    >
> > >>    >>
> > >>    >>
> > >>    >>
> > >>    >> Regards,
> > >>    >> Shahram
> > >>    >>
> > >>    >>
> > >>    >>> wouldn't have done it like this" that arrive this late in
> > >> the process
> > >>    >>>> MIP requires line rate lookup, otherwise the OAM packet
> > >> will not
> > >>    >> take
> > >>    >>>> the same path as data packets.  Therefore any MIP
> > >> identifier that is
> > >>    >>>> proposed in this
> > >>    >>> draft
> > >>    >>> implement out-MIPs, and if you want the OAM to follow
> > >> exactly the
> > >>    >> same
> > >>    >>> a change, then the discussion is outside the scope of this
> > >> I- D and
> > >>    >>> and some of the alternative solutions were tracked with
> > >> their pros
> > >>    >> and
> > >>    >>>>> After getting to section 6 and its features
> > >> (requirements!), I find
> > >>    >>>>> two (or more) MIPs per node on both sides of the
> > >> forwarding engine.
> > >>    >>>>> [two on both sides sounds like four in total to me;
> > >> suggest 'one on
> > >>    >>>>> In-band OAM messages are sent using the G-ACh [RFC5586]
> > >> for MPLS-TP
> > >>    >>>>>> Please send both technical comments, and if you are
> happy
> > >> with the

---

From: Rolf Winter <[email-masked]>
Date: Tue, 4 Dec 2012 08:33:41 +0000

Shahram,

what if it is configured and you only want to talk to one out of all the out-MIPs. I guess we can all craft examples where we can make our point. A single bit simply does not guarantee you that the local CPU does not have to look at the OAM frame to finally discard it.

Best,

Rolf

> Sent: Dienstag, 4. Dezember 2012 01:53
> To: [email-masked]
> Cc: Rolf Winter; [email-masked]
> I think you need to look at my p-code. F a MIP is not configured in the
> Egress port, then that egress port won't sent the OAM packet to its
> processor and drops it. So there is no issue with my proposed method.
> 
> Thx
> Shahram
> 
> First, as Rolf sent, we need in/out-MIP for 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
>  By sending all OAM MIP packets to both processor you are  losing 1/2
> of the capacity of each processor. "
> If we consider the larger number of ports in the LSR which has 100
> ports, for example, All OAM MIP packets for out-MIPs port(B, C) are
> sent to all out-MIPs.
> Even if your solution using ACH header is applied, it can reduce OAM
> packets only for in-MIP, which means only 1/101 effectiveness in the
> case of P2MP for 100 ports.
> 
> Thanks,
> Hideki Endo
> 
> 
> >Rolf,
> >
> >> Your HW guys are correct as long as the amount of data sent to the
> >> in- MIP processor is not much. But from your previous email to Loa I
> >> see that you want to also terminate CV at MIPs. CVs are fast and
> high
> >> bandwidth and blindly dumping them on a CPU or OAM processor  that
> >> may not be expecting them is like DoS attack.
> >>
> >>
> >>
> >> Regards,
> >> Shahram
> >>
> >>
> >> A TTL-expired OAM frame can simply be copied and forwarded to the
> >> out- MIPs where, if the frame is not intended for them, it can
> safely
> >> be dropped. In the P2MP case e.g. this needs to be done anyway, i.e.
> >> the implementation must behave in this exact way in either case. So
> >> there is at least one way to implement this at line rate without
> >> going back and changing a bunch of RFCs.
> >> >
> >> > Best,
> >> >
> >> > Rolf
> >> >
> >> >> Note all this has to be done in the fast-path now at full line
> >> >> rate (and hardware guys hate TLVs).  Before, the only thing the
> >> >> A.4 of
> >> >> example how about using one of the reserved bits in the ACH
> >> >> header.  This
> >> can
> >> >>    >> been for the ingress to look at TTL and if it is expired
> >> >> then send the
> >> >>    >> packet to OAM processor.
> >> >>    >
> >> >> 6371) "per-node MIPs (i.e., a single MIP per node in an
> >> >> unspecified location within the node)".
> >> >>    >
> >> >> E.g. we have a requirement to address a single out-MIP out of a
> >> >> set of out-MIPs on a P2MP branch point.  So this was part of the
> >> >>    >> out leaked OAM frames from upstream. But lets leave lookup
> >> >> of the MEPID
> >> >> assume a TLV wouldn't work for the exact reasons you do not like
> >> >> to have to do a second lookup, since it would require some
> >> >> parsing. All these constraints and the ones outlined in the
> >> >> document led to where we are. In a sense this is a non-spec since
> >> >> it rather rules out a number of things that seem like a good idea
> >> >> at first but then have a catch of some sort.
> >> >>    >
> >> >>    > Best,
> >> >>    >
> >> >>    > Rolf
> >> >>    >
> >> >>    >>
> >> >>    >>
> >> >>    >>
> >> >>    >> Regards,
> >> >>    >> Shahram
> >> >>    >>
> >> >>    >>
> >> >>    >>> But I will leave the chair to worry about process and try
> >> >> to address
> >> >>    >>> the technical points...
> >> >>    >>>
> >> >>    >>> currently identified, so the lookups being done at line
> >> >> rate today on
> >> >>    >>> interfaces. My assumption was that if the incoming
> >> >> interface can do
> >> >>    >>> Another possibility is that the full lookup could be done
> >> >> on the
> >> >> happy with the

---

From: Rolf Winter <[email-masked]>
Date: Tue, 4 Dec 2012 08:46:05 +0000

Hi,

quite some time ago we asked whether we could mandate TLV ordering (at least mandating one out of N TLVs to be the first in the OAM PDU) in order to allow efficient implementation in HW. This actually would be a good thing in this case. The responses we got weren't quite positive (which is actually quite a positive description of the responses we got) but I don't see that the GACh RFC is actually disallowing it. Still we would need to go back and make changes to a few RFCs. That was also something people weren't really happy about. Again, these were some of the constraints we worked with which led to what is on the table right now. We weren't blind to HW considerations, vice versa as you can see when you look at the appendix that was removed in the latest version of the document.

Best,

Rolf

> From: Puneet Agarwal [mailto:[email-masked]]
> Sent: Dienstag, 4. Dezember 2012 06:44
> Cc: Shahram Davari; Rolf Winter; [email-masked]
> Subject: Re: [mpls] working group last call ondraft-ietf-mpls-tp-mip-
> mep-map
> 
> Hi hideki,
> 
> Is the determination that the mip identifier is present in the same
> location  always in the pdu or is it variable (based on oam msg type)?
> 
> Thx
> 
> Puneet
> 
> 
>

---

From: <[email-masked]>
Date: Tue, 4 Dec 2012 17:56:07 +0900

Sharhram,

I didn't mean new requirement similar to Figure 7.
I do think that OAM packets must go through the normal forwarding engine
without bypass.

As Rolf said in other e-mail,
                         --------------------------
                        |                     -----|
                        |                    | MIP1|
                        |                 ->-|     |->----
                        |                |   | Out |
                        |                |   | i/f |
                        |                |    -----|
                        |-----           |    -----|
                        | MIP0|    ----  |   | MIP2|
                        |     |   |    |-    |     |
                 ----->-| In  |->-| FW |--->-| Out |->----
                        | i/f |   |    |-    | i/f |
                        |-----     ----  |    -----|
                        |                |    -----|
                        |                |   | MIP3|
                        |                |   |     |
                        |                 ->-| Out |->----
                        |                    | i/f |
                        |                     -----|
                         --------------------------
The OAM framework describes needs for identifing MIP1 or MIP2 or MIP3 in the P2MP tree individually.
Here, each out-MIP has different MIP ID.
If you don't need this machanism,
how does a out-MIP verify whether the OAM packet is sent to the out-MIP or not? 

Thanks,
Hideki Endo

---

From: "Shahram Davari" <[email-masked]>
Date: Tue, 4 Dec 2012 09:21:57 +0000

Rolf,

The job of OAM is to diagnose issues in the data plane. This means OAM has to take the same path as Data. Therefore on a P2MP LSP, OAM must be multicasted, similar to data. You can't just send to one MEP or MIP.

Here is what RFC6371 says:

P2MP Considerations
All the traffic sent over a P2MP transport path, including OAM packets generated by a MEP, is sent (multicast) from the root to all the leaves. As a consequence:

 o To send an OAM packet to all leaves, the source MEP can send a single OAM packet that will be delivered by the forwarding plane to all the leaves and processed by all the leaves. Hence, a single OAM packet can simultaneously instrument all the MEs in a P2MP MEG.

 o To send an OAM packet to a single leaf, the source MEP sends a single OAM packet that will be delivered by the forwarding plane to all the leaves but contains sufficient information to identify a target leaf, and therefore is processed only by the target leaf and can be silently discarded by the other leaves.

So although you can send a targeted OAM message to only one MEP or MIP, but the same message is going to be received by all MEPs or MIPs (with same TTL distance). The others just drop it.

So in the MIP example provided the ingress port of a router can't decide to which selective egress port it has to send the OAM packet to.  The only decision it can make is that an OAM message is or is not for itself (the in-MEP). Each egress port also decide individually whether the OAM is for itself or not, and if not just drops the packet.

So for sure the in-MEP doesn't need to look at MEPID to decide whether to terminate and send the OAM packet to CPU or forward normally. A single bit is enough for making such decision. Regarding out-MIPs, there are 2 options:

1) send OAM packet received with TTL expiry to CPU and let CPU look at MEPID and if not correct drop it

2) let the HW to look at MEPID and if correct, send the packet to CPU, else drop it.

I agree the 2nd option is more efficient, but is not practical, since locating arbitrarily located TLVs in various different OAM packet types such as BFD, LSP-Ping, etc is not practical.

Thx
Shahram

Regards,
Shahram

On Dec 4, 2012, at 12:34 AM, "Rolf Winter" <[email-masked]<mailto:[email-masked]>> wrote:

Shahram,

Best,

Rolf

-----Original Message-----
From: Shahram Davari [mailto:[email-masked]]
Sent: Dienstag, 4. Dezember 2012 01:53
To: [email-masked]<mailto:[email-masked]>
Cc: Rolf Winter; [email-masked]<mailto:[email-masked]>
Subject: RE: Re:Re: [mpls] working group last call on draft-ietf-mpls-
tp-mip-mep-map

Hi Hideki,

Thx
Shahram

-----Original Message-----
From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]]
Sent: Monday, December 03, 2012 4:48 PM
To: Shahram Davari
Cc: [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
Subject: Re:Re: [mpls] working group last call on draft-ietf-mpls-tp-
mip-mep-map

Hi Shahram,

Second, you wrote;
and this issue could NOT be resolved by even your solution that uses
ACH header to indicate in/out-MIP.
This means that the OAM processors at the other 98 ports lose those
capacities.

Thanks,
Hideki Endo

Rolf,

Ingress Port:

Egress Port:

Thanks
Shahram

-----Original Message-----
From: Shahram Davari [mailto:[email-masked]]
Sent: Montag, 3. Dezember 2012 16:27
To: Rolf Winter
Cc: Pablo Frank; [email-masked]<mailto:[email-masked]>
Subject: Re: [mpls] working group last call on

Hi Rolf,

Regards,
Shahram

On Dec 3, 2012, at 5:53 AM, "Rolf Winter" <[email-masked]<mailto:[email-masked]>>
wrote:

Hi,

fact already. Their answer to the problem is slightly different
though.

Best,

Rolf

-----Original Message-----
From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]] On
Behalf Of Shahram Davari
Sent: Mittwoch, 28. November 2012 18:46
To: Pablo Frank
Cc: [email-masked]<mailto:[email-masked]>
Subject: Re: [mpls] working group last call on
draft-ietf-mpls-tp-mip- mep-map

Pablo,

Thx
Shahram

Cc: [email-masked]<mailto:[email-masked]>

As I understand it, the logic proposed by this draft is as
follows:

At the ingress blade:

 Parse MIP-ID TLV

 Lookup MIP-ID

 IF MIP-is-egress, THEN

    forward normally (but note we must intercept it again on
egress)

 ELSE

    punt to OAM processor

At the egress blade:

 Parse MIP-ID TLV

 Lookup MIP-ID

 IF MIP-is-egress, THEN

    punt to OAM processor

 ELSE

    drop

Ideally, hardware could rely on the reserved bit to do the
initial

regards,

Pablo

On Mon, Nov 26, 2012 at 11:48 AM, Shahram Davari
<[email-masked]<mailto:[email-masked]>>
wrote:

Rolf,

I am sure you know that TLVs are not Hardware friendly. And
I
think you agree with me that this draft requires deep parsing of
all packets at line rate to get to the MIPID TLV.

Regards,
Shahram

-----Original Message-----
From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]]
On
Behalf Of Rolf Winter
Sent: Wednesday, November 21, 2012 12:13 PM
To: S. Davari; [email-masked]<mailto:[email-masked]>
Cc: [email-masked]<mailto:[email-masked]>
Subject: Re: [mpls] working group last call on
draft-ietf-mpls- tp-mip-mep-map

Hi,

Hi Adrian,

You are right and I should have sent these types of
comments
before
last call. I completely understand the procedure.

Yes (and no). While I assume likely MIP functionality will
be

Also, I think "before this draft" is not quite accurate in
that is suggests there is no per-interface MIP addressing
possible
as of
now.
Take RFC 6426. In practice this is where part of the problem lies.
We
cannot really go back and change all this. There are other
constraints.
E.g. we have a requirement to address a single out-MIP out of a
set of out-MIPs on a P2MP branch point.  So this was part of the
constraints we worked with.

the OAM packet to indicate whether it should be taken out

Best,

Rolf

Regards,
Shahram

On Nov 21, 2012, at 1:16 AM, "Adrian Farrel"
<[email-masked]<mailto:[email-masked]>>
wrote:

<co-author mode>

Hi Shahram,

Identifying whether to terminate an OAM packet and
process
it
in In-
MIP vs.
Out-
MIP requires line rate lookup, otherwise the OAM packet
will not
take
the same path as data packets.  Therefore any MIP
identifier that is
proposed in this
draft
requires one extra lookup and therefore adds
significantly
to
cost.

rate) to determine whether they are OAM and targeted at
the
interface.

Perhaps a
similar method to Ethernet MDL/MEL (Maintenance Domain
Level) may be
used that requires only 3 bits and achieves the same
result.

Perhaps it could.

This leaves me with the trade-off of enabling a *simpler*
lookup on
the outgoing interfaces versus doing identical lookups on
both
interfaces. My assumption was that if the incoming
interface can do
the lookup at line rate, it is not hard to perform the
same
lookup on
the outgoing interface. Furthermore, there is a reduction
in
complexity by having fewer things to look up.

Thanks,
Adrian
-----Original Message-----
From: [email-masked]<mailto:[email-masked]> [mailto:mpls-
[email-masked]<mailto:[email-masked]>]
On
Behalf
Of Adrian Farrel
Sent: Monday, November 19, 2012 8:45 AM
To: 't.petch'; 'Loa Andersson'; [email-masked]<mailto:[email-masked]>
Cc: [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
<mailto:[email-masked]> ;
draft-ietf-mpls-tp-mip-
[email-masked]<mailto:[email-masked]>
Subject: Re: [mpls] working group last call on
draft-ietf-mpls-tp-mip-mep-map

-----Original Message-----
From: t.petch [mailto:[email-masked]]
Sent: 19 November 2012 12:38
To: Loa Andersson; [email-masked]<mailto:[email-masked]>
Cc: [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
<mailto:[email-masked]> ; MPLS-TP ad
hoc
team;
[email-masked]<mailto:[email-masked]>
Subject: Re: [mpls] working group last call on
draft-ietf-mpls-tp-mip-mep-map

After getting to section 6 and its features
(requirements!), I find
myself underwhelmed; is that it?  Well, I suppose so, it
is
Informational and not Standards Track.

Title
Handling MPLS-TP OAM Packets Targeted at Internal MIPs
[Handling
MPLS-TP OAM Packets Targeted at Interface MIPs seems a
more
informative statement unless and until you get to the
definition of
Internal in s3; and s6, which is the crux of the
document
says The
preferred solution to per-interface MIP message handling
is
presented in this section]

s1

s4

s5

s6
The appendix of this document contains a
few solutions that the authors have discarded which
have
been
left in
the document for informational purposes.
[not any more they haven't!]

The identification information indside [The
identification
information inside ]

reserved MIP address

Tom Petch

----- Original Message -----
From: "Loa Andersson" <[email-masked]<mailto:[email-masked]>>
To: <[email-masked]<mailto:[email-masked]>>
Cc: <[email-masked]<mailto:[email-masked]>>; <mpls-
[email-masked]<mailto:[email-masked]>>;
"MPLS-TP ad hoc team" <[email-masked]<mailto:[email-masked]>>;
<[email-masked]<mailto:[email-masked]>>
Sent: Wednesday, November 14, 2012 3:16 PM

Working Group,

Please send your comments to the mpls working group
mailing
list
([email-masked]<mailto:[email-masked]>).

/Loa
for the wg co-chairs

_______________________________________________
mpls mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/mpls

_______________________________________________
mpls mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/mpls
_______________________________________________
mpls mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/mpls

NEC Europe Limited | Registered Office: NEC House, 1
Victoria
Road, London W3 6BL | Registered in England 2832014
_______________________________________________
mpls mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/mpls

  _______________________________________________
  mpls mailing list
  [email-masked]<mailto:[email-masked]>
  https://www.ietf.org/mailman/listinfo/mpls

_______________________________________________
mpls mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/mpls

---

From: "S. Davari" <[email-masked]>
Date: Tue, 4 Dec 2012 01:28:52 -0800

Hi Rolf,

For in-MIP a single bit is enough. However for out-MIP the CPU has to drop the unwanted OAM. Not efficient but the system still works. Remember this happens only in a corner case of p2mp MPLS with multiple out-MIP on the same router, and when only root wants to talk to one of the leaves. 

That's why I am suggesting to have a single bit in addition to the MEPID.

Regards,
Shahram

On Dec 4, 2012, at 12:33 AM, Rolf Winter <[email-masked]> wrote:

>>>>>> <[email-masked]>

---

From: "Shahram Davari" <[email-masked]>
Date: Tue, 4 Dec 2012 09:31:05 +0000

How about the G-ACH TLV that immediately follows ACH. 

Regards,
Shahram

---

From: "Shahram Davari" <[email-masked]>
Date: Tue, 4 Dec 2012 09:32:25 +0000

I didn't say I don't need MIPID. I said MIPID lookup can happen in CPU.

Regards,
Shahram

---

From: Loa Andersson <[email-masked]>
Date: Tue, 04 Dec 2012 11:13:39 +0100

Working Group,

since we have a discussion relating to to comments in this working
group last call, the chairs will leave the wg last open until the
end of this week.

/Loa
for the wg co-chairs

On 2012-11-14 16:16, Loa Andersson wrote:
> Please send your comments to the mpls working group mailing
> list ([email-masked]).
>

--

---

From: Stewart Bryant <[email-masked]>
Date: Tue, 04 Dec 2012 10:27:41 +0000

No one liked those (for h/w reasons), so we never used them for any 
first generation OAM applications. If you look at the registry you will 
see that none have been defined.

Stewart

-- 
For corporate legal information go to:

http://www.cisco.com/web/about/doing_business/legal/cri/index.html

---

From: Rolf Winter <[email-masked]>
Date: Tue, 4 Dec 2012 11:08:58 +0000

Right, but the reason was that the TLV can be anywhere, i.e. give more than a single TLV in an OAM frame, there is no guarantee that the TLV will be the first, second, third... Even if you guarantee that the TLV will be the say second TLV, there is no guarantee that the first will be of constant length or always the same and so forth. This requires parsing of TLVs which cannot practically be done in HW at line rate. I understand Shahram to ask for an ID TLV to be required to always be the first TLV independent of the number of TLVs in an OAM frame. Reasons against this that I heard include: "we have never done that and will never do it", "this defeats the purpose of TLVs which are designed with this flexibility", "this is a HW problem not a protocol issue", "what if another TLV comes up that wants to be first too" and others.

Best,

Rolf 

> Stewart Bryant
> Sent: Dienstag, 4. Dezember 2012 11:28
> To: [email-masked]
> >> quite some time ago we asked whether we could mandate TLV ordering
> (at least mandating one out of N TLVs to be the first in the OAM PDU)
> in order to allow efficient implementation in HW. This actually would
> be a good thing in this case. The responses we got weren't quite
> positive (which is actually quite a positive description of the
> responses we got) but I don't see that the GACh RFC is actually
> disallowing it. Still we would need to go back and make changes to a
> few RFCs. That was also something people weren't really happy about.
> Again, these were some of the constraints we worked with which led to
> what is on the table right now. We weren't blind to HW considerations,
> vice versa as you can see when you look at the appendix that was
> removed in the latest version of the document.
> >>
> >> Best,
> >>
> >> Rolf
> >>
> >>> Subject: Re: [mpls] working group last call
> >>> ondraft-ietf-mpls-tp-mip- mep-map
> >>>
> >>> Hi hideki,
> >>>

---

From: Rolf Winter <[email-masked]>
Date: Tue, 4 Dec 2012 11:40:09 +0000

Hi Sharam,

that is not quite accurate. It will happen at all nodes at the same TTL distance because also there the TTL will expire even if no out-MIP is addressed there.

Best,

Rolf

> From: S. Davari [mailto:[email-masked]]
> Sent: Dienstag, 4. Dezember 2012 10:29
> To: Rolf Winter
> Cc: Shahram Davari; [email-masked]; [email-masked]
> For in-MIP a single bit is enough. However for out-MIP the CPU has to
> drop the unwanted OAM. Not efficient but the system still works.
> Remember this happens only in a corner case of p2mp MPLS with multiple
> out-MIP on the same router, and when only root wants to talk to one of
> the leaves.
> 
> > what if it is configured and you only want to talk to one out of all
> the out-MIPs. I guess we can all craft examples where we can make our
> point. A single bit simply does not guarantee you that the local CPU
> does not have to look at the OAM frame to finally discard it.
> >
> > Best,
> >
> > Rolf
> >
> >> Subject: RE: Re:Re: [mpls] working group last call on
> >> I think you need to look at my p-code. F a MIP is not configured in
> >> the Egress port, then that egress port won't sent the OAM packet to
> >> its processor and drops it. So there is no issue with my proposed
> method.
> >>
> >> Thx
> >> Shahram
> >>
> >> MIPs 3. data-plane loopback configuration at a MIP 4. diagnostic
> >> tests Here, CV means On-demand CV. You may misunderstand as
> Proactive CV.
> >>
> >> Second, you wrote;
> >> these MIPs. Now assume OAM packet (P) is meant for out-MIP (MIPID
> >> =port B). In your example, you are saying send a copy of the P to
> the
> >> CPU/Processor on Port A, and send a copy also to CPU/Processor on
> >> Port B. Port A CPU will drop the packet since the MIP-ID is not A.
> >> The issue is that each CPU/processor has limited resources.  By
> >> sending all OAM MIP packets to both processor you are losing 1/2 of
> >> the capacity of each processor.  The practical solution is to have a
> >> simple indicator in the packet header that this OAM packet is meant
> >> for Out-MIP. Then port A just switches the OAM packet to Port B, and
> >> Port B terminates and sends it to its CPU/processor.
> >>>
> >> chip from Port A and is sent to ports B, C, D.  Also assume that
> >> there is In-MIP on port A and out-MIPs of ports B, C (not D).  Now
> >> assume a Multicast OAM packet is  meant for out-MIPs (B, C). In such
> >> case the OAM packet should not be sent to port A CPU/Processor. It
> is
> >> therefore multicast to ports B, C, D. Ports B, C send the OAM packet
> to their CPU.
> >> take an appropriate action and in the P2MP case this will always be
> >> the case since there are 2 or more out MIPs.
> >>>
> >>>> in- MIP processor is not much. But from your previous email to Loa
> >>>> I see that you want to also terminate CV at MIPs. CVs are fast and
> >> high
> >>>>>>>>>>> o  CV between a MEP and a MIP [expand CV on first use]
> >>>>>>>>>>>
> >>>>>>>>>>> s5
> >>>>>>>>>>> The appendix of this document contains a few solutions that
> >>>>>>>>>>> the authors have discarded which
> >> have
> >>>>>> been
> >>>>>>>> left in
> >>>>>>>>>>> The node itself is addresses [The node itself is addressed]
> >>>>>>>>>>>
> >>>>>>>>>>> MIP identifiers are not know [MIP identifiers are not
> known]
> >>>>>>>>>>>
> >>>>>>>>>>> reserved MIP address

---

From: <[email-masked]>
Date: Tue, 4 Dec 2012 20:49:22 +0900

Shahram,

You replied to Rolf in other mail;
"For in-MIP a single bit is enough. However for out-MIP
the CPU has to drop the unwanted OAM. Not efficient but
the system still works. "
Yes, that's right.
This was my point.

Again, even if your solution using ACH header is applied,
it can reduce OAM packets only for in-MIP, which means only 1/101 effectiveness
in the case of P2MP tree having 100 leafs.

Thanks,
Hideki Endo

---

From: "Shahram Davari" <[email-masked]>
Date: Tue, 4 Dec 2012 14:53:53 +0000

That is the whole point, that TLVs are not hardware friendly. But at least ACH TLV is at a fixed location.

Regards,
Shahram

On Dec 4, 2012, at 2:27 AM, "Stewart Bryant" <[email-masked]> wrote:

> No one liked those (for h/w reasons), so we never used them for any first generation OAM applications. If you look at the registry you will see that none have been defined.
> 
> Stewart
>

---

From: "S. Davari" <[email-masked]>
Date: Tue, 4 Dec 2012 06:56:15 -0800

Correct.

Regards,
Shahram

---

From: "Shahram Davari" <[email-masked]>
Date: Tue, 4 Dec 2012 15:05:02 +0000

Hideki,

The whole point of this draft has been to ensure OAM packets addressed to out-MIP reach to the egress ports and are not filtered by in-MIP. And a single bit does that work. Efficiency is an internal matter to the box:

" This document describes a way of forming OAM messages so that they can be targeted at incoming MIPs and outgoing MIPs, forwarded correctly through the "switch fabric", and handled efficiently in node implementations where there is no distinction between the incoming and outgoing MIP."

It makes me wonder Have you implemented this feature or just doing a research exercise? I as a chip architect have hard time implementing this feature. This is a fact, and you can choose to ignore it.

Regards,
Shahram

---

From: "Shahram Davari" <[email-masked]>
Date: Tue, 4 Dec 2012 22:57:12 +0000

Hi MPLS WG,

I would like to summarize our discussion and let the WG decide.

1) The draft requires MIPID to be used by the HW in the Ingress port to select whether an OAM packet should be sent to CPU for processing or be forwarded to egress port(s). 

2) The draft requires MIPID to be used by the HW in Egress port to select whether an OAM packet should be sent to CPU for processing or dropped.

3) The draft solution applies to P2P and P2MP MPLS, and is efficient, meaning that it sends OAM packets only to the CPUs that need to be used for processing. And does not overload CPUs that don't need to receive an OAM packet.

4) The draft solution requires parsing the OAM packets to get to the MIPID TLV. There are many types of OAM messages with different format (BFD, LSP-Ping, APS, RFC6374, etc.) and the TLV can be anywhere in the packet. This makes the draft solution not practical to implement in HW, and therefore not widely deployed.

------------------------------------------------

5) My proposal  is to use a single bit in the ACH to indicate whether the OAM packet is for in-MIP or out-MIP.  This single bit is used by HW in the ingress port to select whether an OAM packet should be sent to CPU for processing or be forwarded to egress port(s). When packet is sent to CPU, then the MIPID can be used by CPU to double check that it has received the expected OAM packet.

6) My proposal is for an egress port to send the OAM packet to CPU, if a MIP is configured on that port, (otherwise drop it in HW. When packet is sent to CPU, then the MIPID can be used by CPU to double check that it has received the expected OAM packet.

7) My solution applies to P2P MPLS (which is more than  95% of the LSPs, PWs) efficiently, meaning that it sends OAM packets only to the CPUs that need to be used for processing. And does not overload CPUs that don't need to receive an OAM packet.

8) My solution applies to P2MP MPLS (which is less than  5% of the LSPs, PWs) but NOT efficiently, meaning that it sends OAM packets to the CPUs that don't need to process the OAM and overloads some CPUs that don't need to receive an OAM packet.

The question in front of the WG is which solution to pick. My argument is that although the draft solution is a theoretically a perfect solution but is not practical and may never get implemented widely.  While my solution is perfect for more than 95% of the LSPs (P2P LSPs) and is in-efficient for less than 5% of the LSPs (P2MP LSPs). However it is simple and trivial to implement in HW.

You choose !

This is my last argument email justifying my proposed solution.

Thanks,
Shahram

---

From: Gregory Mirsky <[email-masked]>
Date: Tue, 4 Dec 2012 23:15:16 +0000

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).
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.

        Regards,
                Greg

-----Original Message-----
From: Rolf Winter [mailto:[email-masked]]
Sent: Tuesday, December 04, 2012 12:00 AM
To: Gregory Mirsky; [email-masked]
Subject: RE: working group last call on draft-ietf-mpls-tp-mip-mep-map

Hi Greg,

Best,

Rolf

> 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.
> > > Subject: Re: working group last call on

---

From: <[email-masked]>
Date: Wed, 5 Dec 2012 09:57:53 +0900

Shahram,

I think that your summarize is misleading.
Our draft does NOT require MIP ID to be parse by the HW. It depends on your implementation.
As Rolf replied to you, we have several options, i.e., a TTL-expired OAM frame can simply be
copied and forwarded to the out-MIPs where, if the frame is not intended for them, 
it can safely be dropped. 
Although you have concern about losing some resources of an OAM processor due to unnecessary
OAM packets, even your proposal using ACH header have low effectiveness in case of P2MP tree
having many leaves as you said below and I pointed out in other email.

Thanks,
Hideki Endo

---

From: <[email-masked]>
Date: Wed, 5 Dec 2012 11:08:30 +0900

Shahram,

Yes, this issue is an internal matter to the box as you said,
and I have some experiences to implement this feature in commercial products.
Therefore, I initially had same concern as you. 
We, the authors of this draft, requested the fixed location of MIP ID TLV or using ACH header.
However, as Rolf sent to you, in that case, we would need to go back and make changes to a few RFCs. 
That was also something people weren't really happy about.

And, I have understood this issue can be resolved by an optimized implementation.
As Rolf sent, we need this feature for some functions as below;
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
In these functions, 1(On-demand CV) and 2(traceroute) would be very slow rate protocol.
Therefor, it is possible for OAM processor/CPU to parse TLVs.
On the other hand, 3(data-plane loopback) and 4(diagnostic tests) would be very fast rate protocol.
It means that these function should be implemented in specific HW with capacity to parse MIP ID TLV
at line rate.

If your proposal using ACH header is applied,
the specific HW parsing MIP ID TLV at line rate is required for these functions, right?

Thanks,
Hideki Endo

---

From: Rolf Winter <[email-masked]>
Date: Wed, 5 Dec 2012 08:10:11 +0000

Hi Shahram,

thanks for the summary. It is not 100% accurate but I have explained before how we believe this can work so I won't repeat myself again. "Your" solution is essentially what we had considered before and dismissed for the reasons that I have also stated on the list before (some of these reasons have been documented in the penultimate version of the draft which have only recently been removed). Changing the document would only be a matter of using some old text and put it back in. We would also need to make this a standards track document which (at least) updates 5586. But this is just a procedural note. But you are absolutely correct that the WG need to decide on this. It would be nice to see other people comment. 

Best,

Rolf

> Sent: Dienstag, 4. Dezember 2012 23:57
> To: [email-masked]
> Subject: Re: [mpls] working group lastcallondraft-ietf-mpls-tp-mip-mep-
> map
> 
>  Hi MPLS WG,
> 
> 1) The draft requires MIPID to be used by the HW in the Ingress port to
> select whether an OAM packet should be sent to CPU for processing or be
> forwarded to egress port(s).
> 
> 2) The draft requires MIPID to be used by the HW in Egress port to
> select whether an OAM packet should be sent to CPU for processing or
> dropped.
> 
> 3) The draft solution applies to P2P and P2MP MPLS, and is efficient,
> meaning that it sends OAM packets only to the CPUs that need to be used
> for processing. And does not overload CPUs that don't need to receive
> an OAM packet.
> 
> 4) The draft solution requires parsing the OAM packets to get to the
> MIPID TLV. There are many types of OAM messages with different format
> (BFD, LSP-Ping, APS, RFC6374, etc.) and the TLV can be anywhere in the
> packet. This makes the draft solution not practical to implement in HW,
> and therefore not widely deployed.
> 
> 5) My proposal  is to use a single bit in the ACH to indicate whether
> the OAM packet is for in-MIP or out-MIP.  This single bit is used by HW
> in the ingress port to select whether an OAM packet should be sent to
> CPU for processing or be forwarded to egress port(s). When packet is
> sent to CPU, then the MIPID can be used by CPU to double check that it
> has received the expected OAM packet.
> 
> 6) My proposal is for an egress port to send the OAM packet to CPU, if
> a MIP is configured on that port, (otherwise drop it in HW. When packet
> is sent to CPU, then the MIPID can be used by CPU to double check that
> it has received the expected OAM packet.
> 
> 7) My solution applies to P2P MPLS (which is more than  95% of the LSPs,
> PWs) efficiently, meaning that it sends OAM packets only to the CPUs
> that need to be used for processing. And does not overload CPUs that
> don't need to receive an OAM packet.
> 
> 8) My solution applies to P2MP MPLS (which is less than  5% of the LSPs,
> PWs) but NOT efficiently, meaning that it sends OAM packets to the CPUs
> that don't need to process the OAM and overloads some CPUs that don't
> need to receive an OAM packet.
> 
> 
> The question in front of the WG is which solution to pick. My argument
> is that although the draft solution is a theoretically a perfect
> solution but is not practical and may never get implemented widely.
> While my solution is perfect for more than 95% of the LSPs (P2P LSPs)
> and is in-efficient for less than 5% of the LSPs (P2MP LSPs). However
> it is simple and trivial to implement in HW.
> 
> You choose !
>

---

From: Rolf Winter <[email-masked]>
Date: Wed, 5 Dec 2012 08:23:15 +0000

Hi Greg,

see inline.

> 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).

> you might not be convinced but there are operators that have asked for
> this functionality based on operational experience.
> 
> 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:
> 
> > <mailto:[email-masked]> <mailto:[email-masked]
> > <mailto:[email-masked]> > ]
> > > <mailto:[email-masked]>
> > > <mailto:[email-masked]
> > > <mailto:[email-masked]> > ]
> > > Cc: [email-masked]; [email-masked]; draft-
> ietf-
> > > [email-masked]
> > > <mailto:[email-masked]> <mailto:[email-masked]
> > > <mailto:[email-masked]> > ] On Behalf Of Rolf Winter
> > > Cc: [email-masked]; [email-masked]; draft-
> ietf-
> > > [email-masked]
> > > > From: Loa Andersson [mailto:[email-masked] <mailto:[email-masked]>
> > > > <mailto:[email-masked] <mailto:[email-masked]> > ]
> > > <https://www.ietf.org/mailman/listinfo/mpls
> > > <https://www.ietf.org/mailman/listinfo/mpls> >
> >
>

---

From: Gregory Mirsky <[email-masked]>
Date: Wed, 5 Dec 2012 23:41:30 +0000

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

        Regards,
                Greg

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

Hi Greg,

see inline.

> different SPMEs. If such interpretation is acceptable, then we can
> have multiple MIPs but only one MIP per MEG Level (even though no such

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.

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.

> 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:
>
> > 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
> > > Subject: RE: working group last call on
> > > per LSP/PW on an LSR/PE node. If that is the case, then there
> > > might
> > be

---

From: <[email-masked]>
Date: Thu, 6 Dec 2012 00:50:16 +0100

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

> Sent: Wednesday, December 05, 2012 5:23 PM
> 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).
>
> 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
> >

---

From: <[email-masked]>
Date: Thu, 6 Dec 2012 10:40:56 +0900

Shahram and Rolf,

It is seemed to me that we will reach same conclusions.

(1)Shahram's proposal that uses AHC header for identifing in/out-MIP is usuful for a P2P path,
but few effectiveness for a P2MP path.

(2)Even if Shahram's proposal is applied, we need to parse MIP ID TLV at line rate
for fast rate protocol such as diagnostic function.

So far, do you agree?
If yes, we have a difficulty to implement fast rate protocols in HW.
As Rolf sent in other email, we need to consider fixed location of ID TLV.
However, we don't need to reconsider all of OAM functions.
I mean we need to consider fixed location ID TLV only for fast rate protocol functions.

My proposal is that we add some texts such as
"The hardware friendly solution such as fixed location of ID TLV should be considered,
 if the OAM protocol requiring fast rate (e.g. line rate) processing will be developed."

Thanks,
Hideki Endo

---

From: Rolf Winter <[email-masked]>
Date: Thu, 6 Dec 2012 16:50:39 +0000

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

> Sent: Donnerstag, 6. Dezember 2012 00:42
> To: Rolf Winter; [email-masked]
> 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.
> 
> 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).
> 
> 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
> >
> > > <mailto:[email-masked]> > <mailto:[email-masked]
> > > <mailto:[email-masked]> > > ]
> > > > <mailto:[email-masked]> >
> > > > <mailto:[email-masked]> > > ]
> > > > Do you envision that multiple MIPs, both in- and out-, required
> to
> > be
> > > > <mailto:[email-masked]> > <mailto:[email-masked]
> > > > <mailto:[email-masked]> > > ] On Behalf Of Rolf Winter
> tp-
> > > mip-
> > > > > <mailto:[email-masked] <mailto:[email-masked]> > <mailto:[email-masked]
> > > > > <mailto:[email-masked]>  <mailto:[email-masked] <mailto:[email-masked]> > > ]
> > > > > > Please send both technical comments, and if you are happy
> with
> > > the
> > > > <https://www.ietf.org/mailman/listinfo/mpls> > >
> > >
> >
>

---

From: Loa Andersson <[email-masked]>
Date: Fri, 14 Dec 2012 19:45:29 +0100

Working group,

this working group last call is closed.

The working group chairs has followed the discussion on the mailing
list closely. We want to go forward with the draft-ietf-mpls-tp-mip-mep-map,
but we also believe that the that it should be turned into a more
framework style of document.

We believe that OAM messages carrying a MIP or MEP identifier in the
message header (before the payload OAM protocol fields) should be
assigned new ACh Type values rather than being variations of existing
OAM messages that does not currently include such identifiers.

The identifiers carried in those messages, regardless of how we chose
to encode them, must be found at well know places and have well known
format.

While the document has been prepared it has gone through and
excluded some solutions, this is fine. As this is made into a
framework document, it does not need to go into as much detail of
the proposed solution. We will need protocol specification for
the ACh types and we should not constrain the protocol specifications
unnecessarily.

As this is made into a framework document, it does not need to go into
as much detail of the proposed solution.

This document is therefore returned for further working group work
and a new WG last call will be held sometime in the future when the
document is ready.

/Loa
for the mpls wg chairs

--