OSPF Link-Local Signaling
draft-nguyen-ospf-lls-06

Waiting for David to clarify his DISCUSS based on the following email:

From: Bill Fenner
Subject: Re: draft-nguyen-ospf-lls-05.txt
Date: Wed, Nov 2 2005 -0800
To: David Kessens
Cc: IESG


>The summary says that the OSPF working group wants to experiment with
>it but it is not an OSPF working group document.
>
>My question is, was this document really an individual submission or
>was it an OSPF working group document ?

It was originally a submission to the OSPF WG, but the WG didn't
want to work on it at the time.  The authors redirected to individual
experimental submissions.  Meanwhile, the WG gained some interest in
this topic; we decided that instead of yanking the document out of
its current path and iterating in the WG, we'd continue on the path
of Experimental and the WG would use this opportunity to Experiment.

>Also, the motivation of this work seems really strange:
>
>1) we want to exchange arbitrary data.
>  Really ?

No, it's about extensibility - turns out OSPF's bet on fixed-format
packets ended up looking like the wrong horse.

>2) an example usage is the need for capabilities negotiation but at
>  the same time this draft is positioned for vendor specific issues
>  while the example mentions that extensions are hard to accomplish
>  because we are running out of bits. Is this capability negotiation
>  envisoned for vendor specific capabilities or for capabilities that
>  should have been standarized instead?

Bits in the EO header are reserved for IETF Consensus - what
about that is positioned for vendor specific issues?  It's not
a standardization escape mechanism, it's an enabler for extensions
that aren't otherwise possible.  The fact that it also enables
vendor extensions in addition to IETF extensions is not a property
of the document itself, is it?...

>3) it is stated that there are no compatibility issues. however, was
>  this tested or is this an assumption ?

It's compatible with implementations that follow the rules in STD 54.
There are some implementations that don't follow those rules - but
how much care do we need to take to not break broken implementations?

  Bill

[Ballot discuss]
I am concerned about draft-nguyen-ospf-lls-05:

  The summary says that the OSPF working group wants to experiment
  with it but it is not an OSPF working group document. What is the
  reason that this document is an individual submission while the
  summary says that the OSPF working group is interested in an
  experiment.

Also, the motivation of this work seems really strange:

1) we want to exchange arbitrary data.
  Really ? What is the reason that the authors want to exchange
  arbitrary data over OSPF
 
2) an example use is the need for capabilities negotiation but at
  the same time this draft is positioned for vendor specific issues
  while the example mentions that extensions are hard to accomplish
  because we are running out of bits. Is this capability negotiation
  envisoned for vendor specific capabilities or for capabilities that
  should have been standarized instead ?

3) it is stated that there are no compatibility issues. however, was
  this tested or is this an assumption ? This sounds somewhat
  optimistic considering the scope of this new option and the
  inconsistency between ip packet length and ospf packet length.

This draft is very open ended in it's motivations and needs more
clarity on what problem is being solved. As it stands now, it appears
there is an incredible amount of freedom which is basically asking for
trouble when people start to use this feature for things that should
have been standarized instead of using incompatible vendor specific
implementations.

[Ballot discuss]
I worry about the extnedibility and how easy this can be done:

  3. IANA Considerations

  LLS TLV types are maintained by the IANA.  Extensions to OSPF which
  require a new LLS TLV type must be reviewed by an designated expert
  from the routing area.

Have you assigned one or two of such experts?

  Following the policies outlined in [IANA], LLS type values in the
  range of 0-32767 are allocated through an IETF Consensus action and

We have seen in the past that "IETF Consensus Action" is vague and
not so easy (straight-forward) as for example stds action

  LLS type values in the range of 32768-65536 are reserved for private
  and experimental use.

Are thoese assigned at all by IANA?
And if so, is it FCFS?
And is any spec required?

  This document assigns LLS types 1 and 2, as follows:

    LLS Type    Name                                      Reference
        0      Reserved
        1      Extended Options                          [RFCNNNN]*
        2      Cryptographic Authentication              [RFCNNNN]*
        3-32767 Reserved for assignment by the IANA
    32768-65535 Private Use

earlier on you state that 32768-65536 are for Private use AND experimental use>
here in the table ujust "Private Use" ??

    65535      Reserved

So 65535 is both "Private Use" and "Reserved" ??

    *[RFCNNNN] refers to the RFC number-to-be for this document.


  This document also assigns the following bits for the Extended
  Options bits field in the EO-TLV outlined in Section 2.4.1:

    Extended Options Bit      Name                        Reference
      0x00000001              LSDB Resynchronization (LR) [OOB]
      0x00000002              Restart Signal (RS-bit)    [RESTART]

  Other Extended Options bits will be allocated through an IETF
  consensus action.

Strange that youwrite that here while the actual assignment is in the
other documents. Oh well

[Ballot comment]
doc: draft-nguyen-ospf-lls-05.txt

document states
  sect 2.4.1 says:
  The value of the type field in EO-TLV is TBD (temporarily used value
  is 1).

  sect. 2.4.2 says:
  The value of the Type field for CA-TLV is TBD. Temporary used value
  is 2.

While IANA considerations section already assigns value 2:
  This document assigns LLS types 1 and 2, as follows:

    LLS Type    Name                                      Reference
        0      Reserved
        1      Extended Options                          [RFCNNNN]*
        2      Cryptographic Authentication              [RFCNNNN]*


