Subject: Re: [pim] Last Call: <draft-ietf-pim-rfc4601bis-03.txt> (Protocol Independent Multicast - Sparse Mode (PIM-SM): Protocol Specification (Revised)) to Internet Standard

From: William Atwood <[email-masked]>
Date: Sun, 01 Mar 2015 13:11:37 -0500

Stig,

My 2 cents (again, looking for guidance from Alia) is that not
referencing 5796 and 6226 amounts to a repudiation of these RFCs,
essentially saying that PIM-SM is going back to what is said in RFC 4601.

RFC 5796 and RFC 4601 say opposing things about the use of AH.  If
4601bis goes back to (or retains) the language of RFC 4601, then there
was no point in doing RFC 5796.

If it is necessary to advance RFC 5796 to Full Standard, I can arrange
for three independent implementations to be shown to inter-operate.  We
have done it already with two (Cisco and Xorp).  Adding a third (or a
fourth) would just be a matter of borrowing a router from one or more
router manufacturers.

Otherwise, we do a Last Call on 4601bis citing the explicit downref.

  Bill

On 27/02/2015 6:35 PM, Stig Venaas wrote:
> Hi
> 
> On 2/27/2015 11:10 AM, Alia Atlas wrote:
>> Bill,
>>
>> Thanks for the good review and catches!
>> I'd like to see the draft updated before March 5 so that it can still
>> make the telechat on March 12.
> 
> I'm not sure it is appropriate to update the document referencing those
> more recent standards track document though. We are progressing 4601bis
> on the standards track here. Should we as part of that have references
> to less mature documents? Those other documents are updating 4601 I
> believe which is fine. But that doesn't necessarily mean that 4601bis
> should reference them.
> 
> Looking for guidance here Alia. My thinking is that 4601bis shouldn't
> change anything from 4601, only leave certain things out.
> 
> Stig
> 
>> Regards,
>> Alia
>>
>> On Fri, Feb 27, 2015 at 2:04 PM, William Atwood
>> <[email-masked] <mailto:[email-masked]>> wrote:
>>
>>     In the following, I will refer to draft-ietf-pim-4601bis as simply
>>     "4601bis".
>>
>>     RFC 4601 has been updated by several RFCs:
>>
>>     RFC 5059 Bootstrap Router (BSR) Mechanism for Protocol
>>               Independent Multicast (PIM)
>>     RFC 5796 Authentication and Confidentiality in Protocol
>>               Independent Multicast Sparse Mode (PIM-SM)
>>               Link-Local Messages
>>     RFC 6226 PIM Group-to-Rendezvous-Point Mapping
>>
>>     4601bis refers to RFC 5059 in Section 3.7.  The new text is
>> identical to
>>     the text in RFC 4601, although the reference in RFC 4601 is to the
>>     Internet Draft that became RFC 5059.
>>
>>     4601bis makes no reference to RFC 5796.  Given that RFC 5796
>> alters the
>>     preferred IPsec solution (AH is "recommended" in RFC 4601, while RFC
>>     5796 says that implementations "MUST support ESP and MAY support
>> AH"),
>>     and given that RFC 5796 provides considerable detail on the use of
>> IPsec
>>     to protect link-local messages for PIM-SM, RFC 5796 should be
>>     specifically referenced in Section 6.3 of 4601bis.
>>
>>     4601bis makes no reference to RFC 6226.  Given that RFC 6226
>> alters the
>>     algorithm for determining the Rendezvous Point, RFC 6226 should be
>>     specifically mentioned in Section 3.7 of 4601bis.  The authors should
>>     also consider whether to eliminate Section 4.7.1 and replace it
>> with a
>>     pointer to RFC 6226, to reduce it and add a pointer to RFC 6226,
>> or to
>>     leave it unchanged.
>>
>>     Suggested text for some of these changes has been supplied to the
>>     authors of 4601bis.
>>
>>        Bill Atwood
>>
>>
>>     On 13/02/2015 12:42 PM, The IESG wrote:
>>      >
>>      > The IESG has received a request from the Protocol Independent
>>     Multicast
>>      > WG (pim) to consider the following document:
>>      > - 'Protocol Independent Multicast - Sparse Mode (PIM-SM): Protocol
>>      >    Specification (Revised)'
>>      >   <draft-ietf-pim-rfc4601bis-03.txt> as Internet 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
>>      > [email-masked] <mailto:[email-masked]> mailing lists by 2015-02-27.
>>     Exceptionally, comments may be
>>      > sent to [email-masked] <mailto:[email-masked]> instead. In either
>>     case, please retain the
>>      > beginning of the Subject line to allow automated sorting.
>>      >
>>      > Abstract
>>      >
>>      >
>>      >    This document specifies Protocol Independent Multicast -
>>     Sparse Mode
>>      >    (PIM-SM).  PIM-SM is a multicast routing protocol that can
>> use the
>>      >    underlying unicast routing information base or a separate
>>     multicast-
>>      >    capable routing information base.  It builds unidirectional
>> shared
>>      >    trees rooted at a Rendezvous Point (RP) per group, and
>> optionally
>>      >    creates shortest-path trees per source.
>>      >
>>      >    This document addresses errata filed against RFC 4601, and
>> removes
>>      >    the optional (*,*,RP) feature that lacks sufficient deployment
>>      >    experience.
>>      >
>>      >
>>      >
>>      >
>>      > The file can be obtained via
>>      > http://datatracker.ietf.org/doc/draft-ietf-pim-rfc4601bis/
>>      >
>>      > IESG discussion can be tracked via
>>      > http://datatracker.ietf.org/doc/draft-ietf-pim-rfc4601bis/ballot/
>>      >
>>      >
>>      > No IPR declarations have been submitted directly on this I-D.
>>      >
>>      >
>>
>>     --
>>     Dr. J.W. Atwood, Eng.             tel: +1 (514) 848-2424 x3046
>>     <tel:%2B1%20%28514%29%20848-2424%20x3046>
>>     Distinguished Professor Emeritus  fax: +1 (514) 848-2830
>>     <tel:%2B1%20%28514%29%20848-2830>
>>     Department of Computer Science
>>         and Software Engineering
>>     Concordia University EV 3.185 email:[email-masked]
>>     <mailto:[email-masked]>
>>     1455 de Maisonneuve Blvd. West http://users.encs.concordia.ca/~bill
>>     Montreal, Quebec Canada H3G 1M8
>>
>>     _______________________________________________
>>     pim mailing list
>>     [email-masked] <mailto:[email-masked]>
>>     https://www.ietf.org/mailman/listinfo/pim
>>
>>
>>
>>
>> _______________________________________________
>> pim mailing list
>> [email-masked]
>> https://www.ietf.org/mailman/listinfo/pim
>>
> 

-- 
Dr. J.W. Atwood, Eng.             tel:   +1 (514) 848-2424 x3046
Distinguished Professor Emeritus  fax:   +1 (514) 848-2830
Department of Computer Science
   and Software Engineering
Concordia University EV 3.185     email:[email-masked]
1455 de Maisonneuve Blvd. West    http://users.encs.concordia.ca/~bill
Montreal, Quebec Canada H3G 1M8

---

From: Toerless Eckert <[email-masked]>
Date: Sun, 1 Mar 2015 13:06:50 -0800

I don't think it's a repudiation. I think that 5796 could
still becomeb a candidate superceeding document to 4601bis.
I just don't think that we need to stall 4601bis for that
decision, and that i would like to see some actual deployment
experience documentation for 5796.

-- 
---
Toerless Eckert, [email-masked]

---

From: Alia Atlas <[email-masked]>
Date: Mon, 2 Mar 2015 17:26:41 -0500

Hi Stig,

Sorry for the delay in responding.  I was getting advice :-)

