Subject: [pim] AD review of draft-ietf-pim-explicit-rpf-vector

From: "Adrian Farrel" <[email-masked]>
Date: Sun, 26 Jan 2014 11:22:41 -0000

Hi,

I have done my usual AD review of this document after receiving the
publication request. The purpose of the review is to catch and fix
any issues that might otherwise show up in IETF last call or IESG
review. This helps smooth the passage of the document later and also
increases the quality text.

This seems like a good and simple proposal, and I don't want to bog
it down. But there are a number of small editorial issues and a 
couple of technical questions included below.

I have put the document into "Revised I-D Needed" state and will 
wait to see an updated version before I start the IETF last call.
But please feel free to debate any of these points with me.

Thanks for the work.

Adrian

---

You need to fix the idnits before I can put this to IETF last call.

- Missing page breaks
- 2119 boilerplate broken (you have "SHALL" "NOT")
- there is a line too long
- missing reference for [draft-mofrr-karan]

[Shepherd - Your write-up says no nits found. How come?]

---                                                         

Conventionally we have used the term "strict" in counterpoint to
"loose" to describe hops, and termed the whole path "explicit". I
don't suppose this matters: you are defining your own terms for a
new application in PIM.

However, this has led to some confusion in the text because of the
normal use of the English word "explicit". For example, the Abstract
says:
   This document defines a new Reverse Path Forwarding (RPF) Vector 
   TLV to build multicast trees via an explicit path sent in the PIM 
   join. 
...which doesn't give any clue to the distinction between this work 
and RFC 5496. You might be better with something like:
   The PIM Reverse Path Forwarding (RPF) Vector TLV defined in RFC 5496
   can be included in a PIM Join Attribute to allow a leaf to apply
   controls to the path of a multicast tree. This document defines a
   new Vector Attribute type so that an RPF Vector TLV can be used to
   indicate that the unicast address indicated in the TLV must be used
   as the next hop in the multicast tree.

This kind of language could usefully be repeated throughout the
document.

---

Section 1

   For some applications, it might be useful to have a way to specify
   the explicit path along which the PIM join is propagated.   

Could you possibly be a little less vague? :-)
If this is the level of certainty you have for the utility of your work
then it shouldn't be on the Standards Track. Fortunately, you *do* have
a good use case later in the document.

I suggest re-ordering paragraphs:

3, 4, 2

...and delete paragraph 1.

---

Suggest to rename Section 3 "Motivation"

---

Section 3

As noted above, you need to provide the reference for
[draft-mofrr-karan]. But actually, I wonder whether you really need to
include the citation as the text in the paragraph seems to hold up well
without any further explanation.

---

Section 3

   It might be useful to have a way to specify the explicit path 
   along which the PIM join is propagated.

I think you established that it *is* useful in the previous text.

---

Section 3

   How the Explicit RPF Vector list is determined is outside the 
   scope of this document. It may either be manually configured by
   the network operator or procedures may be implemented on the 
   egress router to dynamically calculate the vector list based on 
   a link state database protocol, like OSPF or IS-IS.

I agree that this should be out of scope and you should say so.
However, having said it is out of scope, why do you go on to 
discuss it?

---

You should give more clarity as to why an RPF list using 5496 list
entries would not be good enough. In Figure 1 it would appear that the
list {R4, R3, R6, R5, R2, R1} would work just fine using 5496.

---

Section 5

   This draft uses PIM join attribute type 4 for specifying an Explicit 
   RPF Vector. 

Please make this:

   This draft uses PIM join attribute type TBD by IANA for specifying an
   Explicit RPF Vector. 

---

Section 7 is describing, for example, simple network with source S and
leafs R1 and R2...

  A   R1
 / \ /
S   C
 \ / \
  B   R2

...where R1 sends explicit RPF TLVs {C, A} and that path is set up.
Then R2 sends explicit RPF TLVs {C, B}.

Section 3.3.3 of RFC 5384 is cited as the tie-breaker. 
This is OK, but it appears to say that the Explicit RPF is not 
mandatory. It would be nice to make it very clear that a receiver has
no expectations that the explicit RPF list it supplies will actually be
used.

---

Section 10

This is important material to include, but I think it needs some work.

   The F bit MUST be set to 0 by a downstream router in the join that 
   is sent to the upstream router that does not support Explicit RPF 
   vector.

But the downstream router doesn't know whether the upstream router 
supports the new vector or not! So I think you need...

   The F bit MUST be set to 0 in all Explicit RPF vectors in case the
   upstream router receiving the join does not support the TLV. As
   described in section 3.3.2 of [RFC5384], routers that do not 
   understand the type of a particular attribute that has the F bit
   clear will discard it and continue to process the join.
   
   This processing is particularly important when the routers that
   do not support the Explicit RPF TLV are identified as hops in the
   explicit RPF list, because failing to remove the RPF vectors could
   cause upstream routers to send the join back toward these routers
   causing loops.
                                      
However, this doesn't seem to be the only way that loops can be caused
(referring back to section 9).
I don't see this mentioned in RFC 5496 either, but surely:
- the RPF list could contain an explicit loop
- the use of loose hops with poorly ordered list entries could create a
  loop

It is fine to note that this is caught by normal PIM processing, but 
you should say so, and you should say what happens to the join. It
seems to me that 3.3.4 of 5496 only catches the case where join is
targeting the same upstream neighbor. But the sequential list nature
of the RPF list means that the loop might not be "endless" but could
still be a loop. How is this caught and handled?

---

Section 11

Please replace...

OLD
   Type
   ----
   The Vector Attribute type is 4.
NEW
   Type
   ----
   The Vector Attribute type is TBD by IANA.
END

---

Section 13 seems light!

The RPF list (and especially the explicit RPF) provides a way to
cause traffic to take different routes through the network. This
could be used to cause traffic to take expensive paths, to be
routed through hot parts of the network, or to be directed to
snooping nodes.

This means that the existence of the RPF TLV makes the use of 
security in PIM more important to prevent tampering with the RPF
list.

But it also raises a question of policy and authorization. Clearly,
when a receiver seeks to join a multicast tree, it must be 
authenticated for that join. But additionally, you may want to note 
that the inclusion of an RPF list by a receiver should be subject to
policy.