Subject: [Softwires] MAP-E question -- first prefix

From: Tom Taylor <[email-masked]>
Date: Mon, 08 Apr 2013 17:20:00 -0400

In Section 5.2 of -map-05, there is the paragraph:

The MAP subnet ID is defined to be the first subnet (all bits set to
    zero).  Unless configured differently, a MAP node MUST reserve the
    first IPv6 prefix in an End-user IPv6 prefix for the purpose of MAP.

Question: does the second sentence say anything different from the first 
one?

Question: if the MAP node is configured differently, how will other 
nodes be able to synthesize its MAP IPv6 address from the FMR?

Tom Taylor

---

From: "Rajiv Asati (rajiva)" <[email-masked]>
Date: Mon, 8 Apr 2013 21:53:53 +0000

Hi Tom,

Good catch. We also caught this last week and started formulating the
revised text.

We may strive to rewrite this section a bit, time permitting.

> Question: does the second sentence say anything different from the first

Not really. :) 

> nodes be able to synthesize its MAP IPv6 address from the FMR?

You mean, BMR !

Cheers,
Rajiv

-----Original Message-----
From: Tom Taylor <[email-masked]>
Date: Monday, April 8, 2013 5:20 PM
To: Softwires-wg list <[email-masked]>
Subject: [Softwires] MAP-E question -- first prefix

>_______________________________________________
>Softwires mailing list
>[email-masked]
>https://www.ietf.org/mailman/listinfo/softwires

---

From: Ole Troan <[email-masked]>
Date: Tue, 9 Apr 2013 12:51:10 +0200

Tom,

> Question: does the second sentence say anything different from the first one?
> 
> Question: if the MAP node is configured differently, how will other nodes be able to synthesize its MAP IPv6 address from the FMR?

all nodes within the domain must use the same subnet-id. perhaps we could make that clearer.

cheers,
Ole

---

From: Tom Taylor <[email-masked]>
Date: Tue, 09 Apr 2013 07:30:11 -0400

OK, how about this for the complete paragraph:

    "By default, the MAP subnetwork identifier is the first subnetwork 
within the End-user IPv6 prefix (all bits set to zero). An alternative 
subnetwork value MAY be configured. All nodes within a MAP domain MUST 
be configured to use the same value of the subnetwork identifier."

I think that captures the intent. However, I see a possible difficulty: 
differing lengths of the End-user IPv6 prefix for different CEs. We have 
to add two conditions:

  -- the configured subnetwork identifier is at least
             64 - min (n + o)
bits long, where the minimization is taken over all FMRs in the domain

  -- the subnetwork identifier used with a given calculated End-user 
IPv6 prefix uses the right-most (64 - (n + o)) bits of the configured 
subnetwork identifier, where (n + o) is taken from the FMR used for the 
calculation.

Seems simpler just to restrict to the all-zeros value, but please comment.

Tom

---

From: Ole Troan <[email-masked]>
Date: Tue, 9 Apr 2013 21:14:45 +0200

Tom,

>   "By default, the MAP subnetwork identifier is the first subnetwork within the End-user IPv6 prefix (all bits set to zero). An alternative subnetwork value MAY be configured. All nodes within a MAP domain MUST be configured to use the same value of the subnetwork identifier."

I like that text.

> I think that captures the intent. However, I see a possible difficulty: differing lengths of the End-user IPv6 prefix for different CEs. We have to add two conditions:
> 
> -- the subnetwork identifier used with a given calculated End-user IPv6 prefix uses the right-most (64 - (n + o)) bits of the configured subnetwork identifier, where (n + o) is taken from the FMR used for the calculation.
> 

I can't see how different End-user IPv6 prefix lengths within a domain can work.

cheers,
Ole

---

From: Tom Taylor <[email-masked]>
Date: Tue, 09 Apr 2013 18:13:25 -0400

> Tom,
...>
> I can't see how different End-user IPv6 prefix lengths within a domain can work.

The End-user IPv6 prefix length obviously has to be the same for all 
nodes using the same BMR, but couldn't, for example, the PSID width 
(i.e., the sharing ratio) vary from one BMR to another?

---