Reference/Citation issues:

!! Missing Reference for citation: [IANA]
  P007 L029:    Following the policies outlined in [IANA], LLS type values in the

!! Missing citation for Normative reference:
  P008 L034:    [OSPF] Moy, J., "OSPF Version 2", RFC 2328, April 1998.

!! Missing Reference for citation: [RFC2328]
  P002 L015:    [RFC2328] packets are not very flexible to provide an acceptable
  P002 L037:    [RFC2328] packets are not very flexible to provide an acceptable

--------

draft-nguyen-ospf-oob-resync-05.txt

!! Missing Reference for citation: [RFC2328]
  P002 L008:    According to the OSPF standard [RFC2328], after two OSPF routers have

$ idnits draft-nguyen-ospf-oob-resync-05.txt
idnits 1.77 (21 Aug 2005)

draft-nguyen-ospf-oob-resync-05.txt:


  Checking nits according to http://www.ietf.org/ID-Checklist.html:
  * The document seems to lack an Abstract section.
  * The document seems to lack an IANA Considerations section.

-------
draft-nguyen-ospf-restart-05.txt


$ idnits draft-nguyen-ospf-restart-05.txt
idnits 1.77 (21 Aug 2005)

draft-nguyen-ospf-restart-05.txt:


  Checking nits according to http://www.ietf.org/ID-Checklist.html:
  * The document seems to lack an Abstract section.
  * The document seems to lack an Introduction section.
  * The document seems to lack an IANA Considerations section.

On all 3 documents:

We may get a request from the IESG to change the title to
be things like "Cisco's method for OSPF Link-local signaling".
If you don't want to make that change now, at least be prepared
for that request to come.

--

draft-nguyen-ospf-lls-04

In the second paragraph of section 1, you say "However, in some
situations it may not be desirable" -- it'd be better to give at
least one example so that the reader isn't left completely up in
the air as to why it may not be desirable (e.g., mention extra
packets on the network, or the desire to synchronize with other
packets, or something).

Section 2 could use a new title if it's going to be an RFC;
perhaps "The LLS solution"?

The last sentence on page 2 seems to just end; is it complete?
It's not necessarily clear what "the adjacency proceeds" means;
perhaps talk about the data with DBD being delivered after the
DBD packet has been acknowledged.

At the end of section 2.2, I think the reference for the inner
TLVs is supposed to be to section 2.3, not to 2.2?

In 2.4.1:
- It's OK for this document to assign values, since it's creating the
registry.
- You don't talk about a registry for EO bits, here or in section 3.
This might be useful, to establish a policy and prevent collisions.


In 2.4.2: again, it's OK for this document to assign values.

In section 3, it may be useful to show what you think the initial
contents of the registry should be - e.g.,

  This document assigns LLS types 1 and 2, as follows:

  LLS Type    Name                                      Reference
      0      Reserved
      1      Extended Options                          [RFCNNNN]
      2      Cryptographic Authentication              [RFCNNNN]
3-32767      Reserved
32768-65535  Private Use
  65535      Reserved


In section 4, you should be more explicit that the data will be ignored -
i.e., this means that required extensions can not be compatibly carried
in LLS.

In section 5, has anyone from the security area reviewed this security
mechanism?

----

draft-nguyen-ospf-restart-04

I'd suggest adding a section called "Sending Hello packets with the RS bit
set"; it can contain just the paragraph under Figure 1.  In this paragraph,
I would suggest changing "not clear" to "not known", and perhaps change
"may not" to "must not".  (This would make the flow be Figure 1; sentence
about LR bit; new section; then the current 2.1)

In section 2.1, it says "ensure that the RS bit is clear in [your reply]."
What if you're restarting yourself and you would normally be setting RS?

In section 2.2, what if you enable this option, recalculate your
LSDB, reset and generate the 1-WayReceived event, and then get another
Hello packet with RS-bit set since the other guy hasn't stopped
setting the RS-bit?

In other corner cases, what happens if the neighbor keeps sending
RS-bit for longer than RouterDeadInterval (contrary to the spec),
your ResyncTimeout timer goes off but then you keep getting packets
with RS-bit set?  What happens if the neighbor sends a Hello with
RS-bit clear after you've set your RestartState flag and your
ResyncTimeout timer is still running?

Since we're using the RFC 3667/3668 IPR stuff now, please replace
section 6 with the text from section 5 of RFC 3668.

--

draft-nguyen-ospf-oob-resync-04

Similarly to the lls draft, I'd try to expand on the "in some cases" in
the introduction, e.g. by naming one case explicitly.

In 2.1, it's OK to assign a bit position since you're creating the
object in a different document in this set.  (Of course, this has
to be consistent with the IANA guidelines we set for these bits.)

In 2.4, is it OK to assign this bit to R?  The WG has been being the
de-facto registrar for these bits.

At the end of 2.4, you say "the neighboring routers experience problems
in LSDB resynchronization" -- does this mean "the neighboring router
cannot resynchronize me" or something else?  Can you reword this?

One thing I'm not clear on: does the OOBResync flag get set on both
ends (the router requesting the resync and the router providing the
resync)?

In this one also, change section 6 to the text in section 5 of RFC 3668.