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

From: Stig Venaas <[email-masked]>
Date: Wed, 05 Jun 2013 11:11:26 -0700

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