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

[Rolf Winter <[e-mail]>]

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