Subject: ITU-T SG13 meeting on IP OAM and protection switching

From: Hiroshi Ohta <[email-masked]>
Date: Tue, 16 May 2000 18:11:07 +0900

Hello all,

My name is Hiroshi Ohta, the rapporteur on Q.6 of ITU-T SG13 which is
responsible for OAM and protection switching.  I would like to inform you
that ITU-T Q.6/SG13 started to draft a new Recommendation on OAM and
protection switching for IP-based networks.  It was provisionally numbered
Y.17oam.  Please see the attached initial draft.

To progress the work on this issue, a meeting is planned as below.

Date: June 26 - June 30, 2000
Place: Ottawa, Canada
Objectives: The main objective is to progress the work on the new
Recommendation on OAM and protection switching for IP-based networks
(Y.17oam).  Work on next release of Recs. I.610 (OAM for ATM) and I.630
(ATM protection switching) will be done if time permits.

If you intend to attend this meeting, please send me an e-mail.  If you
intend to submit contributions, please send me the titles and abstracts.

Please note that the meeting will be held only if there are sufficient
number of participants and contributions.  I need to report the situation
to ITU to confirm the meeting four weeks before the meeting (i.e., May 29).
 So, please send me your intention to attend or titles and abstracts of
your contributions as soon as possible but not later than May 29.

I hope the meeting will be held and look forward to seeing you in Ottawa.

Best regards,

Hiroshi Ohta

-----------------------------------

Draft Recommendation Y.17oam

OAM and protection switching for IP-based networks

(Geneva, 200?)

1	Scope
This Recommendation provides requirements and mechanisms for OAM functions
and protection switching for IP-based networks.  It is recognized that OAM
(Operation and Maintenance) functionality is important in public networks
for ease of network operation, for verifying network performance and to
reduce network operating costs. OAM functionality is especially important
for networks in which Quality of Service is an important issue.

2	References
The following ITU-T Recommendations and other references contain provisions
which, through reference in this text, constitute provisions of this
Recommendation. At the time of publication, the editions indicated were
valid. All Recommendations and other references are subject to revision;
all users of this Recommendation are therefore encouraged to investigate
the possibility of applying the most recent edition of the Recommendations
and other references listed below. A list of currently valid ITU-T
Recommendations is regularly published.

[References are to be added (contributions are invited).]

3.	Definitions
to be added (contributions are invited)

4.	Symbols and abbreviations
to be added (contributions are invited)

5.	Requirements for OAM functions and protection switching

5.1	General requirements for IP-based networks
for further study (contributions are invited)

5.2	Requirements for MPLS OAM
It is to be noted that MPLS OAM functionality is not seen as a substitute
for physical layer (e.g. SONET/SDH) OAM functionality. However, MPLS layer
OAM functions may nevertheless be seen as desirable in addition to physical
layer OAM: They will be required whenever OAM functionality is needed that
permits differentiation per individual LSP.  OAM functionality is useful
because

-	it allows the Operator to verify whether Quality of Service guarantees
given in SLAs (Service Level Agreements) are in fact being met by the
connection,
-	it allows the Operator to reduce network operating costs. Long term
statistics show that the costs of operating a public network are higher
than the initial installation costs,
-	it allows the Operator to improve traffic flow/distribution through the
network, and
-	it gives support for improved accounting/billing procedures.

The following is a preliminary list of possible requirements.

1.	in-service verification of connection availability (whether a connection
is "up" or "down") and error performance (counting of lost frames)

2.	in-service verification of delay and delay variation

3.	in-service verification of connection throughput guarantees.

4.	tools for fast and efficient fault detection and fault localization 

5.	tools for efficient network setup and configuration.

6.	Traffic Engineering functionality for load-dependent route selection of
traffic.

7.	measurement of throughput per connection for throughput based billing

8.	detection of violations to a SLA traffic contract that can be given
consideration for billing.

5.3	Requirements for MPLS protection switching
Protection switching for MPLS is useful because it allows the operator to
improve network 
reliability.  Details are for further study (contributions are invited).

6	Mechanisms of OAM functions and protection switching

6.1	General mechanisms for IP-based networks
For further study (contributions are invited).

6.2	Mechanisms of MPLS OAM
Examples of MPLS OAM functionalities are the followings:
-	Fault management and continuity check
-	Loopbacks
-	Performance monitoring

These examples are oriented towards OAM functions defined for ATM networks.
 Note, however, that in defining OAM functions for MPLS networks, the
intention is not necessarily to reapply ATM mechanisms without
modifications.  Different functions may be defined as necessary.

An OAM indicator in the MPLS header could enable a simple differentiation
between user packets and OAM packets in equipment supporting MPLS. Further
study is required to clarify the need for such an OAM indicator and to
identify a suitable encoding.

