Subject: [netlmm] Q on draft-muhanna-netlmm-grekey-option

From: <[email-masked]>
Date: Tue, 8 May 2007 05:58:44 +0200

Hi,

I got questions for my clarification on this draft relating
to deployments where a MAG were shared between LMAs (that are
possibly operated by different operators).

There are cases where a LMAs would not return GRE Key option
back to the MAG (e.g. LMAs do not understand the option at
all and just skip it, or LMAs from different operators are
not aware of overloaded IPv4 ranges). In these cases the MAG
might receive overloaded IPv4 forward direction traffic from
different LMAs without any GRE encapsulation. How would the
MAG do the layer-2 address lookup for MNs? 

The other foggy area for me is about the allocation of GRE keys.
In a case of shared MAGs allocated GRE keys have probable collision
issues. Should the draft say something like that for the forward
direction traffic MN layer-2 address lookup should be based
on the GRE key and the LMA address? Or that each GRE tunnel/LMA
have their own GRE key range?

Cheers,
	Jouni

_______________________________________________
netlmm mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/netlmm

---

From: "Ahmad Muhanna" <[email-masked]>
Date: Mon, 7 May 2007 23:31:24 -0500

Hi Jouni,
Thanks for your comments. Please see comments inline.

Regards,
Ahmad

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]] 
> Sent: Monday, May 07, 2007 10:59 PM
> To: [email-masked]; Muhanna, Ahmad (RICH1:2H10)
> Subject: Q on draft-muhanna-netlmm-grekey-option
> 
> Hi,
> 

[Ahmad]
These IPv4 private addresses are allocated by the different LMAs. In
other words, the issue is when two IPv4 private addresses collide while
they are served by the same LMA and MAG. If any LMA would be configured
to server IPv4 private addresses, there are two options here:

1. LMA must guarantee that there is no IPv4 overlap within all the
private IPv4 address pools that the LMA is serving, this seems to be a
stretch and many times it is not possible, or
2. LMA must support GRE encapsulation and a GRE key allocation
mechanism.
 
> In a case of shared MAGs allocated GRE keys have probable 
> collision issues. Should the draft say something like that 
> for the forward direction traffic MN layer-2 address lookup 
> should be based on the GRE key and the LMA address? Or that 
> each GRE tunnel/LMA have their own GRE key range?

[Ahmad]
I agree with your comment. We discussed this and agreed that, in
general, the GRE key is unique for a pair of MAG and LMA. We will
clarify this point in the next revision of the draft. 

However, usually the MAG cares about the GRE keys in the forward
direction and the draft allows the MAG to specify the GRE key in the
forward direction with all LMAs that it interacts with. This mechanism
allows the MAG to guarantee that all forward direction GRE keys are
unique across all LMAs.

The opposite is true in the case of the LMA. i.e. the LMA worries about
the GRE key in the reverse direction and the draft allows the LMA to
generate all of the GRE keys for the reverse direction with all other
MAGs. This way the GRE key for the reverse direction is always unique
within the same LMA across all other MAGs.

Basically in this case, if the local policy allows the MAG to generate
the forward direction GRE keys while the LMA generates the GRE keys in
the reverse direction, we will end up with no GRE key collision.

---

From: "Sri Gundavelli" <[email-masked]>
Date: Mon, 7 May 2007 21:45:31 -0700

Adding to Ahmad's comments ..

> 2. LMA must support GRE encapsulation and a GRE key allocation

This reflects an operational management issue. The LMA's have to be
provisioned with the private IPv4 prefixes that are configured in the
serving region. These prefixes are globally non routable and so the
LMA must enable flow tagging when a mobile using an address from
this prefix anchors to a MAG that is serving multiple operator
networks. So, this is a provisioning issue and the Layer-2 lookup at
the MAG will fail if there is an address collision and when the flows
are not tagged. 

This mechanism is in place in many Mobile IPv4 deployments today.
 
Regards
Sri

---

From: <[email-masked]>
Date: Tue, 8 May 2007 09:17:23 +0200

Hi Sri,

Thanks for your clarifications. I got one more comment inline.

Cheers,
	Jouni

> From: Sri Gundavelli [mailto:[email-masked]] 
> Sent: Tuesday, May 08, 2007 7:46 AM
> To: 'Ahmad Muhanna'; Korhonen, Jouni /TeliaSonera Finland 
> Oyj; [email-masked]
> Subject: RE: [netlmm] RE: Q on draft-muhanna-netlmm-grekey-option
> 
> > > There are cases where a LMAs would not return GRE Key 
> option back to 
> > > the MAG (e.g. LMAs do not understand the option at all 
> and just skip 
> > > it, or LMAs from different operators are not aware of overloaded 
> > > IPv4 ranges). In these cases the MAG might receive 
> overloaded IPv4 
> > > forward direction traffic from different LMAs without any GRE 
> > > encapsulation. How would the MAG do the layer-2 address 
> lookup for 
> > > MNs?
> > 
> > [Ahmad]
> > other words, the issue is when two IPv4 private addresses collide 
> > while they are served by the same LMA and MAG. If any LMA would be 
> > configured to server IPv4 private addresses, there are two options 
> > here:
> > 
> > stretch and many times it is not possible, or 2. LMA must 
> support GRE 
> > encapsulation and a GRE key allocation mechanism.
> 
> This reflects an operational management issue. The LMA's have 
> to be provisioned with the private IPv4 prefixes that are 
> configured in the serving region. These prefixes are globally 
> non routable and so the LMA must enable flow tagging when a 
> mobile using an address from this prefix anchors to a MAG 
> that is serving multiple operator networks. So, this is a 
> provisioning issue and the Layer-2 lookup at the MAG will 
> fail if there is an address collision and when the flows are 
> not tagged. 

