Subject: OSPF - IP Multicast interaction problem

From: "C.C.Boot" <[email-masked]>
Date: Mon, 17 Nov 2003 23:01:25 +0100

From:     Teco Boot
To:       John Moy; IETF OSPF working group

CC:       All interested specialists on OSPF and IP Multicast protocol

Subject:  OSPF - IP Multicast interaction problem

Date:     17 November 2003

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

Dear mister Moy, IETF OSPF working group members

I want to inform you about an OSPF - IP Multicast interaction problem. We did have some problems during our "Proof of Concept" testing this week, caused by RPF (reverse path forwarding) checks, performed by PIM and / or multicast packet forwarding code.

--------

Problem description:

The RPF problem was caused by settings on some of the router links, the OSPF metrics were configured highly, as the config was left from a previous test. The configuration was absolutely valid for OSPF and was preferred for the previous setup. As soon as we saw this configuration, we adjusted it and our problem disappeared.

But I was not amused about this problem. I made multiple designs making use of a permitted technique in OSPF: we set the OSPF metric on values that are related to the interface bandwidth and / or CPU power of the routing device; metrics on interfaces connected to a certain transit network could differ. Here some real world examples:

1) Token Ring and ATM backbone (old technology but it is a real world example, I made the design myself). An 4Mbps interface would get a medium to high metric related to 16Mbps and a high metric related to high speed LANE ATM interfaces.

2) Ethernet VLAN environments (todays technology, so interesting to mention). It is likely that redundant VLAN backbone segments are interconnected using layer-3 switches and possibly WAN routers are connected to multiple backbone segments. The WAN routers should not handle VLAN backbone traffic, so the OSPF metric on the WAN router interfaces would get high metrics related to the layer-3 switches.

3) On Frame Relay or ATM networks, using partly meshed structures and unequal access bitrates, a network designer configures the OSPF metrics with respect to the available bandwidth. This is especially true if other communication means are in place, e.g. ISDN, satcom or microwave links.

--------

If transit networks are configured with unequal OSPF metrics, asymmetric routing is likely to occur.  As an example I studied the network as described in RFC2328, figure 2. I calculated traffic paths from N1 to N7 and vice versa. I included two drawings below, depicting asymmetric routing.

Avoiding asymmetric routing is generally accepted as a design goal and it is mandatory for every IP multicast capable network. On the other side I mentioned a few example networks that benefits from unequal OSPF metric settings on transit network links, which could introduce asymmetric routing very easily.

As I kept thinking about this problem, I came to the conclusion that the IP community running OSPF (or a similar routing protocol) would benefit from an improvement on asymmetric routing probability avoidance. An easy to define mechanism could take the average (and round downwards) of the ingress and egress interface metric on each transit link. Implementing is harder, as each router in an area must have an identical path calculation algorithm. So the implementation must support backwards compatibility, e.g. the new algorithm should be enabled per area and a router LSA option bit could be used to signal existence of old style routers.

Now I can formulate my questions:

Is the problem described above well known and documented in an RFC or Internet Draft?

What is your opinion on this issue? Could it be fixed in OSPF?

When could the problem be fixed, what is your opinion on this?

Your response would be very welcome. If you have needs for any more explanation on this issue, please let me know.

Regards,

Teco Boot

Mail: [email-masked]

Figures:

Taken from RFC2328, figure 2, page 18; route from N1 to N7 and vise versa.

(figure 1)

N1 to N7:

path will be:  N1 - RT1 - N3 - RT4 - RT5 - RT7 - N6 - RT8 - N7

path cost is:          1 +        8 +   6 +   1 +        4     = 20

(figure 2)

N7 to N1:

path will be:  N7 - RT8 - N6 - RT10 - Ia/Ib - RT6 - RT3 - N3 - RT1 - N1

path cost is:          1 +         5 +           6 +   1 +        3     = 16

---

From: Acee Lindem <[email-masked]>
Date: Tue, 18 Nov 2003 10:48:41 -0500

Dear Mr Boot,

If I undertstand your E-mail, you are requesting that OSPF somehow 
guarentee symmetric routing and
take some action in the face of asymmetric costs. I (speaking as a WG 
member) do not think this
is a problem that we should try and solve. In fact, Isuspect that if we 
looked hard enough there would
be IETF documents support not try to solve this problem in OSPF.

