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

[Pablo Frank <[e-mail]>]

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 <[e-mail]>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
> >
> >
> >
> > -----Original Message-----
> > From: [e-mail] [mailto:[e-mail]] On Behalf Of
> Rolf Winter
> > Sent: Wednesday, November 21, 2012 12:13 PM
> > To: S. Davari; [e-mail]
> > Cc: [e-mail]
> > 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" <[e-mail]>
> >> 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
> >>>> -----Original Message-----
> >>>> From: [e-mail] [mailto:[e-mail]] On Behalf
> >>>> Of Adrian Farrel
> >>>> Sent: Monday, November 19, 2012 8:45 AM
> >>>> To: 't.petch'; 'Loa Andersson'; [e-mail]
> >>>> Cc: [e-mail]; [e-mail];
> >>> draft-ietf-mpls-tp-mip-
> >>>> [e-mail]
> >>>> 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)
> >>>>
> >>>>> -----Original Message-----
> >>>>> From: t.petch [mailto:[e-mail]]
> >>>>> Sent: 19 November 2012 12:38
> >>>>> To: Loa Andersson; [e-mail]
> >>>>> Cc: [e-mail]; [e-mail]; MPLS-TP ad
> >>>>> hoc
> >>> team;
> >>>>> [e-mail]
> >>>>> 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" <[e-mail]>
> >>>>> To: <[e-mail]>
> >>>>> Cc: <[e-mail]>; <[e-mail]>;
> >>>>> "MPLS-TP ad hoc team" <[e-mail]>;
> >>>>> <[e-mail]>
> >>>>> Sent: Wednesday, November 14, 2012 3:16 PM
> >>>>>
> >>>>>> Working Group,
> >>>>>>
> >>>>>> This is to start a 2 week working group last call on
> >>>>>> draft-ietf-mpls-tp-mip-mep-map.
> >>>>>>
> >>>>>> Please send your comments to the mpls working group mailing list
> >>>>>> ([e-mail]).
> >>>>>>
> >>>>>> Please send both technical comments, and if you are happy with the
> >>>>>> document as is also indications of support.
> >>>>>>
> >>>>>> This working group last call will end on November 28.
> >>>>>>
> >>>>>> /Loa
> >>>>>> for the wg co-chairs
> >>>>
> >>>>
> >>>> _______________________________________________
> >>>> mpls mailing list
> >>>> [e-mail]
> >>>> https://www.ietf.org/mailman/listinfo/mpls
> >>>
> >>>
> >>> _______________________________________________
> >>> mpls mailing list
> >>> [e-mail]
> >>> https://www.ietf.org/mailman/listinfo/mpls
> >> _______________________________________________
> >> mpls mailing list
> >> [e-mail]
> >> 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
> > [e-mail]
> > https://www.ietf.org/mailman/listinfo/mpls
> >
> >
>
> _______________________________________________
> mpls mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/mpls
>