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

[Loa Andersson <[e-mail]>]

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:
> 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
>
> _______________________________________________
> mpls mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/mpls

-- 


Loa Andersson                         email: [e-mail]
Sr Strategy and Standards Manager            [e-mail]
Ericsson Inc                          phone: [phone]
                                              [phone]