Subject: [MBONED] Trying to clean-up an SSM Errata Report

From: "Adrian Farrel" <[email-masked]>
Date: Tue, 17 Sep 2013 21:48:25 +0100

Stig,

Somewhat later...

I propose to reject this Errata Report as actually representing a substantive
technical change with a note that draft-ietf-6man-multicast-addr-arch-update is
in the pipe.

Last chance for any objections.

Adrian

> -----Original Message-----
> From: Stig Venaas [mailto:[email-masked]]
> Sent: 05 June 2013 19:11
> To: Toerless Eckert
> Cc: [email-masked]; [email-masked]; [email-masked];
> [email-masked]; Adrian Farrel; [email-masked]
> Subject: Re: [MBONED] [pim] Trying to clean-up an SSM Errata Report
> 
> On 5/13/2013 10:21 AM, Stig Venaas wrote:
> > Hi
> >
> > On 5/11/2013 11:25 AM, Toerless Eckert wrote:
> >> Let me add mboned and the author of said errata.
> >>
> >> The author of this errata seems to claim inconsistency between 4607 and
> >> prior addressing standards (RFC3307, RFC4291). He also states: "I'm
> >> sure that
> >> RFC 4291 should NOT be called in question.". This to me implies that
> >> he is asking
> >> to have RFC4607 updated to remove these conflicts in RFC4607bis.
> >
> > Med (copied) and I are trying to get some of these issues resolved, we
> > have one draft (draft-ietf-6man-multicast-addr-arch-update) that will
> > try to clarify and resolve some conflicts. We intent to discuss some of
> > these SSM issues mentioned here as well. We will probably both on the
> > list and in the next IETF meeting try to discuss some of these issues.
> >
> > We've been focusing on how the flag bits are used, and one of the cases
> > is the use of the transient flag and SSM.
> 
> We now have a new version of the draft that suggests some major changes,
> e.g. what is an SSM address (including ff2x::/32 for IANA allocations).
> It would be great if you can see if this addresses the errata, and also
> whether it makes sense in general.
> 
> The latest version is at
> http://tools.ietf.org/html/draft-ietf-6man-multicast-addr-arch-update-01
> 
> Stig
> 
> > Perhaps this thread is a good opportunity to move forward on this topic.
> > One question in particular, is whether the T bit should be allowed to be
> > 0 for SSM, and whether the IANA SSM assignments (non-yet) should have
> > T=0.
> >
> > Stig
> >
> >> IMHO:
> >>
> >> I have not been able to (in)validate the erratas author claims wrt. to
> >> the interpretation of the prior RFCs. I hope others on the lists can
> >> chime
> >> in. Assuming he is right on one or the other accounts:
> >>
> >> I would like to see a resolution that minimizes actual
> >> deployment/interoperability
> >> problems.
> >>
> >> Withdrawing address ranges deemed to be useable according to existing
> >> RFC4607
> >> in an upcoming RFC4607bis definitely has the potentialy to create mayor
> >> disturbances in deployments relying on those addresses. If MBoned can
> >> clearly
> >> identify affected ranges known not to be deployed at all, then they
> >> could be
> >> redesignated, otherwise IMHO not.
> >>
> >> I have not seen any example of actual deployment/interoperability issues
> >> from the incompatibility of existing RFC4607 and its claimed conflicts
> >> with prior address architectures. It would be good if the author of
> >> the errata
> >> (or someone else) could provide some example of such breakage.
> >>
> >> If no real breakage could reasonably be claimed, i think RFC4607bis
> >> should
> >> grandfather in the ranges from RFC4607 and explain how we derived at
> >> them,
> >> and that they constitute unfortunate, but not caught violations of
> >> principle due to the a) human nature, b) IETF process or c) the
> >> complexity
> >> of the IPv6 address architecture. And grandfathering is not the same as
> >> questioning RFC4291.
> >>
> >> Cheers
> >>      Toerless
> >>
> >> On Sat, May 11, 2013 at 05:36:53PM +0100, Adrian Farrel wrote:
> >>> Hi,
> >>>
> >>> Take a look at http://www.rfc-editor.org/errata_search.php?eid=905
> >>>
> >>> I can't make head or tail of what the appropriate resolution is.
> >>> Advice please.
> >>>
> >>> And any ideas if there is a better place to discuss this.
> >>>
> >>> Thanks,
> >>> Adrian
> >>>
> >>> _______________________________________________
> >>> pim mailing list
> >>> [email-masked]
> >>> https://www.ietf.org/mailman/listinfo/pim
> >> _______________________________________________
> >> pim mailing list
> >> [email-masked]
> >> https://www.ietf.org/mailman/listinfo/pim
> >>
> >
> > _______________________________________________
> > MBONED mailing list
> > [email-masked]
> > https://www.ietf.org/mailman/listinfo/mboned

---

From: Stig Venaas <[email-masked]>
Date: Tue, 17 Sep 2013 14:01:39 -0700

> technical change with a note that draft-ietf-6man-multicast-addr-arch-update is

That is fine with me. Note that the arch-update will not change the use
of T-bit for SSM. It would be logical, but after discussions in the pim
WG last time, and privately with Brian Haberman, we concluded it would
be too big a change.

Parts of the errata are correct, but not all. We figured it actually
makes sense to use SSM with the IANA reserved group-ids. That allows
us to have reservations in the SSM space while still have T=1. It's
not very logical, but we think that is the best way forward.

Let us see if we can make it clearer as part of the work on the arch-update.

Copying Brian in case I somehow have misunderstood his point.

Stig

---

From: "Adrian Farrel" <[email-masked]>
Date: Tue, 17 Sep 2013 22:32:20 +0100

Ah, thanks.

I did not mean to imply that the 6man I-D addresses this Errata in full (or even
in part).
The reason for rejection is the substantive technical change.
The mention of the 6man I-D is a "helpful pointer" to related work.

I will try to be clearer about that.

A

> Sent: 17 September 2013 22:02
> To: [email-masked]
> Cc: [email-masked]; [email-masked]; Brian Haberman
> Subject: Re: Trying to clean-up an SSM Errata Report
>

---

From: Brian Haberman <[email-masked]>
Date: Wed, 18 Sep 2013 08:18:05 -0400

I agree that the erratum, as it is written, is trying to make
fundamental changes that are well beyond fixing something broken.

Regards,
Brian

---

From: Brian Haberman <[email-masked]>
Date: Wed, 18 Sep 2013 08:20:57 -0400

Stig,

On 9/17/13 5:01 PM, Stig Venaas wrote:
>> technical change with a note that
>> draft-ietf-6man-multicast-addr-arch-update is
>> in the pipe.
> 

Yes.

> not very logical, but we think that is the best way forward.

There is a muddled line here.  Reserved group-ids do not require T=0.
When T=0, the whole address is reserved via IANA.  Changing that will
require a consensus call.

Regards,
Brian

---

From: Stig Venaas <[email-masked]>
Date: Wed, 18 Sep 2013 10:26:50 -0700

> require a consensus call.

This matches my understanding, and I don't want to change that. I know
I didn't formulate it well. We'll need to update the arch-update draft
to match the conclusions regarding the T-bit, and see if we can do WGLC
soon (with probably review or joint WGLCs in pim and mboned). Copying
my co-author.

Stig