Subject: [Roll] [roll] #89: Spec is limited to single interface intermediate routers

From: "roll issue tracker" <[email-masked]>
Date: Wed, 04 Apr 2012 13:11:10 -0000

#89: Spec is limited to single interface intermediate routers

 Problem (currently open)
 ------------------------------
 The spec does not allow for routers with multiple interfaces. It expects
 that an address is usable downwards and upwards.

 Discussion
 -------------

 [Pascal]
 "When an
 intermediate router adds itself to a route, it MUST ensure that the
 IPv6 address added to the route is reachable in both forward and
 backward directions."
 This is written with the vision that the router has a single interface
 and acts as a repeater.
 But really a router could have 2 interfaces on a same subnet in which
 case that clause does not fly.

 [Mukul]
 All I mean is that the accumulated route MUST NOT have an address that
 cannot be accessed in one of the directions. If the address cannot be
 accessed in the backward direction, then the DRO would not be able to
 travel to the origin.

 [Pascal2] Then you're preventing a router with 2 interfaces. That's sad.
 I'm fine for an experimental draft   but for standard track that will
 have to be changed.

 [Mukul2] OK, I am keeping it the way it is.

 [Pascal3] This also need to be logged as a last call issue and its
 proposed resolution. Nothing wrong with having limitations, yet I think
 we must have specific text to indicate that the spec so far is limited
 to devices with a single interface. When we make the Standard Track
 version, I expect we'll have to go beyond that limitation. The drawback
 is for experimental  implementations that may not be interoperable with
 the final solution.

 [Mukul3] Could you please explain how does the requirement regarding
 addresses to be accessible in both forward and backward directions
 limits P2P-RPL to only single interface devices? I think this
 requirement means that P2P-RPL cannot be used across link layers. Is
 that what you mean? I think allowing operation across link layers would
 require P2P-RDO to accumulate additional information (backward address
 to be used for forward addresses not accessible in backward direction).
 I think at the moment we want to avoid this complexity.

 [Pascal4] Because an IP address is associated to an interface. If you
 have 2 interfaces, even in a same subnet, there should be 2 addresses.

 [Mukul4] But, why would the two IP addresses the device has on the same
 subnet wont be accessible in both forward and backward directions?

 Pascal

-- 
-----------------------------------+---------------------
 Reporter:  jpv@…                  |      Owner:  mukul@…
     Type:  defect                 |     Status:  new
 Priority:  major                  |  Milestone:
Component:  p2p-rpl                |    Version:
 Severity:  Submitted WG Document  |   Keywords:
-----------------------------------+---------------------

Ticket URL: <http://trac.tools.ietf.org/wg/roll/trac/ticket/89>
roll <http://tools.ietf.org/wg/roll/>

---

From: Mukul Goyal <[email-masked]>
Date: Fri, 13 Apr 2012 08:06:16 -0500 (CDT)

Hi Pascal,

I propose the following text to be placed inside the Applicability section:

"The participation in a P2P-RPL route discovery is currently limited to the routers with IPv6 addresses that are reachable in both incoming and outgoing directions, which it quite typical in usual LLN routers with a single radio"

Can we close this ticket?

Thanks
Mukul

----- Original Message -----
From: "roll issue tracker" <[email-masked]>
To: [email-masked], [email-masked]
Cc: [email-masked]
Sent: Wednesday, April 4, 2012 8:11:10 AM
Subject: [roll] #89: Spec is limited to single interface intermediate routers

 Problem (currently open)

 Discussion
 -------------

 [Pascal]
 "When an

 [Mukul]

 Pascal

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Fri, 13 Apr 2012 15:24:45 +0200

Hello Mukul

I'd prefer to use upward and downward which are the terms that RPL traditionally uses.... 

Is that OK with you? Otherwise yes, this text addresses my issue.

Cheers,

Pascal

-----Original Message-----
From: Mukul Goyal [mailto:[email-masked]] 
Sent: vendredi 13 avril 2012 15:06
To: [email-masked]
Cc: [email-masked]; Pascal Thubert (pthubert)
Subject: Re: [roll] #89: Spec is limited to single interface intermediate routers

Hi Pascal,

Thanks
Mukul

