Re: No subject was specified.

See below,

Emmanuel Duros wrote:
> 
> Gorry,
> 
> To understand the characteristics of a "udlr network", it might be
> sensible to describe what udlr brings to nodes (feed and receivers)
> which are directly connected with a udl and use udlr:
> 
> - udlr emulates a complete broadcast and bidirectional connectivity
> among nodes connected to a UDL (e.g. satellite link). Nodes can
> communicate with each other as if they were connected with a broadcast
> network such as Ethernet (although the link characteristics are very
> different!)
> 
> - a receiver receives packets from the UDL via its reception interface,
> but may also send packets through it (thanks to udlr). The UDLR protocol
> captures the outgoing packet and sends them in a tunnel to the feed
> through, for instance, a RTC or ISDN connection.
> 
> - a feed processes the incoming encapsulated packets as if they were
> comming from the sending interface but but in fact came from the
> terrestrial network...
> 
> I believe this is quite important to clarify since the IP layer of a
> receiver and a feed sees the satellite interface as bidirectional.
> Routing protocols can receive and send routing msg through it.
> 
> Configuring protocols then depends on the UDLR network characteristics
> (RTT, asymmetry, flat network, etc.)
> 
> See another comment below. I have to think if there are other relevant
> characteristics...
> 
> Emmanuel
> 

<<snip>>

> >
> > Characteristics of UDLR networks
> >
> > UDLR subnetworks present characteristics which differ significantly from
> > those experienced in the general Internet. These characteristics lead to
> > specific problems and raise specific issues that need to be addressed to
> > deploy an IP multicast service.  This section identifies specific
> > characteristics that impact multicast performance resulting from the
> > asymmetry and the types of network over which the UDLR is commonly
> > implemented.  These are:
> >
> > 1.1.1 Asymmetric routing paths
> > Unidirectional links give rise to differing forward (feed) and return
> > (tunnel) paths. Multicast routing protocols that use the "reverse
> > shortest path tree" towards the source as a part of their forwarding
> > decision (e.g. DVMRP, PIM-SM [DRAFT-PIM-SM-NEW], PIM-DM) will not work
> > correctly over asymmetric routing paths. Solutions include the use of
> > UDLR [RFC 3077] and the use incongruent MBGP routing.
> >
> > 1.1.2 Asymmetric multicast capability
> > Asymmetric multicast capability is not a fundamental feature of UDLR.
> > In some UDLR networks both forward (feed) and return paths may support
> > native IP multicast.  In other UDLR networks, a case may arise where the
> > forward link supports native multicast, whereas return link may supports
> > only unicast. UDLR routing allows a non-broadcast/multicast link to be
> > used for the return path by employing a tunnel in the return direction [RFC2784].
> 
> I do not see why here the forward link would support multicast and not
> the return link ? Outgoing packets (unicast and multicast) via the
> satellite interface are encapsulated in the gre tunnel...

---

My point of 1.1.1 and 1.1.2 was to say why one should use UDLR. 

I see two distinct cases:

The first attempts to cover uni-dierctional feeds.

The second describes the scenario were there is assymmetry in the multicast
connectivity.

Both cases can be "fixed" using UDLR. Does anyone have better text?

Gorry