If A obsoletes B and C updates B, then other than rolling C into A, there is
nothing to do for A.  That C updates A should be automatic inheritance.

Regards,
Alia

On Fri, Feb 27, 2015 at 6:35 PM, Stig Venaas <[email-masked]> wrote:

>>     4601bis refers to RFC 5059 in Section 3.7.  The new text is identical
>> to
>>     4601bis makes no reference to RFC 5796.  Given that RFC 5796 alters
>> the
>>     5796 says that implementations "MUST support ESP and MAY support AH"),
>>     4601bis makes no reference to RFC 6226.  Given that RFC 6226 alters
>> the
>>     also consider whether to eliminate Section 4.7.1 and replace it with a
>>     pointer to RFC 6226, to reduce it and add a pointer to RFC 6226, or to
>>     leave it unchanged.
>>
>>      >    (PIM-SM).  PIM-SM is a multicast routing protocol that can use
>> the

---

From: Rishabh Parekh <[email-masked]>
Date: Mon, 2 Mar 2015 14:54:35 -0800

Alia,

Thanks for the guidance. If I understand the A, B, Cs correctly, we
don't need to refer to 5796 in the draft. In that case I believe that
draft version 4 addresses all the comments received so far.

-Rishabh

---

From: Alia Atlas <[email-masked]>
Date: Mon, 2 Mar 2015 17:55:32 -0500

Excellent - thanks!

