Subject: Re: Issue 25 (was: RE: [netlmm] New Issues #22, #23, #24, #25, #26 and #27)

From: Julien Laganier <[email-masked]>
Date: Wed, 24 May 2006 11:01:27 +0200

Fred, 

Ok, I should have been more precise. It seems that my usage of 
'off-link prefix' is misleading. I should have said 'not on-link'.

According to [1], setting L=0 means that no statement is made about 
on-link or off-link properties of the prefix.

However, If I parse [2] and [3] correctly it means that when L=0 and  
a node has a packet to send to an address in the same prefix, by 
default it sends the packet to the router (In my own words, that 
somehow means that an address in the prefix is considered as off-link 
"by default", but that's beyond the point.)

> > The draft specifies that the prefix is advertized as off-link so
> > that all packets send by MNs goes to their AR. This is meant so
> > that the MN perception is that it has a kind of point-to-point
> > link to its AR. I don't see how that would not be appropriate for
> > a specific media. 
> 
> I still think a better resolution would be for the spec to
> either remain silent on the subject of redirects or cite
> (RFC2461(bis), Section 8.2) as normative because the semantics
> of redirect for the purposes of this document are be no different
> than for any other link on which prefixes are advertised with
> the 'L' bit set to zero. Note also that setting 'L'=0 does not
> necessarily mean "off-link"; see RFC2461, Sections 4.6.2 and
> 6.3.4).

The document does not propose to change the semantic of REDIRECT. 
Rather, it uses the flexibility provided by the use of SHOULD [5] 
regarding situation in which the router SHOULD send REDIRECT [4].

I believe there are valid reasons to do so (allows for SEND usage, 
avoid issues of multi-link subnets.)

> > Advertising the prefix as off-link is essential to this draft as
> > it avoids most of the issues involved with multi-link subnets.
>
> Can you explain? NETLMM is still going to be a multi-link
> subnet for packets that go MAP->AR->MN.

Yes, but issues involved with multi-link subnet mostly concern nodes 
on that subnet, i.e. the MNs. If they got the illusion that all other 
nodes on that prefix are off-link and sends all packet to routers we 
avoid issues. For example MN can use SEND.

> > The point of the proposed resolution is that if the AR sends
> > redirects
> >
> > to MNs, it will break the off-link prefix trick because part of
> > the nodes under that prefix would appear on-link.
>
> Again, setting 'L'=0 does not necessarily mean off-link
> per RFC2461, sections 4.6.2 and 6.3.4.

See my point at the beginning of this message; I should have said 'not 
on-link prefix'.

> > So IMO we should stick to the proposed resolution. Besides, I
> > fail to find an example of a media for which it is not
> > appropriate; I think this behavior is media independent.
>
> I disagree; I don't see it appropriate for this spec to
> supercede the behavior already defined in the ND specs.

I disagree. I do not see it is appropriate to employ the term 
'supersede' here. The behavior specified is this document is 
conformant to RFC2461, it uses the flexibility provided by the use of 
SHOULD [5] regarding when to send REDIRECT [4].

I think I made my point here. You might still disagree, in which case 
I think we'll have to agree to disagree because the messages I'm 
posting here looks more and more like law treaties ;-) I'll however 
be happy to hear someone else's opinion on that matter.

Best,

--julien

[1] Quoting Section 4.6.2. of RFC2461:

      L    1-bit on-link flag.  When set, indicates that this
           prefix can be used for on-link determination.  When
           not set the advertisement makes no statement about
           on-link or off-link properties of the prefix.  For
           instance, the prefix might be used for address
           configuration with some of the addresses belonging
           to the prefix being on-link and others being off-
           link.

[2] Quoting Section 6.3.4. of RFC2461:

   The default behavior (see Section 5.2) when sending a packet to an
   address for which no information is known about the on-link status
   of the address is to forward the packet to a default router; 

[3] Quoting Section 5.2. of RFC2461:

   The sender performs a longest prefix match against the
   Prefix List to determine whether the packet's destination is on- or
   off-link.  If the destination is on-link, the next-hop address is 
   the same as the packet's destination address.  Otherwise, the
   sender selects a router from the Default Router List

[4] Quoting Section 8.2. of RFC2461:

   A router SHOULD send a redirect message, subject to rate limiting,
   whenever it forwards a packet that is not explicitly addressed to
   itself (i.e. a packet that is not source routed through the router)
   in which:

      - the Source Address field of the packet identifies a neighbor,
        and

      - the router determines that a better first-hop node resides on
        the same link as the sending node for the Destination Address 
        of the packet being forwarded, and

      - the Destination Address of the packet is not a multicast
        address ...

