headers
Hesham Soliman | 1 May 2010 13:14

Re: [MEXT] Operations Directorate Review of draft-ietf-mext-flow-binding-06

Thanks Bert, 

> Specifically my task was too look at operational/network-management aspects.
> 
> When I read:
>    Home agents that support this specification MAY refuse to maintain
>    flow bindings by setting the status field of any flow identification
>    mobility options to the value defined for "Administratively
>    prohibited" in Section 4.2, or by just ignoring all the flow binding
>    options.
> 
> Then it sounds to me as if something "administrative" needs to be configured,
> no?
> I see no discussion at all, how this "administratively prohibition" is/can be
> configured.
> So I cannot determine if/how that impact operation and/or network management
> aspects of the protocol extension.

=> This implies that the HA implementation may allow the admin to configure
this behaviour, i.e., something like "Flow_option_support False".
This kind of detail was not explained because there is at least a couple of
dozen config paramters that one could extrapolate from the MIPv6 spec and
we're just re-using that spec. So the spec is essentially saying that you
can use the same response code in MIPv6 to respond to this option.

Do you think we need to spell that out?

Hesham

>
(Continue reading)

Permalink | Reply | 4 comments |
headers
Hesham Soliman | 1 May 2010 15:31

Re: [MEXT] Operations Directorate Review of draft-ietf-mext-flow-binding-06


>> 
>> => This implies that the HA implementation may allow the admin to
>> configure
>> this behaviour, i.e., something like "Flow_option_support False".
>> This kind of detail was not explained because there is at least a couple
>> of
>> dozen config paramters that one could extrapolate from the MIPv6 spec and
>> we're just re-using that spec. So the spec is essentially saying that you
>> can use the same response code in MIPv6 to respond to this option.
>> 
>> Do you think we need to spell that out?
>> 
> 
> I think it would be usefull to spell that out, WITH a ptr to the RFC that
> actually describes it.
> Which one is that? Then I can check.

=> It's RFC 3775, but from memory it doesn't actually say anything about
"configurable parameters". It uses the same error code and it is implied
that this behaviour would be configurable.

> 
> I am not doing a security review, but I would think that if I were, I would
> like
> you to also add a ptr to the RFC you are refering to in that section.

=> ok.

Thanks,
(Continue reading)