On Mon, Mar 2, 2015 at 5:54 PM, Rishabh Parekh <[email-masked]> wrote:

> identical
> with
> >>> a
> use

---

From: William Atwood <[email-masked]>
Date: Mon, 02 Mar 2015 19:05:43 -0500

Alia,

Please see inline.

  Bill

> If A obsoletes B and C updates B, then other than rolling C into A, there is

<bill> What is required to "roll C into A"?  Does this mean to copy the
text of C into A?  Or something else?  I may be dense, but as I see it,
either I put the text of C into A, or at least I change the text of A to
point to C.
</bill>

> nothing to do for A.  That C updates A should be automatic inheritance.

<bill>
I am sorry, but I don't get it.  Here is my specific issue:

RFC 4601 specified that AH is "recommended".

RFC 5796 (on the advice of the Security folks) requires ESP and permits AH.

4601bis (version -04) retains the language of RFC 4601, i.e., it
_recommends_ AH.

Suppose that I were an implementer, told to implement 4601bis (i.e.,
whatever RFC 4601bis becomes).  Since (I believe) a reasonable
assumption is that 4601bis, as a "Full Standard", provides the latest
information, why would I (as an implementer) go back and look at "old"
documentation???  Surely we need to take note of the change in
recommendations when formulating the new document.  In this case, the
changes that I suggested off-list alter the language of the
recommendation in 4601bis, and point to RFC 5796 for the details.
</bill>

> 
> Regards,
> Alia
> 
> On Fri, Feb 27, 2015 at 6:35 PM, Stig Venaas <[email-masked]
> <mailto:[email-masked]>> wrote:
> 
>     Hi
> 
>         <[email-masked]
>         <mailto:[email-masked]>
>         <mailto:[email-masked]
>         <mailto:[email-masked]>>> wrote:
> 
>             and given that RFC 5796 provides considerable detail on the
>         use of IPsec
>              >   <draft-ietf-pim-rfc4601bis-03.__txt> as Internet Standard
>              >
>              > The IESG plans to make a decision in the next few weeks,
>         and solicits
>              > [email-masked] <mailto:[email-masked]>
>         <mailto:[email-masked] <mailto:[email-masked]>> mailing lists by
>         2015-02-27.
>              > sent to [email-masked] <mailto:[email-masked]>
>         <mailto:[email-masked] <mailto:[email-masked]>> instead. In either
>             case, please retain the
>              >    (PIM-SM).  PIM-SM is a multicast routing protocol that
>         can use the
>              >    capable routing information base.  It builds
>         unidirectional shared
>              >    This document addresses errata filed against RFC 4601,
>         and removes
>         http://datatracker.ietf.org/__doc/draft-ietf-pim-rfc4601bis/
>         <http://datatracker.ietf.org/doc/draft-ietf-pim-rfc4601bis/>
>              >
>         http://datatracker.ietf.org/__doc/draft-ietf-pim-rfc4601bis/__ballot/
>         <http://datatracker.ietf.org/doc/draft-ietf-pim-rfc4601bis/ballot/>
>              >
>              >
>             Dr. J.W. Atwood, Eng.             tel: +1 (514) 848-2424
>         x3046 <tel:%2B1%20%28514%29%20848-2424%20x3046>
>             <tel:%2B1%20%28514%29%20848-__2424%20x3046>
>             <tel:%2B1%20%28514%29%20848-__2830>
>             Concordia University EV 3.185
>         email:[email-masked]
>             <mailto:[email-masked]
>         <mailto:[email-masked]>>
>             1455 de Maisonneuve Blvd. West
>         http://users.encs.concordia.__ca/~bill
>         <http://users.encs.concordia.ca/~bill>
>             _________________________________________________
>             pim mailing list
>             [email-masked] <mailto:[email-masked]> <mailto:[email-masked]
>         <mailto:[email-masked]>>
>             https://www.ietf.org/mailman/__listinfo/pim
>         <https://www.ietf.org/mailman/listinfo/pim>
> 
> 
> 
> 
>         _________________________________________________
>         pim mailing list
>         https://www.ietf.org/mailman/__listinfo/pim
>         <https://www.ietf.org/mailman/listinfo/pim>
> 
> 
>

---

From: Toerless Eckert <[email-masked]>
Date: Wed, 11 Mar 2015 06:46:17 -0700

Alia:

How would an implementer of PIM based on 4601 figure out from 4601bis,
what if any changes she would need to do on her implementation ?

I may be missing something, but by not having an errata/changes section/
summary, existing implementers will ahve a lot more trouble adopting
this update than they should IMHO. Is that normal IETF process in bis
documents ?

The "removed functionality" is the least interesting bit of changes,
so that does not count.