6.3	Mechanisms of MPLS protection switching
For further study (contributions are invited).

---------- end of draft Y.17oam -----------

Hiroshi OHTA
NTT Network Service Systems Laboratories
Tel: +81 468 59 8840
Fax: +81 468 59 8569
E-mail: [email-masked]

---

From: "HANSEN CHAN" <[email-masked]>
Date: Tue, 16 May 2000 08:22:05 -0400

Hi all,

I have been hearing IS-IS is a better protocol to be used than OSPF in a MPLS
network for TE application. Is that a fair statement? What are the technical
reasons?

Appreciate if someone can shed some light on this subject.

Thanks,
Hansen

---

From: Jeremy Lawrence <[email-masked]>
Date: Wed, 17 May 2000 11:54:19 +1000

Hansen,

>network for TE application. Is that a fair statement? What are the technical

IS-IS has some advantages over OSPF in general. These are at
least as relevant in MPLS networks doing traffic engineering as
they are in networks not doing TE or MPLS:
- In practice, IS-IS has been shown to support larger Areas
   than OSPF. This is of particular relevance to TE as it
   extends the regions over which a router can have detailed
   knowledge of link state, and hence knowledge of optimal 
   routing of TE paths.
- In practice, IS-IS has proved to be more stable than OSPF
   due to features like the pacing of LSP distribution (at
   least one OSPF implementation has caught up in this regard).

Regards,

Jeremy Lawrence

---

From: Dave Katz <[email-masked]>
Date: Tue, 16 May 2000 19:23:09 -0700 (PDT)

One should note that these "advantages" are artifacts of the state of
a particular vendor's implementations, and does not reflect on any
inherent scaling or stability issues in the protocols themselves.

Probably the bigger issue as far as TE, or extensions in general, is that
they tend to happen faster in IS-IS because the largest customers of
the dominant vendors tend to use it, so it is the first target of
implementation.

--Dave

---

From: Curtis Villamizar <[email-masked]>
Date: Tue, 16 May 2000 22:24:51 -0400

In message <[email-masked]>, Jeremy Lawrence 
>    least one OSPF implementation has caught up in this regard).

Jeremy,

IMHO both ISIS and OSPF are well suited for TE.

The two protocols each have minor advantages and disadvantages.  For
example, OSPF area support works, and ISIS level support offers
limited capability (as now defined).  OSPF is an IETF Full Standard
while ISIS is defined by an ISO document that doesn't reflect what
implementations actually do, one somewhat outdated RFC-1195, and a
patchwork of internet-drafts, most of which are still being argued
over in the WG.  Still ISIS works quite well and the one timer for a
one big ISIS-LSP is much friendlier to naive timer implementations
(such as linked lists of timer events) than a timer for each OSPF-LSA.

Curtis

btw- I always thought ISIS became widely used only because during the
mid-1990s one widely used router had a very poor OSPF implementation
which was inefficient and buggy and preferred to blame the protocol.
Must be just some old Internet folklore.  ;-)

---

From: Tony Przygienda <[email-masked]>
Date: Tue, 16 May 2000 23:20:15 -0700

Curtis Villamizar wrote:

> limited capability (as now defined).

unless you're dying for things like NSSA, everything that is relevant (==deploying folks asked for) is there.
Further _real_ requirements are welcome and will be incorporated.

> OSPF is an IETF Full Standard
> over in the WG.

that's what Internet backbone is all about.  "Patchwork" of drafts under discussion has the advantage
of flexibility ;-)  Monolithic, coherent draft has the advantage of understandability
and coherence.  Internet @ ISP level has some way to go to be monolithic
and understandable and that's why we are where we are whereas @ the level
of campus things are pretty well understood I'd dare venture to say.

> Still ISIS works quite well and the one timer for a

at sizes ISIS is being used today in the backbones, this is a a dated statement at compiler & data-structure level ;-)

    thanks

   -- tony

---

From: Tony Przygienda <[email-masked]>
Date: Tue, 16 May 2000 23:29:25 -0700

> the dominant vendors tend to use it, so it is the first target of

got to agree with the assesement from the horse's mouth ;-))

The way we're going, ISIS will be there to stay for quite some
time since it's ultimately boiling down to avaialble implementations and
who's bending over more to keep the large ISPs happy as said above ... There have been
at least one very successfull modified OSPF implementations in the backbone by a well known guy
from a well-known company ;-) just not @ layer 3.

having done both to some extent, I think that either one done _cluefully_ can do
the job.

    -- tony

---

From: Philip Chen <[email-masked]>
Date: Wed, 17 May 2000 15:48:56 -0400

>       least one OSPF implementation has caught up in this regard).

Here is my 2 cents on the subject of IS-IS vs OSPF scalability issue:

If I understand correctly, the original reason why IS-IS is in favor of other

