Re: draft-ietf-udlr-lltunnel-03.txt - Typographical comments.

[Tim Gleeson <tgleeson@cisco.com>]

> The current draft is a vast improvement, and much clearer!
>
> I enclose a few typographical queries on draft-ietf-udlr-lltunnel-03.txt.

Thank you for taking the time and care to read it in detail.

> ------------
> 4. Problems related to unidirectional links
>
> Last paragraph may make an untrue generalisation (any comments?):
>
> The current draft says "Most protocols in the Internet assume"  which seems
> a rather bold (and possibly wrong) statement - perhaps the draft should
> say "many protocols"?

"Most protocols" is probably too strong. I was thinking (but did not write) 
"Most routing protocols". For example, ospf, isis (I believe), eigrp, bgp 
(and all other protocols that use tcp) require bidirectional connectivity 
to form neighbor relationships. On a UDL, they just won't form these 
relationships. rip will operate, but probably won't give you the 
information you want.

I agree: "Many protocols" would be better.

> Similarly there is a general reference to "routing protocols" ...
> "not behaving properly", I don't think this is universally got to be
> true - but there are a number of cases (e.g. RIP as cited) where it is
> certainly true.

See above.

> Ingress filtering, and policy routing by ISPs could also introduce
> problems.
>
> ------------
>
> 6.2.1
>
> Point 3 (would be helpful to note point in 9.2)
>
> Multicast routing rather than bridging, would suggest that multicast
> packets are not ***necessarily*** rebroadcast to all feeds, but only
> to feeds which have members of the appropriate multicast group. (This
> is suggested in 9.2, but isn't cross-referenced here).

We'd need to run a *link layer* multicast protocol, or rather multicast 
group membership protocol, to make this optimisation.


> ------------
> 9.2 para 4 terminology
> 
> Is "multicast daemon" an appropriate form of words? - Perhaps consider
> "feeds and receivers may implement multicast routing".

That sounds fine.

> ------------
>
> References
>
> No reference is made to RFC2488 or RFC2670 which describe other issues
> relating to performance when using asymmetric capacity. It may (perhaps) be
> helpful to refer readers here?

2670 seems pretty low-level. 2488 certainly has some interesting stuff, but 
it's TCP specific, and though it does mention asymmetry, it seems more 
concerned with long RTTs and errors. I'm unsure about how valuable a 
reference would be.

> ------------
>
> Best wishes,
>
> Gorry Fairhurst.


Tim