Re: [mpls] working group last call on draft-ietf-mpls-tp-mip-mep-map
"Shahram Davari" <davari@broadcom.com> Tue, 04 December 2012 09:22 UTC
Return-Path: <davari@broadcom.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 85B2821F8659 for <mpls@ietfa.amsl.com>; Tue, 4 Dec 2012 01:22:33 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.269
X-Spam-Level:
X-Spam-Status: No, score=-5.269 tagged_above=-999 required=5 tests=[AWL=0.128, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_15=0.6, J_CHICKENPOX_41=0.6, RCVD_IN_DNSWL_MED=-4]
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 wX2E6srVE2uY for <mpls@ietfa.amsl.com>; Tue, 4 Dec 2012 01:22:29 -0800 (PST)
Received: from mms3.broadcom.com (mms3.broadcom.com [216.31.210.19]) by ietfa.amsl.com (Postfix) with ESMTP id 2FF3421F85E6 for <mpls@ietf.org>; Tue, 4 Dec 2012 01:22:29 -0800 (PST)
Received: from [10.16.192.232] by mms3.broadcom.com with ESMTP (Broadcom SMTP Relay (Email Firewall v6.5)); Tue, 04 Dec 2012 01:17:53 -0800
X-Server-Uuid: B86B6450-0931-4310-942E-F00ED04CA7AF
Received: from SJEXCHCAS03.corp.ad.broadcom.com (10.16.203.9) by SJEXCHHUB02.corp.ad.broadcom.com (10.16.192.232) with Microsoft SMTP Server (TLS) id 8.2.247.2; Tue, 4 Dec 2012 01:22:18 -0800
Received: from SJEXCHMB12.corp.ad.broadcom.com ( [fe80::bc15:c1e1:c29a:36f7]) by SJEXCHCAS03.corp.ad.broadcom.com ( [::1]) with mapi id 14.01.0355.002; Tue, 4 Dec 2012 01:21:57 -0800
From: Shahram Davari <davari@broadcom.com>
To: Rolf Winter <Rolf.Winter@neclab.eu>
Thread-Topic: [mpls] working group last call on draft-ietf-mpls-tp-mip-mep-map
Thread-Index: AQHN0gDOGLzGkGQffUCu8eKg5ppt/Q==
Date: Tue, 04 Dec 2012 09:21:57 +0000
Message-ID: <1C7E7722-1249-44A1-AF38-FD6CA490718D@broadcom.com>
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>, <791AD3077F94194BB2BDD13565B6295D55542A55@DAPHNIS.office.hd>
In-Reply-To: <791AD3077F94194BB2BDD13565B6295D55542A55@DAPHNIS.office.hd>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
MIME-Version: 1.0
X-WSS-ID: 7CA3604A39W4985624-01-01
Content-Type: multipart/alternative; boundary="_000_1C7E7722124944A1AF38FD6CA490718Dbroadcomcom_"
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 09:22:33 -0000
Rolf, The job of OAM is to diagnose issues in the data plane. This means OAM has to take the same path as Data. Therefore on a P2MP LSP, OAM must be multicasted, similar to data. You can't just send to one MEP or MIP. Here is what RFC6371 says: P2MP Considerations All the traffic sent over a P2MP transport path, including OAM packets generated by a MEP, is sent (multicast) from the root to all the leaves. As a consequence: o To send an OAM packet to all leaves, the source MEP can send a single OAM packet that will be delivered by the forwarding plane to all the leaves and processed by all the leaves. Hence, a single OAM packet can simultaneously instrument all the MEs in a P2MP MEG. o To send an OAM packet to a single leaf, the source MEP sends a single OAM packet that will be delivered by the forwarding plane to all the leaves but contains sufficient information to identify a target leaf, and therefore is processed only by the target leaf and can be silently discarded by the other leaves. So although you can send a targeted OAM message to only one MEP or MIP, but the same message is going to be received by all MEPs or MIPs (with same TTL distance). The others just drop it. So in the MIP example provided the ingress port of a router can't decide to which selective egress port it has to send the OAM packet to. The only decision it can make is that an OAM message is or is not for itself (the in-MEP). Each egress port also decide individually whether the OAM is for itself or not, and if not just drops the packet. So for sure the in-MEP doesn't need to look at MEPID to decide whether to terminate and send the OAM packet to CPU or forward normally. A single bit is enough for making such decision. Regarding out-MIPs, there are 2 options: 1) send OAM packet received with TTL expiry to CPU and let CPU look at MEPID and if not correct drop it 2) let the HW to look at MEPID and if correct, send the packet to CPU, else drop it. I agree the 2nd option is more efficient, but is not practical, since locating arbitrarily located TLVs in various different OAM packet types such as BFD, LSP-Ping, etc is not practical. Thx Shahram Regards, Shahram On Dec 4, 2012, at 12:34 AM, "Rolf Winter" <Rolf.Winter@neclab.eu<mailto: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<mailto:hideki.endo.es@hitachi.com> Cc: Rolf Winter; mpls@ietf.org<mailto: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> [mailto:hideki.endo.es@hitachi.com] Sent: Monday, December 03, 2012 4:48 PM To: Shahram Davari Cc: Rolf.Winter@neclab.eu<mailto:Rolf.Winter@neclab.eu>; mpls@ietf.org<mailto: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<mailto: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<mailto: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<mailto: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> [mailto:mpls-bounces@ietf.org] On Behalf Of Shahram Davari Sent: Mittwoch, 28. November 2012 18:46 To: Pablo Frank Cc: mpls@ietf.org<mailto: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<mailto: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<mailto: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> [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<mailto:adrian@olddog.co.uk> Cc: mpls@ietf.org<mailto: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<mailto: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> [mailto:mpls- bounces@ietf.org<mailto:bounces@ietf.org>] On Behalf Of Adrian Farrel Sent: Monday, November 19, 2012 8:45 AM To: 't.petch'; 'Loa Andersson'; mpls@ietf.org<mailto:mpls@ietf.org> Cc: mpls-ads@tools.ietf.org<mailto:mpls-ads@tools.ietf.org>; mpls-chairs@tools.ietf.org<mailto:mpls-chairs@tools.ietf.org> <mailto:mpls-chairs@tools.ietf.org> ; draft-ietf-mpls-tp-mip- mep-map@tools.ietf.org<mailto: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<mailto:mpls@ietf.org> Cc: mpls-ads@tools.ietf.org<mailto:mpls-ads@tools.ietf.org>; mpls-chairs@tools.ietf.org<mailto: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<mailto: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<mailto:loa@pi.nu>> To: <mpls@ietf.org<mailto:mpls@ietf.org>> Cc: <mpls-ads@tools.ietf.org<mailto:mpls-ads@tools.ietf.org>>; <mpls- chairs@tools.ietf.org<mailto:chairs@tools.ietf.org>>; "MPLS-TP ad hoc team" <ahmpls-tp@lists.itu.int<mailto:ahmpls-tp@lists.itu.int>>; <draft-ietf-mpls-tp-mip-mep-map@tools.ietf.org<mailto: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<mailto: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<mailto:mpls@ietf.org> https://www.ietf.org/mailman/listinfo/mpls _______________________________________________ mpls mailing list mpls@ietf.org<mailto:mpls@ietf.org> https://www.ietf.org/mailman/listinfo/mpls _______________________________________________ mpls mailing list mpls@ietf.org<mailto: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<mailto:mpls@ietf.org> https://www.ietf.org/mailman/listinfo/mpls _______________________________________________ mpls mailing list mpls@ietf.org<mailto:mpls@ietf.org> https://www.ietf.org/mailman/listinfo/mpls _______________________________________________ mpls mailing list mpls@ietf.org<mailto: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