_More significant comments_
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.
p10: "In order to respect the IPv6 Hop Limit value of the original datagram, a RPL router generating an SRH MUST set the Segments Left to no greater than the original datagram's IPv6 Hop Limit value upon forwarding.". This language is confusing. 'upon forwarding' suggests that it is the 'IPv6 Hop Limit - 1' value, and again only if it is forwarded, but it is not clear. Also, an 'original datagram' may not always be *forwarded*, i.e. if it originates on the RPL router itself.
p10: "In the case that the source route is longer than the original datagram's IPv6 Hop Limit, only the initial hops (determined by the original datagram's IPv6 Hop Limit) should be included in the SRH.". This means it is unlikely to reach its destination, so why bother?
p10: "If the RPL router is not the source of the original datagram, the original datagram's IPv6 Hop Limit field is decremented before generating the SRH." If this were placed the the beginning of the paragraph, it might be clearer.
p10: "After generating the SRH, the RPL router decrements the original datagram's IPv6 Hop Limit value by the SRH Segments Left value. Processing the SRH Segments Left and original datagram's IPv6 Hop Limit fields in this way ensures that ICMPv6 Time Exceeded errors occur as would be expected on more traditional IPv6 networks that forward datagrams without tunneling." It's not really a tunnel then as defined by RFC 2473 and somewhat conflicts with what's written in RFC 2473. Also, you don't want to do this when the packet is not tunneled or you will be double counting.
_Minor (use of language) comments:_ Throughout: Inconsistent use of: 1. 'router' 2. 'RPL router' 3. 'RPL Router'(3) (note capitalization) is a defined term. (1) and (2) are used generally but inconsistently. Use 'RPL router' to mean a 'RPL Border Router' or a 'RPL Router' throughout. Use 'a RPL router' as introductory to a sentence and, if necessary, 'the router' only to refer to the introduced RPL router, although 'the RPL router' is generally better. This would make the document clearer in places.
p1: "or few routers" -> "or a few routers". Reason for change: 'few routers' on its own implies 'not many routers'.
p6: "In the scenarios above, R may indicate a RPL Border Router (when connecting to other routing domains) or a RPL Router" -> "In the scenarios above, the RPL router R may indicate a RPL Border Router (when connecting to other routing domains) or a RPL Router". Reason for change: This introduces the term 'RPL router' as either a 'RPL Border Router' or a 'RPL Router' (note both are defined terms) correctly for the subsequent paragraph.
p6: "One such use case with RPL is to have all RPL traffic flow through a Border Router and have the Border Router use source routes to deliver datagrams to their final destination. When including the SRH using tunneled mode, the Border Router would encapsulate the received datagram unmodified using IPv6-in-IPv6 and include a SRH in the outer IPv6 header." -> "One such use case with RPL is to have all RPL traffic flow through a RPL Border Router and have the RPL Border Router use source routes to deliver datagrams to their final destination. When including the SRH using tunneled mode, the RPL Border Router would encapsulate the received datagram unmodified using IPv6-in-IPv6 and include a SRH in the outer IPv6 header." Reason for change: Uses the correct terminology.
p6: "In the above scenario, datagrams travel from S to D through LBR" -> "In the above scenario, datagrams travel from S to D through the RPL Border Router LBR (referred to as LBRs in [I-D.ietf-roll-terminology])". Reason for change: Clarify what LBR is.
Robert On 19/12/2011 11:59 PM, Park, Kundok wrote:
As another side note, this new draft revision creates a situation where the hop limit from the RPL router performing source routing may be one and hence it cannot use SRH (because Segments Left becomes zero and no address can be included). In order to make it appear as if it tried the source routing with one hop, I think the RPL router must forward the packet to the next hop that it should normally pick for a source routing without modifying the original packet (that is, the destination address remains the same as the final destination). I don't think this requires any change to the draft because the RPL router in this case is not using SRH and hence out of scope of this draft.BR, Kundok ------------------------------------------------------------------------*From:*ipv6-boun...@ietf.org [mailto:ipv6-boun...@ietf.org] *On Behalf Of *Park, Kundok*Sent:* Monday, December 19, 2011 1:18 PM *To:* ipv6@ietf.org *Subject:* draft-ietf-6man-rpl-routing-header-07 It seems that the following text on page 10 has some slight oversights: " In order to respect the IPv6 Hop Limit value of the original datagram, a RPL router generating an SRH MUST set the Segments Left to_no greater_ than the original datagram's IPv6 Hop Limit value upon forwarding. " should have been as follows: " In order to respect the IPv6 Hop Limit value of the original datagram, a RPL router generating an SRH_in an IPv6-in-IPv6 tunnel_ MUST set the Segments Left to_less_ than the original datagram's IPv6 Hop Limit value upon forwarding. "If the Segments Left is equal to Hop Limit value, the source route includes one more hop than the hop limit, which is not intended here.The other change is to make clear that the above phrase does not apply to the case where the SRH is directly included within the original packet.As a side note, the traceroute application doesn't seem to be able to handle the case with no tunnel use, because the original datagram destination address alters when SRH is added, unless, I guess, traceroute application is re-written to handle source routing in returned ICMPv6 error messages. Perhaps, that recommended direct inclusion of SRH should be removed?Best Regards, Kundok -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
smime.p7s
Description: S/MIME Cryptographic Signature
-------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
