Thanks for the review. Please see NB> below for comments.

On 7/31/17, 6:43 AM, "Henning Rogge" <hro...@gmail.com> wrote:

   I found a few things in the draft that in my opinion need a bit more work...
    First it seems that Section 2.3 (Route) is a bit out of sync with the
    BNF later in the document, it should at least mention matching the
    source-IP address of the IP headers.

NB> Good point. I’ll add that.
    Second (if I read the BNF in Section 6 correctly), the match for a
    route seems to be one of the list "ip address, MPLS label, MAC
    address, interface". I think it should be possible to combine
    "interface" or "mac address" with an IP address to restrict the focus
    of a route, e.g. "match fe80::1 from interface X".
NB> Yes it’s possible to do that, but that becomes a traditional firewall 
filter. I think that is more for draft-ietf-i2rs-fb-rib-info-model.

    Last, I wonder if multicast routing needs more different types of
    matchers, e.g. a match on the TTL of the IP packet to limit the range
    of a multicast group.

There is also problem of multicast routing in MANETs (see RFC 6621)
    which can use a hash-based duplicate detection to determine if it
    forwards or drops a multicast packet. Would this be out of scope for
    the draft?

NB> The draft actually only touches on multicast and does not do justice to it. 
Multicast by itself is a big beast. TTL is just one of the few things that can 
be added. The authors had initially thought of leaving traditional multicast to 
a need based extension. The high-level intent is to have some draft extend 
<ip-route-attributes> or <ethernet-route-attributes> to added specialized 

i2rs mailing list

Reply via email to