[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