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

Luca Martini <lmartini@cisco.com> Thu, 03 January 2013 19:03 UTC

Return-Path: <lmartini@cisco.com>
X-Original-To: pwe3@ietfa.amsl.com
Delivered-To: pwe3@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4DA2321F86C8; Thu, 3 Jan 2013 11:03:37 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level:
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599]
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 tBhDrT6IkxeY; Thu, 3 Jan 2013 11:03:36 -0800 (PST)
Received: from napoleon.monoski.com (napoleon.monoski.com [70.90.113.113]) by ietfa.amsl.com (Postfix) with ESMTP id 6BAAC21F861F; Thu, 3 Jan 2013 11:03:36 -0800 (PST)
Received: from confusion.monoski.com (confusion.monoski.com [209.245.27.2]) (authenticated bits=0) by napoleon.monoski.com (8.13.8/8.13.8) with ESMTP id r03J3Ufm017174 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 3 Jan 2013 12:03:32 -0700 (MST)
Message-ID: <50E5D601.1010604@cisco.com>
Date: Thu, 03 Jan 2013 12:03:29 -0700
From: Luca Martini <lmartini@cisco.com>
User-Agent: Mozilla/5.0 (X11; Linux i686 on x86_64; rv:16.0) Gecko/20121026 Thunderbird/16.0.2
MIME-Version: 1.0
To: Alexander Vainshtein <Alexander.Vainshtein@ecitele.com>
References: <4FFC75D9.5080604@cisco.com> <F9336571731ADE42A5397FC831CEAA02099BD8@FRIDWPPMB001.ecitele.com>
In-Reply-To: <F9336571731ADE42A5397FC831CEAA02099BD8@FRIDWPPMB001.ecitele.com>
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: 7bit
Cc: "mpls@ietf.org" <mpls@ietf.org>, pwe3 <pwe3@ietf.org>
Subject: Re: [PWE3] draft-ietf-pwe3-rfc4447bis-00.txt Notes
X-BeenThere: pwe3@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Pseudo Wires Edge to Edge <pwe3.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/pwe3>, <mailto:pwe3-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/pwe3>
List-Post: <mailto:pwe3@ietf.org>
List-Help: <mailto:pwe3-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/pwe3>, <mailto:pwe3-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 03 Jan 2013 19:03:37 -0000

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