Subject: I-D ACTION:draft-ietf-ospf-cap-01.txt

From: [email-masked]
Date: Fri, 24 Oct 2003 10:51:27 -0400

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Open Shortest Path First IGP Working Group of the IETF.

        Title           : Extensions to OSPF for Advertising Optional Router Capabilities
        Author(s)       : A. Lindem, N. Shen, R. Aggarwal, S. Shaffer, J. Vasseur
        Filename        : draft-ietf-ospf-cap-01.txt
        Pages           : 8
        Date            : 2003-10-23

It is useful for routers in an OSPF routing domain to know the capabilities of their neighbors and other routers in the OSPF routing domain. This draft proposes extensions to OSPF for advertising optional router capabilities. A new Router Information (RI) opaque LSA is proposed for this purpose.

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

To remove yourself from the IETF Announcement list, send a message to
ietf-announce-request with the word unsubscribe in the body of the message.

Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
        "get draft-ietf-ospf-cap-01.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

Internet-Drafts can also be obtained by e-mail.

Send a message to:
        [email-masked].
In the body type:
        "FILE /internet-drafts/draft-ietf-ospf-cap-01.txt".

NOTE:   The mail server at ietf.org can return the document in
        MIME-encoded form by using the "mpack" utility.  To use this
        feature, insert the command "ENCODING mime" before the "FILE"
        command.  To decode the response(s), you will need "munpack" or
        a MIME-compliant mail reader.  Different MIME-compliant mail readers
        exhibit different behavior, especially when dealing with
        "multipart" MIME messages (i.e. documents which have been split
        up into multiple messages), so check your local documentation on
        how to manipulate these messages.

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

---

From: Dan Dovolsky <[email-masked]>
Date: Fri, 24 Oct 2003 12:47:01 -0400

I have couple questions to authors of this draft.

1. Could you, please, enumerate reasons why you want to have Router Options
advertisements in the new separated Opaque LSA?
Why the TE Router Opaque LSA is not good for it? RFC3630 doesn't prevent
adding of new tlvs into it.

2. Is it possible scenario when you don't have TE Router Opaque LSA but you
do have the new RI Opaque LSA?

Thanks,
Dan Dovolsky

-----Original Message-----
From: Mailing List [mailto:[email-masked]]On Behalf Of
[email-masked]
Sent: Friday, October 24, 2003 10:51 AM
To: [email-masked]
Subject: I-D ACTION:draft-ietf-ospf-cap-01.txt

A New Internet-Draft is available from the on-line Internet-Drafts
directories.
This draft is a work item of the Open Shortest Path First IGP Working Group
of the IETF.

        Title           : Extensions to OSPF for Advertising Optional Router
Capabilities
        Author(s)       : A. Lindem, N. Shen, R. Aggarwal, S. Shaffer, J.
Vasseur
        Filename        : draft-ietf-ospf-cap-01.txt
        Pages           : 8
        Date            : 2003-10-23

It is useful for routers in an OSPF routing domain to know the capabilities
of their neighbors and other routers in the OSPF routing domain. This draft
proposes extensions to OSPF for advertising optional router capabilities. A
new Router Information (RI) opaque LSA is proposed for this purpose.

Send a message to:
        [email-masked].
In the body type:

---

From: Acee Lindem <[email-masked]>
Date: Fri, 24 Oct 2003 14:11:45 -0400

>adding of new tlvs into it.
This is a more generalized mechanism.  I'm sure what it is used for will
be a topic for debate.

>do have the new RI Opaque LSA?

Yes.

---

From: Sandy Eng <[email-masked]>
Date: Fri, 24 Oct 2003 11:02:37 -0700

Dan,

> adding of new tlvs into it.

RFC3630 TE LSAs are only of area flooding scope. RI LSA can provision a
domain-wide scope. Also this draft is not describing TE-specific
purpose, but tunnels generally. It is a better idea to use a generic
mechanism to advertise router capabilites, especially when there may be
other applications that will use this LSA.

> do have the new RI Opaque LSA?

If a router is simply advertising a particular tunnel capability, a TE
Opaque LSA may not be requried in such a case.

Thanks,
Sandy

---

From: [email-masked]
Date: Thu, 30 Oct 2003 22:24:40 +0100

hi acee,

what's however difficult to understand in this i-d, is the
difference between "ospf capabilities for mpls-te" and
"advertise mpls-te capabilities"

this ambiguity is imho translated in the following flag:

    9         OSPF Path Computation Server discovery [7, 8]

where [7] stands for OSPF PCS discovery and [8] which refers
to the query/response RSVP-TE capability

i don't know if there is a possibility to translate this in
a more structured way ? this imho can only be responsed if
a clear definition of what "mpls-te capability" is provided,
in particular concerning the following: "or the intention of
an LSR to be part of a particular MPLS TE mesh group." i'm
not sure if this is a real mpls-te capability or more like
an mpls-te local policy configuration ?

thanks,
- dimitri.

--
Papadimitriou Dimitri
E-mail : [email-masked]
Private: http://www.rc.bel.alcatel.be/~papadimd/index.html
E-mail : [email-masked]
Public : http://psg.com/~dpapadimitriou/
Address: Fr. Wellesplein 1, B-2018 Antwerpen, Belgium
Phone  : +32 3 240-8491