Subject: Re: [multrans] Proposed text to draft-boucadair

From: Tina TSOU <[email-masked]>
Date: Tue, 01 Nov 2011 03:25:10 +0000

Bonjour Med,
You justify the "sub-group-id" by relying on RFC 4291 (you say 4261, but that's a typo). However, RFC 4291 says:

2.7.  Multicast Addresses

    An IPv6 multicast address is an identifier for a group of interfaces (typically on different nodes).  An interface may belong to any number of multicast groups.  Multicast addresses have the following format (I tried the font "courier new" here, but it cannot be shown in MS Outlook):

    |   8    |  4 |  4 |                  112 bits                   |
    +------ -+----+----+---------------------------------------------+
    |11111111|flgs|scop|                  group ID                   |
    +--------+----+----+---------------------------------------------+

       binary 11111111 at the start of the address identifies the address as being a multicast address.
....

       group ID identifies the multicast group, either permanent or
       transient, within the given scope.  Additional definitions of the multicast group ID field structure are provided in [RFC3306].

So it's RFC 3306 that's the final authority, as I stated.

Best Regards,
Tina TSOU
http://tinatsou.weebly.com/contact.html

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] 
Sent: Wednesday, October 26, 2011 12:37 AM
To: Tina TSOU
Cc: [email-masked]
Subject: RE: Proposed text to draft-boucadair

Hi Tina,

I uploaded an updated version taking into account some of your comments. 

The diff can be found: http://tools.ietf.org/rfcdiff?url2=draft-boucadair-behave-64-multicast-address-format-03

Cheers
Med

-----Message d'origine-----
De : BOUCADAIR Mohamed OLNC/NAD/TIP 
Envoyé : mercredi 26 octobre 2011 08:44
À : 'Tina TSOU'
Objet : RE: Proposed text to draft-boucadair

Hi Tina,

Thank you for the review.

Please see inline.

Cheers,
Med 

-----Message d'origine-----
De : Tina TSOU [mailto:[email-masked]] 
Envoyé : mercredi 26 octobre 2011 02:21
À : BOUCADAIR Mohamed OLNC/NAD/TIP
Objet : Proposed text to draft-boucadair

Bonjour Med,
Having studied RFCs 3306, 3307, 3956, 4291, and 6308 to set a context, I have the following comments on draft-boucadair-behave-64-multicast-address-format-02.txt:

1. Given the long line of predecessors just listed, the draft should model itself on them by concentrating on the address format definition (sections 7-9 of the present draft). Discussion of the use in different transition cases should be brief, and limited to the introduction. There is no need to discuss interworking functions or translation vs. encapsulation functions -- these are topics for other drafts which apply the content of this one.

Med: I moved several section to an appendix so that the core text focuses on the address specification.

2. Section 6.2 is useful, since the use of the remaining flag bit is indeed very tempting. However, this is non-normative material and should be in an appendix.

Med: I moved that text to an appendix.

3. The address format should as much as possible model itself on RFC3306 as its basis. In particular, it is unnecessary to define a new entity, the sub-group-id. Just use the network prefix combined with plen for ASM. SSM needs slightly different handling, of course, but since the "sub-group-id" is all zeros, one could use a more neutral term.

Med: Why should we model the prefix to RFC3306? I understand we need to be able to support rfc3306 for unicast and also rfc but the base is imho rfc4261. in rfc4261, there is "group ID". The current text says:

   o  sub-group-id: This field is configurable according to local
      policies of the entity managing the IPv4-IPv6 Interconnection
      Function.  This field must follow the recommendations specified in
      [RFC3306] if If unicast-based prefix is used or the
      recommendations specified in [RFC3956] if embedded-RP is used.
      The default value is all zeros.

Is there any issue with that text?

4. There is no need for section 10. It is up to the operator what sort of network prefix it wishes to define for ASM -- RFC 3306 gives several examples.

Med: I don't think we can model this document as per rfc3306 because we need to do address synthesize and only; the service will provision the m_prefix64. That's why we need to explain that. Does this make sense to you?

5. The SSM address form should definitely be restricted to IPv4 SSM addresses in the lower 32 bits. This guarantees that those bits will be in the valid range as specified by RFC 3307. The ASM lower 32 bits might as well be similarly restricted to IPv4 ASM addresses.

In brief, the draft should be an update to RFC 3306 rather than 6052, and should be rather shorter.

Med: It is not an update of RFC3306 but RFC4291 because we don't define a unicast prefix based multicast address. I removed the reference to RFC6052. 

Best Regards,
Tina TSOU
http://tinatsou.weebly.com/contact.html
http://www.huawei.com/en/solutions/expand-broadband/hw-092950-ipv6.htm