Right.. thanks for spelling this out! Having had similar
deployment cases on MIP4 side I felt the draft should say a
bit more about the shared MAG case (again ;-). Could text
similar to above on layer-2 address lookups to be added to
those places that describe how the lookup is done using GRE
keys? It does affect the lookup logic after all, right.

> This mechanism is in place in many Mobile IPv4 deployments today.

Yep.

---

From: <[email-masked]>
Date: Tue, 8 May 2007 10:20:46 +0200

Hi Ahmad,

Thanks for your clarifications. See some more comments inline..

Cheers,
	Jouni

> From: Ahmad Muhanna [mailto:[email-masked]] 
> Sent: Tuesday, May 08, 2007 7:31 AM
> To: Korhonen, Jouni /TeliaSonera Finland Oyj; [email-masked]
> Subject: RE: Q on draft-muhanna-netlmm-grekey-option
> 
> Hi Jouni,
> > I got questions for my clarification on this draft relating to 
> > deployments where a MAG were shared between LMAs (that are possibly 
> > operated by different operators).
> > 
> > the MAG (e.g. LMAs do not understand the option at all and 
> > just skip 
> > it, or LMAs from different operators are not aware of 
> > overloaded IPv4 
> > ranges). In these cases the MAG might receive overloaded 
> > IPv4 forward 
> > direction traffic from different LMAs without any GRE 
> > encapsulation. 
> > How would the MAG do the layer-2 address lookup for MNs?
> 
> [Ahmad]
> These IPv4 private addresses are allocated by the different 
> LMAs. In other words, the issue is when two IPv4 private 
> addresses collide while they are served by the same LMA and 
> MAG. If any LMA would be configured to server IPv4 private 
> addresses, there are two options here:
> 
> 1. LMA must guarantee that there is no IPv4 overlap within 
> all the private IPv4 address pools that the LMA is serving, 
> this seems to be a stretch and many times it is not possible, 
> or 2. LMA must support GRE encapsulation and a GRE key 
> allocation mechanism.

Agree.. however, a single LMA case was never an issue. It is
described in very good detail in the current draft. The
questions I had raised because the draft is silent about
multiple LMA deployments. Even if solutions exist and might
be obvious, some clarifying text would definitely lessen
the "what if.." effect.

Like the latter example I gave above. The current text bases
its MN layer-2 address lookup on GRE keys. Some LMA agrees on
using GRE Keys and at the same time the other LMA thinks it
does not need to use GRE Keys for its traffic. E.g. in this
case I think there is room for improvements on describing the
MAG behavior and the lookup logic. Imho Sri's comment on this
topic was close to what I would like to see in the draft.

> on the GRE 
> > key and the LMA address? Or that each GRE tunnel/LMA have their own 
> > GRE key range?
> 
> [Ahmad]
> I agree with your comment. We discussed this and agreed that, 
> in general, the GRE key is unique for a pair of MAG and LMA. 
> We will clarify this point in the next revision of the draft. 

Good. Looking forward to read the next revision.

> However, usually the MAG cares about the GRE keys in the 
> forward direction and the draft allows the MAG to specify the 
> GRE key in the forward direction with all LMAs that it 
> interacts with. This mechanism allows the MAG to guarantee 
> that all forward direction GRE keys are unique across all LMAs.
> 
> The opposite is true in the case of the LMA. i.e. the LMA 
> worries about the GRE key in the reverse direction and the 
> draft allows the LMA to generate all of the GRE keys for the 
> reverse direction with all other MAGs. This way the GRE key 
> for the reverse direction is always unique within the same 
> LMA across all other MAGs.
> 
> Basically in this case, if the local policy allows the MAG to 
> generate the forward direction GRE keys while the LMA 
> generates the GRE keys in the reverse direction, we will end 
> up with no GRE key collision.
> 
> 
> > 
> > Cheers,
> > 	Jouni
> > 
> > 
> > 
>

---

From: "Ahmad Muhanna" <[email-masked]>
Date: Tue, 8 May 2007 09:39:30 -0500

Hi Jouni,

> be obvious, some clarifying text would definitely lessen the 
> "what if.." effect.
> 

[Ahmad]
No problem, we will clarify that one too. 

Regards,
Ahmad

---

From: "Sri Gundavelli" <[email-masked]>
Date: Tue, 8 May 2007 18:45:50 -0700

Hi Jouni,

> keys? It does affect the lookup logic after all, right.

I agree, some guidance can be provided for different scenario's.
Sure.

Regards
Sri