[5] Quoting Section 3. of RFC2119:

   SHOULD   This word, or the adjective "RECOMMENDED", mean that there
   may exist valid reasons in particular circumstances to ignore a
   particular item, but the full implications must be understood and
   carefully weighed before choosing a different course.

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

---

From: "Templin, Fred L" <[email-masked]>
Date: Wed, 24 May 2006 12:14:12 -0700

Julien,

> regarding situation in which the router SHOULD send REDIRECT [4].

Yes, the flexibility is there in RFC2461, and there is even more
flexibility in RFC2461(bis) where Section 8.2 says:

      - the router determines (by means outside the scope of this
        specification) that a better first-hop node resides on
        the same link as the sending node for the Destination Address of
        the packet being forwarded, and

> avoid issues. For example MN can use SEND.

I still don't understand why you keep referring to multi-link
subnet here and how any multi-link issues are mitigated by
sending all packets to the router? Multi-link subnet issues
primarily center around decrementation of the TTL/Hop Limit
within the same logical IP subnet, so I don't see how the
argument applies. Also, AFAICT MN1 and MN2 can still use SEND
whether their packets go MN1<->AR<->MN2 or MN1<->MN2; at least,
the scenario is no different than for ordinary links.

> SHOULD [5] regarding when to send REDIRECT [4].

You already agreed that RFC2461, Section 8.2 provides the
necessary flexibility and, as I have shown, RFC2461(bis),
Section 8.2 provides even more flexibility. AFAICT, you
haven't proved any points for NETLMM links that are any
different than for ordinary links. Behavior should therefore
default to that specified in the normative references.

Fred
[email-masked]

---

From: "Templin, Fred L" <[email-masked]>
Date: Thu, 25 May 2006 09:00:50 -0700

Julien,

It occurred to me that perhaps you weren't intending to refer
to multi-link subnet *issues* but rather a multi-link subnet
*attribute*. One attribute of a multi-link subnet (which I
think should be agreed that NETLMM is an example) is that
MNs in the same IP prefix may be attached to different links.
Moreover, MNs that were formerly attached to the same link may
move to different links during the course of communication
sessions.

So, I can see reason for the MN-AR interface spec to supercede
the normative reference but only if it gives a specific reason
for doing so, e.g.,

  "An AR SHOULD NOT send a redirect message ([RFC2461], Section 8.2)
   unless it can determine that the sending node and better first-hop
   node reside on the same link and will remain on the same link."

Fred

-----Original Message-----
From: Templin, Fred L 
Sent: Wednesday, May 24, 2006 12:14 PM
To: Julien Laganier
Cc: [email-masked]
Subject: RE: Issue 25 (was: RE: [netlmm] New Issues #22, #23, #24,
#25,#26 and #27)

Julien,

Fred

---

From: Julien Laganier <[email-masked]>
Date: Mon, 29 May 2006 12:00:38 +0200

Fred,

On Thursday 25 May 2006 18:00, Templin, Fred L wrote:
>   "An AR SHOULD NOT send a redirect message ([RFC2461], Section
> 8.2) unless it can determine that the sending node and better
> first-hop node reside on the same link and will remain on the same
> link."

It seems we now understand each others.

However, because NetLMM is supposed to deal with _mobile_ nodes, I 
cannot imagine a case where an AR would be able to determine that two 
nodes _will remain_ on the same link... They are mobile after all.

But anyway the text you are proposing is fine with me, so I propose 
that we include it in the draft.

--julien

---

From: "Templin, Fred L" <[email-masked]>
Date: Tue, 30 May 2006 10:14:44 -0700

Julien,

> It seems we now understand each others.

Agree.

> nodes _will remain_ on the same link... They are mobile after all.

Right, but even more interestingly I think this goes to the
question of exactly what is a mobile node. IMHO, a mobile node
is any node that may lose connection with its current router and
need to discover and begin using a new router. This is true for
the classic mobility cases, but it could also be equally true for
traditionally static scenarios such as a bridged campus LAN where
LAN segments might become detached for a certain length of time
during which stationary nodes might lose connection with their
router and need to make connection with a new router. Such
"stationary" nodes would then appear to the network as though
they were mobile even if they were bolted in place on a rack
mount! It makes me wonder if it is ever really truly safe for
a router to issue redirects... 

> that we include it in the draft.

Sounds good.

Fred

--julien