[mpls] Questions to draft-farrel-mpls-tp-mip-mep-map-03
Greg Mirsky <gregimirsky@gmail.com> Fri, 22 October 2010 23:29 UTC
Return-Path: <gregimirsky@gmail.com>
X-Original-To: mpls@core3.amsl.com
Delivered-To: mpls@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9F3AD3A67D1; Fri, 22 Oct 2010 16:29:42 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.383
X-Spam-Level:
X-Spam-Status: No, score=-2.383 tagged_above=-999 required=5 tests=[AWL=0.216, BAYES_00=-2.599]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id orEbaYHAVjO7; Fri, 22 Oct 2010 16:29:41 -0700 (PDT)
Received: from mail-yw0-f44.google.com (mail-yw0-f44.google.com [209.85.213.44]) by core3.amsl.com (Postfix) with ESMTP id 298B93A67BE; Fri, 22 Oct 2010 16:29:40 -0700 (PDT)
Received: by ywp6 with SMTP id 6so483013ywp.31 for <multiple recipients>; Fri, 22 Oct 2010 16:31:19 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:date:message-id :subject:from:to:content-type; bh=bse86rVPrNcmVeD+OZMLdfOVc6dDIYe3jhNzODG4D78=; b=vmlBkPjc+BO1myHNUtQ0A2H90h+lpwhx9qeVM1vqf29LiZBUqY4QrQDtLdCc0FZ8zU tAgnlNcz1jJ9x13VX4RnZ7eSMVMhC+DSmjKMT6aPE3o286TK3u04rQZAFBdXgg7g5Y4X 4dPJssJ+kV/KG66OJy3UtU/T9cK+uCcTs9pSQ=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; b=Lf6Li0ZZRBuoYLFkIeoMcx/A2tqcYqMcXXIMkW+dLIkMp4ZYTeQZgSEqgpDhCuf11r XmyEwVZy36GNRm3Sh9ZljVCfIGmQCxALITOLK0PlPVjjf8NL9TfEtPRROFYeHwbfrh3/ S3uXNLSN4SIUlh8ROg2er3qLk2JA4F+UxOWAw=
MIME-Version: 1.0
Received: by 10.229.95.19 with SMTP id b19mr2873770qcn.64.1287790279614; Fri, 22 Oct 2010 16:31:19 -0700 (PDT)
Received: by 10.220.177.130 with HTTP; Fri, 22 Oct 2010 16:31:19 -0700 (PDT)
Date: Fri, 22 Oct 2010 16:31:19 -0700
Message-ID: <AANLkTimr9pGxXLJNuNoH4nX23-hbdzckw-J_rjCAxh8F@mail.gmail.com>
From: Greg Mirsky <gregimirsky@gmail.com>
To: Adrian Farrel <Adrian.Farrel@huawei.com>, hideki.endo.es@hitachi.com, rolf.winter@neclab.eu, mpls-tp@ietf.org, mpls@ietf.org
Content-Type: text/plain; charset="ISO-8859-1"
Subject: [mpls] Questions to draft-farrel-mpls-tp-mip-mep-map-03
X-BeenThere: mpls@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Multi-Protocol Label Switching WG <mpls.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/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: Fri, 22 Oct 2010 23:29:42 -0000
Dear Authors and All, please find my questions below: - Somewhat generic - perhaps could clarify that PW MIP can be only on MS-PW as SS-PW have only MEPs. - OAM messages for the transit points of pseudowires (PWs) or Label Switched Paths (LSPs) are delivered using the expiration of the MPLS shim header time-to-live (TTL) field. Can this be interpreted as TTL expiration been proposed as the only method for TCM? Does that excludes use of H-LSP for MPLS-TP LSP? - OAM messages for the end points of PWs and LSPs are simply delivered as normal. I think that need to mention that MEP must process OAM messages with properly expired TTL as well. - In PWs, the mechanism used is the presence of the PW Associated Channel Header (PWACH) Does that mean that support of PW CW is mandatory if MPLS-TP OAM is required for the given PW? Should we consider proposal draft-lm-pwe3-mpls-tp-gal-in-pw-00 to extend use of GAL for MPLS-TP PW thus removing exclusion made in the first sentence of Section 4.2 RFC 5586? - This document describes a way of forming OAM messages so that they can be targeted at incoming MIPs and outgoing MIPs ... I believe that addressing of per-interface MIPs as well as per-node MIP require clarification and definition. Perhaps it proper wording can be added to clarify scope of the document. - Figure 1, in my view, presents abstract MPLS-TP Node with per-interface MIP while Figure 2 might be referred not only as presentation of Optimized MPLS-TP Node but presentation of MPS-TP Node with per-node MIP. - CV between a MEP and a MIP Does "CV" imply "CC or CV" session? Would TCM require support of CC/CV between two MIP on different MPLS-TP nodes? - OAM must operate on MPLS-TP nodes that are branch points on point-to-multipoint (P2MP) trees ... Would operation on bud node of p2mp present additional case or node can be viewed as combination of OAM to MEP and OAM to MIP. How these are differentiated? - ... the identifier TLV MUST be in a fixed location after the ACH/PWACH That might be hard to achieve if both CC and CV to be supported by MIP. - The Channel Type field of the PWACH [RFC4385] indicates that the packet is OAM. The following ACH needs to be further examined. I believe that there's no "following ACH" but only PWACH in case of PW OAM. - In addition to Section 5. I think that adding Node MIP capability sub-object to RRO might help originator of OAM messages directed at a MIP encode OAM message with consideration of capability (per-node MIP or per-interface MIP) of the addressee. Regards, Greg