Re: [mpls] [PWE3] draft-ietf-pwe3-rfc4447bis-00.txt Notes

Alexander Vainshtein <Alexander.Vainshtein@ecitele.com> Sun, 06 January 2013 13:29 UTC

Return-Path: <Alexander.Vainshtein@ecitele.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 5148521F8775 for <mpls@ietfa.amsl.com>; Sun, 6 Jan 2013 05:29:29 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.202
X-Spam-Level:
X-Spam-Status: No, score=-5.202 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_MED=-4, UNPARSEABLE_RELAY=0.001]
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 ox6-aSCnnNaf for <mpls@ietfa.amsl.com>; Sun, 6 Jan 2013 05:29:28 -0800 (PST)
Received: from mail1.bemta3.messagelabs.com (mail1.bemta3.messagelabs.com [195.245.230.34]) by ietfa.amsl.com (Postfix) with ESMTP id A0A0121F876E for <mpls@ietf.org>; Sun, 6 Jan 2013 05:29:25 -0800 (PST)
Received: from [85.158.138.51:55736] by server-2.bemta-3.messagelabs.com id F3/43-11239-62C79E05; Sun, 06 Jan 2013 13:29:10 +0000
X-Env-Sender: Alexander.Vainshtein@ecitele.com
X-Msg-Ref: server-12.tower-174.messagelabs.com!1357478948!19707786!1
X-Originating-IP: [147.234.242.234]
X-StarScan-Received:
X-StarScan-Version: 6.6.1.8; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7672 invoked from network); 6 Jan 2013 13:29:09 -0000
Received: from ilptbmg01-out.ecitele.com (HELO ilptbmg01-out.ecitele.com) (147.234.242.234) by server-12.tower-174.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 6 Jan 2013 13:29:09 -0000
X-AuditID: 93eaf2e7-b7f816d00000698d-9d-50e974a795fd
Received: from ILPTEXCH02.ecitele.com ( [147.234.245.181]) by ilptbmg01-out.ecitele.com (Symantec Messaging Gateway) with SMTP id 25.21.27021.7A479E05; Sun, 6 Jan 2013 14:57:11 +0200 (IST)
Received: from ILPTWPVEXCA01.ecitele.com (172.31.244.224) by ILPTEXCH02.ecitele.com (147.234.245.181) with Microsoft SMTP Server (TLS) id 8.3.264.0; Sun, 6 Jan 2013 15:29:08 +0200
Received: from ILPTWPVEXMB02.ecitele.com ([fe80::5979:ca8d:419f:56df]) by ILPTWPVEXCA01.ecitele.com ([fe80::ac15:43ab:d541:dfa7%12]) with mapi id 14.02.0328.009; Sun, 6 Jan 2013 15:29:07 +0200
From: Alexander Vainshtein <Alexander.Vainshtein@ecitele.com>
To: Luca Martini <lmartini@cisco.com>
Thread-Topic: [PWE3] draft-ietf-pwe3-rfc4447bis-00.txt Notes
Thread-Index: AQHNXsrYgfdlUXxfr0mSCyPb8SZy+Zcjf45XgRVrXYCABHSHSg==
Date: Sun, 06 Jan 2013 13:29:07 +0000
Message-ID: <F9336571731ADE42A5397FC831CEAA020DA87D5F@ILPTWPVEXMB02.ecitele.com>
References: <4FFC75D9.5080604@cisco.com> <F9336571731ADE42A5397FC831CEAA02099BD8@FRIDWPPMB001.ecitele.com>, <50E5D601.1010604@cisco.com>
In-Reply-To: <50E5D601.1010604@cisco.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [147.234.1.2]
Content-Type: text/plain; charset="us-ascii"
content-transfer-encoding: quoted-printable
MIME-Version: 1.0
X-Brightmail-Tracker: H4sIAAAAAAAAA3VTa0gUURTuzj4YN6emTd27S+QwWlC5sssaKO5GBZHVD7cHRIVs4+xtd2h3 ZtsZTevPYj+iLexJkFhaWfaiyJ70bnuZFAmGVFRUZupmWSa9FGtmJ02I7q/v3u875zvncg6u MX7XW3COl1CYZwK03qDdGe+NW+ulLrftQMSR++zQUd1MUFBX9wNzg+UR4GR4XpAYCVFeJLIu 2h3mShm2nKY4r4u201QowLAoiHjJRTOhEOK99AwD9c9xyjKOpxDPCl6O97noeYsLrbm50/Os dnrG5Ay7I9+wxM+JFLIGGS5ABZEoMj5EyS8rz2r8fdWLQwedZRv2vtZGwEtbFCThkMyBV/c1 61WcBptfnkpgI3kdwB99KSq+AODpekcUGGR8G8BI6ymtQuhJF2w4/iIRkEJOgidv9QMFa8g8 eONeRUIznsyHfXuimKpxwqcbB/7g2XBrw44E1pKZsP3jK10U4DhBuuGvDXbVaxOAB1uf6BRN EjkF3mk5k/ACcqHfmk5gqpcJPntbg6kNkLDuyiONilNhV9ugTsXp8My5Np2qz4K1l3v1Kp4G D+9/n9AT5Dh4f89brdqwFTY1RrFtAFaNsKgaEV41IrxqRHgt0B4DqVwgJBUHfTZ7NmI5CQVQ NisEG4A6JB0Xwc+azBggcUAnE40NnW6jjikVy4MxYMYxOpXQiV1u45hiwVvuZ0S/J1wSQGIM QFxDpxBb8mSO8DLl61BYGKLmyD+4XWMZzQryOPKSx2Gz/f9Cm4j6yNJCI+mTh3E1QiEUHsoz AcdpSBjWyxbjwsiHylZxAekvjeFJShnJchmv1ylliCEmKHI+lW8CDryr6Xk7wO/uftEOjFpe 4JHFRPQoUlKR+kv44WxDCxMHJvkbxhOfFFWyvE7D+eKyFSZbobYOxUpenWHKEgE1uYOdXw+d zxi7jM3f2q0b63m4dGHLK+q2OTqtwNxRYd5VJLz54NRfIIo+j8nanNaftXNL9aX4APtl+1oW GFbYhFm1+33pBUXQknGseMFcU2ZO5WEsNr92wpru0lFTPNCQMausZN/Ea8mliypjZwuP4O6b 7zwnzBHPgsqeB80rH9Na0c/Yp2rCIvMbU6YjXQsEAAA=
Cc: "mpls@ietf.org" <mpls@ietf.org>, pwe3 <pwe3@ietf.org>
Subject: Re: [mpls] [PWE3] draft-ietf-pwe3-rfc4447bis-00.txt Notes
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: Sun, 06 Jan 2013 13:29:29 -0000

