Subject: [OSPF] OSPF IETF Meeting

From: Glen Kent <[email-masked]>
Date: Mon, 15 Nov 2010 20:45:37 +0530

(1) While i understand the need to speed up the OSPF adjacency
formation process, i somehow dont think that the mechanism described
in draft-dimitri-ospf-phased-db-sync-00.txt is good enough. It looks a
little tenuous and appears unscalable. I would like to compare this
vis-a-vis the transport mechanism that has been proposed by some other
folks, since that too attempts to achieve the same thing.

(2) I support draft-yang-ospf-hiding-00.txt and i think its makes
sense to progress this draft.

(3) I also support draft-bhatia-manral-auth-trailer-ospfv3-01, and i
think there clearly is a need to move away from IPsec security for
OSPFv3.

(4) I am not comfortable with
draft-bhatia-karp-ospf-ip-layer-protection-00.txt, as it currently
stands. While i understand that the author of this draft was one of
the co-authors of RFC 5709, i would like to first understand the
rationale behind introducing Apad in the crypto computation as has
been described in 5709. Thats clearly not a part of the original HMAC
specification. The authors have modified that without giving any
explanation in 5709, and i think its best that we first understand why
that change was introduced before we accept any changes (or
enhancements if you will) to it.

(5) draft-kini-ospf-fast-notification-00.txt looks interesting and i
would like to see some more discussions on it. I dont think its
currently at a maturity level where it can be progressed, but a
discussion would nevertheless be good.

Glen

---

From: "Bhatia, Manav (Manav)" <[email-masked]>
Date: Tue, 16 Nov 2010 21:44:14 +0530

Glen,
 
> think there clearly is a need to move away from IPsec security for

Thanks!

I believe we have a good consensus on this draft. We have seen support on the mailing list earlier and the folks who were there in Beijing.

> enhancements if you will) to it.

We were categorically told that NIST wanted to see the construction (using Authentication Pad (Apad)) that we have finally used in RFC 5310 and RFC 5709. Given that NIST owns the Secure Hash Standard family of algorithms that we're using in these standards it makes sense to follow NIST's instructions.

Compliance with NIST cryptographic modes, and general cryptographic guidance is a practical market requirement when creating a specification that uses NIST standard algorithms, regardless of whether one likes or dislikes particular choices that NIST has made.

If these specifications were *not* using a NIST algorithm, then NIST's views could be ignored, but not when youre working with a NIST standard algorithm.

Hope this helps.

Cheers, Manav

---

From: "Papadimitriou, Dimitri (Dimitri)" <[email-masked]>
Date: Sat, 20 Nov 2010 16:22:01 +0100

Glen,

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On 
> Behalf Of Glen Kent
> Sent: Monday, November 15, 2010 4:16 PM
> To: [email-masked]
> Subject: [OSPF] OSPF IETF Meeting
> 
> little tenuous and appears unscalable.

Can you please clarify what you mean with i) tenuous and ii) "appears unscalable" wrt to what ? and why ? this could be helpful for the next iteration of the document.

> I would like to compare this

As stated during the meeting, if you do such comparison keep in mind objectives and criteria. Indeed, partitioning instances is detrimental for devices which uses OSPF for exchanging non-IP routing information but this is the information from which they derive their forwarding entries. For instance, with MPLS-TE, separate instances would delay the RSVP-TE LSP setup (since relying on TE information). 
 
Thanks,
-d.
> _______________________________________________
> OSPF mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ospf
>

---

From: Acee Lindem <[email-masked]>
Date: Sat, 20 Nov 2010 11:53:50 -0500

As long as we are discussing this draft, I've changed the subject line. 

Speaking as a WG member, my opinion is that this draft is not worth the complexity and I wouldn't implement it even if the WG choose to adopt it as a WG document. 
There are many places in RFC 2328 where a decision is made dependent on whether or not a neighbor is FULL and I don't think one can introduce this protocol change under the assumption that the current definition. For example, MAXAGE LSAs are handled differently dependent on whether or not any neighbors are in exchange state. This logic would need to be bifurcated to handle both types of exchange. 

Additionally, the database exchange is only one component of separation between routing and non-routing information. The transport instance is superior in that it offers complete separation. 

See one more comment inline. 

> As stated during the meeting, if you do such comparison keep in mind objectives and criteria. Indeed, partitioning instances is detrimental for devices which uses OSPF for exchanging non-IP routing…

I disagree on two counts. 

  1. There is nothing that says the TE information has to moved to a separate instance. It is your draft that arbitrarily splits the database at the opaque LSA boundary. 
  2. You can not categorically say the transport instance will add delay. While the primary OSPF instance will normally be given priority, there is no reason delay will be added unless there are bottlenecks in the routing domain. 

Thanks,
Acee

---

From: Glen Kent <[email-masked]>
Date: Tue, 23 Nov 2010 05:55:52 +0530

Dimitri,

> Can you please clarify what you mean with i) tenuous and ii) "appears unscalable" wrt to what ? and why ? this could be helpful for the next iteration of the document.

As per your draft you exchange the important information first
followed by all ancillary stuff. Now, what you have not spelled out is
whether SPF should get triggered or not when you do the first phase?
If Yes, then you do delay doing the second phase as most OSPF tasks
are monolithic and can only do one thing at a time. So, after some
delayed time you start the subsequent exchanges, is this correct?

Glen