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, 6 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
Content-Type: text/plain; charset="us-ascii"
content-transfer-encoding: quoted-printable
MIME-Version: 1.0
Cc: "mpls@ietf.org" <mpls@ietf.org>, pwe3 <pwe3@ietf.org>
Subject: Re: [mpls] [PWE3] draft-ietf-pwe3-rfc4447bis-00.txt Notes
Precedence: list

Luca,
Lots of thanks for a detailed response. 

I see that in the time that has passed since my original review what has bee=
n draft-raza then has become a WG document of the MPLS WG.

I I have said before, I wholeheartedly support advancing 4447 to Internet St=
andard.

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 de=
ployment and operational experience.
2. No unused features in the specification that greatly increase implementat=
ion complexity.

The original 4447 (without the change) would definitely meet these requireme=
nts. 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 l=
abels 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 discus=
sing) widely deployed?
- if, as I guess, the answer to both questions above is negative, does not t=
he proposed change fall under the category of an unused feature in the speci=
fication that adds complexity to implementations?

Again, I do not have technical concerns about the proposed changes, but I ha=
ve procedural concerns about their impact on advancing 4447 to Internet Stan=
dard.

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 curre=
nt 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 m=
anner, 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 statemen=
t in RFC 5036, Section 2.6:
>       However, for any given LDP session, each LSR must be aware of the la=
bel distribution method used by its peer
>       in order to avoid situations where one peer using Downstream  Unsoli=
cited 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.t=
xt>
I am making sure thsi document is compliant with that.
<http://tools.ietf.org/html/draft-ietf-mpls-ldp-applicability-label-adv-00.t=
xt>

> 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 st=
atements 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 IMH=
O. It could also put 4447bis on hold if an explicit dependency is created. A=
t 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.t=
xt>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 Mart=
ini [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 inform=
ation 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, p=
hone or fax, and then delete the original and all copies thereof.
>
>

This e-mail message is intended for the recipient only and contains informat=
ion which is CONFIDENTIAL and which may be proprietary to ECI Telecom. If yo=
u have received this transmission in error, please inform us by e-mail, phon=
e or fax, and then delete the original and all copies thereof.