Toerless

On Fri, Feb 27, 2015 at 02:10:25PM -0500, Alia Atlas wrote:
> On Fri, Feb 27, 2015 at 2:04 PM, William Atwood <[email-masked]
> > wrote:
> 
> > 4601bis refers to RFC 5059 in Section 3.7.  The new text is identical to
> > 4601bis makes no reference to RFC 5796.  Given that RFC 5796 alters the
> > and given that RFC 5796 provides considerable detail on the use of IPsec
> > 4601bis makes no reference to RFC 6226.  Given that RFC 6226 alters the
> > > The IESG has received a request from the Protocol Independent Multicast
> > > 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
> > > [email-masked] mailing lists by 2015-02-27. Exceptionally, comments may
> > be
> > > sent to [email-masked] instead. In either case, please retain the
> > >    This document specifies Protocol Independent Multicast - Sparse Mode
> > >    (PIM-SM).  PIM-SM is a multicast routing protocol that can use the
> > >    underlying unicast routing information base or a separate multicast-
> > >    capable routing information base.  It builds unidirectional shared
> > >    trees rooted at a Rendezvous Point (RP) per group, and optionally
> > >    This document addresses errata filed against RFC 4601, and removes

---

From: Alia Atlas <[email-masked]>
Date: Wed, 11 Mar 2015 10:24:20 -0400

Toerless,

> what if any changes she would need to do on her implementation ?

It is not very hard to compare 4601 and 4601bis with the rfcdiff tool to
see the
differences.

> this update than they should IMHO. Is that normal IETF process in bis

So - I have three responses.  First, this type of feedback would be quite
useful during WGLC.  It isn't, I think, a reason to impact the draft at this
stage,even if the draft comes back to the WG to handle issues around the
updates and section 6.3.  Second, looking with rfcdiff shows some changes
from "should to SHOULD or must to MUST"; I don't really see a way of
summarizing it cleanly.  Third, the major changes to a bis version are
summarized;
I haven't seen a lot of bis drafts progressed yet but the short summary
that
is there about the removed functionality seems useful.

Regards,
Alia

---

From: Toerless Eckert <[email-masked]>
Date: Wed, 11 Mar 2015 07:53:48 -0700

Thanks, Alia

No offense, but i think this is hilarious. The most hilarious part is
that nobody beside me seems to care about a good summary. Especially
because that summary (list of collected errata) was the starting point ofr
the new RFC, aka: it did exist. But i will be happy to tell customers whom
i am presenting IP multicast to the recommended IETF process:

  -> There is a new version of PIM
  -> To understand what it improves and/or under what circumstances
     there may be incompatibilities with older implementations
     or improvements you want:

     - Go to https://tools.ietf.org/tools/rfcdiff/rfcdiff
     - Aquire rfc4601 and rfc4601bis files
     - create a diff
     - read throught he diff and understad what it means.

I am sure customers will appreciate the geek factor of the IETF process.

Btw: i ran through that process between 2362/4601 when we got bugged
by our products and customer RFPs about claims re. 4601... 

Cheer
    Toerless

---

From: Alia Atlas <[email-masked]>
Date: Wed, 11 Mar 2015 10:59:31 -0400

Toerless,

If you ran into the same issue for 2362/4601, why didn't you raise it while
the
WG was working on this draft or in the last 6 months since WGLC?

Can you write up a meaningful summary other than "clarifying the required
behavior"?

I'm sure that those discussing this with their customers can translate as
and if
necessary.

Regards,
Alia

On Wed, Mar 11, 2015 at 10:53 AM, Toerless Eckert <[email-masked]> wrote:

> > > > > > [email-masked] mailing lists by 2015-02-27. Exceptionally,
> comments
> > > may
> > > > > be
> Sparse
> > > Mode
> email:[email-masked]
> http://users.encs.concordia.ca/~bill

---

From: Toerless Eckert <[email-masked]>
Date: Wed, 11 Mar 2015 10:03:32 -0700

Alia,

as said, it doesn't make sense to raise this requirement against
an RFC if i am the only one interested in it.

Cheers
    Toerless

---

From: Stig Venaas <[email-masked]>
Date: Tue, 17 Mar 2015 16:58:29 -0700

There are no changes that I'm aware of needed for an implementation of 4601
to comply with the current 4601bis. I believe the errata mainly fix issues
that are fairly obvious. There may have been some issues that caused
confusion so an implementer of 4601 may in some cases have misunderstood
something.

I think listing all the errata that got addressed in 4601bis is a bit much.
Both a diff and the errata themselves are available if an implementers of
4601 wants to check.

Stig