Subject: OSPF WG Charter Proposal

From: Rohit Dube <[email-masked]>
Date: Mon, 28 Oct 2002 17:54:41 -0500

Folks,

Here is a strawman of the Charter. Please have a look at and send
any comments you may have to me or Acee or to the list.

The current charter is largely designed to clear up items that have
pending for a while. The charter will be re-visited periodically and
new items that come up will be added after discussions with the ADs.

Thanks,
Rohit and Acee
(OSPF WG Co-chairs)

---

From: Rohit Dube <[email-masked]>
Date: Tue, 29 Oct 2002 15:11:18 -0500

On Mon, 28 Oct 2002 22:46:31 -0500 "Singh, Ajay" writes:
=>Hello Venkata,Acee, Rohit,
=>  With regards to OSPF-TE mib requirements, i would like to differ from what
=>venkata has to say. OSPF - TE requirements as is, are not part of OSPF
=>protocol requirements/ of any use in OSPF networks. Its only that OSPF acts
=>as a transport mechanism to propagate the TE info in the network( which
=>quite often would be a superset of OSPF network(TE links and associated
=>nodes may not be running OSPF for that matter)). Injection( and hence its
=>generation) of this TE info, per se, should not lie in the perview of OSPF
=>group, as the requirements are to be dealt with by the users of the
=>information( e.g connecting MPLS modules, LMP etc) . Hence, is it right to
=>develop the OSPF-TE mib as an OSPF working group item.
=>Please let me know disconnects in my understandings.
=>Thanks
=>Ajay

Ajay,

Acee and I discussed this. I would agree with you. Any OSPF-TE mib is
likely to be equally relevant to ISIS. I would prefer to not get into
specifying this here - if at all, the TEWG can specify (perhaps they
do already) the contents of the TED to be extracted into a MIB.

Regards,
--rohit.

PS: I am cc'ing the list as well. Hope you don't mind.

---

From: Don Goodspeed <[email-masked]>
Date: Tue, 29 Oct 2002 15:35:09 -0500

Rohit and all,

In our work on the ISIS MIB update with Jeff Parker, myself, and
others, we are keeping the TLV contents in their raw hex form
and are not interpreting any of them further, including TE
info.  We leave it up to the CLI or network manangement system
to interpret further (which they'll do better than the MIB
can).  And it's more extensible since any changes to TLVs do
not require a subsequent MIB update in order to support.

However, I do feel we can include administrative items in
the MIB such as TE support (already in OSPF's mib update),
TE metric (either in the ospfIfTable or the ospfIfMetric
table), and administrative group.  It's the bandwidth
reservation stuff that's trickier.

-don

 --- On Tue 10/29, Rohit Dube  wrote:
From: Rohit Dube [mailto: [email-masked]]
To: [email-masked]
Date: Tue, 29 Oct 2002 15:11:18 -0500
Subject: Re: FW: OSPF WG Charter Proposal

> PS: I am cc'ing the list as well. Hope you don't mind.

_______________________________________________
Join Excite! - http://www.excite.com
The most personalized portal on the Web!

---

From: "Manral, Vishwas" <[email-masked]>
Date: Wed, 30 Oct 2002 07:57:18 -0500

Hi Rohit,

I am not claiming that with flooding optimizations the network
meltdowns/failures, which the paper observes "could" be typical(its been
some time since I read the paper though), would be solved, not optimizing
aggravates the problem further.

The same is true about our draft. Though flooding optimizations by
themselves wont suffice they do help solve part of the problem.

I think if "flooding optimizations" can be achieved without cluttering up
the spec/code, it would be helpful, besides from the two documents I refer
to it could mean the problem has been seen by the operators too(though I am
not sure of the no workarounds in site part of it).

Thanks,
Vishwas

-----Original Message-----
From: Rohit Dube [mailto:[email-masked]]
Sent: Wednesday, October 30, 2002 12:21 AM
To: [email-masked]
Subject: Re: OSPF WG Charter Proposal

On Tue, 29 Oct 2002 08:22:54 -0500 "Manral, Vishwas" writes:
=>Hi Rohit/Acee,
=>
=>>Is anybody running OSPF networks hitting this problem with no workarounds
=>in sight?
=>I am not sure about this statement exactly, however I do think it can be
=>helpful in a few cases. A recent paper by Aman Shaikh/Albert Greenberg
=>et.al. about analyzing OSPF for Enterprise is one such case. One of our
=>drafts "Congestion Avoidance and Control for OSPF networks" talks about
=>problems that have been caused by flooding overload in production
networks.
[snip]

Vishwas,

I am familiar with Aman's work. The problem identified there was
that of (a) sub-optimal network/ospf configuration and (b) broken router.
This does not ofcourse justify building new protocol mechanisms, thereby
complicating the protocol.

I will look at the congestion again to see if/why it concludes otherwise.

Regards,
--rohit.

---

From: "Manral, Vishwas" <[email-masked]>
Date: Wed, 30 Oct 2002 08:22:07 -0500

Hi Rohit,

I was part of the "others" that Don mentioned in his other mail.

Jeff P. correct me(I may have interpreted it wrongly), but I think we chose
the TLV approach in ISIS as we could have probs because of "small SNMP
buffer size and the lack of a defined way to fragment payload". In short an
SNMP agent may not be able to fulfill the request for an LSP of large
size(255 bytes??). In OSPF we anyway send the entire LSA as OCTET string.

If we are not interpreting the TLV's, we could as well send the entire LSA
itself as OCTET string. An OSPF-v2 TE LSA by the way would contain just one
top-level TLV anyway. We could have a seperate table for TE LSA's though in
this case.

Thanks,
Vishwas

-----Original Message-----
From: Rohit Dube [mailto:[email-masked]]
Sent: Wednesday, October 30, 2002 2:54 AM
To: [email-masked]
Subject: Re: FW: OSPF WG Charter Proposal

Hi Venkata,

Ofcourse the item is being considered - we are discussing it here
right! That said, it is in the working groups interest to (a) keep
the focus on a manageable set of issues and (b) take operational
requirements into account before expanding the goals.

Don's approach is reasonable too in this regard (specify a mechanism
to extract the TLVs and Acee and I did discuss this as well) but again,
I would prefer the application that interprets the TLVs (here TE) to
specify the MIB.

