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
> >
>