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

[<[e-mail]>]

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

-----Message d'origine-----
De : DiME [mailto:[e-mail]] De la part de Tom Taylor
Envoyé : mercredi 17 septembre 2014 03:51
À : [e-mail]
Objet : [Dime] Fwd: New Version Notification for draft-zhou-dime-4over6-provisioning-04.txt

This is the mature version of a document on which DIME has provided advice in the past. Please have a quick look and see whether it makes sense in Diameter terms. If it is OK, I'm not sure what process the Chairs want to follow: adopt as a DIME document, or pass it off to Softwires?

Tom Taylor


-------- Original Message --------
Subject: New Version Notification for
draft-zhou-dime-4over6-provisioning-04.txt
Date: Tue, 16 Sep 2014 18:21:42 -0700
From: [e-mail]
To: M. Boucadair <[e-mail]>, "Qiong Sun" 
<[e-mail]>, "Tom Taylor" <[e-mail]>, Cathy Zhou <[e-mail]>, Qiong Sun <[e-mail]>, T. 
Taylor <[e-mail]>, "Cathy Zhou" 
<[e-mail]>, "Mohamed Boucadair" <[e-mail]>


A new version of I-D, draft-zhou-dime-4over6-provisioning-04.txt
has been successfully submitted by T. Taylor and posted to the IETF repository.

Name:		draft-zhou-dime-4over6-provisioning
Revision:	04
Title:		Attribute-Value Pairs For Provisioning Customer Equipment 
Supporting IPv4-Over-IPv6 Transitional Solutions
Document date:	2014-09-16
Group:		Individual Submission
Pages:		17
URL: 
http://www.ietf.org/internet-drafts/draft-zhou-dime-4over6-provisioning-04.txt
Status: 
https://datatracker.ietf.org/doc/draft-zhou-dime-4over6-provisioning/
Htmlized: 
http://tools.ietf.org/html/draft-zhou-dime-4over6-provisioning-04
Diff: 
http://www.ietf.org/rfcdiff?url2=draft-zhou-dime-4over6-provisioning-04

Abstract:
    During the transition from IPv4 to IPv6, customer equipment may have
    to support one of the various transition methods that have been
    defined for carrying IPv4 packets over IPv6.  This document
    enumerates the information that needs to be provisioned on a customer
    edge router to support a list of transition techniques based on
    tunneling IPv4 in IPv6, with a view to defining reusable components
    for a reasonable transition path between these techniques.  To the
    extent that the provisioning is done dynamically, AAA support is
    needed to provide the information to the network server responsible
    for passing the information to the customer equipment.  This document
    specifies Diameter (RFC 6733) attribute-value pairs to be used for
    that purpose.

 



Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org.

The IETF Secretariat




_______________________________________________
DiME mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/dime

_________________________________________________________________________________________________________________________

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.