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

From: Yiqun Cai <[email-masked]>
Date: Thu, 09 Jun 2011 19:28:06 -0700

Adrian,

Many thanks for the detailed comment.  We have studied carefully and updated
the document accordingly.  A new version, -08, has been uploaded.

More inline.  

On 4/22/11 1:50 PM, "Adrian Farrel" <[email-masked]> wrote:

> ---
> 
> 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.
> 
> ---

Done.

> 
> 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.

<snipped the rest of the text>

We have incorporated most of the text (the wording might be slightly
different in a few places).

Having a native speaker reviewing and suggesting text is greatly
appreciated.  In fact, many text that you supplied was taken "literally" in
the -08  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.
> 

Done

> ---
> 
> 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.
> 

The comment was accepted.

This section was also expanded significantly.  An example was added too.
The purpose of the modification is to clarify the relationship between PIM
MT-ID and IGP MT-ID, and describe possible use of PIM MT-ID.

Some of the description was communicated at Minneapolis IETF (the first IETF
the idea was presented) and San Francisco IETF.  But it wasn't captured in
text,  which we are doing now, hoping to clarify the confusions.

> ---
> 
> 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?

No I can't.

In fact, the issue of inconsistency exists today with PIM, and without the
use of MT.  That is due to the very nature of PIM which doesn't build its
own topology like DVMRP or MOSPF does.

The only thing that can be guaranteed is that the IGP routes imported in the
RPF topology is loop-free.  However, different routers may use different
policies to build their own RPF topology,  the potential of something bad
happening is always there, with or without MT.

We had lots of discussion on this topic on the mailing list last year.  Some
text in the draft was a result of contribution (and compromise) made by
several of us, including Dimitri, Thomas and Hui.

> 
> ---
> 
> 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?

Done.

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

Done.

> ---
> 
> 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?

PIM MT-ID is assigned by operators,  not generated automatically.  The
revised section 3.1 describes an example how it can be done.  Hope that
helps.

> 
> 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.
> 

Done.

> ---
> 
> 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.
> 

Done

> ---
> 
> 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).
> 
> 

Modified the text as suggested.

> ---
> 
> 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)."

Done as suggested.

> 
> ---
> 
> Section 4.2.1
> 
> Please start the bullets with capital letters as they are sentences.
> 

Done.

>      - 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 ..."
> 

More text has been added in -08 to clarify the point.

> ---
> 
> 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.
> 

The description has been added to -08.

> 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.
> 

The description has also been added.  However,  it is different than 4.2.3.
This paragraph is about a router which can parse the attribute but choose
not to tell others it can.  While 4.2.3 is about a router who can parse the
attribute but receive the attribute from another router which doesn't claim
it supports this document.

So we still keep the text in 4.2.3 where it is.

> 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".
> 

Yes it is MUST.

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

The description for handling MT-ID in the pruned sources was added to 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.
> 

<snipped some text>

Thanks for the suggestion.  The text is used in -08.

> 
> 
> 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.
> 
> ---

Done.

> 
> 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?
> 

We usually say Join/Prune together because they use the same message type.
However we did make an attempt in -08 to be clear about whether we are
dealing with a Join source or a Prune source.

> ---
> 
> 5.2
> 
>      - Attr Type: 3.
> 
> This should read:
> 
>      - Attr Type: <value TBD by IANA>

Done.

> 
> ---
> 
> 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
> 

We discussed a little bit among us and decided to remove "experimental and
proprietary use".  The use case we initially discussed doesn't mandate the
use of a "private" range.  And having it creates more problems than it
solves.

> 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?

You caught a very good point here.

The use of mt-topology for "multicast" has been evolving quite a bit since
MT came to the world maybe 10 years ago.  If I understand properly,  the
multicast topology specified by RFC4915 means that topology SHOULD NOT be
used by unicast.  I'm not sure if all implementations honor that rule.

On the other hand, MT for PIM doesn't depend on this particular "multicast
topology" described in 4915.  Routes in any topology can be used for RPF.
And this is explained in the new Section 3.1. Please let us know if it is
still not clear.

> 
> ---
> 
> Section 6
> 
> The IANA section needs some work!
> 
> 

Thanks for the text.  They are taken "literally" ;)

> ---
> 
> 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:
> 
>

Same as above.

> ---
> 
> Section 11
> 
> You no longer need the reference [HELLO]
> 

Done.

Thanks again. 

-- 
Yiqun

---

From: Stig Venaas <[email-masked]>
Date: Fri, 10 Jun 2011 10:48:04 -0700

> the document accordingly.  A new version, -08, has been uploaded.
[...]

Folks, as you can tell from Yiqun's email, there are a lot of changes
to the draft, although I believe they are fine and don't actually change
how mtid works.

Please look at the changes though, and speak up if you have any
concerns. You can find the new draft, old draft, and a diff at
http://tools.ietf.org/wg/pim/draft-ietf-pim-mtid/

For just the diff, you might go directly to
http://tools.ietf.org/wg/pim/draft-ietf-pim-mtid/draft-ietf-pim-mtid-08-from-07.diff.html

Stig