Best regards,
--rohit.

PS: The TEWG lists atleast one MIB on its web page
    http://www.ietf.org/internet-drafts/draft-ietf-tewg-mib-03.txt
    so I don't believe it to be inconceivable for the TEWG (or some other)
    to specify another for the TED.

On Tue, 29 Oct 2002 16:05:14 -0500 "Naidu, Venkata" writes:
=>Rohit,
=>
=>-> Acee and I discussed this. I would agree with you. Any OSPF-TE mib is
=>-> likely to be equally relevant to ISIS. I would prefer to not
=>-> get into specifying this here - if at all, the TEWG can specify
=>-> (perhaps they do already) the contents of the TED to be extracted
=>-> into a MIB.
=>
=> Please give consideration - after all are we discussing OSPF WG charter.
=> Please talk to TEWG chairs and discuss all the possibilities.
=>
=> OSPF-TE is given to OSPF-WG, but OSPF diff extensions (as far as
=> I know, Francois is pretty confident with the recent LOM/BC
=> related IGPs update). So, coordinate with TEWG chairs, if
=> they don't have any agenda related to OSPF-TE MIB and/or OSPF-Diff-TE
=> MIBs in their charter, then discuss which is the better WG to have
=> such drafts. May be single draft will suffice for all the OSPF TE
=> related MIBs (OSPF-TE, OSPF-Diff-TE, OSPF-GMPLS, OSPF-FA LSPs etc).
=>
=> As far as I know, TEWG works for requirements and they don't
=> have any such charter for protocol related MIBs.
=>
=>--
=>Venkata.

---

From: Jeff Parker <[email-masked]>
Date: Wed, 30 Oct 2002 10:37:18 -0500

I can't speak for the others, but here are my thoughts.

In OSPF, there is no restriction on what a PDU contains,
and a router can deal out an arbitrary hand from the
LSA in the DB.  IS-IS, on the other hand, fixes the
contents of a Link State PDU (LSP) at creation time.
If one TLV changes in IS-IS, we cannot simply flood
the updated TLV: we have to regenerate and reflood
the whole LSP.

This is all to say that the standard unit of exchange
in ISIS is a big honking LSP of 1492 or more bytes.
We decided to split this into TLVs (rather than hand
back a whole LSP) due to concerns about SNMP limits,
not because we thought is was the best thing to do.

This is moot in OSPF, as there is no "standard unit"
bigger than an LSA, and thus I wouldn't expect the
same issue to arise.

- jeff parker

---

From: "Joyal, Daniel R (Daniel)" <[email-masked]>
Date: Wed, 30 Oct 2002 11:01:34 -0500

>bigger than an LSA, and thus I wouldn't expect the

Jeff did a good job of laying out the motivation for
splitting the LSP database table in the ISIS MIB into LSP header
and LSP body. LSA size issues could arise in OSPFv2 (OSPFv3
addresses this), however, with variable size LSAs, such as
the router-LSA. In certain topologies, these LSAs could be
honking big, though I would venture that this is not the typical case.

-Dan