IETF Open Shortest Path First general discussion

Acee Lindem | 9 May 2013 20:03

Re: New Version Notification for draft-acee-ospf-rfc6506bis-01.txt

There have been a couple errata filed on RFC 6505 (authors copied). As a service to the 
OSPF community and in an effort to ensure interoperable OSPFv3 authentication 
trailer implementations, I have produced a BIS draft. The changes are listed in 
section 1.2:

1.2.  Summary of Changes from RFC 6506

   This document includes the following changes from RFC 6506 [RFC6506]:

   1.  Sections 2.2 and 4.2 explicitly state the Link-Local Signalling
       (LLS) block checksum calculation is omitted when an OSPFv3
       authentication is used.  The LLS block is included in the
       authentication digest calculation and computation of a checksum
       is unneccessary.  Clarification of this issue was raised in an
       errata.

   2.  Section 4.5 includes a correction to the key preparation to use
       the protocol specific key (Ks) rather than the key (K) as the
       initial key (Ko).  This problem was also raised in an errata.

   3.  Section 4.5 also includes a discussion of the choice of key
       length to be the hash length (L) rather than the block size (B).
       The discussion of this choice was included to clarify an issue
       raised in a rejected errata.

   4.  Section 4.1 indicates that sequence number checking is dependent
       on OSPFv3 packet type in order to account for packet
       prioritization as specified in [RFC4222].  This was an omission
       from RFC 6506.

(Continue reading)

headers

Hannes Gredler | 6 May 2013 18:43

Fwd: New Version Notification for draft-gredler-ospf-label-advertisement-02.txt

Dear OSPF working group,

have posted a new version of the OSPF label advertisement draft.
the major changes between -00 to -02 are:

-support for signaling Bypass (FRR) Labels
-support for SPT labels using RFC4761 'VPLS' style label block
 advertisements. this is mainly to comply to RFC3031 which
 mandates that label allocation is a strict local procedure,
 and still not loose the comfort of getting an
 automatically provided transport mesh (similar to LDP).

 This provides similar functionality like first mentioned in
 http://tools.ietf.org/id/draft-tian-mpls-lsp-source-route-01.txt
 *without* the need of an RFC 3031 architectural violation.

 The advertised label blocks allow in addition to specify a particular
 rfc4195 topology-ID and an algorithm (e.g. SPT). we got feedback
 that having a pluggable algorithm (e.g., but not limited to: MRT)
 would solve a couple of practical use cases for
 'infrastructure LSPs' in the area of make-before break, ordered FIB,
 etc.

the authors are looking for feedback and suggested text changes
to improve the draft. - please help us to make it better 

as a vehicle to foster open collaboration we are VCing our work in github.
feel free to clone the repository at:
https://github.com/hannesgredler/draft-gredler-ospf-label-advertisement.git
send us pull requests with your suggested changes (or diffs using email);

(Continue reading)

headers