Thanks,
Acee

C.C.Boot wrote:

> Subject: OSPF – IP Multicast interaction problem
>
> Date: 17 November 2003
>
> ==================
>
> I want to inform you about an OSPF – IP Multicast interaction problem. 
> We did have some problems during our “Proof of Concept” testing this 
> week, caused by RPF (reverse path forwarding) checks, performed by PIM 
> and / or multicast packet forwarding code.
>
> --------
>
> Problem description:
>
> The RPF problem was caused by settings on some of the router links, 
> the OSPF metrics were configured highly, as the config was left from a 
> previous test. The configuration was absolutely valid for OSPF and was 
> preferred for the previous setup. As soon as we saw this 
> configuration, we adjusted it and our problem disappeared.
>
> But I was not amused about this problem. I made multiple designs 
> making use of a permitted technique in OSPF: we set the OSPF metric on 
> values that are related to the interface bandwidth and / or CPU power 
> of the routing device; metrics on interfaces connected to a certain 
> transit network could differ. Here some real world examples:
>
> 1) Token Ring and ATM backbone (old technology but it is a real world 
> example, I made the design myself). An 4Mbps interface would get a 
> medium to high metric related to 16Mbps and a high metric related to 
> high speed LANE ATM interfaces.
>
> 2) Ethernet VLAN environments (todays technology, so interesting to 
> mention). It is likely that redundant VLAN backbone segments are 
> interconnected using layer-3 switches and possibly WAN routers are 
> connected to multiple backbone segments. The WAN routers should not 
> handle VLAN backbone traffic, so the OSPF metric on the WAN router 
> interfaces would get high metrics related to the layer-3 switches.
>
> 3) On Frame Relay or ATM networks, using partly meshed structures and 
> unequal access bitrates, a network designer configures the OSPF 
> metrics with respect to the available bandwidth. This is especially 
> true if other communication means are in place, e.g. ISDN, satcom or 
> microwave links.
>
> --------
>
> If transit networks are configured with unequal OSPF metrics, 
> asymmetric routing is likely to occur. As an example I studied the 
> network as described in RFC2328, figure 2. I calculated traffic paths 
> from N1 to N7 and vice versa. I included two drawings below, depicting 
> asymmetric routing.
>
> Avoiding asymmetric routing is generally accepted as a design goal and 
> it is mandatory for every IP multicast capable network. On the other 
> side I mentioned a few example networks that benefits from unequal 
> OSPF metric settings on transit network links, which could introduce 
> asymmetric routing very easily.
>
> As I kept thinking about this problem, I came to the conclusion that 
> the IP community running OSPF (or a similar routing protocol) would 
> benefit from an improvement on asymmetric routing probability 
> avoidance. An easy to define mechanism could take the average (and 
> round downwards) of the ingress and egress interface metric on each 
> transit link. Implementing is harder, as each router in an area must 
> have an identical path calculation algorithm. So the implementation 
> must support backwards compatibility, e.g. the new algorithm should be 
> enabled per area and a router LSA option bit could be used to signal 
> existence of old style routers.
>
> Your response would be very welcome. If you have needs for any more 
> explanation on this issue, please let me know.
>
> Regards,
>
> Teco Boot
>
> Mail: [email-masked]
>
> Figures:
>

---

From: Jing Shen <[email-masked]>
Date: Tue, 25 Nov 2003 09:14:59 +0800

To our observation asymmetric routing seldomly appear
in ISP's backbone network, as usually those links are
ATM, 100Mbps/1000Mbps Ethernet or POS type.

But we do observe asymmetric routing in inter-AS
routing and QoS on the two paths differs much ( one
with e2e traceroute lay around 350ms, the other about
1000ms with 50% packet loss rate).

 --- Acee Lindem <[email-masked]> 的正文：> Dear Mr
Boot,
> be IETF documents support not try to solve this
' spamcontrol '

=====
Jing Shen

Data Communication Center
HangZhou TeleCom
HangZhou ZJ 310027
P.R.China

' spamcontrol '

__________________________________________________
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around
http://mail.yahoo.com