Subject: [mpls] AD Review of draft-ietf-mpls-ldp-igp-sync-bcast

From: Adrian Farrel <[email-masked]>
Date: Mon, 21 Jun 2010 20:56:38 +0100

Hi,

Don't panic!

I have performed my AD review of your draft. The purpose of the
review is to catch any nits or issues before the document goes
forward to IETF last call and IESG review. By getting these issues
out at this stage we can hope for a higher quality review and a
smoother passage through the process.

The draft looks pretty good to me, and what I have found are
basically simple questions of understanding. If you are able to
answer my questions, then it would help to make changes/additions
to the text to save you having to handle the same questions again.

I think my comments will be easy for you to address in a new
revision of the draft. None of the comments is mandatory: all are
open for discussion.

I have moved the draft into "AD-review:Revised-ID-needed" state in
the datatracker, and I look forward to seeing the new revision which
I can put forward for IETF last call.

Thanks,
Adrian

---

Please remove the reference citation from the Abstract. (Abstracts
have to be standalone pieces of text.)

I suggest
OLD
    LDP IGP Synchronization ([LDP-IGP-SYNC]) describes a mechanism to
NEW
    LDP IGP Synchronization is a mechanism to

---

Abstract

Is the term "cost-out procedure" widely known?
Would the Abstract be clearer if you explained it?

---

As clearly stated in the Abstract, this document does not introduce
any protocol changes. In view of this, I wondered why it is Standards
Track. Wouldn't it be better targeted as a BCP (if it affects how
the network operates) or Informational (if it is advice to
implementers)?

Given that RFC 5443 is Informational, and this document describes
procedures for operating LDP Synch in certain topologies, I would
have thought this I-D would be Informational as well.

What is the motivation for this being Standards Track?

---

Thanks to Martin for pointing out the Downref in the shepherds write-up.

This is obviously linked to the previous point.
We can handle the Downref if necessary, but usually the existence of a
Downref is a red flag; it warns us that there is something out of phase.

---

It feels to me that [LDP] should be a normative reference. None of this
document makes sense in the absence of LDP.

I suspect that [OSPF] and [ISIS] are similarly normative.

---

Section 4

Question. How are LDP messages between two routers routed if the
routers have not advertised themselves in the IGP (because they are
waiting for LDP to come up)?

---

Section 4

You have some "must not" etc. in this section. Are you sure you
should not use RFC 2119 language?