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

"S. Davari" <davarish@yahoo.com> Tue, 04 December 2012 14:56 UTC

Return-Path: <davarish@yahoo.com>
X-Original-To: mpls@ietfa.amsl.com
Delivered-To: mpls@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BF32921F870C for <mpls@ietfa.amsl.com>; Tue, 4 Dec 2012 06:56:49 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.003
X-Spam-Level:
X-Spam-Status: No, score=-0.003 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_15=0.6, J_CHICKENPOX_41=0.6, MIME_QP_LONG_LINE=1.396]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Yg60leKBpaOk for <mpls@ietfa.amsl.com>; Tue, 4 Dec 2012 06:56:48 -0800 (PST)
Received: from nm46-vm2.bullet.mail.ne1.yahoo.com (nm46-vm2.bullet.mail.ne1.yahoo.com [98.138.121.82]) by ietfa.amsl.com (Postfix) with ESMTP id A305E21F85BF for <mpls@ietf.org>; Tue, 4 Dec 2012 06:56:47 -0800 (PST)
Received: from [98.138.226.178] by nm46.bullet.mail.ne1.yahoo.com with NNFMP; 04 Dec 2012 14:56:43 -0000
Received: from [98.138.88.107] by tm13.bullet.mail.ne1.yahoo.com with NNFMP; 04 Dec 2012 14:56:43 -0000
Received: from [127.0.0.1] by smtp124-mob.biz.mail.ne1.yahoo.com with NNFMP; 04 Dec 2012 14:56:42 -0000
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1354633002; bh=jAruvo3TsPiiQKdim7scB74rm3qQI/vuEZ2AwZcM9/U=; h=X-Yahoo-Newman-Id:X-Yahoo-Newman-Property:X-YMail-OSG:X-Yahoo-SMTP:Received:Content-Type:Content-Transfer-Encoding:Subject:References:From:Mime-Version:In-Reply-To:Message-Id:Date:Cc:To:X-Mailer; b=5PsoWKq3RhIyUmNzv30P0/7FxzFXW070MFGUHhXDZmVZeqoxkl+UEUADzEXgp+VGNSm8+pLiuPMraOiqhwbOwzkZP1lGdYmbJgg+rxvFhIqHisAyzvjyIoTj/7Dkqk9gCdOO75loVAlKGb/prLtlk92bsENoeenbICm+gjcT8Ms=
X-Yahoo-Newman-Id: 978202.92292.bm@smtp124-mob.biz.mail.ne1.yahoo.com
X-Yahoo-Newman-Property: ymail-3
X-YMail-OSG: pFU1F_QVM1lKSXaWVQeOxDKiAXwM2LzxqT_kfqZi8LBV7cB 1YdJHOeoh75ydn6phRxPqhi2piegt80TF37WHDLbWyHTGR1veXv17XJdMyIW 8GkCzEA831z7.P2hAwnPJEFWt40MPvq_v8sFdYA5WqYJajErCc9wzxzzuYuw Sne4rEGinEAZAJpAoE55V9p6.zfMZ39LdqCkr6FEuyEa2IhBOuwnlRAJcRkv ZOHKfYfrOG3yXdISFKX7IlBDaRXUU.yBN._J3jcH36eRbTPCrvTBtYTTKZtk 9JBmrwF2u.0GN7Nhyxh7IdDeqowzFP2L94uJ0V5rk3TFv0xwlW0iJilm3JN5 _Q8fCbujCLA.r8Blc_rhr4Uyu5yncH7OiGA5VInjUgjukN2FCsZB7gu4Ou3f 9fmoJeB.8zcE_rS.NKBjo4IEsNUzfeUXmg.h.6Ob8JB33x7D0r8LkzBZOBZ7 VhtdtfX3No9o-
X-Yahoo-SMTP: ygPrP9CswBCWPbPtKJlJyLY0KMlg
Received: from [192.168.0.104] (davarish@98.248.36.11 with xymcookie) by smtp124-mob.biz.mail.ne1.yahoo.com with SMTP; 04 Dec 2012 14:56:42 +0000 UTC
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
References: <5098CF68.2000105@pi.nu> <50A3B5C0.4060203@pi.nu> <01e601cdc652$dab31600$4001a8c0@gateway.2wire.net> <016e01cdc675$3b64d6b0$b22e8410$@olddog.co.uk> <4A6CE49E6084B141B15C0713B8993F281BD2E957@SJEXCHMB12.corp.ad.broa> <027c01cdc7c8$d5500430$7ff00c90$@olddog.co.uk> <F0E40950-2607-4AB5-BB17-88EFC41C1603@yahoo.com> <791AD3077F94194BB2BDD13565B6295D5552490A@Hydra.office.hd> <4A6CE49E6084B141B15C0713B8993F281BD2FBBB@SJEXCHMB12.corp.ad.broa> <38DFCE5F-A496-4AAC-A2C5-0450B5260EAD@broadcom.com> <CAGEmCZyDCBV-vdA96Amnx-08U-Xq_6t+mnF34k8o_8tX+4z2VQ@mail.gmail.c> <4A6CE49E6084B141B15C0713B8993F281BD338A7@SJEXCHMB12.corp.ad.broa> <791AD3077F94194BB2BDD13565B6295D555415E0@DAPHNIS.office.hd> <B5CDD7D1-CBD7-4E74-ADE6-0DEBE26E3757@broadcom.com> <791AD3077F94194BB2BDD13565B6295D55542847@DAPHNIS.office.hd> <4A6CE49E6084B141B15C0713B8993F281BD389A3@SJEXCHMB12.corp.ad.broa> <XNM1$7$0$0$$6$1$2$A$5003751U50bd483f@hitachi.com> <4A6CE49E6084B141B15C0713B8993F281BD38C6B@SJEXCHMB12.corp.ad.br oadcom.com> <791AD3077F94194BB2BDD13565B6295D55542A55@DAPHNIS.office.hd> <98F14E8F-9AAC-4372-B322-C23D2AD0DDCE@yahoo.com> <791AD3077F94194BB2BDD13565B6295D55543BED@DAPHNIS.office.hd>
From: "S. Davari" <davarish@yahoo.com>
Mime-Version: 1.0 (1.0)
In-Reply-To: <791AD3077F94194BB2BDD13565B6295D55543BED@DAPHNIS.office.hd>
Message-Id: <6B968B80-D20C-4A29-8ACD-9DA27992C169@yahoo.com>
Date: Tue, 04 Dec 2012 06:56:15 -0800
To: Rolf Winter <Rolf.Winter@neclab.eu>
X-Mailer: iPhone Mail (10A403)
Cc: "mpls@ietf.org" <mpls@ietf.org>
Subject: Re: [mpls] working group last call on draft-ietf-mpls-tp-mip-mep-map
X-BeenThere: mpls@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Multi-Protocol Label Switching WG <mpls.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/mpls>, <mailto:mpls-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/mpls>
List-Post: <mailto:mpls@ietf.org>
List-Help: <mailto:mpls-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/mpls>, <mailto:mpls-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 04 Dec 2012 14:56:49 -0000

