[mpls] Second AD review of draft-ietf-mpls-explicit-resource-control-bundle

["Adrian Farrel" <[e-mail]>]

Hi,

I have performed a further AD review of this document because my first review
was quite substantial and it has been a while since then.

idnits throws up a large number of issues. A substantial number are caused by
formatting problems with the document as submitted. It would be wise to fix
these to allow you to uncover the real problems that are lurking.

I do not appear to have received a direct response to my previous review (sorry
if I lost it) and so I am piecing together your responses from the changes you
have made. A number of issues remain to be addressed. I have interleaved these
with a few new comments.

> I have a meta-question about this draft. Given RFC 4990 Section 6.2,
> why is this extension needed? I can see it would work, but what is the
> benefit of creating a second way to signal a component link in an ERO
> or RRO?

I still think this question needs to be answered in the document. I would expect
a direct reference to 4990, a statement of the limitation of 4990, and a summary
of how this proposal resolves the limitation.

The Abstract makes a forceful assertion on the need for this work, but the
document seems to completely ignore the solution set out in 4990. 

> I think you need to rewrite the Abstract. Consider that you should be
> able to read the Abstract in a fair degree of isolation, so it should
> give context.
> 
> At the moment you jump straight into Record Route without any hints
> that you are dealing with GMPLS!
> 
> You also need to remove citations from the Abstract (you are allowed
> to name the documents).

I don't see any changes for these points.

> Section 1 needs to include a definition of "Component Interface"

I don't see a change for this.

> Can you go through the document and expand all of the acronyms where
> they are first used.

LSP is expanded but some time after first use
SRLG is expanded but not quite in the right place
LSR isn't expanded

---

Section 4.1
s/oPTIoNAL/OPTIONAL/

> Section 4.1
> 
>    The following SHOULD result in "Bad EXPLICIT_ROUTE object" error
>    being sent upstream by a node processing an ERO that contains the
>    Component Interface ID sub-object:
> 
>    o) The first component interface identifier subobject is not
>       preceded by a sub-object containing an IPv4 or IPv6 address, or
>       an interface identifier [RFC3477], associated with a TE link.
> 
> and later...
> 
>    Inferred from above, the interface subobject should never be the
>    first subobject in a newly received message.  If the component
>    interface subobject is the first subobject in a received ERO, then it
>    SHOULD be treated as a "Bad strict node" error.
> 
> These seem to contradict each other.

Doesn't appear to have been resolved.

---

Section 7

There seems to be a discrepancy about the codepoint requests. 
This is marked as an Experimental document (for publication as an Experimental
RFC). Yet it is making requests for codepoints from "Standard Actions"
registries.

My understanding is IANA will not allow this.

So either the status of the I-D needs to change, or the allocations need to
change.


Thanks,
Adrian