UDLR: Comments on draft-ietf-udlr-experiments-00

--Apple-Mail-4--43591093
Content-Transfer-Encoding: 7bit
Content-Type: text/plain;
	charset=US-ASCII;
	format=flowed

UDLR: Comments on draft-ietf-udlr-experiments-00

General comments
===============

Here are some general queries, which I suggest should be
discussed on the list...

---
Section 3.1.2.1 Path RTT

There is no real upper bound on the delay that may be observed
by the UDLR link. The current text suggests that this is bounded
by a "couple of hundred milliseconds". While, this may seem a
typical value, it is by no means the ***largest***  - since some 
scenarios
could have very long return links - Satellite links have been used
in conjunction  with low speed modem links, and cellular radio...

I'd argue there is no real upper bound!!!

---
Section  3.1.2.1 ARP

"IP packets are buffered"

I'd prefer to say "to improve performance IP packets SHOULD be buffered"

arp doesn't actually say you **have** to hold on to a packet when you 
do an arp, in fact the original text says you do not. In practice, most 
implementations for Ethernet queue at least one packet while pending a 
resolution.

Plummer, D. An Ethernet Address Resolution Protocol - or - Converting 
Network Protocol Addresses to 48.bit Ethernet Address for Transmission 
on Ethernet Hardware, 1982 IETF RFC826 (STD37)

-----
Section  3.1.2.2 (page 11) ARP Cache

The large size of the arp cache in very flat networks is described
for the case of the feed router. Do the same considerations also
apply to the receivers on the same network?

----
Section  4.1.2.1 DHCP

"therefore the use of DHCP should be taken into account..."

Good point.

But, the text in the ID currently doesn't give much guidance on how
to dimension, can you be more explicit please of the issues?


Top of page 14.

I can see many cases in which it is probably a rather dangerous 
assumption
that a lack of an ICMP echo reply assumes the client has gone away.
If we have loss on the forward link (or the return path), or the client 
is
"busy"... I would prefer to see some more detailed guidance on how this
could be used and/or some information about possible failure modes.

---
Section  4.1.2.2  Security issues

last line paragraph 1 - this seems too vague to say it is "of great 
interest"
I suspect a security AD may think this needs more explanation.

(A NiTs list has been sent separately to the authors)

---
Section  4.5.1. DR Election

The use of the word "listener", should perhaps be "source" ???

As I recall, the DR is responsible for transmission of link local 
sources to the
multicast distribution tool. ensuring that each source is registered
with the upstream RP for the network to which they belong.

Thinking more, does the text we have describe a different scenario, 
because
the current text says the feed acts as a DR - so does that mean the 
receivers
(who receive via the feed) are not multicast capable routers (could be) 
and
so this is not scenario D, it could be A,B?

What do others think?

----
PIM Join Override?

Finally, does anyone have experience of a large PIM-routed network
based on UDLR links?

Do we get cases where there are an implosion of Join-Overide messages
being issued by receiver multicast routers when one router sends a 
prune?

That's all on this read. (N.B.,  A separate sets of NiTs was sent to 
the authors)

Best wishes,

Gorry


--Apple-Mail-4--43591093
Content-Transfer-Encoding: 7bit
Content-Type: text/enriched;
	charset=US-ASCII

UDLR: Comments on draft-ietf-udlr-experiments-00


General comments

===============


Here are some general queries, which I suggest should be

discussed on the list...


---

Section 3.1.2.1 Path RTT


There is no real upper bound on the delay that may be observed

by the UDLR link. The current text suggests that this is bounded

by a "couple of hundred milliseconds". While, this may seem a 

typical value, it is by no means the ***largest***  - since some
scenarios

could have very long return links - Satellite links have been used

in conjunction  with low speed modem links, and cellular radio...


I'd argue there is no real upper bound!!!


---

Section  3.1.2.1 <fontfamily><param>Geneva</param>ARP

</fontfamily>

"IP packets are buffered"


I'd prefer to say "to improve performance IP packets SHOULD be
buffered"


arp doesn't actually say you **have** to hold on to a packet when you
do an arp, in fact the original text says you do not. In practice,
most implementations for Ethernet queue at least one packet while
pending a resolution.  

<fontfamily><param>Geneva</param>

Plummer, D. An Ethernet Address Resolution Protocol - or - Converting
Network Protocol Addresses to 48.bit Ethernet Address for Transmission
on Ethernet Hardware, 1982 IETF RFC826 (STD37)</fontfamily>


-----

Section  3.1.2.2 (page 11) ARP Cache


The large size of the arp cache in very flat networks is described

for the case of the feed router. Do the same considerations also

apply to the receivers on the same network?


----

Section  4.1.2.1 DHCP


"therefore the use of DHCP should be taken into account..."


Good point.


But, the text in the ID currently doesn't give much guidance on how 

to dimension, can you be more explicit please of the issues?



Top of page 14.


I can see many cases in which it is probably a rather dangerous
assumption

that a lack of an ICMP echo reply assumes the client has gone away.

If we have loss on the forward link (or the return path), or the
client is

"busy"... I would prefer to see some more detailed guidance on how this

could be used and/or some information about possible failure modes.


---

Section  4.1.2.2  Security issues


last line paragraph 1 - this seems too vague to say it is "of great
interest"

I suspect a security AD may think this needs more explanation.


(A NiTs list has been sent separately to the authors)


---

Section  4.5.1. DR Election


The use of the word "listener", should perhaps be "source" ???


As I recall, the DR is responsible for transmission of link local
sources to the

multicast distribution tool. ensuring that each source is registered

with the upstream RP for the network to which they belong.


Thinking more, does the text we have describe a different scenario,
because 

the current text says the feed acts as a DR - so does that mean the
receivers 

(who receive via the feed) are not multicast capable routers (could
be) and 

so this is not scenario D, it could be A,B?


What do others think?


----

PIM Join Override?


Finally, does anyone have experience of a large PIM-routed network

based on UDLR links?


Do we get cases where there are an implosion of Join-Overide messages

being issued by receiver multicast routers when one router sends a
prune?


That's all on this read. (N.B.,  A separate sets of NiTs was sent to
the authors)


Best wishes,


Gorry



--Apple-Mail-4--43591093--