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

<hideki.endo.es@hitachi.com> Thu, 06 December 2012 01:41 UTC

Return-Path: <hideki.endo.es@hitachi.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 8391D21F8AF1 for <mpls@ietfa.amsl.com>; Wed, 5 Dec 2012 17:41:23 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.01
X-Spam-Level:
X-Spam-Status: No, score=0.01 tagged_above=-999 required=5 tests=[AWL=-0.100, BAYES_00=-2.599, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, J_CHICKENPOX_15=0.6, J_CHICKENPOX_41=0.6, RCVD_IN_DNSWL_LOW=-1]
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 AXey9XPp2yzb for <mpls@ietfa.amsl.com>; Wed, 5 Dec 2012 17:41:21 -0800 (PST)
Received: from mail9.hitachi.co.jp (mail9.hitachi.co.jp [133.145.228.44]) by ietfa.amsl.com (Postfix) with ESMTP id 879B021F8BB6 for <mpls@ietf.org>; Wed, 5 Dec 2012 17:41:20 -0800 (PST)
Received: from mlsv6.hitachi.co.jp (unknown [133.144.234.166]) by mail9.hitachi.co.jp (Postfix) with ESMTP id 94DD337C8C; Thu, 6 Dec 2012 10:41:19 +0900 (JST)
Received: from mfilter05.hitachi.co.jp by mlsv6.hitachi.co.jp (8.13.1/8.13.1) id qB61fJ4N017731; Thu, 6 Dec 2012 10:41:19 +0900
Received: from vshuts02.hitachi.co.jp (vshuts02.hitachi.co.jp [10.201.6.84]) by mfilter05.hitachi.co.jp (Switch-3.3.4/Switch-3.3.4) with ESMTP id qB61fI8C014342; Thu, 6 Dec 2012 10:41:19 +0900
Received: from gmml25.itg.hitachi.co.jp (unknown [158.213.165.145]) by vshuts02.hitachi.co.jp (Postfix) with ESMTP id 5C71449005A; Thu, 6 Dec 2012 10:41:18 +0900 (JST)
Received: from [127.0.0.1] by gmml25.itg.hitachi.co.jp (AIX5.2/8.11.6p2/8.11.0) id qB61fI211321540; Thu, 6 Dec 2012 10:41:18 +0900
Message-Type: Multiple Part
MIME-Version: 1.0
Message-ID: <XNM1$7$0$0$$6$1$2$A$5003770U50bff789@hitachi.com>
Content-Type: text/plain; charset="us-ascii"
To: davari@broadcom.com, Rolf.Winter@neclab.eu
From: hideki.endo.es@hitachi.com
Date: Thu, 06 Dec 2012 10:40:56 +0900
References: <5098CF68.2000105@pi.nu> <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> <4A6CE49E6084B141B15C0713B8993F281BD38CA7@SJEXCHMB12.corp.ad.broa> <XNM1$7$0$0$$6$1$2$A$5003753U50bd5093@hitachi.com> <63293273-A276-4F9F-AD24-27A70977E445@yahoo.com> <B3B28804-C35E-42DC-8062-D0E7A858D2CE@broadcom.com> <XNM1$7$0$0$$6$1$2$A$5003763U50bdba91@hitachi.com> <B392FF00-C186-4630-B136-415D08685B1D@broadcom.com> <XNM1$7$0$0$$6$1$2$A$5003764U50bde31f@hitachi.com> <175D51A2-5876-4EEE-9D36-AEE78017A99D@broadcom.com> <XNM1$7$0$0$$6$1$2$A$5003766U50beac7a@hitachi.com>
Priority: normal
Importance: normal
X400-Content-Identifier: X50BFF78900000M
X400-MTS-Identifier: [/C=JP/ADMD=HITNET/PRMD=HITACHI/;gmml28121206104025USY]
Content-Transfer-Encoding: 7bit
Cc: mpls@ietf.org
Subject: Re: [mpls] working grouplastcallondraft-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: Thu, 06 Dec 2012 01:41:23 -0000

Shahram and Rolf,

It is seemed to me that we will reach same conclusions.

(1)Shahram's proposal that uses AHC header for identifing in/out-MIP is usuful for a P2P path,
but few effectiveness for a P2MP path.

