gmane.ietf.ospf

Document Action: 'OSPF Stub Router Advertisement' toInformationalRFC (draft-ietf-ospf-rfc3137bis-04.txt)

The IESG — 2013-05-23T15:27:03

The IESG has approved the following document:
- 'OSPF Stub Router Advertisement'
  (draft-ietf-ospf-rfc3137bis-04.txt) as Informational RFC

This document is the product of the Open Shortest Path First IGP Working
Group.

The IESG contact persons are Stewart Bryant and Adrian Farrel.

A URL of this Internet Draft is:
http://datatracker.ietf.org/doc/draft-ietf-ospf-rfc3137bis/




Technical Summary

  This document describes a backward-compatible technique that may be
  used by OSPF (Open Shortest Path First) implementations to advertise
  unavailability to forward transit traffic or to lower the preference
  level for the paths through such a router. This document updates
  RFC3137 to include applicability to OSPFv3. 

Working Group Summary

  There were some noteworthy discussions around including an alternate
  solution in OSPFv3 which achieves some of the same goals as RFC3137.
  Authors added a section to capture the use of R-bit as a potential
  alternative solution. R-bit is part of base OSPFv3 (RFC274

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

Acee Lindem — 2013-05-23T12:06:22

The OSPF WG is requesting publication of   "Use of the OSPF-MANET Interface in Single-Hop Broadcast Networks" (draft-ietf-ospf-manet-single-hop-or-02). Yi Yang is acting a document shepherd and the attendant write-up is attached.
Thanks,
Acee

On May 17, 2013, at 10:12 AM, Yi Yang (yiya) wrote:


(1) What type of RFC is being requested (BCP, Proposed Standard,Internet Standard, Informational, Experimental, or Historic)?  Whyis this the proper type of RFC?  Is this type of RFC indicated in the title page header?     Experimental.           As an update of RFC5820, an Experimental RFC, it's justified to      categorize this draft as Experimental. (2) The IESG approval announcement includes a Document AnnouncementWrite-Up. Please provide such a Document Announcement Write-Up. Recentexamples can be found in the "Action" announcements for approveddocuments. The approval announcement contains the following sections:     Technical Summary      This draft describes how to simplify/optimize OSPF-MANE

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

Yi Yang (yiya — 2013-05-17T14:12:26

Hi Acee,

I have completed my shepherd writeup and I believe the document is ready
for publication. Please see the attached for the writeup.

Yi




On 5/4/13 5:53 PM, "Acee Lindem" <acee.lindem< at >ericsson.com> wrote:


(1) What type of RFC is being requested (BCP, Proposed Standard,Internet Standard, Informational, Experimental, or Historic)?  Whyis this the proper type of RFC?  Is this type of RFC indicated in the title page header?     Experimental.           As an update of RFC5820, an Experimental RFC, it's justified to      categorize this draft as Experimental. (2) The IESG approval announcement includes a Document AnnouncementWrite-Up. Please provide such a Document Announcement Write-Up. Recentexamples can be found in the "Action" announcements for approveddocuments. The approval announcement contains the following sections:     Technical Summary      This draft describes how to simplify/optimize OSPF-MANET interface     operation, originally specified in RFC5820, in single-hop broad

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

Acee Lindem — 2013-05-09T18:03:14

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
       len

Re: draft-acee-ospfv3-lsa-extend-00

Anton Smirnov — 2013-05-07T08:43:41

    Hi Acee,
    introducing non-backward-compatible revision of protocol is very big 
deal both for vendors and customers.
    What I am vigorously objecting is approach of developing 
non-backward-compatible protocol revision with "minimum of changes" 
being the primary requirement. This almost guarantees end result to be 
inefficient.

    Protocol *extension* must be designed to be backward compatible even 
if that makes it very complex.
    That complexity should be addressed by major protocol *revision*. 
Work on major protocol revision should start from writing requirements 
document - and this stage alone should probably last couple of years.


 > Additionally,
 > history has proven that more focused work has a better chance of
 > reaching fruition.

That's why burning need for new feature should not be mentioned while 
discussing non-backward-compatible protocol extension. Latter should be 
developed on its own.


Anton


On 05/04/2013 11:31 PM, Acee Lindem wrote:

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

Hannes Gredler — 2013-05-06T16:43:08

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

Re: draft-acee-ospfv3-lsa-extend-00

Peter Psenak — 2013-05-05T08:47:44

Hi Acee,

let me start by saying that I fully support the effort to define 
extensible LSAs in OSPF. I also don't believe we need a new protocol 
version for it, nor that we need to address all the legacy in the 
protocol at this point.

One piece I have a problem with is the backward compatibility. I don't 
think we can afford to introduce an extension to the protocol that is 
not backward compatible. I know it's easier for us who "write and 
maintain" the software to do it that way, but we have to look at it from 
the perspective of the users who have thousands of nodes running the 
current version of the protocol deployed. Using separate OSPFv3 routing 
domains during transition has significant impact on the network and 
brings a lot of complexity to the operational folks. I'm afraid the 
complexity associated with the backward compatibility would have to be 
incorporated in the protocol, not pushed to the user.

Last, but not least, we have a similar requirements in OSPFv2. I'm in 
process of writing a d

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

Acee Lindem — 2013-05-04T21:53:10

The WG last call for the subject document has completed. It will go to the ADs for review once the shepherding writeup is complete. Yi Yang has consented to be the document shepherd.
Thanks,
Acee

From: Ericsson <acee.lindem< at >ericsson.com<mailto:acee.lindem< at >ericsson.com>>
Date: Sunday, April 7, 2013 11:56 AM
To: OSPF List <ospf< at >ietf.org<mailto:ospf< at >ietf.org>>
Subject: [OSPF] 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
_______________________________________________
OSPF mailing list
OSPF< at >ietf.org
https://www.ietf.org/mailman/listinfo/ospf

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

Acee Lindem — 2013-05-04T21:51:40

The working group last call has ended on the subject document. It will go to the ADs for review once the shepherding document it complete.

From: Ericsson <acee.lindem< at >ericsson.com<mailto:acee.lindem< at >ericsson.com>>
Date: Sunday, April 7, 2013 11:52 AM
To: OSPF List <ospf< at >ietf.org<mailto:ospf< at >ietf.org>>
Subject: [OSPF] 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
_______________________________________________
OSPF mailing list
OSPF< at >ietf.org
https://www.ietf.org/mailman/listinfo/ospf

Re: draft-acee-ospfv3-lsa-extend-00

Acee Lindem — 2013-05-04T21:31:52

Hi Anton, 
If you look at the drafts Fred recently refreshed, I think you'll have to
agree that we have a burning requirement for this extension. Additionally,
history has proven that more focused work has a better chance of reaching
fruition. As for backward compatibly, it is possible to do something akin
to RFC 1793 and the original unpublished version of this draft contained
these mechanisms. However, it is not clear that the complexity justifies
the mechanisms - we'll leave that for the WG to decide.
Acee 
P.S. To quote a philosopher of the late 20th century, "You can't always
get what you want. But if you try sometimes well you might find you get
what you need." 

On 5/3/13 8:53 AM, "Anton Smirnov" <asmirnov< at >cisco.com> wrote:

Re: draft-acee-ospfv3-lsa-extend-00

Anton Smirnov — 2013-05-03T15:53:49

    Hi Acee,

 > As far as calling it OSPFv4, I don't think we need to do this since
 > only the encoding of the LSAs change.

Yes I understand the reasoning but that is exactly where I have a 
problem with this approach.
As it is said - “For every problem there is a solution which is simple, 
fast and wrong.”
I believe approach taken while architecturing OSPFv3 was exactly that - 
simple, fast and wrong. Exactly the reason why we have to talk right now 
about creating non-backward-compatible change is because OSPFv3 
inherited from OSPFv2 rigid LSA structure in the name of simplicity.

I just want to make sure we will not repeat the same mistake again - 
create non-backward-compatible revision of the protocol which missed 
opportunity to implement anything but only single change.

So understand me right - I fully agree with you that OSPFv3 is not 
extendable, I have no big problem with semantics of proposed extended 
LSAs, I am even ready to accept non-backward-compatible change (just 
because I do not

Extensible LSAs

Fred Baker (fred — 2013-05-03T15:58:15

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-

Re: draft-acee-ospfv3-lsa-extend-00

Acee Lindem — 2013-05-03T15:14:53

Hi Anton, 
Thanks for introducing the draft - I had meant to do it but am chronically pressed for time. Here is the link: 

https://datatracker.ietf.org/doc/draft-acee-ospfv3-lsa-extend/

You are correct that the draft does require a deployment upgrade. A mixed deployment will require separate OSPFv3 routing domains and multiple OSPFv3 instances at least at the boundaries. The alternative was to require both the existing LSAs and the Extended-LSAs to be originated in mixed deployments. This adds quite a lot of complexity and will not be scalable in many networks. It is definitely possible but is the is the sort of backward compatibility mechanism people who don't write or maintain routing software propose. 

As far as calling it OSPFv4, I don't think we need to do this since only the encoding of the LSAs change. We were careful not to change the LSA semantics in the interest of rapid acceptance, implementation, and, hopefully, deployment. I believe the OSPFv3 moniker should be reserved for a version of the p

draft-acee-ospfv3-lsa-extend-00

Anton Smirnov — 2013-05-03T13:01:55

    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 minimu

Biggest Fake Conference in Computer Science

2013-04-27T17:31:41

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

[Technical Errata Reported] RFC5185 (3595)

RFC Errata System — 2013-04-17T10:19:16

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 det

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

Acee Lindem — 2013-04-16T13:25:37

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
   poin

draft-gredler-ospf-label-advertisement

Hannes Gredler — 2013-04-13T12:51:28

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

[Technical Errata Reported] RFC5709 (3585)

RFC Errata System — 2013-04-10T02:54:10

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:

OSPF WG Last Call: Use of the OSPF-MANET Interface in Single-Hop Broadcast Networks (Corrected)

Acee Lindem — 2013-04-07T19:10:43

All,

I'd like to start a 3 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-or/

Thanks,
Acee

OSPF WG Last Call: Use of OSPF-MDR in Single-Hop Broadcast Networks - draft-ietf-ospf-manet-single-hop-mdr-01.txt (Corrected)

Acee Lindem — 2013-04-07T19:07:50

All,


I'd like to start a 3 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

P.S. I meant to say 3 week WG Last Call. This is accommodate those who have to file US taxes but haven't done so yet.