Early Review of draft-ietf-pals-rfc4447bis-03
review-ietf-pals-rfc4447bis-03-rtgdir-early-farrel-2016-02-26-00

Hello,

I have been selected as the Routing Directorate reviewer for this draft. The
Routing Directorate seeks to review all routing or routing-related drafts as
they pass through IETF last call and IESG review. The purpose of the review is
to provide assistance to the Routing ADs. For more information about the
Routing Directorate, please see ​

http://trac.tools.ietf.org/area/rtg/trac/wiki/RtgDir

Although these comments are primarily for the use of the Routing ADs, it would
be helpful if you could consider them as the draft advances, and strive to
resolve them through discussion or by updating the draft.

Thanks,
Adrian

===

Document: draft-ietf-pals-rfc4447bis-03.txt
Reviewer: Adrian Farrel
Review Date: 21 February 2016
IETF LC End Date: Not yet started
Intended Status: Internet Standard

= Summary =

I have some minor concerns about this document that I think should be resolved
before publication.

= Comments =

I'm OK to see 4447 being advanced to full standard, although I'm also a little
surprised that there was energy to do it.

The work is largely mechanical. My comments are a mix of minor process concerns
(that your AD should be able to resolve), minor text clarifications, and nits.

It's been a while since I was concerned with LDP, but I have no reason to doubt
the integrity of this document.

= Major Issues =

No major issues found.

= Minor Issues =

I believe that this document should be marked as obsoleting 4447 and
6723. It will result in a new RFC with a new number, so 4447 will no
longer be relevant. And, as Section 1 says: a new section (6.3) on
control-word renegotiation by label request message has been added,
obsoleting RFC 6723.

By the way, it is section 7.3 (not 6.3) that you have added!

[NB: Q16 of the Shepherd write-up seems a bit garbled on this front.
Especially "Will publication of this document change the status of any
existing RFCs?" seems to need a much clearer answer!]

---

I'm not up to speed on the new process for advancing a specification to
Internet-Standard when it has normative references that are not
similarly advanced/advancing. I do know that the process changed
recently and I am sure that your AD can look it up.

---

It might be a reasonable question to ask why some of the
(informatively) referenced related PW RFCs (such as encapsulations)
are not being advanced at the same time, especially those that are
described as "companion documents".

---

It seems unnecessary petty-fogging process, but the inclusion of
section 7.3 seems to me to defeat the stability requirement for
advancement to Internet Standard unless your claim here is that you
are advancing 4447 and 6723 together in this single document. That
might be fine.

---

The Errata that have been deliberately disregarded need to be marked as
Rejected. I think the ones that have been actioned could usefully be
marked as Verified or have a note added saying "fixed in RFCabcd".

As far as I can tell:

3554 was not actioned
938 was done
86 was done
3555 was done
3115 no longer applies
3114 was done
3112 was done
1530 was done

---

Because you (incorrectly) said that section 6.3 was new text, I gave it
careful review. I think the text is in rather poor state:

For example, in 6.3.1...

   Using the procedures
   outlined in this section, a simple label withdraw method MAY also be
   supported as a legacy means of signaling PW status and AC status.

...Since this is *the* specification now, what does "legacy" mean?

Indeed, you end 6.3.1 with...
   The PW status
   signaling procedures described in this section MUST be fully
   implemented.
...which kind of implies ... hmm.

I think you could rework 6.3.1 to handle this more gracefully and avoid
the "clunk" of the 2nd para...

   Once the PW status negotiation procedures are completed and if they

...where we are surprised to hear about status negotiation.

For example:

OLD
   The PEs MUST send Label Mapping Messages to their peers as soon as
   the PW is configured and administratively enabled, regardless of the
   attachment circuit state.  The PW label should not be withdrawn
   unless the operator administratively configures the pseudowire down
   (or the PW configuration is deleted entirely).  Using the procedures
   outlined in this section, a simple label withdraw method MAY also be
   supported as a legacy means of signaling PW status and AC status.  In
   any case, if the label-to-PW binding is not available the PW MUST be
   considered in the down state.

   Once the PW status negotiation procedures are completed and if they
   result in the use of the label withdraw method for PW status
   communication, and this method is not supported by one of the PEs,
   then that PE must send a Label Release Message to its peer with the
   following error:

   "Label Withdraw PW Status Method Not Supported"

   If the label withdraw method for PW status communication is selected
   for the PW, it will result in the Label Mapping Message being
   advertised only if the attachment circuit is active.  The PW status
   signaling procedures described in this section MUST be fully
   implemented.
NEW
   The PEs MUST send Label Mapping Messages to their peers as soon as
   the PW is configured and administratively enabled, regardless of the
   attachment circuit state.  The PW label should not be withdrawn
   unless the operator administratively configures the pseudowire down
   (or the PW configuration is deleted entirely).

   Section 6.3.2 describes a mechanism for signaling the status of the
   PW and AC.  Additionally, a simple label withdraw method MAY be used
   to signal the PW status and AC status.  In any case, if the label-to-
   PW binding is not available the PW MUST be considered to be in the
   down state.

   The PEs negotiate which PW and AC status signaling mechanism to use
   by following the procedures in Section 6.3.3.  If the PW negotiation
   procedures are completed and if they result in the use of the simple
   label withdraw method for PW status communication, and if this method
   is not supported by one of the PEs then that PE must send a Label
   Release Message to its peer with the following error:

   "Label Withdraw PW Status Method Not Supported"

   If the label withdraw method for PW status communication is selected
   for the PW, it will result in the Label Mapping Message being
   advertised only if the AC is active.

   The PW status signaling procedures described in Section 6.3.2 MUST be
   fully implemented.
END

---

Section 6.3.2 achieves ambiguity by stating...
   The general format of the Notification Message is:
...and then showing the specific case of "PW status".

You can fix this by re-ordering and tweaking slightly, as follows.

Note that the old text says:
   Since this notification does not
   refer to any particular message, the Message Id and Message Type
   fields are set to 0.
...but I think the Message Type is set to 0x0001 :-)

