Subject: [pim] AD review of draft-ietf-pim-mtid-07.txt

From: Adrian Farrel <[email-masked]>
Date: Fri, 22 Apr 2011 21:50:53 +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.

I don't have any major technical issues with your draft. The intention and
solution are fine. However, I found a largish number of small issues and
questions. These are mainly concerns with clarity, although I did have some more
substantial concerns about the selection of the MT-ID.

All of my comments are up for discussion, and you should not feel rail-roaded
into making changes. But I do think my comments need to be addressed for this
document to stand half a chance of getting through IESG review, and I would like
you to have a look and see whether you can work to improve the text before I
take it forward. Perhaps you should take some time to talk with the document
shepherd and WG chairs to determine what the best course of action is.

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

---

idnits reports a warning that you need to fix. It should be simple.

  == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD',
     or 'RECOMMENDED' is not an accepted usage according to RFC 2119.  Please
     use uppercase 'NOT' together with RFC 2119 keywords (if that is what you
     mean).
     
     Found 'MUST not' in this paragraph:
     
     -  the value MUST not be 0.  If it is 0, the PIM MT-ID attribute is
     ignored.  Processing of the rest of the Join message, including the
     current (S,G) or (*,G) entry, continues as if the particular PIM MT-ID
     attribute weren't present in the packet.

---

I had some real trouble with the Introduction. I tried various ways to 
make some comments that would help you, but found it really hard. So I
have opted for giving you some text to look at and consider.

   Some unicast routing protocols, such as OSPF and IS-IS, allow a
   single network to be viewed as multiple topologies [RFC4915], 
   [RFC5120].  Such multi-topology (MT) routing allows different paths
   through the network to be selected to support different traffic, or
   to offer protection paths in the event of failures.

   PIM [RFC4601] uses Reverse Path Forwarding (RFP) to leverage the 
   unicast routing protocols and construct multcast distribution trees.
   If PIM was able to access the multiple topologies created by the
   unicast routing protocols, it would be possible to construct
   multicast distribution trees using separate network paths even when
   the roots of the trees are the same.

   This capability would facilitate an improvement to the resilience of
   multicast applications.  For instance, a multicast stream could be
   duplicated and transported using two source trees, (S1, G1) and 
   (S1, G2), simultneously. By using MT capable unicast routing 
   protocols and procedures described in this document, it is possible
   to construct the two source trees in such a way that they do not 
   share any transit network segment.  As a result, a single network
   failure will not cause any loss to the stream.

   This document introducess a new type of PIM Join Attribute [RFC5384] 
   to encode the identity of the topology PIM is to use when performing 
   RPF for the source tree that is being joined. This document also
   specifies the procedures and rules to process the attribute and 
   resolve conflicts arrising from mismatches in MT capabilities or
   identifiers.
   
   This document does not introduce any change to the RPF check 
   procedure used to verify the incoming interface when a packet is
   forwarded as defined in [RFC4601]. For example, to use the capability
   described by this document, an application can choose to use group
   addresses, and/or source addresses, to identify a unique multicast
   stream.  It might further need to perform the functions of splitting
   and merging.  But the detailed processing is beyond the scope of the
   document.

---
                                                                  
Please search the text for the word "draft" and replace it with
"document". This makes the etxt easier to parse when the document
becomes and RFC.

---

In Section 3.1

   To select the RPF topology for a particular multicast distribution
   tree, one or more of the following can be done.

Your use of "can" implies that there are also other options. In other
words you are also saying that it is possible to select the RPF topology
using another mechanism not specified here.

Whether you intend this or not, I would like you to be more explicit so
that "can be done" causes no ambiguity. Either say "is done" or "could
be done in addition other mechanisms that may be defined in other
documents."

In the end, this all starts to sound a bit vague! Perhaps it is better
to turn it around and say up-front that...

   Selection of RPF topology can be made by configured policy. For 
   example:

   - foo
   - bar

   This document describes a mechanims where the topology to select is
   encoded by the leaf in a new Join Attribute.

---

I am worried about whether the RPF topology selection mechanism needs
to be coordinated across the whole network, and what happens if it is 
not. Can you convince me that you will not build routing loops by 
having a mix of policies in the network?

---

Section 3.2

   For each PIM RPF topology created, a unique numerical ID is assigned
   per PIM domain.  This ID is called PIM MT-ID. PIM MT-ID has the
   following property,

s/PIM MT-ID/the PIM MT-ID/  twice
s/property,/properties:/

     - this value is not required to be the same as the MT-ID used by
       the unicast routing protocols that contribute routes to the
       topology.  In practice, when only one unicast routing protocol
       (such as OSPF or IS-IS) is used, PIM MT-ID is recommended to be
       assigned using the same value as the IGP topology identifier.
       This is for the purpose of reducing management overhead and
       simplifying troubleshooting.

Do you mean RECOMMENDED?

---

Please select consistent terminology. I see                                
- Join-Attribute
- Join Attribute
- join attribute

