Doing the same as I did with Ben’s email. Fixing the simple stuff first. The simple changes (editorial) will be submitted in -21.
> ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- > > S 5.3. >> header. >> >> When doing ETR/PETR decapsulation: >> >> o The inner-header 'Time to Live' field (or 'Hop Limit' field, in >> the case of IPv6) SHOULD be copied from the outer-header 'Time to > > This should probably be a MUST because there are other protocols that > assume that TTLs get decremented. Agree, changed. It was SHOULD a long time ago because some hardware couldn’t support this. Technology has moved on. > S 7.1. >> destination site. The two fragments are reassembled at the >> destination host into the single IP datagram that was originated by >> the source host. Note that reassembly can happen at the ETR if the >> encapsulated packet was fragmented at or after the ITR. >> >> This behavior MAY be performed by the ITR only when the source host > > Nit: I think you want to say MUST be, assuming you mean that you can > perform it only if…. Agree. Same issue as my last comment. > > S 7.2. >> 2. When an IPv6-encapsulated packet, or an IPv4-encapsulated packet >> with the DF bit set to 1, exceeds what the core network can >> deliver, one of the intermediate routers on the path will send an >> ICMPv6 "Packet Too Big" message or an ICMPv4 Unreachable/ >> Fragmentation-Needed to the ITR, respectively. The ITR will >> parse the ICMP message to determine which Locator is affected by > > What if you are in an environment where ICMP is blocked? You lose. There are mechanisms (un-documented) for the control-plane to detect this on its own. > > S 9. >> outside of the subset list if it determines that the subset list >> is unreachable (unless RLOCs are set to a Priority of 255). Some >> sharing of control exists: the server-side determines the >> destination RLOC list and load distribution while the client-side >> has the option of using alternatives to this list if RLOCs in the >> list are unreachable. > > How would you obtain alternative RLOCs? You can use a PETR that is configurable. But we didn’t want to document interworking mechanisms here. > S 10. >> also acting as an ITR and has traffic to return to the original >> ITR site, it can use this status information to help select an >> RLOC. >> >> 2. When an ETR receives an encapsulated packet from an ITR, the >> source RLOC from the outer header of the packet is likely up. > > What does "is likely up" mean? Changed to “reachable”. Thanks. Thanks, Dino _______________________________________________ lisp mailing list [email protected] https://www.ietf.org/mailman/listinfo/lisp