Permalink | Reply | 0 comments |
headers
Bert Wijnen (IETF | 1 May 2010 12:40

Re: [MEXT] Operations Directorate Review of draft-ietf-mext-flow-binding-06

I did the OPS-DIRECTORATE review for this document.
 
Specifically my task was too look at operational/network-management aspects.
 
When I read:
   Home agents that support this specification MAY refuse to maintain
   flow bindings by setting the status field of any flow identification
   mobility options to the value defined for "Administratively
   prohibited" in Section 4.2, or by just ignoring all the flow binding
   options.
Then it sounds to me as if something "administrative" needs to be configured, no?
I see no discussion at all, how this "administratively prohibition" is/can be configured.
So I cannot determine if/how that impact operation and/or network management
aspects of the protocol extension.
 
Other than that, the document seems fine.
 
Bert
I copied the mext WG mailing list, but I am not subscribed to that one.
SO it may have to be approved.
 
----- Original Message -----
From: Tina TSOU
Sent: Monday, April 26, 2010 11:31 AM
Subject: Operations Directorate Review of draft-ietf-mext-flow-binding-06 by 2010-05-03

Hello,

As a member of the Operations Directorate you are being asked to review the

following IESG work item for it's operational impact.


 

IETF Last Call:

The file can be obtained via http://www.ietf.org/internet-drafts/draft-ietf-mext-flow-binding-06.txt IESG discussion can be tracked via https://datatracker.ietf.org/public/pidtracker.cgi?command=view_id&dTag=17255&rfc_flag=0

Please provide comments and review to the Ops-dir mailing list

(ops-dir <at> ietf.org) before 2010-05-03, and include the authors of the

draft as well.


 

For a list of questions to be answered in an OPS-DIR review see Appendix A in RFC 5706. Note that not all questions may apply to all documents, and some other items may be identified by the OPS-DIR reviews.



The status of Operations Directorate Review could be found

You could wiki it when you finish the review.

Thank you,

Tina

http://tinatsou.weebly.com/contact.html


_______________________________________________
MEXT mailing list
MEXT <at> ietf.org
https://www.ietf.org/mailman/listinfo/mext
Permalink | Reply | 6 comments |
headers
Bert Wijnen (IETF | 1 May 2010 15:26

Re: [MEXT] Operations Directorate Review of draft-ietf-mext-flow-binding-06

Inline
----- Original Message ----- 
From: "Hesham Soliman" <hesham <at> elevatemobile.com>
To: "Bert Wijnen (IETF)" <bertietf <at> bwijnen.net>; <tsirtsis <at> qualcomm.com>; 
<nicolas.montavont <at> telecom-bretagne.eu>; <gerardog <at> qualcomm.com>; 
<koo <at> comnets.uni-bremen.de>
Cc: "Dan (Dan) Romascanu" <dromasca <at> avaya.com>; "Ron Bonica" 
<rbonica <at> juniper.net>; <ops-dir <at> ietf.org>; <mext <at> ietf.org>
Sent: Saturday, May 01, 2010 1:14 PM
Subject: Re: Operations Directorate Review of 
draft-ietf-mext-flow-binding-06

> Thanks Bert,
>
>
>> Specifically my task was too look at operational/network-management 
>> aspects.
>>
>> When I read:
>>    Home agents that support this specification MAY refuse to maintain
>>    flow bindings by setting the status field of any flow identification
>>    mobility options to the value defined for "Administratively
>>    prohibited" in Section 4.2, or by just ignoring all the flow binding
>>    options.
>>
>> Then it sounds to me as if something "administrative" needs to be 
>> configured,
>> no?
>> I see no discussion at all, how this "administratively prohibition" 
>> is/can be
>> configured.
>> So I cannot determine if/how that impact operation and/or network 
>> management
>> aspects of the protocol extension.
>
> => This implies that the HA implementation may allow the admin to 
> configure
> this behaviour, i.e., something like "Flow_option_support False".
> This kind of detail was not explained because there is at least a couple 
> of
> dozen config paramters that one could extrapolate from the MIPv6 spec and
> we're just re-using that spec. So the spec is essentially saying that you
> can use the same response code in MIPv6 to respond to this option.
>
> Do you think we need to spell that out?
>

I think it would be usefull to spell that out, WITH a ptr to the RFC that 
actually describes it.
Which one is that? Then I can check.

I am not doing a security review, but I would think that if I were, I would 
like
you to also add a ptr to the RFC you are refering to in that section.

Bert

> Hesham
>
>>
>> Other than that, the document seems fine.
>>
>> Bert
>> I copied the mext WG mailing list, but I am not subscribed to that one.
>> SO it may have to be approved.
>>
>>   ----- Original Message -----
>>   From: Tina TSOU
>>   To: bertietf <at> bwijnen.net
>>   Cc: Dan (Dan) Romascanu ; Ron Bonica
>>   Sent: Monday, April 26, 2010 11:31 AM
>>   Subject: Operations Directorate Review of 
>> draft-ietf-mext-flow-binding-06 by
>> 2010-05-03
>>
>>
>>   Hello,
>>
>>   As a member of the Operations Directorate you are being asked to review 
>> the
>>
>>   following IESG work item for it's operational impact.
>>
>>
>>
>>   IETF Last Call:
>>
>> The file can be obtained via
>> http://www.ietf.org/internet-drafts/draft-ietf-mext-flow-binding-06.txt
>>
>>
>> IESG discussion can be tracked via
>> https://datatracker.ietf.org/public/pidtracker.cgi?command=view_id&dTag=17255&
>> rfc_flag=0Please provide comments and review to the Ops-dir mailing list
>>
>>   (ops-dir <at> ietf.org) before 2010-05-03, and include the authors of the
>>
>>   draft as well.
>>
>>
>>
>>   For a list of questions to be answered in an OPS-DIR review see 
>> Appendix A
>> in RFC 5706. Note that not all questions may apply to all documents, and 
>> some
>> other items may be identified by the OPS-DIR reviews.
>>
>>
>>
>>
>>
>>   The status of Operations Directorate Review could be found
>>   http://trac.tools.ietf.org/area/ops/trac/wiki/Directorates
>>
>>
>>   You could wiki it when you finish the review.
>>
>>
>>   Thank you,
>>
>>   Tina
>>
>>   http://tinatsou.weebly.com/contact.html
>>
>>
>
>
Permalink | Reply | 2 comments |
headers
Charles E. Perkins | 3 May 2010 20:05
Picon
Favicon

[MEXT] Mobility architecture for LTE/3GPP


Hello folks,

My understanding of the recent 3gv6 workshop
discussion was that the LTE design is not
comfortably situated in the design space
of IETF protocols.  I have some pretty
good ideas about why.  I would like to
have a BOF at the next IETF on the subject
of how 3GPP-based designs might evolve to
make better use of IETF mobility management,
and what IETF-based mobility designs might
need in order to better support 3GPP security,
policy management, and traffic conditioning.

In order for such a BOF to be approved
(quoting from recent email I received) we
need to develop a proposal to figure out
what the scope of the work is, and why it
belongs to the IETF and not the 3GPP.

Recent proposals to the [mext] working group
have been made that suggest strong needs for
evolution of Mobile IPv6 to better enable the
use of 3GPP-based security and tunneling
procedures.  It seems likely that, if this
were properly done, IETF could have more
impact on the future improvement of LTE.

I do have a more specific proposal which I
hope to publish as a new Internet Draft in
the next few weeks, but in the meantime I am
curious to find out if the participants on
these mailing lists would be interested in
attending such a BOF.

If there is support, I would be happy to create
a new mailing list for the BOF proposal.

Regards,
Charlie P.
Permalink | Reply | 0 comments |
headers
Laganier, Julien | 4 May 2010 17:38

Re: [MEXT] CoA==HoA test (Was: Re: Document Shepherd review of draft-ietf-mext-rfc3775bis-05)

Folks,

Laganier, Julien wrote:
> 
> Devarapalli, Vijay wrote:
> >
> > Laganier, Julien wrote:
> >
> > > [...]
> > >
> > > - Remove the HoA == CoA test as sufficient condition for deregistration.
> > > If we go this way, we also have to specify what to do when the HA
> > > receives a binding with HoA == CoA, we can't just remove the test alone.
> > > Since you're in favor of removing this test, what would you suggest the HA 
> > > does when it receives a BU with non-zero lifetime and set CoA == HoA? Send 
> > > an  error? Deregister the binding?
> >
> > We had discussed this too. The HA is supposed to send a binding ack
> > with error status if the HoA is set to CoA and the lifetime is not zero.
> > I don't have access to my email archive right now (had to change
> > email servers four months ago). I forgot what error status we had decided on.
> 
> OK.
> 
> Charlie also pointed out to an earlier conclusion but I couldn't find
> anything in the issue tracker. I personally don't care which way to go,
> but we need all cases to be covered in 3775bis.
> 
> If we go the way you suggest we concluded earlier, we need to agree on
> text and choose error code.
> 
> What are other people on the list thinking?

Is nobody thinking of anything? :-)

