Subject: [nemo] Re:Comments on draft-ietf-nemo-mib-02.txt

From: Alexandru Petrescu <[email-masked]>
Date: Wed, 14 Mar 2007 14:56:54 +0100

Hi Sri, I have some comments on the NEMO-MIB draft, a WG item.

[email-masked] wrote:
  > 	Title		: NEMO Management Information Base
> 	Author(s)	: S. Gundavelli, et al.
> 	Filename	: draft-ietf-nemo-mib-02.txt
> 	Pages		: 34
> 	Date		: 2006-10-25
> 	
> This memo defines a portion of the Management Information Base (MIB),
>    the network mobility support (NEMO) MIB, for use with network
>    management protocols in the Internet community.  In particular, the
>    NEMO MIB will be used to monitor and control a mobile ipv6 node with
>    NEMO functionality.
> 
> A URL for this Internet-Draft is:
> http://www.ietf.org/internet-drafts/draft-ietf-nemo-mib-02.txt

>        nemoActiveRoamingIfIndex OBJECT-TYPE
>              SYNTAX      InterfaceIndex
>              MAX-ACCESS  read-only
>              STATUS      current
>              DESCRIPTION
>                      "The interface index of the current active
>                       roaming interface.
>                      "
>              REFERENCE
>                  "RFC3963 : Section 5.5"
>              ::= { nemoSystem 14 }

Can we call it "egress" interface, instead of "roaming" interface, 
because rfc3963 nemov6 and NEMOv4 draft in MIP4 WG both call it "egress" 
interface.

>         nemoDynamicHADiscovery  OBJECT-TYPE
>              SYNTAX      TruthValue
>              MAX-ACCESS  read-write
>              STATUS      current
>              DESCRIPTION
>                      "This object indicates whether or not the mobile
>                       router should attempt to make dynamic home agent
>                       address discovery(DHAAD).
>                      "
>              ::= { nemoRegistration 5 }

Can we have a related OBJECT-TYPE that flags the use of DHAAD upon each 
handover.  I mean, a flag value would enforce performing DHAAD upon each 
new CoA obtention, another flag value would enforce perfoming DHAAD now 
only (not upon each handover time).  Is this something feasible?  Or 
needed at all?  I need such kind of conditioning of the DHAAD behaviour 
in my implementation.

>        nemoHomeNetworkPrefixTable   OBJECT-TYPE
>              SYNTAX      SEQUENCE OF NemoHomeNetworkPrefixEntry
>              MAX-ACCESS  not-accessible
>              STATUS      current
>              DESCRIPTION
>                      "A table representing the potential home networks
>                       that the mobile router can use
>                      "
>              ::= { nemoRegistration 12 }

Who would use this table and where?  On MR?  Who fills it?  DHCP?

>         nemoPrefixTable   OBJECT-TYPE
>              SYNTAX      SEQUENCE OF NemoPrefixEntry
>              MAX-ACCESS  not-accessible
>              STATUS      current
>              DESCRIPTION
>                      "A table representing the NEMO prefixes.
>                      "
>              ::= { nemoConfiguration 2 }

I think this table should also contain the Home Address for each Home 
Network Prefix, no?  All MIB entries for the Prefix Table don't seem to 
include the HoA, am I right.

>          nemoOpNotSupported  OBJECT-TYPE
>              SYNTAX      Counter32
>              MAX-ACCESS  read-only
>              STATUS      current
>              DESCRIPTION
>                      "The total number of Binding Update requests
>                       rejected by the home agent with status code in the
>                       Binding Acknowledgement indicating
>                       'Mobile Router Operation not permitted'
>                       (Code 140).

Can we call this nemoOpNotPermitted instead of notSupported, to reflect 
the IANA number name better.

>    [RFC3775] Johnson, D., Perkins, C. and Arkko J., Mobility Support in
>    IPv6q RFC 3775, June 2004.

Typo q.

Finally, what would you think about doing same kind of document but for 
MIP4 WG (who does NEMOv4).  This MIB-NEMOv6 has several IPv6-related 
text that could be changed for IPv4 relatively easily (I think?).

