Re: [mpls] working group last call on draft-ietf-mpls-tp-mip-mep-map
"Adrian Farrel" <adrian@olddog.co.uk> Wed, 21 November 2012 09:16 UTC
Return-Path: <adrian@olddog.co.uk>
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 84EE221F84CA for <mpls@ietfa.amsl.com>; Wed, 21 Nov 2012 01:16:08 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.265
X-Spam-Level:
X-Spam-Status: No, score=-2.265 tagged_above=-999 required=5 tests=[AWL=-0.266, BAYES_00=-2.599, J_CHICKENPOX_15=0.6]
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 wnBoWakqbxAS for <mpls@ietfa.amsl.com>; Wed, 21 Nov 2012 01:16:07 -0800 (PST)
Received: from asmtp5.iomartmail.com (asmtp5.iomartmail.com [62.128.201.176]) by ietfa.amsl.com (Postfix) with ESMTP id 6C9C721F84B2 for <mpls@ietf.org>; Wed, 21 Nov 2012 01:16:07 -0800 (PST)
Received: from asmtp5.iomartmail.com (localhost.localdomain [127.0.0.1]) by asmtp5.iomartmail.com (8.13.8/8.13.8) with ESMTP id qAL9G1JL008417; Wed, 21 Nov 2012 09:16:02 GMT
Received: from 950129200 (47.Red-88-2-96.staticIP.rima-tde.net [88.2.96.47]) (authenticated bits=0) by asmtp5.iomartmail.com (8.13.8/8.13.8) with ESMTP id qAL9FwL5008398 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Wed, 21 Nov 2012 09:16:00 GMT
From: Adrian Farrel <adrian@olddog.co.uk>
To: 'Shahram Davari' <davari@broadcom.com>
References: <5098CF68.2000105@pi.nu><XNM1$7$0$0$$6$1$2$A$5003661U50a19cc6@hitachi.com> <50A3B5C0.4060203@pi.nu> <01e601cdc652$dab31600$4001a8c0@gateway.2wire.net> <016e01cdc675$3b64d6b0$b22e8410$@olddog.co.uk> <4A6CE49E6084B141B15C0713B8993F281BD2E957@SJEXCHMB12.corp.ad.broadcom.com>
In-Reply-To: <4A6CE49E6084B141B15C0713B8993F281BD2E957@SJEXCHMB12.corp.ad.broadcom.com>
Date: Wed, 21 Nov 2012 09:16:01 -0000
Message-ID: <027c01cdc7c8$d5500430$7ff00c90$@olddog.co.uk>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Outlook 14.0
Thread-Index: AQDwTq+cva56r/gyEHDyHZEPyR6eEgEKgN8HAb1Qi9MDDe5DeAGRyH3pAWHDGtOZaJiNoA==
Content-Language: en-gb
Cc: 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
Reply-To: adrian@olddog.co.uk
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: Wed, 21 Nov 2012 09:16:08 -0000
<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; 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; 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] 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