Re: [Roll] Erik Kline's Discuss on draft-ietf-roll-useofrplinfo-42: (with DISCUSS and COMMENT)

Dear Erik,

Thank you very much for your comments and suggestions, in version 43
(diff)  [Diff:
https://www.ietf.org/rfcdiff?url2=draft-ietf-roll-useofrplinfo-43] we added
a definition of consumed RH:

New text:
    Consumed: A Routing Header is consumed when the Segments Left field
    is zero, which indicates that the destination in the IPv6 header is
    the final destination of the packet and that the hops in the Routing
    Header have been traversed.

Please let us know if this addresses your concern.

Thank you again,

Ines, Michael and Pascal.

On Fri, Dec 18, 2020 at 5:42 PM Pascal Thubert (pthubert) <pthubert=
40cisco.com@dmarc.ietf.org> wrote:

> Hello Michael and all:
>
> > -----Original Message-----
> > From: Roll <roll-bounces@ietf.org> On Behalf Of Michael Richardson
> > Sent: mercredi 16 décembre 2020 19:02
> > To: Erik Kline <ek.ietf@gmail.com>; Routing Over Low power and Lossy
> > networks <roll@ietf.org>
> > Subject: Re: [Roll] Erik Kline's Discuss on
> draft-ietf-roll-useofrplinfo-42: (with
> > DISCUSS and COMMENT)
> >
> >
> > Erik Kline via Datatracker <noreply@ietf.org> wrote:
> >     >   I might recommend instead referring to RFC 6554 S4.2 for how to
> >     > handle RH3's if the node is also a RPL-aware router and say it MUST
> >     > drop the packet if segments left is non-zero and it's not a
> RPL-aware
> >     > router.
> >
> >     >   Related: I'd also recommend:
> >
> >     >   "It should just be noted that an incoming RH3 must be fully
> consumed,
> >     > or very carefully inspected."
> >
> >     ->
> >
> >     >   "It should just be noted that an incoming RH3 MUST be fully
> >     > consumed."
> >
> > I think that Pascal and I, when we write the "carefully inspected", is
> that we
> > are imagining situations where the topology is a bit subtle.
>
> Yes, I expected policies that would validate the right of a Leaf to
> participate to a DODAG ,or to remap the information from the leaf (could be
> the RPI, the opaque field in the EARO, or the 6-tuple) into an RPI.
>
> > Perhaps there are firewalls involved.
> > Perhaps a device has multiple interfaces (many radios for instance) and
> the
> > extra segments address the other interfaces.
> >
> > Also draft-ietf-anima-autonomic-control-plane uses storing mode, so never
> > has
> > RH3 headers, but imagine if it did.
> >
> > One could have a situation where the physical system containing one or
> more
> > layers of container was not the ultimate last hop from a logical point
> of view.
> > Rather than inner container was.  So, it's all the same stack actually.
> In that
> > case, an optimization might be to process more than one segment in that
> > stack.
> > (The ANIMA ACP definitely supports having VMs and containers inside
> > routers)
> >
> > So, I can live with your suggestion, because in my case above, we can
> argue
> > that it's still "consumed"
> >
> >     > * I'm confused by the use of "consumed" here.  Is the final RH3
> entry
> >     > RUL's address?  I guess you could say RH penultimate hop
> "consumes" the
> >     > header because the ultimate destination address is put in the
> header DA
> >     > field.  Seems a bit odd though.
> >
> > Yes, that's what we mean.
>
> Yes, as I said in my response I thought it was quite common. I'm surprised
> to find little art to quote.
>
> > Once that ultimate destination is in the DA, then the RH3 is a dummy,
> but one
> > we are aren't supposed to remove.
> >
> >     >   I assume 6LR_n gets RUL's address from the last segment in RH3.
> >
> >     >   "Consumed" means segments left == 0, I guess?  I suppose should
> have
> >     > picked up on this terminology when it was first used in Section 2.
> >     > Maybe clarify what it means in that section (2)?
> >
> > Yes.
>
>
> Cool, we're good!
>
> Pascal
> _______________________________________________
> Roll mailing list
> Roll@ietf.org
> https://www.ietf.org/mailman/listinfo/roll
>