----- Original Message -----
From: "roll issue tracker" <[email-masked]>
To: [email-masked], [email-masked]
Cc: [email-masked]
Sent: Wednesday, April 4, 2012 8:11:10 AM
Subject: [roll] #89: Spec is limited to single interface intermediate routers

 Problem (currently open)
 ------------------------------
 The spec does not allow for routers with multiple interfaces. It expects  that an address is usable downwards and upwards.

 Discussion
 -------------

 [Pascal]
 "When an
 intermediate router adds itself to a route, it MUST ensure that the
 IPv6 address added to the route is reachable in both forward and  backward directions."
 This is written with the vision that the router has a single interface  and acts as a repeater.
 But really a router could have 2 interfaces on a same subnet in which  case that clause does not fly.

 [Mukul]
 All I mean is that the accumulated route MUST NOT have an address that  cannot be accessed in one of the directions. If the address cannot be  accessed in the backward direction, then the DRO would not be able to  travel to the origin.

 [Pascal3] This also need to be logged as a last call issue and its  proposed resolution. Nothing wrong with having limitations, yet I think  we must have specific text to indicate that the spec so far is limited  to devices with a single interface. When we make the Standard Track  version, I expect we'll have to go beyond that limitation. The drawback  is for experimental  implementations that may not be interoperable with  the final solution.

 [Mukul3] Could you please explain how does the requirement regarding  addresses to be accessible in both forward and backward directions  limits P2P-RPL to only single interface devices? I think this  requirement means that P2P-RPL cannot be used across link layers. Is  that what you mean? I think allowing operation across link layers would  require P2P-RDO to accumulate additional information (backward address  to be used for forward addresses not accessible in backward direction).
 I think at the moment we want to avoid this complexity.

 [Pascal4] Because an IP address is associated to an interface. If you  have 2 interfaces, even in a same subnet, there should be 2 addresses.

 [Mukul4] But, why would the two IP addresses the device has on the same  subnet wont be accessible in both forward and backward directions?

 Pascal

---

From: Mukul Goyal <[email-masked]>
Date: Fri, 13 Apr 2012 08:26:11 -0500 (CDT)

Should we use forward and backward terms? I already define them in the draft.

Thanks
Mukul

----- Original Message -----
From: "Pascal Thubert (pthubert)" <[email-masked]>
To: "Mukul Goyal" <[email-masked]>, [email-masked]
Cc: [email-masked]
Sent: Friday, April 13, 2012 8:24:45 AM
Subject: RE: [roll] #89: Spec is limited to single interface intermediate routers

Hello Mukul

Cheers,

Pascal

-----Original Message-----
From: Mukul Goyal [mailto:[email-masked]] 
Sent: vendredi 13 avril 2012 15:06
To: [email-masked]
Cc: [email-masked]; Pascal Thubert (pthubert)
Subject: Re: [roll] #89: Spec is limited to single interface intermediate routers

Hi Pascal,

Thanks
Mukul

----- Original Message -----
From: "roll issue tracker" <[email-masked]>
To: [email-masked], [email-masked]
Cc: [email-masked]
Sent: Wednesday, April 4, 2012 8:11:10 AM
Subject: [roll] #89: Spec is limited to single interface intermediate routers

 Problem (currently open)

 Discussion
 -------------

 [Pascal]
 "When an

 [Mukul]

 Pascal

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Fri, 13 Apr 2012 15:32:15 +0200

Yes, that would be perfect

Pascal

-----Original Message-----
From: Mukul Goyal [mailto:[email-masked]] 
Sent: vendredi 13 avril 2012 15:26
To: Pascal Thubert (pthubert)
Cc: [email-masked]; [email-masked]
Subject: Re: [roll] #89: Spec is limited to single interface intermediate routers

Thanks
Mukul

----- Original Message -----
From: "Pascal Thubert (pthubert)" <[email-masked]>
To: "Mukul Goyal" <[email-masked]>, [email-masked]
Cc: [email-masked]
Sent: Friday, April 13, 2012 8:24:45 AM
Subject: RE: [roll] #89: Spec is limited to single interface intermediate routers

Hello Mukul

Cheers,

Pascal

-----Original Message-----
From: Mukul Goyal [mailto:[email-masked]] 
Sent: vendredi 13 avril 2012 15:06
To: [email-masked]
Cc: [email-masked]; Pascal Thubert (pthubert)
Subject: Re: [roll] #89: Spec is limited to single interface intermediate routers

Hi Pascal,

Thanks
Mukul

----- Original Message -----
From: "roll issue tracker" <[email-masked]>
To: [email-masked], [email-masked]
Cc: [email-masked]
Sent: Wednesday, April 4, 2012 8:11:10 AM
Subject: [roll] #89: Spec is limited to single interface intermediate routers

 Problem (currently open)

 Discussion
 -------------

 [Pascal]
 "When an

 [Mukul]

 Pascal

---

From: Mukul Goyal <[email-masked]>
Date: Fri, 13 Apr 2012 08:39:04 -0500 (CDT)

Problem

Resolution:
-----------------------------
Add the following text to the Applicability section:

"The participation in a P2P-RPL route discovery is currently limited to the routers with IPv6 addresses that are reachable in both forward and backward directions, which it quite typical in usual LLN routers with a single radio"

 Discussion
 -------------

 [Pascal]
 "When an

 [Mukul]

[Mukul5]

[Pascal5]

[Mukul6]

[Pascal6]

---

From: "roll issue tracker" <[email-masked]>
Date: Fri, 13 Apr 2012 13:41:23 -0000

Changes (by jpv@…):

 * status:  new => closed
 * resolution:   => fixed

Comment:

 Problem

 Resolution:

 "The participation in a P2P-RPL route discovery is currently limited to
 the routers with IPv6 addresses that are reachable in both forward and
 backward directions, which it quite typical in usual LLN routers with a
 single radio"

 Discussion
 -------------

 [Pascal]
 "When an
 IPv6 address added to the route is reachable in both forward and  backward
 directions."

 [Mukul]

 [Pascal3] This also need to be logged as a last call issue and its
 proposed resolution. Nothing wrong with having limitations, yet I think
 we must have specific text to indicate that the spec so far is limited  to
 devices with a single interface. When we make the Standard Track  version,
 I expect we'll have to go beyond that limitation. The drawback  is for
 experimental  implementations that may not be interoperable with  the
 final solution.

 [Mukul3] Could you please explain how does the requirement regarding
 addresses to be accessible in both forward and backward directions  limits
 P2P-RPL to only single interface devices? I think this  requirement means
 that P2P-RPL cannot be used across link layers. Is  that what you mean? I
 think allowing operation across link layers would  require P2P-RDO to
 accumulate additional information (backward address  to be used for
 forward addresses not accessible in backward direction).
 I think at the moment we want to avoid this complexity.

 [Mukul5]
 I propose the following text to be placed inside the Applicability
 section:

 "The participation in a P2P-RPL route discovery is currently limited to
 the routers with IPv6 addresses that are reachable in both incoming and
 outgoing directions, which it quite typical in usual LLN routers with a
 single radio"

 [Pascal5]

 I'd prefer to use upward and downward which are the terms that RPL
 traditionally uses....

 [Mukul6]
 Should we use forward and backward terms? I already define them in the
 draft.

 [Pascal6]

 _______________________________________________
 Roll mailing list
 [email-masked]
 https://www.ietf.org/mailman/listinfo/roll

-- 
-----------------------------------+----------------------
 Reporter:  jpv@…                  |       Owner:  mukul@…
     Type:  defect                 |      Status:  closed
 Priority:  major                  |   Milestone:
Component:  p2p-rpl                |     Version:
 Severity:  Submitted WG Document  |  Resolution:  fixed
 Keywords:                         |
-----------------------------------+----------------------

Ticket URL: <http://trac.tools.ietf.org/wg/roll/trac/ticket/89#comment:1>
roll <http://tools.ietf.org/wg/roll/>

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Fri, 13 Apr 2012 15:53:33 +0200

Perfect : )

Pascal

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
Mukul Goyal
Sent: vendredi 13 avril 2012 15:39
To: JP Vasseur
Cc: roll
Subject: [Roll] Closure text for ticket #89

 Problem
 ------------------------------
 The spec does not allow for routers with multiple interfaces. It
expects  that an address is usable downwards and upwards.

Resolution:

 Discussion
 -------------

 [Pascal]
 "When an

 [Mukul]

 [Pascal2] Then you're preventing a router with 2 interfaces. That's
sad.
 I'm fine for an experimental draft   but for standard track that will
 have to be changed.

[Mukul5]

[Pascal5]

[Mukul6]

[Pascal6]

---

From: Michael Richardson <[email-masked]>
Date: Fri, 13 Apr 2012 10:05:58 -0400

>>>>> "Mukul" == Mukul Goyal <[email-masked]> writes:
    Mukul> I propose the following text to be placed inside the
    Mukul> Applicability section:

    Mukul> "The participation in a P2P-RPL route discovery is currently
    Mukul> limited to the routers with IPv6 addresses that are reachable
    Mukul> in both incoming and outgoing directions, which it quite
    Mukul> typical in usual LLN routers with a single radio"

I'm happy with this.

It likely covers the many cases where the P2P route crosses into a
backbone and then across ethernet.  There many some corner cases where
such a network is not functional, but the only way I can get to those
corner cases is due to bad implementation decisions.

-- 
]       He who is tired of Weird Al is tired of life!           |  firewalls  [
]   Michael Richardson, Sandelman Software Works, Ottawa, ON    |net architect[
] [email-masked] http://www.sandelman.ottawa.on.ca/ |device driver[
   Kyoto Plus: watch the video <http://www.youtube.com/watch?v=kzx1ycLXQSE>
	               then sign the petition.