From: Ole Troan <[email-masked]>
Date: Wed, 10 Apr 2013 12:54:13 +0200

Tom,

> The End-user IPv6 prefix length obviously has to be the same for all nodes using the same BMR, but couldn't, for example, the PSID width (i.e., the sharing ratio) vary from one BMR to another?

absolutely. 'everything' can be different between different BMRs within the same domain.

cheers,
Ole

---

From: Tom Taylor <[email-masked]>
Date: Wed, 10 Apr 2013 08:57:35 -0400

Looks like we had a misunderstanding. Did the authors think of the 
configured subnetwork identifier of the existing text as being 
configured for a particular rule, in effect another rule parameter? I 
took it to be configured as a single value used in conjunction with all 
FMRs to calculate the target MAP IPv6 addresses.

---

From: Ole Troan <[email-masked]>
Date: Wed, 10 Apr 2013 15:22:22 +0200

Tom,

> Looks like we had a misunderstanding. Did the authors think of the configured subnetwork identifier of the existing text as being configured for a particular rule, in effect another rule parameter? I took it to be configured as a single value used in conjunction with all FMRs to calculate the target MAP IPv6 addresses.

apologies, I think I confused myself as well.
if we were to support a configurable subnet-id, it would have to be a per BMR/FMR property.

the base document really just leaves the 'hook' for a provisioning mechanism to use.

cheers,
Ole

---

From: Tom Taylor <[email-masked]>
Date: Wed, 10 Apr 2013 09:29:40 -0400

I'm happy to propose more text, but if that hook is going to be there, I 
think it should be shown explicitly as an optional part of what is 
provisioned for a MAP rule.

---

From: Ole Troan <[email-masked]>
Date: Thu, 11 Apr 2013 09:12:15 +0200

Tom,

> I'm happy to propose more text, but if that hook is going to be there, I think it should be shown explicitly as an optional part of what is provisioned for a MAP rule.

the intent was to set a default that all implementations must support (i.e. 0), but not completely close the door for making it configurable.

I think the current text achieves that intent.

cheers,
Ole

---

From: <[email-masked]>
Date: Thu, 11 Apr 2013 16:33:54 +0530

Dear administrators, 

Just wanted to raise the issue on the MAP-T standardization.  Reliance JIO is a new service provider in India and is about to launch the 4G services along with FTTX.  We are banking upon getting MAP-T as our deployment mode as measure to avoid CGNAT.  Already we are in the process of testing MAP-T CPE devices and MAP-BR on our Gateways. 

I request all concerned to put this on standardization track and get the RFC as quickly as possible so that we can drive all the eco-system like DHCP /ACS / Gateways, etc., towards the deployment scenario. 

With regards, 

B.Nagaraj

Cabin 3, 2A, 2nd floor, 
RCP complex, 
Thane Belapur Road
Ghonsoli, Navi Mumbai-400701

Phone: 
Work: +912244773047
Mobile: +919867564147

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Rajiv Asati (rajiva)
Sent: Tuesday, April 09, 2013 3:24 AM
To: Tom Taylor; Softwires
Subject: Re: [Softwires] MAP-E question -- first prefix

Hi Tom,

Good catch. We also caught this last week and started formulating the revised text.

Not really. :) 

You mean, BMR !

Cheers,
Rajiv

-----Original Message-----
From: Tom Taylor <[email-masked]>
Date: Monday, April 8, 2013 5:20 PM
To: Softwires-wg list <[email-masked]>
Subject: [Softwires] MAP-E question -- first prefix

_______________________________________________
Softwires mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/softwires
"Confidentiality Warning: This message and any attachments are intended only for the use of the intended recipient(s). 
are confidential and may be privileged. If you are not the intended recipient. you are hereby notified that any 
review. re-transmission. conversion to hard copy. copying. circulation or other use of this message and any attachments is 
strictly prohibited. If you are not the intended recipient. please notify the sender immediately by return email. 
and delete this message and any attachments from your system.

Virus Warning: Although the company has taken reasonable precautions to ensure no viruses are present in this email. 
The company cannot accept responsibility for any loss or damage arising from the use of this email or attachment."