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

Hi,

Some updates were done in the document through github, still we are
reviewing if all the requested changes are completed.

Apologizes for the delay,

Ines.

On Tue, Jan 5, 2021 at 10:25 PM Alvaro Retana <aretana.ietf@gmail.com>
wrote:

> Hi!
>
> Where are we with this?   It is not clear whether we need to update the
> document or if we’re all agreeing. ;-)
>
> Erik/Pascal?
>
> Thanks!
>
> Alvaro.
>
> On December 18, 2020 at 10:42:24 AM, 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
>
> _______________________________________________
> Roll mailing list
> Roll@ietf.org
> https://www.ietf.org/mailman/listinfo/roll
>