Subject: [mpls] IPR poll on draft-ietf-mpls-tp-mip-mep-map

From: Loa Andersson <[email-masked]>
Date: Tue, 06 Nov 2012 09:50:48 +0100

Working Group,

the authors of draft-ietf-mpls-tp-mip-mep-map have indicated that the
draft is ready for working group last call.

Before we start the working group last call an IPT poll is needed.

This is to start the IPR Poll.

Are you aware of any IPR that applies to draft-ietf-mpls-tp-mip-mep-map?

If so, has this IPR been disclosed in compliance with IETF IPR rules
(see RFCs 3979, 4879, 3669 and 5378 for more details).

If you are listed as a document author or contributor please respond to
this email regardless of whether or not you are aware of any relevant
IPR. The response needs to be sent to the MPLS wg mailing list. The 
documents will not advance to the next stage until a response
has been received from each author and contributor.

If you are on the MPLS WG email list but are not listed as an author or
contributor, then please explicitly respond only if you are aware of any
IPR that has not yet been disclosed in conformance with IETF rules.

Thanks, Loa
(as MPLS WG co-chair)

-- 

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: "Adrian Farrel" <[email-masked]>
Date: Tue, 6 Nov 2012 12:57:16 -0000

Hi,

I started this work as draft-farrel-mpls-tp-mip-mep-map on 11/9/2009

I do not hold any IPR related to anything.
I am unaware of any IPR held by others related to this draft.

Adrian

> -----Original Message-----
> From: Loa Andersson [mailto:[email-masked]]
> Sent: 06 November 2012 08:51
> To: [email-masked]; [email-masked]
> Cc: [email-masked]; Martin Vigoureux; MPLS-TP ad hoc team
> Subject: IPR poll on draft-ietf-mpls-tp-mip-mep-map
> 
> Working Group,
>

---

From: <[email-masked]>
Date: Tue, 6 Nov 2012 16:46:38 +0100

Hi,

> Sent: Tuesday, November 06, 2012 3:51 AM
[MP:] No.

Regards,
Manuel

---

From: Gregory Mirsky <[email-masked]>
Date: Tue, 6 Nov 2012 19:27:00 +0000

Dear Authors, Editors, WG chairs, et al.,
Please kindly consider my notes below as WG LC on draft-ietf-mpls-tp-mip-mep-map-03:
*       Section 3
*       Note that RFC 6371 refers to per-interface MEP as Up and Down (Section 3.3, p.15) whereas in this document per-interface MIPs referred as in- and out-. I think that both types of Maintanence Points (MP) must use one terminology in regard to location in per-interface model.
*       Section 4.
*       I believe that CV operation can be performed only between MEPs, not between MEP and MIP, as stated in the document.
      * I think that "diagnostic tests" is bit too open-ended and would suggest considering making this bullet more specific or removing it altogether.

        Regards,
                Greg

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Loa Andersson
Sent: Tuesday, November 06, 2012 12:51 AM
To: [email-masked]; [email-masked]
Cc: [email-masked]; MPLS-TP ad hoc team
Subject: [mpls] IPR poll on draft-ietf-mpls-tp-mip-mep-map

Working Group,

the authors of draft-ietf-mpls-tp-mip-mep-map have indicated that the draft is ready for working group last call.

If so, has this IPR been disclosed in compliance with IETF IPR rules (see RFCs 3979, 4879, 3669 and 5378 for more details).

If you are listed as a document author or contributor please respond to this email regardless of whether or not you are aware of any relevant IPR. The response needs to be sent to the MPLS wg mailing list. The documents will not advance to the next stage until a response has been received from each author and contributor.

If you are on the MPLS WG email list but are not listed as an author or contributor, then please explicitly respond only if you are aware of any IPR that has not yet been disclosed in conformance with IETF rules.

Thanks, Loa
(as MPLS WG co-chair)

--

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 _______________________________________________
mpls mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/mpls

---

From: Rolf Winter <[email-masked]>
Date: Tue, 6 Nov 2012 22:51:54 +0000

Hi Greg,

thanks for the comments. Some relies inline.

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

> *	Section 3
> 
> *	Note that RFC 6371 refers to per-interface MEP as Up and Down
> (Section 3.3, p.15) whereas in this document per-interface MIPs
> referred as in- and out-. I think that both types of Maintanence Points
> (MP) must use one terminology in regard to location in per-interface
> model.

I see your point. But I think you could argue this two ways. I personally liked in- and out-MIP as it illustrates the point of MIPs being transit points and therefore somewhat different in nature. RFC 6371 does talk about per-interface MIPs but does not name them in any way, which I found strange at first. Can someone involved in the ITU-T (or IEEE for that matter) maybe comment on terminology here. Up/Down MEP is a commonly used term, but how about per interface-MIPs?