Vijay, would you care to propose some text so that we can close the issue?

--julien
Permalink | Reply | 52 comments |
headers
Basavaraj.Patil | 4 May 2010 18:12
Picon

Re: [MEXT] CoA==HoA test (Was: Re: Document Shepherd review of draft-ietf-mext-rfc3775bis-05)


Inline:

On 5/4/10 10:38 AM, "ext Laganier, Julien" <julienl <at> qualcomm.com> wrote:

> Folks,
> 
> Laganier, Julien wrote:
>> 
>> Devarapalli, Vijay wrote:
>>> 
>>> Laganier, Julien wrote:
>>> 
>>>> [...]
>>>> 
>>>> - Remove the HoA == CoA test as sufficient condition for deregistration.
>>>> If we go this way, we also have to specify what to do when the HA
>>>> receives a binding with HoA == CoA, we can't just remove the test alone.
>>>> Since you're in favor of removing this test, what would you suggest the HA
>>>> does when it receives a BU with non-zero lifetime and set CoA == HoA? Send
>>>> an  error? Deregister the binding?
>>> 
>>> We had discussed this too. The HA is supposed to send a binding ack
>>> with error status if the HoA is set to CoA and the lifetime is not zero.

From 3775 only perspective:
Isnt the case of an MN sending a BU with HoA==CoA and lifetime!=0 an
anomaly? 
However it would help if the MN received an error response from the HA as
Vijay suggested. So if Vijay can propose the error code and associated text
you could close the issue.