OLD
   The Status TLV is transported to the remote PW peer via the LDP
   Notification message.  The general format of the Notification Message
   is:

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |0|   Notification (0x0001)     |      Message Length           |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                       Message ID                              |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                       Status (TLV)                            |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                      PW Status TLV                            |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |           PWId FEC TLV or Generalized ID FEC TLV              |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |               PW Grouping ID TLV (Optional)                   |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   The Status TLV status code is set to 0x00000028, "PW status", to
   indicate that PW status follows.  Since this notification does not
   refer to any particular message, the Message Id and Message Type
   fields are set to 0.
NEW
   The Status TLV is transported to the remote PW peer via the LDP
   Notification message as described in [RFC5036].

   The Status TLV status code is set to 0x00000028, "PW status", to
   indicate that PW status follows.  The format of the Notification
   Message for carrying the PW Status is as follows:

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |0|   Notification (0x0001)     |      Message Length           |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                       Message ID                              |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                       Status (TLV)                            |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                      PW Status TLV                            |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |           PWId FEC TLV or Generalized ID FEC TLV              |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |               PW Grouping ID TLV (Optional)                   |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Since this notification does not refer to any particular message,
   the Message Id field is set to 0.
END

---

Section 8 could be tidied a little.

The use of "in general" gives the IANA no way to know whether they
should or should not update a reference.

Are you sure that you want to remove the nice, concise listing of code
points that are present in RFC 4447?

8.1, 8.2, and 8.3 all say "new". I suggest deleting that word.

And lastly, "IANA needs to..." is not what we say :-) "IANA is requested
to..." is nicer.

[NB: The Shepherd write-up seems to report all this wrongly at Q17]

---

Shouldn't the whole of Section 10 be moved to an interop report
somewhere? It's presence within the document seems somewhat temporally
unstable. I understand that you want to write it down and record it
somewhere, also that you probably developed it in the I-D as a useful
place for working text. For advice about how and where to do this you
can look at RFC 5657.

You seem to have answered the four points from 6410, but may be missing
a little corroboration.

>  The pseudowire technology was first deployed in 2001 and has been
>  widely deployed by many carriers. [RFC7079] documents the results of
>  a survey of PW implementations, with specific emphasis on Control
>  Word usage.  [EANTC] documents a public multi-vendor interoperability
>  test of MPLS and Carrier Ethernet equipment, which included testing
>  of Ethernet, ATM and TDM pseudowires.

7079 is a slightly related piece of survey work, but the only mention of
LDP (which is the subject of *this* document) is to point out an issue
with non-implementation.

The EANTC reference really needs something that helps us find the report
of the interop event. Possibly this is

http://www.eantc.de/fileadmin/eantc/downloads/events/2007-2010/MPLSEWC09/EANTC-MPLSEWC2009-WhitePaper-v1.0.pdf

