Re: [Roll] Benjamin Kaduk's Abstain on draft-ietf-roll-aodv-rpl-13: (with COMMENT)

[Charles Perkins <[e-mail]>]

Hello Benjamin,

Here, finally, are some proposed resolutions for the comments you have 
made three months ago.

On 3/21/2022 1:42 PM, Benjamin Kaduk via Datatracker wrote:
 >
 > ----------------------------------------------------------------------
 > COMMENT:
 > ----------------------------------------------------------------------
 >
               ..........
 >
 > Section 6.4.1 (RREP handling) directs the router's processing to 
proceed to
 > §6.2.2 (RREQ handling), which seems like an unfortunate copy/paste error.

Yes, this should have been "6.4.2.  Step 2: OrigNode or Intermediate 
Router".

 > I continue to believe that it would be very helpful to depict the 'S bit'
 > information associated with an RREQ-Instance as a tristate rather than a
 > single bit.  In essence, this state reflects the contract between 
adjacent
 > nodes about how to process the corresponding RREP-DIO, but a given
 > (intermediate) router needs to know what contract to use both when
 > processing an incoming RREP-DIO and when emitting an RREP-DIOO (indeed,
 > even to know whether to emit unicast or multicast), and it's hard to see
 > how a single bit could cover both incoming and outgoing RREP-DIOs at the
 > point of transition.

It's easier if one expresses the meaning of the 'S' bit differently.
If a RREQ-DIO is received with the 'S bit' is one, then the receiver
treats the route back to OrigNode as a symmetric route.  Upon reception
of a RREP, if the 'S bit' of the associated RREQ-Instance is 1, then
the intermediate node can transmit the RREP toward the OrigNode along a
symmetric route.  The truth tables for these two actions are identical,
and so can be represented by a single bit.

 > A few other section-by-section notes follow.
 >
 > Section 4.1
 >
 >     L
 >        2-bit unsigned integer determining the length of time that a node
 >        is able to belong to the RREQ-Instance (a temporary DAG including
 >        the OrigNode and the TargNode).  Once the time is reached, a node
 >        MUST leave the RREQ-Instance and stop sending or receiving any
 >        more DIOs for the RREQ-Instance.  This naturally depends on the
 >        node's ability to keep track of time.  Once a node leaves an RREQ-
 >        Instance, it MUST NOT rejoin the same RREQ-Instance.  L is
 >        independent from the route lifetime, which is defined in the DODAG
 >        configuration option.
 >
 > I assume that this "MUST NOT rejoin" would have some timeframe associated
 > with it (at least for L != 0x00), since the instance-id could 
eventually be
 > reused for a different logical instance.

We will create another configurable parameter, perhaps called 
REJOIN_REENABLE,
with a relatively long default value.

 > Section 4.2
 >
 >     L
 >        2-bit unsigned integer defined as in RREQ option.  The lifetime of
 >        the RREP-Instance MUST be shorter than the lifetime of the RREQ-
 >        Instance to which it is paired.
 >
 > Strictly shorter, or "less than or equal to"?  I think, given the limited
 > options, strictly shorter would be pretty disruptive.

Yes, that is appropriate.

 > Section 6.2.4
 >
 >     Suppose a router has joined the RREQ-Instance, and H=0, and the S-bit
 >     of the RREQ-Instance is set to 1.  In this case, the router MAY
 >     optionally associate to the RREQ-Instance, the Address Vector of the
 >     symmetric route back to OrigNode.  This is useful if the router later
 >     receives an RREP-DIO that is paired with the RREQ.
 >
 > I think we should say what happens if I don't do what the MAY says.  
Do we
 > just fail to find a route entirely, or only with degraded performance, or
 > ...?

If the router does NOT associate the Address Vector, then it has to rely on
multicast for the RREP. This can impose a substantial performance penalty.

 > Section 6.4.2
 >
 >     The router updates its stored value of the TargNode's sequence number
 >     according to the value provided in the ART option.  The router next
 >     checks if one of its addresses is included in the ART Option.  If so,
 >     this router is the OrigNode of the route discovery.  [...]
 >
 > This seems to set up a scenario where TargNode learns about its own 
sequence
 > number updates by processing the ART Option, which is rather amusing to
 > think about

This text in section 6.4.2 specifies that the recipient of the RREP should
update the information it has about TargNode's sequence number.  If TargNode
receives the RREP, that action would not apply.  A good way to eliminate 
this
problem is to specify at the very beginning of section 6.4 that the TargNode
MUST drop the RREP-DIO if the TargNode was the device that originated the
RREP-DIO with that RREP-InstanceID.  This prevents recirculating RREPs as
well as eliminating the problem just identified.


 > NITS
 >
 > Section 6.1
 >
 >     RPLInstance and a DODAG rooted at itself.  Then it transmits a DIO
 >     message containing exactly one RREQ option (see Section 4.1) to
 >     multicast group all-RPL-nodes.  The DIO MUST contain at least one ART
 >
 > "the multicast group".