-Raj

>>> I don't have access to my email archive right now (had to change
>>> email servers four months ago). I forgot what error status we had decided
>>> on.
>> 
>> OK.
>> 
>> Charlie also pointed out to an earlier conclusion but I couldn't find
>> anything in the issue tracker. I personally don't care which way to go,
>> but we need all cases to be covered in 3775bis.
>> 
>> If we go the way you suggest we concluded earlier, we need to agree on
>> text and choose error code.
>> 
>> What are other people on the list thinking?
> 
> Is nobody thinking of anything? :-)
> 
> Vijay, would you care to propose some text so that we can close the issue?
> 
> --julien
Permalink | Reply | 50 comments |
headers
Behcet Sarikaya | 5 May 2010 18:31
Picon
Favicon

Re: [MEXT] DHCPv6 relay co-located with the DHCPv6 client at the MR for DHCPv6PD in NEMO

Hi Alex,

  Sorry for my late reply.

 
> Hi Behcet and thanks for the pointer.

>IMHO.

>It is not clear to me 
> whether the 2007 draft you cited
(draft-ietf-nemo-prefix-delegation-02) 
> addresses the problems listed in
> the recent discussion.

> That draft 
> uses BU extensions (new BU bit) as part of the MIPv6
protocol.  I 
> disagree with it, because DHCPv6-PD is better than DHCPv6
at allocating 
> prefixes, and already implemented, and already used.  I do
not see why 
> extending MIPv6 to allocate prefixes.

> To me (IMHO) a good solution would 
> use DHCPv6-PD non-encapsulated,
> between MR and AR-Relay.

Absolutely. This was missing in draft-ietf-nemo-prefix-delegation-02. That is the reason why we
redesigned it using DHCPv6 PD, but using it from HA as RR to the delegating router 
as in 
http://tools.ietf.org/html/draft-sarikaya-mext-bu-prefixdelegation-02

> Generally 
> speaking, if I had to describe the need:

>-need to allocate dynamically an 
> MNP to the MR.
-need to perform it securely: some of the risks are: (1) an MR 
> could
  falsely request a prefix prior to having identified itself to HA 
> using
  its MIP6 keys, (2) the HA may miss the allocated MNP from its 
> Prefix
  Table and thus couldn't ensure the MNP in the explicit mode BU 
> is
  legitimate.
>-need to reuse the NEMOv6 MIP6 protocol 
> unmodified.
>-need to reuse existing protocols naturally fit for prefix 
> allocation.
>-reliability: need to allocate a prefix to MR even when the 
> MIPv6
 > implementation fails; this is good in order to allow in-mobile 
> network
  communication between LFNs; MIP6 may fail when the MR is 
> disconnected,
  and when MIP traffic blocked by firewalls in the access 
> networks.
-need to inform the HA about the MNP allocated to the mobile 
> network,
  such that NEMOv6 MIP6 implementation works unmodified, and is 
> able to
  check the presence of the prefix in the NEMOv6 Prefix 
> Table.

I think we need a fresh look into this problem and what you have above could be a good starting point.

It is a difficult problem.

Regards,

Behcet
Permalink | Reply | 20 comments |
headers
Alexandru Petrescu | 5 May 2010 18:42
Picon

Re: [MEXT] DHCPv6 relay co-located with the DHCPv6 client at the MR for DHCPv6PD in NEMO