Looking at that paper, it definitely supports the claim of multiple
interoperating implementations of 4447.

We lack, however, any statements about "widespread deployment and
successful operational experience."

>  The errata against [RFC4447] are all editorial in nature and have
>  been addressed in this document.

Good (except for those not addressed as above, and except that some of
those errata are incorrectly marked as "Technical").

>  All features in this specification have been implemented by multiple
>  vendors.

How do we know this?
Further, are all the features used? One point of this step in the
process is to prune out features that are unnecessary (and so complicate
implementation and operation, and cost money).

>  There is no IPR filed against this document or its predecessor.

This may be overly vague (you probably mean "No IPR disclosures have
been made to the IETF related to this document, to RFC 4447 or RFC 6723,
or to the Internet-Drafts that resulted in RFC 4447 and RFC 6723.").

---

= Nits =

In the Abstract, probably...

OLD
   This document has been written to address errata in a previous
   version of this standard.
NEW
   This document has been written to address errata in a previous
   version of this specification.
END

But, actually, I think you are missing the main purpose which is to
advance the spec to full standard.

On reflection, I think that this paragraph probably served well in the
draft as it was being processed, but can be removed now. The equivalent
text obviously needs to be in the shepherd write-up.

[ditto the paragraph in the introduction]

---

Thank you for including Section 1. It's important and helpful.

Three tiny points:

Second para should probably s/However/Additionally/

The RFC Editor requires that section 1 is the Introduction. A simple
solution is to swap sections 1 and 2, or to move the current section 2
to be the new section 1 and the current section 1 to be section 1.1.

The text says "A note was added to clarify that the C-bit is part of
the FEC." I think you should s/was/has been/ and you could also usefully
give a little hint as to where the note was added.

---

Shouldn't you mention the inclusion of text referencing 7358? This is
clearly a change to the original text. I wonder, however, whether what
really want to do is take that part of 7358 that updated 4447 and simply
write it here so that this spec has no need of that reference.

Either way, you also need to take care about the stability requirement
for advancement.

---

In 6.2.2.1
please note that IANA has "PW Interface Parameters TLV" not "Interface
Parameters TLV".

The is a good chance to make this consistent.

---

In 6.2.2.2 and the rest of the document, please note that the IANA has
"PW Group ID TLV" not "PW Grouping ID TLV".

The is a good chance to make this consistent.

---

6.3.2 has a figure which claims to include a "PWId FEC TLV" or a
"Generalized ID FEC TLV". However, 6.1 and 6.2 describe these as
"elements" not TLVs and they show up in the Forwarding Equivalence Class
(FEC) Type Name Space.

I think you can clarify 6.3.2 by explaining that what is included here
is "a FEC TLV containing either a PWId FEC element or a Generalized FEC
element.

Then, just after the figure you have "The PW FEC TLV" but it is just a
"FEC TLV"

---

In 7.3 you have "re-provisioned". I wonder whether you mean
"re-configured". "Provisioning" has a context initial set-up, so re-
provisioning suggests (to me?) re-initialization.

---

In the first para of 7.3 you have "PW C-bit negotiation procedure" and
"Control-Word negotiation procedures".

Could you decide on a single name, and on whether it is singular or
plural.

---

7.3
OLD
        -i. If local PE has previously sent a Label Mapping message, it
            MUST send a Label Withdraw message to remote PE and wait
NEW
        -i. If the local PE has previously sent a Label Mapping message, it
            MUST send a Label Withdraw message to the remote PE and wait
END

---

7.3
OLD
       -ii. the local PE MUST send a label release message to the remote
NEW
       -ii. The local PE MUST send a Label Release message to the remote
END

---

7.3
s/negotaiation/negotiation/
s/renegotation/renegotiation/

---

7.3

   The above C-bit renegotiation process SHOULD NOT be interrupted until
   it is completed, or unpredictable results might occur.

This is a bit odd. Normally the "or" that follows a "SHOULD" or "SHOULD
NOT" explains the conditions under which you might want to vary the
"SHOULD".

But I'm struggling: interrupted by whom and by doing what?

---

Some of the formatting in the references seems to have been hit with a
global change of /. /.  / You might want to polish.

---

The latest version of G.707 is dated January 2007. Is there any reason
to not update the reference?

---

Have a look at Section 8 of RFC 5036 for an example of a nice way to
handle "legacy authors" and credits for past work.

In any case, the RFC Editor will require that Section 15 is renamed
"Contributors".

---

There are two trivial nits from idnits.