(2)Even if Shahram's proposal is applied, we need to parse MIP ID TLV at line rate
for fast rate protocol such as diagnostic function.

So far, do you agree?
If yes, we have a difficulty to implement fast rate protocols in HW.
As Rolf sent in other email, we need to consider fixed location of ID TLV.
However, we don't need to reconsider all of OAM functions.
I mean we need to consider fixed location ID TLV only for fast rate protocol functions.

My proposal is that we add some texts such as
"The hardware friendly solution such as fixed location of ID TLV should be considered,
 if the OAM protocol requiring fast rate (e.g. line rate) processing will be developed."

Thanks,
Hideki Endo


>Shahram,
>
>Yes, this issue is an internal matter to the box as you said,
>and I have some experiences to implement this feature in commercial products.
>Therefore, I initially had same concern as you. 
>We, the authors of this draft, requested the fixed location of MIP ID TLV or using ACH header.
>However, as Rolf sent to you, in that case, we would need to go back and make changes to a few RFCs. 
>That was also something people weren't really happy about.
>
>And, I have understood this issue can be resolved by an optimized implementation.
>As Rolf sent, we need this feature for some functions as below;
>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
>In these functions, 1(On-demand CV) and 2(traceroute) would be very slow rate protocol.
>Therefor, it is possible for OAM processor/CPU to parse TLVs.
>On the other hand, 3(data-plane loopback) and 4(diagnostic tests) would be very fast rate protocol.
>It means that these function should be implemented in specific HW with capacity to parse MIP ID TLV
>at line rate.
>
>If your proposal using ACH header is applied,
>the specific HW parsing MIP ID TLV at line rate is required for these functions, right?
>
>Thanks,
>Hideki Endo
>
>
>>Hideki,
>>
>>The whole point of this draft has been to ensure OAM packets addressed to out-MIP reach to the egress ports and are not filtered by in-MIP. And a single bit does that work. Efficiency is an internal matter to the box:
>>
>>" This document describes a way of forming OAM messages so that they can be targeted at incoming MIPs and outgoing MIPs, forwarded correctly through the "switch fabric", and handled efficiently in node implementations where there is no distinction between the incoming and outgoing MIP."
>>
>>
>>It makes me wonder Have you implemented this feature or just doing a research exercise? I as a chip architect have hard time implementing this feature. This is a fact, and you can choose to ignore it.
>>
>>
>>
>>Regards,
>>Shahram
>>
>>
>>On Dec 4, 2012, at 3:49 AM, "hideki.endo.es@hitachi.com" <hideki.endo.es@hitachi.com> wrote:
>>
>>> Shahram,
>>> 
>>> You replied to Rolf in other mail;
>>> "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. "
>>> Yes, that's right.
>>> This was my point.
>>> 
>>> Again, 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 tree having 100 leafs.
>>> 
>>> Thanks,
>>> Hideki Endo
>>> 
>>> 
>>>> I didn't say I don't need MIPID. I said MIPID lookup can happen in CPU.
>>>> 
>>>> Regards,
>>>> Shahram
>>>> 
>>>> 
>>>> On Dec 4, 2012, at 12:56 AM, "hideki.endo.es@hitachi.com" <hideki.endo.es@hitachi.com> wrote:
>>>> 
>>>>> Sharhram,
>>>>> 
>>>>> I didn't mean new requirement similar to Figure 7.
>>>>> I do think that OAM packets must go through the normal forwarding engine
>>>>> without bypass.
>>>>> 
>>>>> As Rolf said in other e-mail,
>>>>>                        --------------------------
>>>>>                       |                     -----|
>>>>>                       |                    | MIP1|
>>>>>                       |                 ->-|     |->----
>>>>>                       |                |   | Out |
>>>>>                       |                |   | i/f |
>>>>>                       |                |    -----|
>>>>>                       |-----           |    -----|
>>>>>                       | MIP0|    ----  |   | MIP2|
>>>>>                       |     |   |    |-    |     |
>>>>>                ----->-| In  |->-| FW |--->-| Out |->----
>>>>>                       | i/f |   |    |-    | i/f |
>>>>>                       |-----     ----  |    -----|
>>>>>                       |                |    -----|
>>>>>                       |                |   | MIP3|
>>>>>                       |                |   |     |
>>>>>                       |                 ->-| Out |->----
>>>>>                       |                    | i/f |
>>>>>                       |                     -----|
>>>>>                        --------------------------
>>>>> The OAM framework describes needs for identifing MIP1 or MIP2 or MIP3 in the P2MP tree individually.
>>>>> Here, each out-MIP has different MIP ID.
>>>>> If you don't need this machanism,
>>>>> how does a out-MIP verify whether the OAM packet is sent to the out-MIP or not? 
>>>>> 
>>>>> Thanks,
>>>>> Hideki Endo
>>>>> 
>>>>> 
>>>>>> Hideki,
>>>>>> 
>>>>>> In summary your requirement is similar to Figure 7 , where you are going to bypass the normal forwarding  engine and do unicast forwarding of a multicast   OAM packet to a single outgoing port.  This kind of behavior is explicitly rejected in the draft.
>>>>>> 
>>>>>> Regards,
>>>>>> Shahram
>>>>>> 
>>>>>> 
>>>>>> On Dec 3, 2012, at 10:00 PM, "S. Davari" <davarish@yahoo.com> wrote:
>>>>>> 
>>>>>>> Hi Hideki,
>>>>>>> 
>>>>>>> I think we have a fundamental problem statement difference. Based on your examples I think you are looking in to how to send an OAM packet only to a single out-MIP out of Nxout-MIPs in a P2MP LSP.
>>>>>>> 
>>>>>>> But I don't think this is architecturally sound or even required. Imagine there is no in-MIP at all. We want a multicast OAM packet behaves like a data packet and be replicated to all egress ports. Now if a MIP is configured in say 2 of the egress ports and not the other 98 ones, then the 98 egress ports will drop the OAM packet in HW and won't send them to their CPU. For the other 2 ports with Out-MIP, both will send the packets to their CPU and both CPUs have to process and respond such as with link trace reply or Loopback reply, etc.
>>>>>>> 
>>>>>>> 
>>>>>>> Regards,
>>>>>>> Shahram
>>>>>>> 
>>>>>>> 
>>>>>>> On Dec 3, 2012, at 5:24 PM, <hideki.endo.es@hitachi.com> wrote:
>>>>>>> 
>>>>>>>> Hi Shahram,
>>>>>>>> 
>>>>>>>> Back and forth.
>>>>>>>> Here, let's focus on whether using MIP ID requires unnecessarily parsing in HW or not.
>>>>>>>> 
>>>>>>>>> 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.
>>>>>>>> Don't you consider the case when MIPs is configured in the Egress port B,C and D?
>>>>>>>> In the case of P2MP, we need to identify the only one out-MIP of these out-MIPs in port B,C and D.
>>>>>>>> In that case, your solution has low effectiveness as I pointed out.
>>>>>>>> Do I miss something?
>>>>>>>> 
>>>>>>>> Thanks,
>>>>>>>> Hideki Endo
>>>>>>>> 
>>>>>>>> 
>>>>>>>>> Hi,
>>>>>>>>> 
>>>>>>>>> Using MIP ID as the only method to filter OAM packets to CPU/Processor is not practical. There are many OAM PDUs such as BFD, LSP-Ping, RFC6374 LM/DM, etc. Each has its own format and the TLV can be anywhere. Using MIP ID as the only identifier requires unnecessarily parsing of all these different packet types at line rate in HW.
>>>>>>>>> 
>>>>>>>>> Why not just use a simple bit in the ACH header? We need a n indicator in a fixed location or the solution is not going to be practical in HW.
>>>>>>>>> 
>>>>>>>>> Thanks,
>>>>>>>>> Shahram
>>>>>>>>> 
>>>>>>>>> -----Original Message-----
>>>>>>>>> From: Shahram Davari 
>>>>>>>>> Sent: Monday, December 03, 2012 4:53 PM
>>>>>>>>> To: 'hideki.endo.es@hitachi.com'
>>>>>>>>> Cc: Rolf.Winter@neclab.eu; 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 mailing list
>mpls@ietf.org
>https://www.ietf.org/mailman/listinfo/mpls
>