Re: [Dime] Fwd: New Version Notification for draft-zhou-dime-4over6-provisioning-04.txt

[Tom Taylor <[e-mail]>]

Thank you for your comments. I think my aversion to going with Grouped 
AVPs was concern over reusability of the AVPs, that I would have to 
create a new AVP for each Grouped one to make the semantics clear. But I 
guess if I can get away with using a generic AVP like the 
Framed-IPv6-Prefix AVP the semantics are set by its presence within the 
specific Grouped AVP. I'll rework the document and see what I get.

I can't find Framed-IPv6-Prefix AVP in the IANA registry. So I guess 
that's my "common data format" redefined as an AVP.

Tom Taylor

On 17/09/2014 7:12 AM, [e-mail] wrote:
> Hi Tom,
>
> Coming back on the need for a new format ("Common prefix Data format"), could you please explain (or remind me) why this new AVP format would be simpler than creating a Grouped AVP as soon as Prefix or Address can be provisioned?
>
> For instance, based on the current draft, the Tunnel-Source-Pref-Or-Addr is defined as a single AVP using the new AVP format defined in this draft:
>
> 3.4. Tunnel-Source-Pref-Or-Addr AVP
>
>     The Tunnel-Source-Pref-Or-Addr AVP (AVP Code TBD02) conveys either
>     the IPv6 Binding Prefix or the tunnel source address on the CE, as
>     described in Section 2.2.  The Tunnel-Source-Pref-Or-Addr AVP uses
>     the common prefix data format.  The AddressType field MUST be set to
>     2 (IPv6).  Valid values in the PrefixLength field are from 0 to 128
>     (full address).
>
>     This AVP is defined separately from the LW4over6-Binding AVP (which
>     includes it) to provide flexibility in the transport of the tunnel
>     source address from the provisioning system to AAA.
>
> But the same info could be also provided as follow:
>
> 3.4. Tunnel-Source-Pref-Or-Addr AVP
>
>     The Tunnel-Source-Pref-Or-Addr (AVP Code TBD0X) is of type Grouped.
>     It MUST contains either an either the IPv6 Binding Prefix or the tunnel source
>     address on the CE, as described in Section 2.2.
>
>                      Tunnel-Source-Pref-Or-Addr  ::= < AVP Header: TBD0X >
>                               [ Tunnel-Source-Address ]
>                               [ Tunnel-Source-Prefix ]
>                              *[ AVP ]
>
> 3.X Tunnel-Source-Address AVP
>
>     The Tunnel-Source-Address AVP (AVP Code xxx) is of type Address
>     and specifies the tunnel source IPv6 address on the CE.
>
> 3.Y. Framed-IPv6-Prefix AVP
>
>     The Tunnel-Source-Prefix AVP (AVP Code yyy) is of type OctetString and
>     contains the IPv6 Binding Prefix on the CE.
>
> If there is no risk of clash, the existing Framed-IPv6-Prefix AVP could even be reused for the second one.
>
> This alternative would have the advantage not to define a new format. I'm not saying that the definition of any new format should be prohibited. But in this case, it seems weird to have to define a new format for combining different types of information that can be already carried in existing AVPs.
>
> About the link with Softwires, we need to ensure that the set of information defined in this document has reviewed and somehow endorsed by the WG. Then I think it will become a pure Dime discussion.
>
> Lionel
>
...