Re: [mpls] working group last call on draft-ietf-mpls-tp-mip-mep-map
Rolf Winter <Rolf.Winter@neclab.eu> Tue, 04 December 2012 08:34 UTC
Return-Path: <Rolf.Winter@neclab.eu>
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 0950121F854E for <mpls@ietfa.amsl.com>; Tue, 4 Dec 2012 00:34:10 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.849
X-Spam-Level:
X-Spam-Status: No, score=-102.849 tagged_above=-999 required=5 tests=[AWL=-0.450, BAYES_00=-2.599, J_CHICKENPOX_15=0.6, J_CHICKENPOX_41=0.6, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100]
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 G6N1-qEKF6kF for <mpls@ietfa.amsl.com>; Tue, 4 Dec 2012 00:34:08 -0800 (PST)
Received: from mailer1.neclab.eu (mailer1.neclab.eu [195.37.70.40]) by ietfa.amsl.com (Postfix) with ESMTP id DBC7121F85B2 for <mpls@ietf.org>; Tue, 4 Dec 2012 00:34:07 -0800 (PST)
Received: from localhost (localhost [127.0.0.1]) by mailer1.neclab.eu (Postfix) with ESMTP id 44FA210282A; Tue, 4 Dec 2012 09:34:07 +0100 (CET)
X-Virus-Scanned: Amavisd on Debian GNU/Linux (netlab.nec.de)
Received: from mailer1.neclab.eu ([127.0.0.1]) by localhost (atlas-a.office.hd [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 81L+-x8wuVzU; Tue, 4 Dec 2012 09:34:07 +0100 (CET)
Received: from METHONE.office.hd (methone.office.hd [192.168.24.54]) by mailer1.neclab.eu (Postfix) with ESMTP id 2002E102828; Tue, 4 Dec 2012 09:33:52 +0100 (CET)
Received: from DAPHNIS.office.hd ([169.254.2.105]) by METHONE.office.hd ([192.168.24.54]) with mapi id 14.01.0323.003; Tue, 4 Dec 2012 09:33:52 +0100
From: Rolf Winter <Rolf.Winter@neclab.eu>
To: Shahram Davari <davari@broadcom.com>, "hideki.endo.es@hitachi.com" <hideki.endo.es@hitachi.com>
Thread-Topic: Re:Re: [mpls] working group last call on draft-ietf-mpls-tp-mip-mep-map
Thread-Index: AQHNxlMXKWb9xeipk0ykh7jRLlQh+ZfxTQkAgAHCTQCAAOTmgIAAXp2AgABi/fCAAA0igIAHi3cAgAMdCoCAABe0gIAHqEqAgAAMUACAAF+SUIAAToJZ///wNICAAJC4IA==
Date: Tue, 04 Dec 2012 08:33:41 +0000
Message-ID: <791AD3077F94194BB2BDD13565B6295D55542A55@DAPHNIS.office.hd>
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.broadcom.com>
In-Reply-To: <4A6CE49E6084B141B15C0713B8993F281BD38C6B@SJEXCHMB12.corp.ad.broadcom.com>
Accept-Language: en-US, de-DE
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.7.0.208]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
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 08:34:10 -0000
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] 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