Fred Baker (fred | 3 May 2013 17:58

Extensible LSAs

As I started at the past IETF meeting, there has been some additional work on extensible LSAs, egress
routing, and building access control into routing (which in my mind is primarily useful in data centers).
Interested in your remarks.

http://tools.ietf.org/html/draft-acee-ospfv3-lsa-extend
"OSPFv3 LSA Extendibility", Acee Lindem, Sina Mirtorabi, Abhay Roy, Fred
Baker, 1-May-13

http://tools.ietf.org/html/draft-baker-ipv6-ospf-dst-flowlabel-routing
diff: http://tinyurl.com/ct9wn6g
"Using OSPFv3 with Role-Based Access Control", Fred Baker, 2-May-13

http://tools.ietf.org/html/draft-baker-ipv6-ospf-dst-src-routing
diff: http://tinyurl.com/ctcshzb
"IPv6 Source/Destination Routing using OSPFv3", Fred Baker, 2-May-13

To diff from the previous drafts, if you want one, you want to do this following. This is what the tiny url gets you.
http://tools.ietf.org/rfcdiff?
url1=http://tools.ietf.org/id/draft-baker-ipv6-ospf-dst-src-routing-00.txt
&url2=http://tools.ietf.org/id/draft-baker-ipv6-ospf-dst-src-routing-02.txt

http://tools.ietf.org/rfcdiff?
url1=http://tools.ietf.org/id/draft-baker-ipv6-ospf-dst-flowlabel-routing-00.txt
&url2=http://tools.ietf.org/id/draft-baker-ipv6-ospf-dst-flowlabel-routing-02.txt

I'll save you one question, though. I get asked frequently why these didn't follow MT-OSPF or MI-OSPF, and
commented on this in the meeting in Orlando. The reason is that neither is fundamentally a topology or
instance question. MT-OSPF OSPF presumes that some non-null set of links in a topology are either absent
from some of the topologies or that metrics differ, so that routes in one topology differ from those in
another. This is about qualification of routes - a scalable access list or policy route, if you will. One

(Continue reading)

headers

Anton Smirnov | 3 May 2013 15:01

draft-acee-ospfv3-lsa-extend-00

    Hi all,
    I saw this draft was published a few days ago and I wanted to 
discuss the approach taken by authors. In brief, this draft deeply 
changes OSPFv3 by totally reworking LSA encodings but stops short of 
calling it a new version of OSPF protocol. Per draft routers supporting 
new LSA encodings do not mix with RFC 5340 OSPFv3 routers and do not 
talk to them. So from deployment point of view section of the draft 
describing backward compatibility can be reduced to simply "Totally not 
backward compatible".

    I think no one will object that OSPFv3 rigid LSA format became big 
obstacle in introducing new features and even simply catching up with ISIS.
    I personally fully agree that OSPFv3 has to be deeply reworked.
    But in my opinion this draft is presenting OSPFv4 without calling it 
so - and carries into the new version of the protocol some outdated 
features of OSPFv2.
    Isn't it a time to admit that OSPFv3 is failure of epic proportions? 
And to admit that stance 'to introduce minimum changes into the 
protocol' taken when developing OSPFv3 architecture was deeply flawed, 
sacrificed long-term benefits of introducing new protocol version to 
short-term benefits of quick standardization and will continue causing 
difficulties unless addressed (with LSA encodings being the most obvious 
but not the only one)?

--

-- 
Anton

headers

johnsonhammond1 | 27 Apr 2013 19:31

Biggest Fake Conference in Computer Science

Biggest Fake Conference in Computer Science

We are researchers from different parts of the world and conducted a study on  
the world’s biggest bogus computer science conference WORLDCOMP 
( http://sites.google.com/site/worlddump1 ) organized by Prof. Hamid Arabnia 
from University of Georgia, USA.

We submitted a fake paper to WORLDCOMP 2011 and again (the same paper 
with a modified title) to WORLDCOMP 2012. This paper had numerous 
fundamental mistakes. Sample statements from that paper include: 

(1). Binary logic is fuzzy logic and vice versa
(2). Pascal developed fuzzy logic
(3). Object oriented languages do not exhibit any polymorphism or inheritance
(4). TCP and IP are synonyms and are part of OSI model 
(5). Distributed systems deal with only one computer
(6). Laptop is an example for a super computer
(7). Operating system is an example for computer hardware

Also, our paper did not express any conceptual meaning.  However, it 
was accepted both the times without any modifications (and without 
any reviews) and we were invited to submit the final paper and a 
payment of $500+ fee to present the paper. We decided to use the 
fee for better purposes than making Prof. Hamid Arabnia (Chairman 
of WORLDCOMP) rich. After that, we received few reminders from 
WORLDCOMP to pay the fee but we never responded. 

We MUST say that you should look at the above website if you have any thoughts 
to submit a paper to WORLDCOMP.  DBLP and other indexing agencies have stopped 
indexing WORLDCOMP’s proceedings since 2011 due to its fakeness. See

(Continue reading)

headers

RFC Errata System | 17 Apr 2013 12:19

[Technical Errata Reported] RFC5185 (3595)

The following errata report has been submitted for RFC5185,
"OSPF Multi-Area Adjacency".

--------------------------------------
You may review the report below and at:
http://www.rfc-editor.org/errata_search.php?rfc=5185&eid=3595

--------------------------------------
Type: Technical
Reported by: Marek Karasek <mkarasek <at> cisco.com>

Section: 4

Original Text
-------------
   A link-LSA SHOULD NOT be advertised for a multi-area adjacency.  The
   neighbor's IPv6 link local address can be learned in other ways,
   e.g., it can be extracted from the IPv6 header of Hello packets
   received over the multi-area adjacency.  The neighbor IPv6 link local
   address is required for the OSPFv3 route next-hop calculation on
   multi-access networks (refer to Section 3.8.1.1 of [OSPFV3]).

Corrected Text
--------------
OSPFv3 supports two Address Families (AF), AF IPv6 and AF IPv4, using separate instances [RFC 5338]. The
route calculation differs for the IPv4 and IPv6 address families with respect to the next-hop
determination. OSPFv3 instances supporting an IPv6 AF SHOULD learn the IPv6 next-hop address from the
IPv6 Header source address and SHOULD NOT advertise a Link-LSA for a multi-area adjacency. However, for
OSPFv3 instances supporting an IPv4 AF, the next-hop address cannot be learned from the OSPFv3 hellos and
require advertisement of the Link-LSA. Hence, OSPFv3 instances supporting an IPv4 AF SHOULD advertise a

(Continue reading)

headers

Acee Lindem | 16 Apr 2013 15:25

FW: New Version Notification for draft-ietf-ospf-ospfv3-autoconfig-02.txt

This version includes a change to allow differing hello/dead intervals for
auto-configured routers. This was based on input in the Homenet WG and
interoperability testing between auto-configured implementations.

   3.  OSPFv3 HelloInterval/RouterDeadInterval Flexibility

   Auto-configured OSPFv3 routers will not require an identical
   HelloInterval and RouterDeadInterval to form adjacencies.  Rather,
   the received HelloInterval will be ignored and the received
   RouterDeadInterval will be used to determine OSPFv3 liveliness with
   the sending router.  In other words, the Inactivity Timer for each
   neighbor will reflect that neighbor's advertised RouterDeadInterval
   and MAY be different from other OSPFv3 routers on the link without
   impacting adjacency formation.  A similar mechanism requiring
   additional signaling is proposed for all OSPFv2 and OSPFv3 routers
   [ASYNC-HELLO].

I also put MANET requirements out of scope.

   Auto-configured operation over wireless networks requiring a
   point-to-multipoint (P2MP) topology and dynamic metrics
   based on wireless feedback is not within the scope of this
   document.  However, auto-configuration is not precluded in
   these environments.

Thanks,
Acee

On 4/15/13 7:14 AM, "internet-drafts <at> ietf.org" <internet-drafts <at> ietf.org>
wrote:

(Continue reading)

headers

Hannes Gredler | 13 Apr 2013 14:51

draft-gredler-ospf-label-advertisement

dear ospf-wg,

in orlando i have presented in RTGWG and MPLSWG use-cases for
IGP advertisment of MPLS labels.

   http://tools.ietf.org/html/draft-gredler-rtgwg-igp-label-advertisement

here is the draft outlining the actual protocol extensions for OSPF

   http://tools.ietf.org/html/draft-gredler-ospf-label-advertisement

the authors would love to hear feedback, opinions, flames 

thanks,

/hannes

headers

RFC Errata System | 10 Apr 2013 04:54

[Technical Errata Reported] RFC5709 (3585)

The following errata report has been submitted for RFC5709,
"OSPFv2 HMAC-SHA Cryptographic Authentication".

--------------------------------------
You may review the report below and at:
http://www.rfc-editor.org/errata_search.php?rfc=5709&eid=3585

--------------------------------------
Type: Technical
Reported by: Mike Dubrovsky <mdubrovs <at> cisco.com>

Section: 3.3

Original Text
-------------
(1) PREPARATION OF KEY
       In this application, Ko is always L octets long.

       If the Authentication Key (K) is L octets long, then Ko is equal
       to K.  If the Authentication Key (K) is more than L octets long,
       then Ko is set to H(K).  If the Authentication Key (K) is less
       than L octets long, then Ko is set to the Authentication Key (K)
       with zeros appended to the end of the Authentication Key (K),
       such that Ko is L octets long.

Corrected Text
--------------
(1) PREPARATION OF KEY
       In this application, Ko is always B octets long and is computed as
       follows:

(Continue reading)

headers

Acee Lindem | 7 Apr 2013 20:56

Use of the OSPF-MANET Interface in Single-Hop Broadcast Networks - draft-ietf-ospf-manet-single-hop-or-01

All, I'd like to start a 2 week WG last call on the subject document. The last call will end at 12:00 AM PDT on April 29th, 2012. Please review the document and send any comments to the list prior to that time. Here is a URL for your convenience: Thanks, Acee

<div>
<div>
All, 

I'd like to start a 2 week WG last call on the subject document. The last call will end at 12:00 AM PDT on April 29th, 2012. Please review the document and send any comments to the list prior to that time. Here is a URL for your convenience: 

Thanks,
Acee 
</div>
</div>

headers

Acee Lindem | 7 Apr 2013 20:52

Use of OSPF-MDR in Single-Hop Broadcast Networks - draft-ietf-ospf-manet-single-hop-mdr-01.txt

All, I'd like to start a 2 week WG last call on the subject document. The last call will end at 12:00 AM PDT on April 29th, 2012. Please review the document and send any comments to the list prior to that time. Here is a URL for your convenience: https://datatracker.ietf.org/doc/draft-ietf-ospf-manet-single-hop-mdr/ Thanks, Acee

<div>
<div>
All, 

I'd like to start a 2 week WG last call on the subject document. The last call will end at 12:00 AM PDT on April 29th, 2012. Please review the document and send any comments to the list prior to that time. Here is a URL for your convenience: 

https://datatracker.ietf.org/doc/draft-ietf-ospf-manet-single-hop-mdr/

Thanks,
Acee 
</div>
</div>

12	May 2013
12	April 2013
25	March 2013
7	February 2013
9	January 2013
9	December 2012
3	November 2012
10	October 2012
22	September 2012
13	August 2012
40	July 2012
20	June 2012
21	May 2012
11	April 2012
12	March 2012
25	February 2012
4	January 2012
9	December 2011
7	November 2011
15	October 2011
16	September 2011
17	August 2011
11	July 2011
18	June 2011
37	May 2011
92	April 2011
32	March 2011
46	February 2011
88	January 2011
17	December 2010
49	November 2010
27	October 2010
32	September 2010
5	August 2010
8	July 2010
8	June 2010
4	May 2010
7	April 2010
16	March 2010
29	February 2010
23	January 2010
3	December 2009
12	November 2009
10	October 2009
11	September 2009
51	August 2009
42	July 2009
13	June 2009
21	May 2009
33	April 2009
25	March 2009
39	February 2009
87	January 2009
9	December 2008
37	November 2008
29	October 2008
25	September 2008
7	August 2008
12	July 2008
29	June 2008
32	May 2008
36	April 2008
43	March 2008
43	February 2008
25	January 2008
20	December 2007
8	November 2007
69	October 2007
79	September 2007
36	August 2007
33	July 2007
12	June 2007
23	May 2007
31	April 2007
49	March 2007
17	February 2007
14	January 2007
82	December 2006
66	November 2006
41	October 2006
37	September 2006
61	August 2006
40	July 2006
81	June 2006

Mon	Tue	Wed	Thu	Fri	Sat	Sun

		1	2	3	4	5
6	7	8	9	10	11	12
13	14	15	16	17	18	19
20	21	22	23	24	25	26
27	28	29	30	31