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

[Rolf Winter <[e-mail]>]

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.

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


> -----Original Message-----
> From: Shahram Davari [mailto:[e-mail]]
> Sent: Montag, 3. Dezember 2012 16:27
> To: Rolf Winter
> Cc: Pablo Frank; [e-mail]
> Subject: Re: [mpls] working group last call on draft-ietf-mpls-tp-mip-
> mep-map
> 
> 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
> 
> 
> On Dec 3, 2012, at 5:53 AM, "Rolf Winter" <[e-mail]>
> wrote:
> 
> > 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
> >
> > NEC Europe Limited | Registered Office: NEC House, 1 Victoria Road,
> > London W3 6BL | Registered in England 2832014
> >
> >
> >> -----Original Message-----
> >> From: [e-mail] [mailto:[e-mail]] On Behalf
> >> Of Shahram Davari
> >> Sent: Mittwoch, 28. November 2012 18:46
> >> To: Pablo Frank
> >> Cc: [e-mail]
> >> 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:[e-mail]]
> >> Sent: Wednesday, November 28, 2012 8:22 AM
> >> To: Shahram Davari
> >> Cc: [e-mail]
> >> 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
> >> <[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]
> >> <mailto:[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]
> >> <mailto:[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]>; <mpls-
> >> [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
> >
> >