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

From: Luca Martini <[email-masked]>
Date: Thu, 03 Jan 2013 12:03:29 -0700

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: [email-masked] [[email-masked]] on behalf of Luca Martini [[email-masked]]
> 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
> [email-masked]
> 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.
>
>

---

From: Alexander Vainshtein <[email-masked]>
Date: Sun, 6 Jan 2013 13:29:07 +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 [[email-masked]]
Sent: Thursday, January 03, 2013 8:03 PM
To: Alexander Vainshtein
Cc: pwe3; [email-masked]
Subject: Re: [PWE3] draft-ietf-pwe3-rfc4447bis-00.txt Notes

Yes.