Check.   Also, we are requesting a new multicast group.

Naturally Yours,
Charlie P.





On 3/21/2022 1:42 PM, Benjamin Kaduk via Datatracker wrote:
> Benjamin Kaduk has entered the following ballot position for
> draft-ietf-roll-aodv-rpl-13: Abstain
>
> When responding, please keep the subject line intact and reply to all
> email addresses included in the To and CC lines. (Feel free to cut this
> introductory paragraph, however.)
>
>
> Please refer to https://www.ietf.org/about/groups/iesg/statements/handling-ballot-positions/
> for more information about how to handle DISCUSS and COMMENT positions.
>
>
> The document, along with other ballot positions, can be found here:
> https://datatracker.ietf.org/doc/draft-ietf-roll-aodv-rpl/
>
>
>
> ----------------------------------------------------------------------
> COMMENT:
> ----------------------------------------------------------------------
>
> Thanks for the updates in -12 and -13, they're a big help for clarity and
> readability.
>
> I'm abstaining because I don't think this document should be published in
> its current form, but cannot supply a concrete path to changes that would
> make it suitable.  (I believe that such a path exists, but I cannot provide
> a proof by construction.)  I'm also concerned about the level of review this
> document has received, with multiple errors having gone uncaught until the
> IESG Evaluation stage.
>
> That said, I do have some additional comments to offer in the hope that they
> improve the document.
>
> Section 6.4.1 (RREP handling) directs the router's processing to proceed to
> §6.2.2 (RREQ handling), which seems like an unfortunate copy/paste error.
>
> I continue to believe that it would be very helpful to depict the 'S bit'
> information associated with an RREQ-Instance as a tristate rather than a
> single bit.  In essence, this state reflects the contract between adjacent
> nodes about how to process the corresponding RREP-DIO, but a given
> (intermediate) router needs to know what contract to use both when
> processing an incoming RREP-DIO and when emitting an RREP-DIOO (indeed, even
> to know whether to emit unicast or multicast), and it's hard to see how a
> single bit could cover both incoming and outgoing RREP-DIOs at the point of
> transition.
>
> A few other section-by-section notes follow.
>
> Section 4.1
>
>     L
>        2-bit unsigned integer determining the length of time that a node
>        is able to belong to the RREQ-Instance (a temporary DAG including
>        the OrigNode and the TargNode).  Once the time is reached, a node
>        MUST leave the RREQ-Instance and stop sending or receiving any
>        more DIOs for the RREQ-Instance.  This naturally depends on the
>        node's ability to keep track of time.  Once a node leaves an RREQ-
>        Instance, it MUST NOT rejoin the same RREQ-Instance.  L is
>        independent from the route lifetime, which is defined in the DODAG
>        configuration option.
>
> I assume that this "MUST NOT rejoin" would have some timeframe associated
> with it (at least for L != 0x00), since the instance-id could eventually be
> reused for a different logical instance.
>
> Section 4.2
>
>     L
>        2-bit unsigned integer defined as in RREQ option.  The lifetime of
>        the RREP-Instance MUST be shorter than the lifetime of the RREQ-
>        Instance to which it is paired.
>
> Strictly shorter, or "less than or equal to"?  I think, given the limited
> options, strictly shorter would be pretty disruptive.
>
> Section 6.2.4
>
>     Suppose a router has joined the RREQ-Instance, and H=0, and the S-bit
>     of the RREQ-Instance is set to 1.  In this case, the router MAY
>     optionally associate to the RREQ-Instance, the Address Vector of the
>     symmetric route back to OrigNode.  This is useful if the router later
>     receives an RREP-DIO that is paired with the RREQ.
>
> I think we should say what happens if I don't do what the MAY says.  Do we
> just fail to find a route entirely, or only with degraded performance, or
> ...?
>
> Section 6.4.2
>
>     The router updates its stored value of the TargNode's sequence number
>     according to the value provided in the ART option.  The router next
>     checks if one of its addresses is included in the ART Option.  If so,
>     this router is the OrigNode of the route discovery.  [...]
>
> This seems to set up a scenario where TargNode learns about its own sequence
> number updates by processing the ART Option, which is rather amusing to
> think about :)
>
> NITS
>
> Section 6.1
>
>     RPLInstance and a DODAG rooted at itself.  Then it transmits a DIO
>     message containing exactly one RREQ option (see Section 4.1) to
>     multicast group all-RPL-nodes.  The DIO MUST contain at least one ART
>
> "the multicast group".
>
>
>