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

[<[e-mail]>]

"I can't find Framed-IPv6-Prefix AVP in the IANA registry"

It is because it is one of the reuse of RADIUS attributes and it is therefore part of AVP codes reserved for RADIUS attributes. You can look into the table given in http://www.iana.org/assignments/radius-types/radius-types.xhtml#radius-types-2 
You can also refer to RFC 7155 when the AVP is defined.

If you are considering reusing the Framed-IPv6-Prefix AVP, we may also consider reusing the IP-Address AVP (Address type) defined in RFC 5777 to convey either an IPv4 or an IPv6.

Again, this is only a proposal and others might have another opinion. I just try to move forward this draft in the best and easiest direction.

Regards,

Lionel


-----Message d'origine-----
De : Tom Taylor [mailto:[e-mail]] 
Envoyé : mercredi 17 septembre 2014 15:46
À : MORAND Lionel IMT/OLN; [e-mail]
Objet : Re: [Dime] Fwd: New Version Notification for draft-zhou-dime-4over6-provisioning-04.txt

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
>
...

_________________________________________________________________________________________________________________________

Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.

This message and its attachments may contain confidential or privileged information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.
Thank you.