PIM Multi-Topology ID (MT-ID) Join Attribute
draft-ietf-pim-mtid-10

[Ballot discuss]
This is updated.

#1) resolved

#2) Section 5.2, needs to include something to say how the reserved bits are set and how they're treated.  Maybe something like what's in RFC 4601:

  Reserved
        Set to zero on transmission.  Ignored upon receipt.

[Ballot comment]
Can you clarify the first paragraph of  4.2.3? It's not yet obvious why you felt a need to call out the Robustness Principle here specifically. Are you trying to note that you have some backwards compatibility with existing systems, provide guidance to implementers of the extension to be careful to achieve that compatibility, both, or something completely different?

[Ballot comment]
#1) Section 3.2 contains the following:

    - This value must be unique and consistent within the network
      domain for the same topology. 

r/must/MUST?

[Ballot discuss]
#1) Section 3.2 mentions the use of unique values for the PIM ID.  Normally, when I see the need for unique values a normative reference to RFC 4086 comes to mind because it provides guidance on random #s that could be used for uniqueness.  However, the # range is 1-4095 so that's overkill.  Maybe just adding that it " ... MUST be unique (within the range of 1-4095) ... " (i.e., copy the values forward from the later section would make it crystal clear.

#2) Section 5.2, needs to include something to say how the reserved bits are set and how they're treated.  Maybe something like what's in RFC 4601:

  Reserved
        Set to zero on transmission.  Ignored upon receipt.

IANA understands that, upon approval of this document, there are two
actions which IANA must complete.

First, in the PIM-Hello Options registry in the Protocol Independent
Multicast (PIM) Parameters located at:

http://www.iana.org/assignments/pim-parameters/pim-parameters.xml

the entry for value 30 - PIM MT-ID - will be made permanent and the
reference will be changed to refer to [ RFC-to-be ].

Second, in the PIM Join Attribute Types registry in the Protocol
Independent Multicast (PIM) Parameters located at:

http://www.iana.org/assignments/pim-parameters/pim-parameters.xml

a new value will be registered as follows:

Value: [TBD]
Name: PIM MT-ID
Reference: [ RFC-to-be ]

IANA understands that these are the only actions which need to be
completed upon approval of this document.

State changed to In Last Call from Last Call Requested.

The following Last Call Announcement was sent out:

From: The IESG
To: IETF-Announce
CC:
Reply-To: ietf@ietf.org
Subject: Last Call:  (PIM Multi-Topology ID (MT-ID) Join Attribute) to Proposed Standard


The IESG has received a request from the Protocol Independent Multicast
WG (pim) to consider the following document:
- 'PIM Multi-Topology ID (MT-ID) Join Attribute'
  as a Proposed Standard

The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action. Please send substantive comments to the
ietf@ietf.org mailing lists by 2011-06-27. Exceptionally, comments may be
sent to iesg@ietf.org instead. In either case, please retain the
beginning of the Subject line to allow automated sorting.

Abstract


  This document introduces a new type of PIM Join Attribute that
  extends PIM signaling to identify a topology that should be used when
  constructing a particular multicast distribution tree.






The file can be obtained via
http://datatracker.ietf.org/doc/draft-ietf-pim-mtid/

IESG discussion can be tracked via
http://datatracker.ietf.org/doc/draft-ietf-pim-mtid/


No IPR declarations have been submitted directly on this I-D.

State changed to AD Evaluation::Revised ID Needed from AD Evaluation.
AD review

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:

---

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]

(1.a) Who is the Document Shepherd for this document? Has the
> Document Shepherd personally reviewed this version of the document
> and, in particular, does he or she believe this version is ready
> for forwarding to the IESG for publication?
>
> Mike McBride is the document shepherd. I have personally reviewed the
> document, and believe it is ready for publication as a Proposed
> Standard.
>
> (1.b) Has the document had adequate review both from key members of
> the interested community and others? Does the Document Shepherd
> have any concerns about the depth or breadth of the reviews that
> have been performed?
>
> The document has undergone thorough review within IETF's Multicast
> community.
>
> (1.c) Does the Document Shepherd have concerns that the document
> needs more review from a particular or broader perspective, e.g.,
> security, operational complexity, someone familiar with AAA,
> internationalization or XML?
>
> No
>
> (1.d) Does the Document Shepherd have any specific concerns or
> issues with this document that the Responsible Area Director
> and/or the IESG should be aware of? For example, perhaps he or
> she is uncomfortable with certain parts of the document, or has
> concerns whether there really is a need for it. In any event, if
> the interested community has discussed those issues and has
> indicated that it still wishes to advance the document, detail
> those concerns here.
>
> I have no concerns.
>
> (1.e) How solid is the consensus of the interested community behind
> this document? Does it represent the strong concurrence of a few
> individuals, with others being silent, or does the interested
> community as a whole understand and agree with it?
>
> There is consensus within the PIM WG to publish the document. The
> participation has been with individuals from a variety of vendors and
> providers.
>
>
> (1.f) Has anyone threatened an appeal or otherwise indicated extreme
> discontent? If so, please summarise the areas of conflict in
> separate email messages to the Responsible Area Director. (It
> should be in a separate email because this questionnaire is
> entered into the ID Tracker.)
>
> No.
>
> (1.g) Has the Document Shepherd personally verified that the
> document satisfies all ID nits? (See
> http://www.ietf.org/ID-Checklist.html and
> http://tools.ietf.org/tools/idnits/). Boilerplate checks are not
> enough; this check needs to be thorough. Has the document met all
> formal review criteria it needs to, such as the MIB Doctor, media
> type and URI type reviews?
>
> Yes. There is one minor ID nit suggestion for a "MUST NOT" instead of
> "MUST not". That will be changed upon any update recommendations from
> the IESG.
>
>
> (1.h) Has the document split its references into normative and
> informative? Are there normative references to documents that are
> not ready for advancement or are otherwise in an unclear state
> If such normative references exist, what is the strategy for their
> completion? Are there normative references that are downward
> references, as described in [RFC3967]? If so, list these downward
> references to support the Area Director in the Last Call procedure
> for them [RFC3967].
>
> Yes. Normative references are all stable documents published as RFCs.
>
>
> (1.i) Has the Document Shepherd verified that the document IANA
> consideration section exists and is consistent with the body of
> the document? If the document specifies protocol extensions, are
> reservations requested in appropriate IANA registries? Are the
> IANA registries clearly identified? If the document creates a new
> registry, does it define the proposed initial contents of the
> registry and an allocation procedure for future registrations?
> Does it suggested a reasonable name for the new registry? See
> [I-D.narten-iana-considerations-rfc2434bis]. If the document
> describes an Expert Review process has Shepherd conferred with the
> Responsible Area Director so that the IESG can appoint the needed
> Expert during the IESG Evaluation?
>
>
> The IANA Considerations section exists. A new PIM Hello Option type, 30,
>
> has been assigned for PIM MT-ID Hello Option. A new PIM Join Attribute
> type needs to be assigned. 3 is proposed for now.
>
>
> (1.j) Has the Document Shepherd verified that sections of the
> document that are written in a formal language, such as XML code,
> BNF rules, MIB definitions, etc., validate correctly in an
> automated checker?
>
>
> Not applicable.
>
>
> (1.k) The IESG approval announcement includes a Document
> Announcement Write-Up. Please provide such a Document
> Announcement Writeup. Recent examples can be found in the
> "Action" announcements for approved documents.
>
>
> This document introduces a new type of PIM Join Attribute that extends
> PIM signaling to identify a topology that should be used when
> constructing a particular multicast distribution tree.