---

I don't understand how a consistent PIM MT-ID will be generated. Each
router will apply RPF on the various different IGP MT topologies to
generate the set of RPF topologies. Isn't it the case that all routers
need to assign the same PIM MT-ID to the same RPF topology, and also
that the leaf nodes (issuing PIM messages containing Join Attributes)
must select the RPF topology based on the same PIM MT-ID. 

To me, that means that some consistent naming policy is needed. Your
reccommendation in section 3.2 is fine when (as you note) there is only
one IGP instance present. How will you handle the other cases?

It really is a cop-out to go on to say...

     - how to assign a PIM MT-ID to a topology is decided by the network
       administrator and is outside the scope of this document

...What is more, this seems to be in contradiction to the previous
recommendation. Furter, this short note has major impacts for an
implementation - I'm willing to bet that your implementation does not
allow the full range of options that an administrator might want to 
impose.

I also don't feel that it is enough to say...

     - this value must be unique and consistent within the network
       domain for the same topology. For actual deployment, one should
       have a means to detect inconsistency of the MT-ID configuration,
       but the detail of such mechanism is beyond the scope of this
       document.

...without some description of what "consistency" means and how to
achieve it.

I would also feel that your teaser about "a means to detect 
inconsistency" is a bit weak. If such a means is important for the
deployment of your extension, then don't you need to work to define that
means (or derive something like the previous recommendation that mean
it is not necessary)?

---

Section 3.3

   The PIM MT-ID join attribute described in this draft applies to PIM
   Join/Assert packets used by PIM SM/SSM/Bidir.  It is not used in any
   other PIM packets, such as Prune, Register, Register-Stop, Graft,
   Graft-ack, DF Election, Candidate-RP, and Bootstrap. As such, it can
   only be used to build shared or source trees for PIM SM/SSM and PIM-
   bidir downstream.

I suggest removing the "such as Prune, ..."  If it is not used in any
otherPIM packets, no list is necessary. Furthermore, if you have
accidentally lefta message out of the list, you have increased the
ambiguity.

---

Section 3.3

   When this attribute is used in combination with RPF vectors defined
   in [RFC5496] [ID.ietf-l3vpn-2547bis-mcast], they are processed
   against the topology identified by the PIM MT-ID attribute.

Need two small fixes to avoid ambiguity...

   When this attribute is used in combination with RPF vectors defined
   in [RFC5496] and [ID.ietf-l3vpn-2547bis-mcast], the vectors are
   processed against the topology identified by the PIM MT-ID attribute.

---

Section 4.1

This took me a long while to parse. Can I suggest:

4.1. Indicating Support for MT

   A router that supports the functionality described by this document
   MUST include the PIM Hello Option in its PIM Hello packets and MUST
   include both the Join Attribute Option [RFC5384] and the new PIM
   MT-ID Option (see Section 5.1 of this document).

---

Section 4.2.1

   When a PIM router originates a PIM Join/Assert packet, it may choose
   to encode PIM MT-ID of the topology in which RPF lookup takes place

s/takes place/is to take place/

   for the corresponding (*,G) or (S,G) entry. The chosen PIM MT-ID MUST
   be the one decided by local topology selection configuration if it
   exists, or the one received from downstream routers after conflict
   resolution procedures are applied.

Is "MUST" appropriate here? Especially as you have an "or" and some
exceptions. How about "The PIM MT-ID identifies the topology chosen by
local policy/configuration or is the value received from downstream
routers after ID conflict resolution procedures have been applied (see
Section 4.2.4)."

---

Section 4.2.1

Please start the bullets with capital letters as they are sentences.

     - a router SHOULD NOT do so if the upstream router, or any of the
       routers on the LAN does not include "PIM Join Attribute" or "PIM
       MT-ID" option in its Hello packets.

"SHOULD NOT" do what? Please expand the text.

     - a router SHOULD NOT encode PIM MT-ID for pruned sources.  If
       encoded, the value is ignored.

"is ignored" by whom? Maybe "will be ignored as described in ..."

---

Section 4.2.2

Please start the bullets with capital letters as they are sentences.

There are two cases missing from this section.

1. How will a node that does not recognise the MT-ID Join Attribute
   react? You need to state this with a reference to the RFC that
   defines how it will behave.

2. How will a node react if it recognises the attribute, but did not 
   send both of the specific Hello Options and does not want to accept
   the MT-ID? You should define this behavior in this document.

You may feel that the first paragraph of 4.2.3 belongs in this section

to help address my second question.

---

4.2.3

You have...

   An upstream router must be known to support this draft in order for a

...I suspect you wanted "MUST" although it would be less clumsy to re-
word the text so that you can use "MUST NOT".

---

4.2.3

Aren't you missing text for the case of pruned sources per 4.2.1?

---