Correct.

Regards,
Shahram


On Dec 4, 2012, at 3:40 AM, Rolf Winter <Rolf.Winter@neclab.eu> wrote:

> Hi Sharam,
> 
> that is not quite accurate. It will happen at all nodes at the same TTL distance because also there the TTL will expire even if no out-MIP is addressed there.
> 
> Best,
> 
> Rolf
> 
> NEC Europe Limited | Registered Office: NEC House, 1 Victoria Road, London W3 6BL | Registered in England 2832014 
> 
> 
>> -----Original Message-----
>> From: S. Davari [mailto:davarish@yahoo.com]
>> Sent: Dienstag, 4. Dezember 2012 10:29
>> To: Rolf Winter
>> Cc: Shahram Davari; hideki.endo.es@hitachi.com; mpls@ietf.org
>> Subject: Re: [mpls] working group last call on draft-ietf-mpls-tp-mip-
>> mep-map
>> 
>> Hi Rolf,
>> 
>> For in-MIP a single bit is enough. However for out-MIP the CPU has to
>> drop the unwanted OAM. Not efficient but the system still works.
>> Remember this happens only in a corner case of p2mp MPLS with multiple
>> out-MIP on the same router, and when only root wants to talk to one of
>> the leaves.
>> 
>> That's why I am suggesting to have a single bit in addition to the
>> MEPID.
>> 
>> Regards,
>> Shahram
>> 
>> 
>> On Dec 4, 2012, at 12:33 AM, Rolf Winter <Rolf.Winter@neclab.eu> wrote:
>> 
>>> Shahram,
>>> 
>>> what if it is configured and you only want to talk to one out of all
>> the out-MIPs. I guess we can all craft examples where we can make our
>> point. A single bit simply does not guarantee you that the local CPU
>> does not have to look at the OAM frame to finally discard it.
>>> 
>>> Best,
>>> 
>>> Rolf
>>> 
>>> NEC Europe Limited | Registered Office: NEC House, 1 Victoria Road,
>>> London W3 6BL | Registered in England 2832014
>>> 
>>> 
>>>> -----Original Message-----
>>>> From: Shahram Davari [mailto:davari@broadcom.com]
>>>> Sent: Dienstag, 4. Dezember 2012 01:53
>>>> To: hideki.endo.es@hitachi.com
>>>> Cc: Rolf Winter; mpls@ietf.org
>>>> Subject: RE: Re:Re: [mpls] working group last call on
>>>> draft-ietf-mpls- tp-mip-mep-map
>>>> 
>>>> Hi Hideki,
>>>> 
>>>> I think you need to look at my p-code. F a MIP is not configured in
>>>> the Egress port, then that egress port won't sent the OAM packet to
>>>> its processor and drops it. So there is no issue with my proposed
>> method.
>>>> 
>>>> Thx
>>>> Shahram
>>>> 
>>>> -----Original Message-----
>>>> From: hideki.endo.es@hitachi.com [mailto:hideki.endo.es@hitachi.com]
>>>> Sent: Monday, December 03, 2012 4:48 PM
>>>> To: Shahram Davari
>>>> Cc: Rolf.Winter@neclab.eu; mpls@ietf.org
>>>> Subject: Re:Re: [mpls] working group last call on draft-ietf-mpls-
>> tp-
>>>> mip-mep-map
>>>> 
>>>> Hi Shahram,
>>>> 
>>>> First, as Rolf sent, we need in/out-MIP for 1. CV between a MEP and
>> a
>>>> MIP 2. traceroute over an MPLS-TP LSP and/or an MPLS-TP PW
>> containing
>>>> MIPs 3. data-plane loopback configuration at a MIP 4. diagnostic
>>>> tests Here, CV means On-demand CV. You may misunderstand as
>> Proactive CV.
>>>> 
>>>> Second, you wrote;
>>>> "The issue is that each CPU/processor has limited resources.
>>>> By sending all OAM MIP packets to both processor you are  losing 1/2
>>>> of the capacity of each processor. "
>>>> It depends on implementations,
>>>> and this issue could NOT be resolved by even your solution that uses
>>>> ACH header to indicate in/out-MIP.
>>>> Let's consider P2MP case as you pointed out.
>>>> All OAM MIP packets for out-MIPs port(B, C) are sent to all out-MIPs.
>>>> This means that the OAM processor at port D loses its capacity.
>>>> If we consider the larger number of ports in the LSR which has 100
>>>> ports, for example, All OAM MIP packets for out-MIPs port(B, C) are
>>>> sent to all out-MIPs.
>>>> This means that the OAM processors at the other 98 ports lose those
>>>> capacities.
>>>> Even if your solution using ACH header is applied, it can reduce OAM
>>>> packets only for in-MIP, which means only 1/101 effectiveness in the
>>>> case of P2MP for 100 ports.
>>>> 
>>>> Thanks,
>>>> Hideki Endo
>>>> 
>>>> 
>>>>> Rolf,
>>>>> 
>>>>> For clarity it is better to use an example. Assume that an LSR has
>> 4
>>>> ports (A, B, C, D). Now assume that it receives packets  on a
>> unicast
>>>> LSP-X from port A and forwards them to port B.  there can only be 3
>>>> configurations:
>>>>> 
>>>>> 1) MIP on port A (In-MIP), or
>>>>> 2) MIP on port B (out-MIP), or
>>>>> 3) MEIP on Port A and B
>>>>> 
>>>>> A single OAM packet can be terminated and processed only by one of
>>>> these MIPs. Now assume OAM packet (P) is meant for out-MIP (MIPID
>>>> =port B). In your example, you are saying send a copy of the P to
>> the
>>>> CPU/Processor on Port A, and send a copy also to CPU/Processor on
>>>> Port B. Port A CPU will drop the packet since the MIP-ID is not A.
>>>> The issue is that each CPU/processor has limited resources.  By
>>>> sending all OAM MIP packets to both processor you are losing 1/2 of
>>>> the capacity of each processor.  The practical solution is to have a
>>>> simple indicator in the packet header that this OAM packet is meant
>>>> for Out-MIP. Then port A just switches the OAM packet to Port B, and
>>>> Port B terminates and sends it to its CPU/processor.
>>>>> 
>>>>> Lest get to P2MP example. Assume LSP-Y is a P2MP LSP that enters
>> the
>>>> chip from Port A and is sent to ports B, C, D.  Also assume that
>>>> there is In-MIP on port A and out-MIPs of ports B, C (not D).  Now
>>>> assume a Multicast OAM packet is  meant for out-MIPs (B, C). In such
>>>> case the OAM packet should not be sent to port A CPU/Processor. It
>> is
>>>> therefore multicast to ports B, C, D. Ports B, C send the OAM packet
>> to their CPU.
>>>> Port D drops the OAM packets and does not send it to its CPU, since
>>>> there is no MIP configured for that MPLS label.
>>>>> 
>>>>> So the Pseudo-code is like this:
>>>>> 
>>>>> Ingress Port:
>>>>> 
>>>>> If packet is OAM and TTL=1
>>>>>   If MIP is enabled
>>>>>       If packet indicates In-MIP
>>>>>           Send to local CPU
>>>>>       Else
>>>>>           Forward to egress port
>>>>>       End
>>>>>   Else
>>>>>       Forward normally
>>>>>   End
>>>>> Else
>>>>> 
>>>>> Egress Port:
>>>>> 
>>>>> If packet is OAM and TTL=1
>>>>>   If MIP is enabled
>>>>>       If packet indicates In-MIP
>>>>>           Drop  packet
>>>>>       Else If packet indicates Out-MIP
>>>>>           Send to local CPU
>>>>>       End
>>>>>   Else
>>>>>       Drop packet
>>>>>   End
>>>>> End
>>>>> 
>>>>> 
>>>>> Using this example could you please describe your reasoning for not
>>>> requiring HW to identify In-MEP vs out-MIPs?
>>>>> 
>>>>> Thanks
>>>>> Shahram
>>>>> 
>>>>> -----Original Message-----
>>>>> From: Rolf Winter [mailto:Rolf.Winter@neclab.eu]
>>>>> Sent: Monday, December 03, 2012 12:10 PM
>>>>> To: Shahram Davari
>>>>> Cc: Pablo Frank; mpls@ietf.org
>>>>> Subject: RE: [mpls] working group last call on
>>>>> draft-ietf-mpls-tp-mip-mep-map
>>>>> 
>>>>> 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:davari@broadcom.com]
>>>>>> Sent: Montag, 3. Dezember 2012 16:27
>>>>>> To: Rolf Winter
>>>>>> Cc: Pablo Frank; mpls@ietf.org
>>>>>> 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" <Rolf.Winter@neclab.eu>
>>>>>> 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: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On
>>>>>>>> Behalf Of Shahram Davari
>>>>>>>> Sent: Mittwoch, 28. November 2012 18:46
>>>>>>>> To: Pablo Frank
>>>>>>>> Cc: mpls@ietf.org
>>>>>>>> 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:pabloisnot@gmail.com]
>>>>>>>> Sent: Wednesday, November 28, 2012 8:22 AM
>>>>>>>> To: Shahram Davari
>>>>>>>> Cc: mpls@ietf.org
>>>>>>>> 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
>>>>>>>> <davari@broadcom.com>
>>>>>>>> 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: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org]
>>>> On
>>>>>>>> Behalf Of Rolf Winter
>>>>>>>>> Sent: Wednesday, November 21, 2012 12:13 PM
>>>>>>>>> To: S. Davari; adrian@olddog.co.uk
>>>>>>>>> Cc: mpls@ietf.org
>>>>>>>>> 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"
>>>>>>>> <adrian@olddog.co.uk>
>>>>>>>>>> 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: mpls-bounces@ietf.org [mailto:mpls-
>>>> bounces@ietf.org]
>>>>>> On
>>>>>>>> Behalf
>>>>>>>>>>>> Of Adrian Farrel
>>>>>>>>>>>> Sent: Monday, November 19, 2012 8:45 AM
>>>>>>>>>>>> To: 't.petch'; 'Loa Andersson'; mpls@ietf.org
>>>>>>>>>>>> Cc: mpls-ads@tools.ietf.org; mpls-chairs@tools.ietf.org
>>>>>>>> <mailto:mpls-chairs@tools.ietf.org> ;
>>>>>>>>>>> draft-ietf-mpls-tp-mip-
>>>>>>>>>>>> mep-map@tools.ietf.org
>>>>>>>>>>>> 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:ietfc@btconnect.com]
>>>>>>>>>>>>> Sent: 19 November 2012 12:38
>>>>>>>>>>>>> To: Loa Andersson; mpls@ietf.org
>>>>>>>>>>>>> Cc: mpls-ads@tools.ietf.org; mpls-chairs@tools.ietf.org
>>>>>>>> <mailto:mpls-chairs@tools.ietf.org> ; MPLS-TP ad
>>>>>>>>>>>>> hoc
>>>>>>>>>>> team;
>>>>>>>>>>>>> draft-ietf-mpls-tp-mip-mep-map@tools.ietf.org
>>>>>>>>>>>>> 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" <loa@pi.nu>
>>>>>>>>>>>>> To: <mpls@ietf.org>
>>>>>>>>>>>>> Cc: <mpls-ads@tools.ietf.org>; <mpls-
>>>>>>>> chairs@tools.ietf.org>;
>>>>>>>>>>>>> "MPLS-TP ad hoc team" <ahmpls-tp@lists.itu.int>;
>>>>>>>>>>>>> <draft-ietf-mpls-tp-mip-mep-map@tools.ietf.org>
>>>>>>>>>>>>> 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
>>>>>>>>>>>>>> (mpls@ietf.org).
>>>>>>>>>>>>>> 
>>>>>>>>>>>>>> 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
>>>>>>>>>>>> mpls@ietf.org
>>>>>>>>>>>> https://www.ietf.org/mailman/listinfo/mpls
>>>>>>>>>>> 
>>>>>>>>>>> 
>>>>>>>>>>> _______________________________________________
>>>>>>>>>>> mpls mailing list
>>>>>>>>>>> mpls@ietf.org
>>>>>>>>>>> https://www.ietf.org/mailman/listinfo/mpls
>>>>>>>>>> _______________________________________________
>>>>>>>>>> mpls mailing list
>>>>>>>>>> mpls@ietf.org
>>>>>>>>>> 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
>>>>>>>>> mpls@ietf.org
>>>>>>>>> https://www.ietf.org/mailman/listinfo/mpls
>>>>>>>> 
>>>>>>>>  _______________________________________________
>>>>>>>>  mpls mailing list
>>>>>>>>  mpls@ietf.org
>>>>>>>>  https://www.ietf.org/mailman/listinfo/mpls
>>>>> 
>>>>> 
>>>>> 
>>>>> _______________________________________________
>>>>> mpls mailing list
>>>>> mpls@ietf.org
>>>>> https://www.ietf.org/mailman/listinfo/mpls
>>> 
>>> _______________________________________________
>>> mpls mailing list
>>> mpls@ietf.org
>>> https://www.ietf.org/mailman/listinfo/mpls