Hi Robert, Thanks for your review. We'll try to address what we can in the next revision. See below:
On Dec 21, 2011, at 5:25 AM, Robert Cragie wrote: > Looks like I missed the boat, but I also had some comments on > draft-ietf-6man-rpl-routing-header-07: > > _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. Page 12 describes processing rules intended to keep the SRH within a RPL Instance. > 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. "Upon forwarding" was intended to indicate "upon submitting to the proper interface for forwarding". Would you prefer the RFC 2473 language: "during forwarding"? We purposely did not indicate that it is the IPv6 Hop Limit - 1 value because, as you indicate, the original datagram may originate on the 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? To support traceroute, which was an application that ZigBee/IP members indicated was important. > 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. Agree. > 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. Agree that this is in conflict with RFC 2473, but necessary to support traceroute as requested by ZigBee/IP members. We can add text that clearly states this difference with RFC 2473. > _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. Agree. > p1: "or few routers" -> "or a few routers". Reason for change: 'few routers' > on its own implies 'not many routers'. Agree. > 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. Agree. > 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. Agree. > 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. Agree. Thanks again. -- Jonathan Hui -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
