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

Hi Shahram,

thanks for the summary. It is not 100% accurate but I have explained before how we believe this can work so I won't repeat myself again. "Your" solution is essentially what we had considered before and dismissed for the reasons that I have also stated on the list before (some of these reasons have been documented in the penultimate version of the draft which have only recently been removed). Changing the document would only be a matter of using some old text and put it back in. We would also need to make this a standards track document which (at least) updates 5586. But this is just a procedural note. But you are absolutely correct that the WG need to decide on this. It would be nice to see other people comment. 

Best,

Rolf

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

> -----Original Message-----
> From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf Of
> Shahram Davari
> Sent: Dienstag, 4. Dezember 2012 23:57
> To: mpls@ietf.org
> Subject: Re: [mpls] working group lastcallondraft-ietf-mpls-tp-mip-mep-
> map
> 
>  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
> 
> 
> _______________________________________________
> mpls mailing list
> mpls@ietf.org
> https://www.ietf.org/mailman/listinfo/mpls