Luca,
Lots of thanks for a detailed response. 

I see that in the time that has passed since my original review what has been draft-raza then has become a WG document of the MPLS WG.

I I have said before, I wholeheartedly support advancing 4447 to Internet Standard.

However, according to RFC 6410, an Internet Standard must meet the following requirements that IMHO are relevant for 4447bis:

1. At least two independent interoperable implementations with widespread deployment and operational experience.
2. No unused features in the specification that greatly increase implementation complexity.

The original 4447 (without the change) would definitely meet these requirements. I am less sure about the proposed modification, and hence worried about possible delays in the process:
- are there two independent interoperable implementations that exchange PW labels using DU mode of LDP over a session that has been negotiated as DoD?
- are these implementation  (and the specific mode of operation we're discussing) widely deployed?
- if, as I guess, the answer to both questions above is negative, does not the proposed change fall under the category of an unused feature in the specification that adds complexity to implementations?

Again, I do not have technical concerns about the proposed changes, but I have procedural concerns about their impact on advancing 4447 to Internet Standard.

Hopefully this clarifies my position.

Regards,
     Sasha

________________________________________
From: Luca Martini [lmartini@cisco.com]
Sent: Thursday, January 03, 2013 8:03 PM
To: Alexander Vainshtein
Cc: pwe3; mpls@ietf.org
Subject: Re: [PWE3] draft-ietf-pwe3-rfc4447bis-00.txt Notes

On 07/10/12 23:21, Alexander Vainshtein wrote:
> Luca (and all),
> I fully support the idea of progressing RFC 4447 to Internet Standard.
>
> Looking up the draft, I have found the following difference with the current text:
>
> RFC 4447, Section 3:
>        LDP MUST be used in its  "downstream unsolicited" mode.
> which is quite unambiguous.
>
>
> draft-ietf-pwe3-rfc4447bis-00, Section 3, changes this to:
>        LDP MUST exchange PW FEC label bindings in downstream unsolicited manner, independent of the
>        negotiated label advertisement mode of the LDP session.
>
> I assume that this is the change you've had in mind when you said:
> ""Added text to specify that downstream unsolicited bit does not apply to PW application..."
> even if the actual text states that it does apply.
Yes.
> But, what is more serious, this seems to contradict the following statement in RFC 5036, Section 2.6:
>       However, for any given LDP session, each LSR must be aware of the label distribution method used by its peer
>       in order to avoid situations where one peer using Downstream  Unsolicited label distribution assumes its peer is also.
Yes. the MPLS wg is in the process of fixing that problem. There is a
draft already in the queue there.
Please see draft-ietf-mpls-ldp-applicability-label-adv-00.txt .
<http://tools.ietf.org/html/draft-ietf-mpls-ldp-applicability-label-adv-00.txt>
I am making sure thsi document is compliant with that.
<http://tools.ietf.org/html/draft-ietf-mpls-ldp-applicability-label-adv-00.txt>

> and further in Section 2.6.3:
>    Each interface on an LSR is configured to operate in either
>    Downstream Unsolicited or Downstream on Demand advertisement mode.
>    LSRs exchange advertisement modes during initialization.
>
> I am not sure that the proposed change in 4447 complies with the quoted statements in 5036.
It is not supposed to comply with those statements.
>
> A reference (in the notes only, not in the draft) to draft-raza (which has not yet been posted as a WG document) does not justify such a deviation IMHO. It could also put 4447bis on hold if an explicit dependency is created. At the very least we should hear what the MPLS WG has to say on that.
>
> And, speaking about references, I see that RFC 4448 is marked as "Work in Progress" in the draft.
So draft-ietf-mpls-ldp-applicability-label-adv-00.txt proposes exactly
the
<http://tools.ietf.org/html/draft-ietf-mpls-ldp-applicability-label-adv-00.txt>text
that i added to rfc4447bis. I suggest that you send comments the mpls
ldp mode bit to the MPLS WG.

I believe that is a typo.
will fix it.
> Is it just a typo, or do you imply that it is going to undergo a revision soon?
>
> Hopefully these notes will be useful.
Thank you for the review !
Luca

> Regards,
>      Sasha
>
> ________________________________________
> From: pwe3-bounces@ietf.org [pwe3-bounces@ietf.org] on behalf of Luca Martini [lmartini@cisco.com]
> Sent: Tuesday, July 10, 2012 8:35 PM
> To: pwe3
> Subject: [PWE3] draft-ietf-pwe3-rfc4447bis-00.txt Notes
>
> WG,
>
> At the request of the chairs, I have posted the initial version of an
> update to rfc4447.
>
> This is the next step in the process defined by rfc6410 to progress this
> document to "Internet Standard".
> Quoting rfc6410:
>
> "   A specification may be, and indeed, is likely to be, revised as it
>     advances from Proposed Standard to Internet Standard.  When a revised
>     specification is proposed for advancement to Internet Standard, the
>     IESG shall determine the scope and significance of the changes to the
>     specification, and, if necessary and appropriate, modify the
>     recommended action.  Minor revisions and the removal of unused
>     features are expected, but a significant revision may require that
>     the specification accumulate more experience at Proposed Standard
>     before progressing."
>
> According to the above guidelines, I have revised the rfc4447 document
> to incorporate all erratas , and a WG discussions about the PW
> encapsulation being symmetric in both direction of traffic. I also added
> a clarification about the LDP mode bit as per MPLS WG discussion.
> Let me know what else I might have missed.
>
> Here is a list of changes from my log:
> --------------------------------------------------------------------------------------------------------------------------------
> - Updated all references - published v00 of bis rfc draft
> - Added clarification about PW always being symmetrical in both
> direction of traffic.
> - Changed Generalized ID FEC element, and  Generalized PWid FEC element
> to >> Generalized PWid FEC element to be consistent with IANA allocation
> and within the document ( this was noted in errata, but IMHO incorrectly
> rejected )
> - Errata ID: 1530 - accepted
> - Errata ID: 3112 - accepted
> - Errata ID: 3114 - accepted
> - Errata ID: 3115 - removed table
> - Errata ID: 86 - accepted
> - Errata ID: 938  - accepted
> - Added text to specify that downstream unsolicited bit does not apply
> to pw application according to
> draft-raza-mpls-ldp-applicability-label-adv-02.txt (WG document of MPLS WG)
> - made source identical , to rfc
>
> --------------------------------------------------------------------------------------------------------------------------------
>
> Thanks.
> Luca
> _______________________________________________
> pwe3 mailing list
> pwe3@ietf.org
> https://www.ietf.org/mailman/listinfo/pwe3
> This e-mail message is intended for the recipient only and contains information which is CONFIDENTIAL and which may be proprietary to ECI Telecom. If you have received this transmission in error, please inform us by e-mail, phone or fax, and then delete the original and all copies thereof.
>
>

This e-mail message is intended for the recipient only and contains information which is CONFIDENTIAL and which may be proprietary to ECI Telecom. If you have received this transmission in error, please inform us by e-mail, phone or fax, and then delete the original and all copies thereof.