routing protocols is because IS-IS can be easily made to support  multiple
communication protocols. This will alow us to avoid so called “Ships in the
Night” approach. The advantages of this approach include:

    less management work (do not have to manage many protocol any more)
    less router resources consumption (less routing process is running)

These translate to better scalability for IS-IS. However, those reasons are
vanished now. Today, a carrier network pretty much only needs to deal with
one protocol--IP. So, use a non generic routing protocol optimized for IP
such as OSPF makes more sense.

Another technical reason why IS-IS might be better scalable than OSPF comes
from the following fact:
Both IS-IS and OSPF follows two level of hierarchy, but they differ in the
amount of information flooded into each area. OSPF floods more information
about other areas to an area, so an internal OSPF router can choose an
optimal ABR (if there are more than one ABRs) for traffic destinated to other

areas. Why IS-IS follows more strict hierarchy model. IS-IS has no
information about other level 1 area. So an internal IS-IS router will always

send the traffic destinated to other level 1 areas to the nearest level 2
router (if ther are more than one level 2 routers). Note the difference here:

if there are more than one "ABR"s for traffics to other areas, OSPF always
pick the optimized path. IS-IS may not. The price paid by OSPF is more router

and network resource utilization to deal with more network reachability
information and of course more complex protocol. In other words, for the same

resources consumption, IS-IS can support larger networks (area, AS) than
OSPF. In this sense IS-IS is more scalable than OSPF, but we have to mention
another side of the coin: that is OSPF alway pick optimized routes.

That is not the complete story yet. OSPF fixes some of the scalability
problem by introducing stub area and NSSA. This allows controlled filtering
of information flooded into an area. One important difference is stub area
cannot be a transit area. Nevertherless, in many cases, this is good enough
to solve OSPF scalibility issue. Oh, do not forget, the concept of stub area,

NSSA also contribute to the complexity of OSPF over IS-IS.

Thanks!

--Phil

---

From: Haoxin Song <[email-masked]>
Date: Thu, 18 May 2000 23:45:24 -0400 (EDT)

hi there, 

Although both OSPF and ISIS meet basic IGP requirements to support TE over
MPLS, there are some basic differences in their features which I think
might be causing ISPs to change from OSPF to ISIS. 

1. the method of fragmentation of LSPs are different. ISIS divides all the
Link_state information into MTUs which could be sent independently. In
OSPF, fragmentation is first made based on different type of information,
but as the number of neighbors increases, it's quite possible that the
fragmented LSAs still exceeds MTU, so OSPF will further divide it by
creating one LSP for each destination. This will make OSPF to transmit
much more LSAs than ISIS to advertise same information. Since each LSP
need a packet header, more  LSPs will mean more overhead which make OSPF
less scalable.

2. Both protocol support two level hierarchy, but ISIS level 1 router
flood only information about  its own area while OSPF level 1 router
floods also information about level two. This is also a reason OSPF will
need more bandwidth for advertising. Although there are some methods to
solve the scalable problem, that will introduce more complexity.

cheers, 

Larry

---

From: Alex Zinin <[email-masked]>
Date: Thu, 18 May 2000 23:06:00 -0700

> fragmented LSAs still exceeds MTU,

We do not fragment LSAs.

> so OSPF will further divide it by
> creating one LSP for each destination.

We also do not divide LSAs into LSPs [in fact, we don't have LSPs in
OSPF at all].

Enabling error correction produces somewhat like "OSPF will create
a separate LSA for each external prefix"? Is this what you mean?

> This will make OSPF to transmit
> need a packet header,

Seems to be you're still making a difference between LSAs and LSPs.
What do you mean by LSP in OSPF?

As far as the number of LSAs vs number of ISIS LSP fragments is
concerned, this is always a choice between possibility to put more
info within one PDU (read "put more TLVs into one LSP") vs necessity
to reoriginate and reflood the whole PDU when one item changes.

> more  LSPs will mean more overhead which make OSPF
> less scalable.

Easy to say, isn't it?
An example to you: you have an ISIS LSP fragment fitting 1500b MTU, full
of internal adjacency info and a couple of external routes, and you
have an OSPF router-LSA carrying adj. info and two ASE-LSAs carrying
external routes. Now suppose your external route starts flapping,
which protocol will consume more bandwidth?
Now change external routing info to TE info... See what I mean?

Again, my point is not that ISIS is worse and OSPF is better
or the other way. My point is that you cannot make such an "easy"
conclusion that one proto is less scalable than the other.
Both protos have pros and cons.

> solve the scalable problem, that will introduce more complexity.

I would recommend reading RFC2328, specifically the part about stub
areas. I'd also recommend reading drafts about L2-to-L1 route leaking
in ISIS.

Cheers,

Alex.

---

