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

From: Tom Taylor <[email-masked]>
Date: Tue, 16 Sep 2014 21:50:48 -0400

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: [email-masked]
To: M. Boucadair <[email-masked]>, "Qiong Sun" 
<[email-masked]>, "Tom Taylor" <[email-masked]>, Cathy 
Zhou <[email-masked]>, Qiong Sun <[email-masked]>, T. 
Taylor <[email-masked]>, "Cathy Zhou" 
<[email-masked]>, "Mohamed Boucadair" <[email-masked]>

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

---

From: <[email-masked]>
Date: Wed, 17 Sep 2014 11:12:23 +0000

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:[email-masked]] De la part de Tom Taylor
Envoyé : mercredi 17 septembre 2014 03:51
À : [email-masked]
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 --------
<[email-masked]>, "Tom Taylor" <[email-masked]>, Cathy Zhou <[email-masked]>, Qiong Sun <[email-masked]>, T. 

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.

Abstract:

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
[email-masked]
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.

---

From: Tom Taylor <[email-masked]>
Date: Wed, 17 Sep 2014 09:45:46 -0400

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

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

---

From: <[email-masked]>
Date: Wed, 17 Sep 2014 14:11:48 +0000

"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:[email-masked]] 
Envoyé : mercredi 17 septembre 2014 15:46
À : MORAND Lionel IMT/OLN; [email-masked]
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

...

---

From: Tom Taylor <[email-masked]>
Date: Tue, 23 Sep 2014 22:48:42 -0400

OK, I've used Delegated-IPv6-Prefix (RFC 4818) in version -05 where the 
semantics seemed to fit, and otherwise defined Grouped AVPs based on RFC 
5777 IP-Address. Submitted as draft-zhou-dime-4over6-provisioning-05. 
Thanks for your comments.

Tom

On 17/09/2014 10:11 AM, [email-masked] wrote:
> It is because it is one of the reuse of RADIUS attributes and it istom.taylor.stds@gmail.
> 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
>
>
>
> 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:[email-masked]] Envoyé : mercredi 17 septembre
> 2014 15:46 À : MORAND Lionel IMT/OLN; [email-masked] Objet : Re:
> [Dime] Fwd: New Version Notification for
> 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.
>
>> 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:
>>
>> 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.
>>
>> 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 ]
>>
>> The Tunnel-Source-Address AVP (AVP Code xxx) is of type Address and
>> specifies the tunnel source IPv6 address on the CE.
>>
>> The Tunnel-Source-Prefix AVP (AVP Code yyy) is of type OctetString
>> and contains the IPv6 Binding Prefix on the CE.
>>
>> 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.
>
>