> 
> *	Section 4.
> 
> *	I believe that CV operation can be performed only between MEPs,
> not between MEP and MIP, as stated in the document.

Would qualifying it as on-demand CV work for you?

> *	I think that "diagnostic tests" is bit too open-ended and would
> suggest considering making this bullet more specific or removing it
> altogether.

This is a term taken from 5860 - the OAM requirements. I agree that a number of more specific OAM functions fall into the category of diagnostic test, but using the term should be fine give that it has been used already in RFCs. Would you agree?

Thanks again,

Rolf

> From: [email-masked] [mailto:[email-masked] <mailto:mpls-
> [email-masked]> ] On Behalf Of Loa Andersson
> documents will not advance to the next stage until a response has been
> received from each author and contributor.
> 
> contributor, then please explicitly respond only if you are aware of
> any IPR that has not yet been disclosed in conformance with IETF rules.
> 
> 
> Thanks, Loa
> (as MPLS WG co-chair)
> 
> 
> --
> 
> 
> _______________________________________________
> mpls mailing list
> [email-masked]
> <https://www.ietf.org/mailman/listinfo/mpls>
>

---

From: Gregory Mirsky <[email-masked]>
Date: Tue, 6 Nov 2012 23:22:24 +0000

Hi Rolf,
802.1ag differentiates as Up or Down both MEP and MIP Half Function (MHF). I assume that Y.1731 is not different (not much different).

        Regards,
                Greg

-----Original Message-----
From: Rolf Winter [mailto:[email-masked]]
Sent: Tuesday, November 06, 2012 2:52 PM
To: Gregory Mirsky; Loa Andersson; [email-masked]; [email-masked]
Cc: [email-masked]
Subject: RE: [mpls] IPR poll on draft-ietf-mpls-tp-mip-mep-map

Hi Greg,

Thanks again,

Rolf

> From: [email-masked] [mailto:[email-masked]
> <mailto:mpls- [email-masked]> ] On Behalf Of Loa Andersson
> If you are listed as a document author or contributor please respond
> to this email regardless of whether or not you are aware of any
> relevant IPR. The response needs to be sent to the MPLS wg mailing
> list. The documents will not advance to the next stage until a
> response has been received from each author and contributor.
>
> If you are on the MPLS WG email list but are not listed as an author
> or contributor, then please explicitly respond only if you are aware
> of any IPR that has not yet been disclosed in conformance with IETF rules.
>
>
> Thanks, Loa
> (as MPLS WG co-chair)
>
>
> --
>
>

---

From: Rolf Winter <[email-masked]>
Date: Tue, 6 Nov 2012 23:25:56 +0000

Hi Greg,

thanks. What's with the other two points. Would you accept these as resolutions/answers to your comments?

Best,

Rolf

> From: Gregory Mirsky [mailto:[email-masked]]
> Sent: Dienstag, 6. November 2012 18:22
> To: Rolf Winter; Loa Andersson; [email-masked]; draft-ietf-mpls-tp-mip-
> [email-masked]
> 802.1ag differentiates as Up or Down both MEP and MIP Half Function
> (MHF). I assume that Y.1731 is not different (not much different).
> 
>         Regards,
>                 Greg
> 
> From: Rolf Winter [mailto:[email-masked]
> <mailto:[email-masked]> ]
> NEC Europe Limited | Registered Office: NEC House, 1 Victoria Road,
> London W3 6BL | Registered in England 2832014
> 
> 
> > *     Section 3
> >
> I see your point. But I think you could argue this two ways. I
> personally liked in- and out-MIP as it illustrates the point of MIPs
> being transit points and therefore somewhat different in nature. RFC
> 6371 does talk about per-interface MIPs but does not name them in any
> way, which I found strange at first. Can someone involved in the ITU-T
> (or IEEE for that matter) maybe comment on terminology here. Up/Down
> MEP is a commonly used term, but how about per interface-MIPs?
> 
> >
> > *     Section 4.
> >
> This is a term taken from 5860 - the OAM requirements. I agree that a
> number of more specific OAM functions fall into the category of
> diagnostic test, but using the term should be fine give that it has
> been used already in RFCs. Would you agree?
> 
> Thanks again,
> 
> Rolf
> 
> >
> >
> >         Regards,
> >                 Greg
> >
> > <mailto:[email-masked]>
> > <mailto:mpls- [email-masked] <mailto:mpls- [email-masked]> > ] On
> > Behalf Of Loa Andersson
> > <https://www.ietf.org/mailman/listinfo/mpls
> > <https://www.ietf.org/mailman/listinfo/mpls> >
> >
>