Thanks,

Alex

______________________________________________________________________
This email has been scanned by the MessageLabs Email Security System.
For more information please visit http://www.messagelabs.com/email 
______________________________________________________________________

---

From: "Sri Gundavelli" <[email-masked]>
Date: Wed, 14 Mar 2007 23:42:24 -0700

Hi Alex,

-----Original Message-----
From: Alexandru Petrescu [mailto:[email-masked]] 
Sent: Wednesday, March 14, 2007 6:57 AM
To: [email-masked]
Subject: [nemo] Re:Comments on draft-ietf-nemo-mib-02.txt

[Sri] Ok.

[Sri] Possible. Too many knobs. But, we can do that.

[Sri] Plan to remove it. Its a feature, but we decided to remove this.

[Sri] Why should the HoA be prefix specific. The MIB is on the MR
and so there is only one HoA, per-3963.

[Sri] Ok.

Typo q.

[Sri] Sure. Will fix it.

[Sri] There is a 2206bis ...may be it can go there. You should talk to those
authors.

Thanks for the review.

Sri

---

From: Alexandru Petrescu <[email-masked]>
Date: Thu, 15 Mar 2007 11:55:59 +0100

Sri Gundavelli wrote:
[skpped what we agree - thanks]
>> nemoDynamicHADiscovery  OBJECT-TYPE SYNTAX      TruthValue 
>> MAX-ACCESS  read-write STATUS      current DESCRIPTION "This object
>> indicates whether or not the mobile router should attempt to make
>> dynamic home agent address discovery(DHAAD). " ::= {
>> nemoRegistration 5 }
> 
> Can we have a related OBJECT-TYPE that flags the use of DHAAD upon
> each handover.  I mean, a flag value would enforce performing DHAAD
> upon each new CoA obtention, another flag value would enforce
> perfoming DHAAD now only (not upon each handover time).  Is this
> something feasible?  Or needed at all?  I need such kind of
> conditioning of the DHAAD behaviour in my implementation.
> 
> 

Yes, I have that general feeling too, of too many knobs.

But this one is particularly relevant.  AFAIK, in no document is it
specified _when_ to do DHAAD: at each handover, or only at specific
times (which? bootstrap, etc).

I can achieve this with a config file, not necessarily MIB.  But using
MIB has other advantages (existing remote clients, etc).  So I'd prefer
having only one place to do all NEMO config, that's why I write about
MIB.  You may think differently...

>> nemoPrefixTable   OBJECT-TYPE SYNTAX      SEQUENCE OF
>> NemoPrefixEntry MAX-ACCESS  not-accessible STATUS      current 
>> DESCRIPTION "A table representing the NEMO prefixes. " ::= {
>> nemoConfiguration 2 }
> 
>  Network Prefix, no?  All MIB entries for the Prefix Table don't seem
> to include the HoA, am I right.
> 
> 
> [Sri] Why should the HoA be prefix specific. The MIB is on the MR and
> so there is only one HoA, per-3963.

Ok, for each HoA there is one or several Prefixes.  But the entry above
talks only Prefixes, not HoA.  The Prefix Table contains prefixes, and
for each prefix there is at least one HoA.

One prefix in the Prefix Table must be linked somehow (in configuration)
to a HoA.  If this is achieved by other-than-MIB mechanism then I'm
fine.  In my configuration file one entry in the Prefix Table looks like
this:

MNP1
MNP2    HoA

Which means MNP1 and MNP2 are 'linked' to that HoA, so that the security
check can happen.

> Finally, what would you think about doing same kind of document but
> for MIP4 WG (who does NEMOv4).  This MIB-NEMOv6 has several
> IPv6-related text that could be changed for IPv4 relatively easily (I
> think?).
> 
> [Sri] There is a 2206bis ...may be it can go there. You should talk
> to those authors.

You mean rfc2006? MIB for IP Mobility using SMIv2?

Which 'bis' draft should I search?

draft-sjostrand-mip4-udptunnel-mib-01.txt?

Thanks, I'll ask on the MIP4 list.

Alex