4.2.4

   On an upstream router, a conflict occurs when the router doesn't have
   local topology selection policy and it has received different PIM
   MT-ID from Join packets sent by its downstream routers or Assert
   packets from another forwarding router on the LAN.  In another word,
   if an upstream router has a local configuration that specifies a
   different topology than that from an incoming Join/Assert packet,
   including the case PIM MT-ID is not encoded in the incoming packet,
   it does not apply the conflict resolution procedures.
                   
I *think* this paragraph is talking about two things.

1. The definition of conflict on an upstream router
2. A condition that is not consider to be conflict when it happens on
   an upstream router.

The problem is with the conjunciton "in another word" which normally
means that it is explaining the previous text, but in this case seems
to be introducing a separate case.

If I'm right about your intention, I think you could clarify the text
quite a bit. For example:

   PIM MT-ID conflict arises on an upstream router when the router
   doesn't have a local topology selection policy and receives Join
   packets from downstream routers and/or Assert packets from other
   forwarding routers on the LAN, and those packets contain different
   PIM MT-IDs.

   However, if an upstream router has a local configuration that 
   specifies PIM MT-IDs to identify RPF topologies, and those MT-IDs do
   not match the MT-ID on a received Join or Assert packet, this is not
   considered to be a conflict and the resolution procedures are not
   applied. This includes the case where there are local PIM MT-IDs, but
   there is no PIM MT-ID encoded in the incoming packet.

In the final paragraph of the section you have...

   It MUST be noted that the MT-ID value being considered for comparison
   does not include the four reserved bits.  That is, only the lower
   order 12 bits are used in resolving conflicting attributes.

...The "MUST" seems to be applied to the need to make an observation.
You really want it to apply to the comparison rules...

   When two PIM MT-IDs are compared, only the 12-bit Value field (see
   Section 5.2) is compared. Other fields of the PIM MT-ID Join
   Attribute TLV Format (including the four reserved bits) MUST NOT
   be used in te comparison.

---

4.2.4.1

       In order to minimize the chances of potential transient
       forwarding loops, an upstream router MAY choose to ignore the
       incoming PIM Join/Prune packets all together if it sees a
       conflict in PIM MT-ID attributes.  This action may also be taken
       by an upstream router which has locally configured topology
       selection policy, as an exception to the rules described above.

s/may/MAY/

Why do you say "Join/Prune"?
Is it assumed that the PIM MT-ID from the other Join (the one that was 
discarded) will have been retained so that this decision can be made?

---

5.2

     - Attr Type: 3.

This should read:

     - Attr Type: <value TBD by IANA>

---

5.2

     - Value: PIM MT-ID, 1 to 4095. Range 2048 to 4095 are for
       experimental and proprietary use.

This was a surpise!
We have already established that...

       In practice, when only one unicast routing protocol
       (such as OSPF or IS-IS) is used, PIM MT-ID is recommended to be
       assigned using the same value as the IGP topology identifier.

...and...

     - how to assign a PIM MT-ID to a topology is decided by the network
       administrator and is outside the scope of this document

Section 3.7 of RFC 4915 gives a very different view of how MT-IDs might
be numbered.

I am not sure I understand what difference there is between a policy
configuration value, and an experimental or proprietary value. In *all*
cases, the operator will need to ensure that there is a uniform policy
across the network, so reserving values for proprietary use doesn't seem
to buy anything (and anyway, how would you avoid clashes?).

RFC 4915 did observe that there might be purpose to reserving a (small)
subset for IANA control.

Can you have a look at this issue and work out the right guidance to
include here?

---

Section 6

The IANA section needs some work!

6.1.  PIM MT-ID Hello Option

   The IANA maintains a registry of "Protocol Independent Multicast 
   (PIM) Parameters" with a sub-registry called "PIM-Hello Options".

   The IANA assigned the PIM Hello Option type value 30 for the PIM
   MT-ID Hello Option according to the First Come First Served 
   allocaiton policy. 

   The IANA is requested to make that allocation permanent with 
   reference to this document.

   Note that the option defined in Section 5.1 of this document has
   length 0. The IANA is requested to update the length value recorded
   in the registry.

6.2.  PIM MT-ID Join Attribute  

   The IANA maintains a registry of "Protocol Independent Multicast 
   (PIM) Parameters" with a sub-registry called "PIM Join Attribute 
   Types".

   The IANA is requested to assign the next available value for the 
   PIM MT-ID Join Attribute defined in Section 5.2 of this document.

---

Section 7 is a little thin. I know there is not much to say, but it
might be helpful to pad it out a bit. For example:

   As described in [RFC5384], the security of the Join Attribute is only
   guaranteed by the security of the PIM packet that carries it.
   Similarly, the security of the Hello Options is only guaranteed by 
   securing the whole Hello packet.

   In view of the fact that malicious alteration of the PIM MT-ID Hello
   Option or the PIM MT-ID carried in a packet might cause the PIM
   resiliency goals to be violated, the security considerations of
   [RFC4601] apply to the extensions described in this document.
   
---

Section 11

You no longer need the reference [HELLO]