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
- [mpls] IPR poll on draft-ietf-mpls-tp-mip-mep-map Loa Andersson
- Re: [mpls] IPR poll on draft-ietf-mpls-tp-mip-mep… Adrian Farrel
- Re: [mpls] IPR poll on draft-ietf-mpls-tp-mip-mep… Manuel.Paul
- Re: [mpls] IPR poll on draft-ietf-mpls-tp-mip-mep… Gregory Mirsky
- Re: [mpls] IPR poll on draft-ietf-mpls-tp-mip-mep… Rolf Winter
- Re: [mpls] IPR poll on draft-ietf-mpls-tp-mip-mep… Gregory Mirsky
- Re: [mpls] IPR poll on draft-ietf-mpls-tp-mip-mep… Rolf Winter
- Re: [mpls] IPR poll on draft-ietf-mpls-tp-mip-mep… Gregory Mirsky
- Re: [mpls] IPR poll on draft-ietf-mpls-tp-mip-mep… Yoshinori Koike
- Re: [mpls] IPR poll on draft-ietf-mpls-tp-mip-mep… Pablo Frank
- Re: [mpls] IPR poll on draft-ietf-mpls-tp-mip-mep… Rolf Winter
- Re: [mpls] IPR poll on draft-ietf-mpls-tp-mip-mep… hideki.endo.es
- [mpls] working group last call on draft-ietf-mpls… Loa Andersson
- Re: [mpls] working group last call on draft-ietf-… t.petch
- Re: [mpls] working group last call on draft-ietf-… Adrian Farrel
- Re: [mpls] working group last call on draft-ietf-… Shahram Davari
- Re: [mpls] working group last call on draft-ietf-… Adrian Farrel
- Re: [mpls] working group last call on draft-ietf-… S. Davari
- Re: [mpls] working group last call on draft-ietf-… Rolf Winter
- Re: [mpls] working group last call on draft-ietf-… Shahram Davari
- Re: [mpls] working group last call on draft-ietf-… Shahram Davari
- Re: [mpls] working group last call on draft-ietf-… Pablo Frank
- Re: [mpls] working group last call on draft-ietf-… Shahram Davari
- Re: [mpls] working group last call on draft-ietf-… Loa Andersson
- Re: [mpls] working group last call on draft-ietf-… Rolf Winter
- Re: [mpls] working group last call on draft-ietf-… Rolf Winter
- Re: [mpls] working group last call on draft-ietf-… Shahram Davari
- Re: [mpls] working group last call on draft-ietf-… Gregory Mirsky
- Re: [mpls] working group last call on draft-ietf-… Rolf Winter
- Re: [mpls] working group last call on draft-ietf-… Rolf Winter
- Re: [mpls] working group last call on draft-ietf-… Gregory Mirsky
- Re: [mpls] working group last call on draft-ietf-… Shahram Davari
- Re: [mpls] working group last call on draft-ietf-… hideki.endo.es
- [mpls] Extended - Re: working group last call on … Loa Andersson
- Re: [mpls] working group last call on draft-ietf-… Shahram Davari
- Re: [mpls] working group last call on draft-ietf-… Shahram Davari
- Re: [mpls] working group last call ondraft-ietf-m… hideki.endo.es
- Re: [mpls] working group last call ondraft-ietf-m… Puneet Agarwal
- Re: [mpls] working group last call ondraft-ietf-m… S. Davari
- Re: [mpls] working group last call ondraft-ietf-m… Shahram Davari
- Re: [mpls] working group last call on draft-ietf-… Rolf Winter
- Re: [mpls] working group last call on draft-ietf-… Rolf Winter
- Re: [mpls] working group last call on draft-ietf-… Rolf Winter
- Re: [mpls] working group last call ondraft-ietf-m… Rolf Winter
- Re: [mpls] working group last callondraft-ietf-mp… hideki.endo.es
- Re: [mpls] working group last call on draft-ietf-… Shahram Davari
- Re: [mpls] working group last call on draft-ietf-… S. Davari
- Re: [mpls] working group last call ondraft-ietf-m… Shahram Davari
- Re: [mpls] working group last callondraft-ietf-mp… Shahram Davari
- Re: [mpls] working group last call ondraft-ietf-m… Stewart Bryant
- Re: [mpls] working group last call ondraft-ietf-m… Rolf Winter
- Re: [mpls] working group last call on draft-ietf-… Rolf Winter
- Re: [mpls] working group lastcallondraft-ietf-mpl… hideki.endo.es
- Re: [mpls] working group last call ondraft-ietf-m… Shahram Davari
- Re: [mpls] working group last call on draft-ietf-… S. Davari
- Re: [mpls] working group lastcallondraft-ietf-mpl… Shahram Davari
- Re: [mpls] working group lastcallondraft-ietf-mpl… Shahram Davari
- Re: [mpls] working group last call on draft-ietf-… Gregory Mirsky
- Re: [mpls] working group lastcallondraft-ietf-mpl… hideki.endo.es
- Re: [mpls] working grouplastcallondraft-ietf-mpls… hideki.endo.es
- Re: [mpls] working group lastcallondraft-ietf-mpl… Rolf Winter
- Re: [mpls] working group last call on draft-ietf-… Rolf Winter
- Re: [mpls] working group last call on draft-ietf-… Gregory Mirsky
- Re: [mpls] working group last call on draft-ietf-… Manuel.Paul
- Re: [mpls] working grouplastcallondraft-ietf-mpls… hideki.endo.es
- Re: [mpls] working group last call on draft-ietf-… Rolf Winter
- [mpls] Working Group Last Call - closed. Re: Exte… Loa Andersson