Subject: Working Group Last Call on "Multi-Topology (MT) Routing in OSPF" (draft-ietf-ospf-mt-03.txt) - Corrected

From: Acee Lindem <[email-masked]>
Date: Mon, 4 Apr 2005 18:45:45 -0400

This is the start of a Working Group last call for
"Multi-Topology (MT) Routing in OSPF" (draft-ietf-ospf-mt-03.txt).
All comments should be sent to this list by 12 AM (EDT), 04/19/2005.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-ospf-mt-03.txt

The RFC 3978 IPR notices will be updated in the next revision.

Thanks,
Acee

---

From: Yakov Rekhter <[email-masked]>
Date: Tue, 5 Apr 2005 10:35:53 -0700

Folks,

> All comments should be sent to this list by 12 AM (EDT), 04/19/2005.

How is computing different paths for different classes of service
mention in the draft differs from ToS routing ?

Yakov.

---

From: Peter Psenak <[email-masked]>
Date: Tue, 5 Apr 2005 14:48:02 -0700

Yakov,

> mention in the draft differs from ToS routing ?

one difference compared to ToS routing as specified in 1583 is the 
ability to include/exclude each link/prefix in/from each topology.

Peter

---

From: Acee Lindem <[email-masked]>
Date: Tue, 5 Apr 2005 23:11:50 -0400

Note that  this is a standards track draft. I neglected to mention this in
the original WG last call announcement.

There are, at least, two other subtle differences with RFC 1583 TOS routing:

     1. With RFC 1583 TOS routing the TOS or DSCP in the IP header mapping
          directly to the the corresponding OSPF SPF and RIB. With 
multi-topology
          routing, the classification of what type of traffic maps to 
which topology is
          not within the scope of the document (other than the default 
unicast and
         default multicast topologies are reserved). There are 
appropriate warnings
         that all routers in the OSPF routing domain should classify 
traffic
         consistently.

     2. With RFC 1583 TOS routing, traffic which is unreachable in the RIB
          associated with the corresponding TOS will revert to the TOS 0
          RIB. With multi-topology routing, this is an option but not 
required. Of
          course, all routers in the OSPF routing domain should make 
this decision
          consistently.

Thanks,
Acee

---

From: Yakov Rekhter <[email-masked]>
Date: Wed, 6 Apr 2005 06:34:18 -0700

Folks,

> The RFC 3978 IPR notices will be updated in the next revision.

As the draft correctly points out:

   TOS based routing as described in [RFC1583] was never
   deployed and was subsequently deprecated.

So, why computing different paths for different classes of service
be any different ?

Yakov.

---

From: Peter Psenak <[email-masked]>
Date: Wed, 6 Apr 2005 09:08:28 -0700

Yakov,

> So, why computing different paths for different classes of service

because MTR allows people to do things that were not possible with the 
TOS based routing as described in [RFC1583].

Peter

---

From: Yakov Rekhter <[email-masked]>
Date: Wed, 6 Apr 2005 09:30:35 -0700

Peter,

> TOS based routing as described in [RFC1583].

Then the draft should document how this addressed and solved the problems 
that caused TOS routing being never deployed.

Yakov.

---

From: Acee Lindem <[email-masked]>
Date: Wed, 6 Apr 2005 13:36:55 -0400

>So, why computing different paths for different classes of service
Hi Yakov,

In addition to the differences between the two protocol mechanisms, 
we've evolved
technologically since RFC 1583. It is now fairly straight-forward to 
support multiple
topologies (protocol signaling, SPF computations, and logically separate 
RIBs/FIBs).
As for requirements, the example most often given is when a SP wants to 
provide
separate topologies for unicast and multicast services.
 
Note that there is a similar proposal in the ISIS WG so I'd venture to 
say that there
is some agreement on the requirement - 
draft-ietf-isis-wg-multi-topology-09.txt.

Thanks,
Acee

---

From: Tony Przygienda <[email-masked]>
Date: Wed, 6 Apr 2005 23:40:27 +0000

> topologies (protocol signaling, SPF computations, and logically 
> separate RIBs/FIBs).
> As for requirements, the example most often given is when a SP wants 
> to provide

we could always just force diffserv to disavow the TOS bits or, even 
better, make network
operators deploy carefull 'precedence designation remarking nodes' and 
set metrics
for certain TOSes on certain links to infinity and then we would almost 
have the same

    good idea, NOT

    -- tony

---

From: Naiming Shen <[email-masked]>
Date: Wed, 6 Apr 2005 23:39:33 -0700

< cut ...>
> provide separate topologies for unicast and multicast services.
> 

I was told at least one ISP used MT isis to link remote IPv6 POPs
through GRE tunnels, IPv4 topology was not enabled on those tunnels.

thanks.
- Naiming

---

From: Yakov Rekhter <[email-masked]>
Date: Mon, 11 Apr 2005 06:50:05 -0700

Naiming,

> through GRE tunnels, IPv4 topology was not enabled on those tunnels.

That is fine. But what that has to do with computing different paths for 
different classes of service ?

Yakov.

---

From: Acee Lindem <[email-masked]>
Date: Wed, 20 Apr 2005 10:40:24 -0400

The Working Group last call for the subject document has completed.
The next version will address the comments received during the last call.

The next version will include a section precisely describing the protocol
differences between  RFC 1583 TOS routing and multi-topology routing.
Personally,  I don't think we need a section on requirements or
deployment scenarios. I'm sure that everyone can recall the famous, yet
unnamed, service provider that wished to offer gold, silver, and bronze
service level agreements (SLAs) to their customers -  now they simply
want to to use incongruent topologies to guarentee these SLAs. Of course,
this is just one of the many possible applications for multi-topology 
routing.

Thanks,
Acee