Re: [Roll] draft-ietf-6man-rpl-routing-header-07

[Mukul Goyal <[e-mail]>]

Hi Jonathan

I have serious issues with the use of RPL Instance as the domain for SRH.

>>[R Cragie]
>> p7: RPL Instance ID - why is this needed for source routing? RPL is not even used for source routing. This flavors the SRH unnecessarily and the processing does not use it. If the reason is for checking entering and exiting a RPL domain, this processing needs to be stated.

>[J Hui]
>Page 12 describes processing rules intended to keep the SRH within a RPL Instance.


Page 12 has no mention of RPL Instance. Page 13 does mention RPL Instance in the following rules:

   2.  Datagrams destined elsewhere within the same RPL Instance are
       forwarded to the correct interface.

   3.  Datagrams destined to nodes outside the RPL Instance are dropped
       if the outer-most IPv6 header contains a SRH not generated by the
       RPL router forwarding the datagram.

My question is how does a router know whether the next hop is within the same RPL Instance or not? A router has no idea what RPL Instances its neighbors belong to. 

It seems that a router, that receives a packet with a SRH, does not need to check if it belongs to the RPL Instance mentioned in the SRH. It just needs to check if the next hop belongs to that RPL Instance or not. And as I said in the prev para, I am not sure how would the router make that check.

It would be a problem if the router were required to check its own membership in the RPL Instance in order to accept a packet with SRH. Routers part of a source route should not need to maintain any state about it. 

Thanks
Mukul