Le 05/05/2010 18:31, Behcet Sarikaya a écrit :
> Hi Alex,
>
> Sorry for my late reply.
>
>
>> Hi Behcet and thanks for the pointer.
>
>> IMHO.
>
>> It is not clear to me whether the 2007 draft you cited
> (draft-ietf-nemo-prefix-delegation-02)
>> addresses the problems listed in the recent discussion.
>
>> That draft uses BU extensions (new BU bit) as part of the MIPv6
> protocol.  I
>> disagree with it, because DHCPv6-PD is better than DHCPv6
> at allocating
>> prefixes, and already implemented, and already used.  I do
> not see why
>> extending MIPv6 to allocate prefixes.
>
>> To me (IMHO) a good solution would use DHCPv6-PD non-encapsulated,
>> between MR and AR-Relay.
>
>
> Absolutely. This was missing in draft-ietf-nemo-prefix-delegation-02.
> That is the reason why we redesigned it using DHCPv6 PD, but using it
> from HA as RR to the delegating router as in
> http://tools.ietf.org/html/draft-sarikaya-mext-bu-prefixdelegation-02

But this draft still extends BU/BAck to do PD on MR (it's in the title),
instead of using DHCPv6. I do not agree with this.

This draft does use DHCPv6-PD for HA as RR (DHCP Requesting Router, not
"Return Routability" nor "Resource Records" :-)  I agree with this in
general, although not sure whether HA could be RR if MR were too -
better have a single RR in the picture.

>> Generally speaking, if I had to describe the need:
>
>> -need to allocate dynamically an MNP to the MR.
> -need to perform it securely: some of the risks are: (1) an MR
>> could
> falsely request a prefix prior to having identified itself to HA
>> using
> its MIP6 keys, (2) the HA may miss the allocated MNP from its
>> Prefix
> Table and thus couldn't ensure the MNP in the explicit mode BU
>> is
> legitimate.
>> -need to reuse the NEMOv6 MIP6 protocol unmodified. -need to reuse
>>  existing protocols naturally fit for prefix allocation.
>> -reliability: need to allocate a prefix to MR even when the MIPv6
>> implementation fails; this is good in order to allow in-mobile
>> network
> communication between LFNs; MIP6 may fail when the MR is
>> disconnected,
> and when MIP traffic blocked by firewalls in the access
>> networks.
> -need to inform the HA about the MNP allocated to the mobile
>> network,
> such that NEMOv6 MIP6 implementation works unmodified, and is
>> able to
> check the presence of the prefix in the NEMOv6 Prefix
>> Table.
>
> I think we need a fresh look into this problem and what you have
> above could be a good starting point.

WEll we have a WG item, suffices it to change it according to remarks on
the WG list.  Or according to its consensus which should yet to be found.

Alex

>
> It is a difficult problem.
>
> Regards,
>
> Behcet
>
>
>
Permalink | Reply | 12 comments |
headers
Behcet Sarikaya | 5 May 2010 18:58
Picon
Favicon

Re: [MEXT] DHCPv6 relay co-located with the DHCPv6 client at the MR for DHCPv6PD in NEMO


> Absolutely. This was missing in 
> draft-ietf-nemo-prefix-delegation-02.
> That is the reason why we 
> redesigned it using DHCPv6 PD, but using it
> from HA as RR to the 
> delegating router as in
> 
> http://tools.ietf.org/html/draft-sarikaya-mext-bu-prefixdelegation-02

>But 
> this draft still extends BU/BAck to do PD on MR (it's in the title),
instead 
> of using DHCPv6. I do not agree with this.

This draft does use DHCPv6-PD 
> for HA as RR (DHCP Requesting Router, not
"Return Routability" nor "Resource 
> Records" :-)  I agree with this in
general, although not sure whether HA 
> could be RR if MR were too -
better have a single RR in the 
> picture.

Sorry, I misunderstood your comments. I was under the impression that the main problem with the nemopd
draft is because MR which is a moving node is RR. I think such an architecture intrinsically creates lots
of problems that you mentioned in your mails. 
If you don't agree with this then we don't need to argue more.

Regarding extending BU/BA for DHCPv6 PD, actually no, the extension needed has already been defined in RFC 5213.

> WEll we have a WG 
> item, suffices it to change it according to remarks on
the WG list.  Or 
> according to its consensus which should yet to be 
> found.

Good luck!

Behcet
Permalink | Reply | 4 comments |

Gmane