---

From: Gregory Mirsky <[email-masked]>
Date: Wed, 7 Nov 2012 05:04:06 +0000

Hi Rolf,
Apologies, missed.
*       I think that I understand what you mean by "CV on-demand" but CC/CV/RDI can not act in on-demand mode and LSP Ping is not the only on-demand MEP to MIP OAM mechanism. I feel that "CV on-demand" can not be attributed to LB;
   *    I'd rather not refer to ambigious item. If one wants to perform PM to a MIP, that, IMHO, will be done with by SPME means, not by directly addressing MIP. Frankly, I can not come up with any other use case and thus propose to remove reference to "diagnostic tests".

        Regards,
                Greg

-----Original Message-----
From: Rolf Winter [mailto:[email-masked]]
Sent: Tuesday, November 06, 2012 3:26 PM
To: Gregory Mirsky; Loa Andersson; [email-masked]; [email-masked]
Subject: RE: [mpls] IPR poll on draft-ietf-mpls-tp-mip-mep-map

Hi Greg,

Best,

Rolf

> > <mailto:mpls- [email-masked] <mailto:mpls- [email-masked]> > ]
> > On Behalf Of Loa Andersson
> > the authors of draft-ietf-mpls-tp-mip-mep-map have indicated that
> > the draft is ready for working group last call.
> >

---

From: Yoshinori Koike <[email-masked]>
Date: Wed, 07 Nov 2012 17:34:10 +0900

Hi,

 >Are you aware of any IPR that applies to draft-ietf-mpls-tp-mip-mep-map?

No. I'm not aware of any IPR related to this draft.

Regards,

Yoshinori

-- 
Yoshinori Koike
[email-masked]

---

From: Pablo Frank <[email-masked]>
Date: Wed, 7 Nov 2012 12:31:53 -0500

Hi Rolf,

To me, the concepts of up/down MEP/MIP vs. node/interface-MEP/MIPs are
orthogonal concepts.  In 802.1q, the up/down direction of MP is in
reference to the direction (in the baggy-pants model) in which it sends and
consumes frames (i.e. the "active" side). For example, an up-MEP transmits
"up" towards the forwarding function while a down-MEP transmits "down"
towards the interface.  MIPs are modeled as two MIP-Half-Functions because
they're basically active in either direction.  I've interpreted
per-Interface MIPs to be really both MHFs together.  (I suppose you could
extend this to say that per-Node MIPs are like down-MHF only).

Strictly speaking, you're hitting the "down-MHF" if your traceroute message
terminates at what you call the "in-MIP".  You're hitting the "up-MHF" of
the MIP on the other side of the device when the message terminates at the
"out-MIP".  Personally, I find that unintuitive so I actually prefer your
in-MIP/out-MIP terminology.

If you're going to introduce this new terminology though, you'll want to
include a section that explains this mapping.

regards,
Pablo

On Tue, Nov 6, 2012 at 5:51 PM, Rolf Winter <[email-masked]> wrote:

> I see your point. But I think you could argue this two ways. I personally
> liked in- and out-MIP as it illustrates the point of MIPs being transit
> points and therefore somewhat different in nature. RFC 6371 does talk about
> per-interface MIPs but does not name them in any way, which I found strange
> at first. Can someone involved in the ITU-T (or IEEE for that matter) maybe
> comment on terminology here. Up/Down MEP is a commonly used term, but how
> about per interface-MIPs?
>
> >
> > *     Section 4.
> >
> number of more specific OAM functions fall into the category of diagnostic
> test, but using the term should be fine give that it has been used already
> in RFCs. Would you agree?
>
> Thanks again,
>
> Rolf
>
> >
> >
> >         Regards,
> >                 Greg
> >

---

From: Rolf Winter <[email-masked]>
Date: Thu, 8 Nov 2012 11:42:34 +0000

Hi,

I am not aware of IPR that applies to this draft.

Best,

Rolf

> Sent: Dienstag, 6. November 2012 03:51

---

From: <[email-masked]>
Date: Tue, 13 Nov 2012 10:05:43 +0900

Hi,

No. I'm not aware of any IPR related to this draft.
I'm sorry for this late reply.

Tnaks,
Hideki Endo

---

From: Loa Andersson <[email-masked]>
Date: Wed, 14 Nov 2012 16:16:16 +0100

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

--

---

From: t.petch <[email-masked]>
Date: Mon, 19 Nov 2012 12:38:22 +0000

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]>; <[email-masked]>; "MPLS-TP ad
hoc team" <[email-masked]>;
<[email-masked]>
Sent: Wednesday, November 14, 2012 3:16 PM

---

