Subject: [mpls] AD review of draft-ietf-mpls-mldp-recurs-fec

From: "Adrian Farrel" <[email-masked]>
Date: Sun, 12 Jun 2011 10:55:37 +0100

Hi,

Don't panic!

I have carried out my usual AD review of your draft. The purpose of the
review is to iron out any wrinkles before the document goes to IETF last
call and IESG review, the better to ensure smooth passage through those
stages and rapid adoption as an RFC.

Thank you for a well-written and clear document. I have no technical
concerns with your work. There is one relatively important editorial 
point I would like you to resolve, and while you are at it, there are
a few nits that can be mopped up.

I think this merits a new revision, if you don't mind. As soon as I see
it, I will kick off the IETF last call.

I have also asked the document shepherd to find out about the
implementation status for me. Implementation is not a requirement, but
the write-up needs to give the information. Obviously, at least an 
intent to implement is strongly desirable.

Many thanks,
Adrian

---

I don't think including Figure 1 here actually adds to the readability
of the document. And, as usual, when there is a duplicated definition
we have to worry about cross-checking and stating which document 
contains the normative definition. It would be better if you could delete
the figure and simply reference [mLDP].

---

Rather trivially, the text about Figure 2 does not state what R is.
Suggest...

s/route for R/route for R in the customer network/

---

Section 1

s/from CE1 address to R/from CE1 addressed to R/

---

The term "mLDP" turns up unexplained. Can you insert an expansion?

---

Section 2.2

It is not so important, but...

   PE1 therefore MUST create a new MP FEC element         

I don't think this is really a "MUST". I'd be happy with...

   PE1 creates a new MP FEC element

Similarly...
   PE1 then MUST send this FEC element to P1.
becomes...
   PE1 then sends this FEC element to P1.

This shows again in 3.2.2

---

Section 2.2

       PE2-FEC = <root=PE2, opaque_value=CE1-FEC>, or

       PE2-FEC = <root=PE2, opaque_value=<root=R,
                                          opaque_value=Q>>

With my small brain that is easily confused, I found "or" misleading.
Would "i.e." be more accurate?

---

Section 2.2

   This will result in CE1-FEC being sent on to CE2, and
   presumably further from CE2 to R.

Strike "presumably" because [mLDP] makes this clear.

---

Section 3.1

This is the second Figure 3!

The text about this figure doesn't match the figure itself. The figure
shows two explicit fields (RD and FEC), but the text talks about *the*
value field.

---

Section 5

It might be advisable to include an informational reference to RFC 5920

---

From: Loa Andersson <[email-masked]>
Date: Sun, 12 Jun 2011 07:34:45 -0700

Working Group,

we have requested that draft-ietf-mpls-mldp-recurs-fec is
published as an RFC on the standards track.

The document shepherd has a question on implementation status,
when the shepherd write up was written I had no such info, and
really believed that it was not that important. We are filling a
rather obvious hole in the spec, and anyone who have am implementation
of the base spec should be interested in adding this piece.

Anyhow, the shepherding AD has asked for info on the implementation
status. Can you send info on this to the mailing list or to the
the document shepherd (me):

Do you have an implementation of draft-ietf-mpls-mldp-recurs-fec?
Do you have intentions to implement the draft?

/Loa

On 2011-06-12 02:55, Adrian Farrel wrote:
>         PE2-FEC =<root=PE2, opaque_value=CE1-FEC>, or
>
>         PE2-FEC =<root=PE2, opaque_value=<root=R,
>                                            opaque_value=Q>>
>
> _______________________________________________
> mpls mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/mpls

-- 

Loa Andersson                         email: [email-masked]
Sr Strategy and Standards Manager            [email-masked]
Ericsson Inc                          phone: +46 10 717 52 13
                                              +46 767 72 92 13