Re: [mpls] working group lastcallondraft-ietf-mpls-tp-mip-mep-map

["Shahram Davari" <[e-mail]>]

 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