From: "Adrian Farrel" <[email-masked]>
Date: Mon, 19 Nov 2012 16:45:04 -0000

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]; MPLS-TP ad hoc team;
> [email-masked]
> Subject: Re: [mpls] working group last call on draft-ietf-mpls-tp-mip-mep-map
>

---

From: "Shahram Davari" <[email-masked]>
Date: Tue, 20 Nov 2012 19:36:46 +0000

Hi Adrian,

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. Perhaps a similar method to Ethernet MDL/MEL (Maintenance Domain Level) may be used that requires only 3 bits and achieves the same result.

Regards,
Shahram

---

From: "Adrian Farrel" <[email-masked]>
Date: Wed, 21 Nov 2012 09:16:01 -0000

<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
> Cc: [email-masked]; [email-masked];
draft-ietf-mpls-tp-mip-

---

From: "S. Davari" <[email-masked]>
Date: Wed, 21 Nov 2012 06:54:39 -0800

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. 

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

Regards,
Shahram

---

From: Rolf Winter <[email-masked]>
Date: Wed, 21 Nov 2012 20:12:49 +0000

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

> > 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...
> >
> >> 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
> > 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
> > 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
> >> 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".
> >>
> >>> Cc: [email-masked]; [email-masked]; MPLS-TP ad
> >>> hoc
> > team;
> >>> 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
> >>> [two on both sides sounds like four in total to me; suggest 'one on
> >>> each side of the forwarding engine']
> >>>
> >>> s4
> >>> ['respectively' suggests to me that there should be two precedents,
> >>> not just RFC5586; the second paragraph specifies RFC5586 for LSPs,
> >>> The identification information indside [The identification
> >>> information inside ]
> >>>
> >>> Cc: <[email-masked]>; <[email-masked]>;
> >>> "MPLS-TP ad hoc team" <[email-masked]>;
> >>>> Please send your comments to the mpls working group mailing list
> >>>> ([email-masked]).
> >>>>

---

From: "Shahram Davari" <[email-masked]>
Date: Wed, 21 Nov 2012 21:35:57 +0000

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

-----Original Message-----
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,

Best,

Rolf

---

From: "Shahram Davari" <[email-masked]>
Date: Mon, 26 Nov 2012 16:48:56 +0000

---

From: Pablo Frank <[email-masked]>
Date: Wed, 28 Nov 2012 11:21:39 -0500

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

---

From: "Shahram Davari" <[email-masked]>
Date: Wed, 28 Nov 2012 17:46:29 +0000

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.

At the ingress blade:

At the egress blade:

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.

regards,
Pablo

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

> From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]<mailto:[email-masked]>] On Behalf Of Rolf Winter
> To: S. Davari; [email-masked]<mailto:[email-masked]>
> Cc: [email-masked]<mailto:[email-masked]>
>> On Nov 21, 2012, at 1:16 AM, "Adrian Farrel" <[email-masked]<mailto:[email-masked]>>
>> wrote:
>>
>>> <co-author mode>
>>>
>>> Hi Shahram,
>>>
>>>> From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]<mailto:[email-masked]>] On Behalf
>>>> Of Adrian Farrel
>>>> To: 't.petch'; 'Loa Andersson'; [email-masked]<mailto:[email-masked]>
>>>> Cc: [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>;
>>> draft-ietf-mpls-tp-mip-
>>>> [email-masked]<mailto:[email-masked]>
>>>>> From: t.petch [mailto:[email-masked]<mailto:[email-masked]>]
>>>>> To: Loa Andersson; [email-masked]<mailto:[email-masked]>
>>>>> Cc: [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; MPLS-TP ad
>>>>> hoc
>>> team;
>>>>> [email-masked]<mailto:[email-masked]>
>>>>> From: "Loa Andersson" <[email-masked]<mailto:[email-masked]>>
>>>>> To: <[email-masked]<mailto:[email-masked]>>
>>>>> Cc: <[email-masked]<mailto:[email-masked]>>; <[email-masked]<mailto:[email-masked]>>;
>>>>> "MPLS-TP ad hoc team" <[email-masked]<mailto:[email-masked]>>;
>>>>> <[email-masked]<mailto:[email-masked]>>
>>>>>> ([email-masked]<mailto:[email-masked]>).
>>>>>>
>>>> [email-masked]<mailto:[email-masked]>
>>> [email-masked]<mailto:[email-masked]>
>> [email-masked]<mailto:[email-masked]>
> [email-masked]<mailto:[email-masked]>

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

---

From: Loa Andersson <[email-masked]>
Date: Fri, 30 Nov 2012 11:40:42 +0100

Authors,

Can you plese give me an indication of which OAM functions the
separation of in and out MIPs are intended for?

/Loa

--