From: Haoxin Song <[email-masked]>
Date: Fri, 19 May 2000 23:46:31 -0400 (EDT)

> We also do not divide LSAs into LSPs [in fact, we don't have LSPs in

I am sorry that I may have introduced some confusions in last mail dy
using the terms of LSP, LSA and fragmentation. OK, let's put it this way,
both protocol need a method to split information, which need to be
advertised, into meaningful smaller pieces (in ISIS, LSP fragments; in
OSPF, LSAs) so that each of them could be forwarded
independently. Otherwise, during transmission, it will have to relay on
conventional fragmentation/reassembly (in OSPF, IP fragmentation), which
will make the packets have to wait to be reassembled at each hop. The
overhead I mensioned in last mail comes from the different method of this
spliting. Does that make sense now?

> a separate LSA for each external prefix"? Is this what you mean?

As described above, OSPF split the whole information into smaller pieces
based first on defferent types, if the smaller pieces is still too large
to be fitted in one IP packet, it will further divide it by different
neighbors and make each of them a LSAs.
 
> Both protos have pros and cons.

Yes, I agree with you. I was not tring to make any conclusion that in
general one is better than the other. What I was tring to point out is
just some differents of the two protocols which could be one of the
reasons ISPs make their decision.

> areas. I'd also recommend reading drafts about L2-to-L1 route leaking

Thanks for reconmmending, I will.

Regards,

Larry

---

From: Alex Zinin <[email-masked]>
Date: Fri, 19 May 2000 22:56:05 -0700

> spliting. Does that make sense now?

Yeah...
I could add some notes, but it is ok so far.

> neighbors and make each of them a LSAs.

Larry, I'm afraid reality is a bit different.
The only type of LSA in OSPF that may become huge is router-LSA.
We can do some tricks [potentially] to break adjacency info
into several LSAs, BUT no OSPF implementation [AFAIK] is doing
this today. The reason for not doing this is because we don't
have a lot of huge router-LSAs in reality.

> reasons ISPs make their decision.

The thing is that both protos are equally good. They are both
link-state. They use the same topology abstraction methods,
practically the same flooding algo, and practically the same
Dijkstra [especially if you recall wide-scale metrics in ISIS].
How you tie routing info to a vertex in the topo graph is just a
minor detail. Everyone has one's personal preference.

I don't want to talk about reasons for the choice, since
it will just start the whole thread over.

Alex.
P.S. Don't expect ppl developing OSPF to say "yeah, ISIS is
better" and the other way. Note however, that people who
actually implemented them never say one proto is better than
the other in public. Why? Because they know the truth :)

---

From: "HANSEN CHAN" <[email-masked]>
Date: Sat, 20 May 2000 16:17:40 -0400

Alex,

> areas. I'd also recommend reading drafts about L2-to-L1 route leaking

Can you point me to the L2-to-L1 route leak draft? I searched both RFC and draft
webpage of IETF to no avail. What is the experience of deploying that L2-to-L1
route leaking? Is it actually deployed today in the big tier 1 ISP network? Does
it help to optimize inter-area forwarding to the same degree of OSPF?

Cheers,
Hansen

---

From: stefano previdi <[email-masked]>
Date: Sun, 21 May 2000 21:40:03 +0200

>At 22:17 20/05/2000 , HANSEN CHAN wrote:
 >Alex,
 >
 >>
 >route leaking? 

http://www.ietf.org/internet-drafts/draft-ietf-isis-domain-wide-02.txt

 >Is it actually deployed today in the big tier 1 ISP network? Does

yes, with some small differences that have already been debated 
on this list....

s.

---

From: Alex Zinin <[email-masked]>
Date: Sun, 21 May 2000 18:01:22 -0700

Thanks, Stefano.

Regarding any ISPs using this ISIS feature: my sources say "no" :)

Alex.

---

From: Robert Raszuk <[email-masked]>
Date: Mon, 22 May 2000 17:37:07 -0700

Alex,

Most ISPs I know who run ISIS have a single level so this does not apply.
Although I know at least one who is leaking /32 (of their PEs) to level1s due
to the fact that this is required by mpls-vpns.

R.

> Alex Zinin wrote:

---

From: stefano previdi <[email-masked]>
Date: Mon, 22 May 2000 08:29:59 +0200

>Regarding any ISPs using this ISIS feature: my sources say "no" :)

I know one who is deploying this.

s.

---

From: Alex Zinin <[email-masked]>
Date: Sun, 21 May 2000 23:45:57 -0700

Robert:

> Most ISPs I know who run ISIS have a single level so this does not apply.

Since one of the reasons for not running multiple levels could be
lack of inter-area routes, I think it does apply.

> to the fact that this is required by mpls-vpns.

Thanks for the info.
It is especially interesting because of the subject of this thread.

A. ;)