Re: draft comments : 2740 update

[Erblichs <[e-mail]>]

Acee, et al,

	This is getting messy..

	I guess you raised to me what seems like a bigger
	question. Should generic protocol RFCs (Ex:2740) at 
	the time of creation or modificiation attempt to
	generate an illusion of completeness?

	If this is so, then yes, I would like to see at least
	all exceptions to common expected practices that could
	be "hidden" within one of tens of RFCs.

	Yes, I would like to see a Reference to Graceful Restart
	within this spec, if and only if (iff) it is a publicly
	documented spec AND it is(to become) common. Else,
	how would the people who read the V2 or V3 specs just
	know of its existance.

	Ex: So, who can find me in what RFC totally stubby area
	support is defined? NSSA is Ref in v3 and v2.

	And, i think we SHOULD make these RFCs with as minimal
	amount of ambiguity as possible and cross-reference them
	as freq as possible, to make sure that ALL curently supported
	implimnetations support a common set of features.

	Thus, if major changes were being done, yes, I would
	also suggest incorporation how each LSA type with its
	various scope is handled in stubs, totally stubby,
	not so totally stubby, etc area interactions.

	So, the RFC had/has the GM LSA as one of the 9 types
	and a separate RFC defines its processing, so I did
	see a need to include it, because it is slated for
	removal. But as it should be clear, at best IMO it
	should at most go to reserve with the type value and
	not reused. It could then be covered with other unknown
	types as you stated in a earlier email.

>I've change this to "each router on the network with
> neighbor
> state 1-Way or greater".

	Yes, I agree, this is more accurate, But it looses
	the implicit hello pkt to hello pkt field exchange.

> Since this section is defining RouterDeadInterval, I'm not sure we want
> to try and document
> every case where it isn't applicable.

	Why not? :) 
	Actually, in general, I would expect us to list at least
	A FEW exceptions as we see them and indicate in a footnote
	that the list may not be ALL encompassing.

	Else, we should consider it as an equiv as a Architectural
	constant.
	

> There is not agreement in the WG on whether or not these little
> implementation tweaks
> which have been practice for many years should be documented in an
> informational RFC.

	If "little implemenatation tweaks" are common public 
	practice, then at least they should be documented/ standardized, 
	IMO.

	Mitchell Erblich
	----------------------

	
	
	
Acee Lindem wrote:
> 
> Hi Mitchell,
> 
> Erblichs wrote:
> 
> >Acee, et al,
> >
> >       Just a few additional item Suggestions:
> >
> >       A) A.3.2 The Hello Packet
> >
> >       Neighbor Id
> >
> >               Append -> (exception of D/C neighbors)
> >
> >               Where I don't expect to see a hello within
> >               RouterDeadInterval sec.
> >
> >
> This could be a slippery slope to try and incorporate every exception
> case. One could
> make the same argument for graceful restart when the grace interval is
> greater than
> the dead interval.  I've change this to "each router on the network with
> neighbor
> state 1-Way or greater".
> 
> >       B) A.3.3 DD Packet field layout
> >
> >               Options field is shown 1 bit to small.
> >
> >
> Bits 8-31 - It's 24 bits as defined.
> 
> >       C) A.3.6
> >               To make the flooding of LSAs reliable, flooded
> >               LSAs are explicitly acknowledged.
> >
> >               Shouldn't it be ... flooded LSAs are explicitly or
> >               implicitly acknowledged.
> >
> >               Then ...
> >
> >               This acknowledgment is ...
> >
> >                       to
> >
> >               The explicit acknowledgment is
> >
> >
> Corrected (although I think the intent was clear without it).
> 
> >       D) C.3
> >               RouterDeadInterval
> >
> >                       before its neighbors declare the router down
> >
> >                       to
> >
> >               before its neighbors declare the non D/C neighbor
> >               down.
> >
> >               We are talking about missing hellos here..
> >
> >
> Since this section is defining RouterDeadInterval, I'm not sure we want
> to try and document
> every case where it isn't applicable.
> 
> >       E) 3 items: Inline..
> >
> >
> >       Mitchell Erblich
> >       --------------------------
> >
> >
> >
> >Acee Lindem wrote:
> >
> >
> >>Hi Mitchell,
> >>
> >>Thanks for the comments. See inline.
> >>
> >>Erblichs wrote:
> >>
> >>
> >>
> >>>group,
> >>>
> >>>      yes, these are suggested comments to the 2740 revision..
> >>>
> >>>      Mitchell Erblich
> >>>      -----------------
> >>>
> >>>Erblichs wrote:
> >>>
> >>>
> >>>
> >>>
> >>>>Acee, et, al,
> >>>>
> >>>>       Here are my first few comments. I will give you more
> >>>>       this weekend if my reading is to your aggreement.
> >>>>
> >>>>       1)
> >>>>          A.4 LSA formats
> >>>>          "defines seven distinct types of LSAs."
> >>>>
> >>>>          A.4.2.1 LSA Type : lists 9 types, thus seven -> nine
> >>>>
> >>>>
> >>>>
> >>>>
> >>We have router-LSAs, network-LSAs, intra-area-prefix-LSAs,
> >>inter-area-prefix-LSAs,
> >> inter-area-router-LSAs,  AS-external-LSAs, link-LSAs, and NSSA-LSAs.
> >>That makes
> >>eight - Corrected.
> >>
> >>
> >>
> >       E1) --> Group-membership-LSA was in the list
> >
> >
> The format of this LSA is not documented in this specification. In fact,
> we were considering
> getting rid of it completely but there was some opposition.
> 
> >>>>       2)
> >>>>          3.1.3 Neighbor Data Structure
> >>>>
> >>>>
> >>>>       Neighbor's Backup Designated Router
> >>>>
> >>>>     The neighbor's choice of Designated Router is now encoded as a
> >>>>     Router ID instead of as an IP address.
> >>>>
> >>>>       Insert Backup between : Designated Router, because we are
> >>>>       talking about the BDR. Or have you now the the same router
> >>>>       ID for the DR and BDR? :^)
> >>>>
> >>>>
> >>>>
> >>>>
> >>>      ... choice of Backup Designated Router ....
> >>>
> >>>
> >>>
> >>>
> >>Corrected.
> >>
> >>
> >>
> >>>>       3)
> >>>>          3.2.1.1  Sending Hello packets
> >>>>
> >>>>       and the DC-bit is set if
> >>>>     and only if the router wishes to suppress the sending of future
> >>>>     Hellos over the interface (see [DEMAND]).
> >>>>
> >>>>       ONLY after an a "full" adj has been established ??????
> >>>>
> >>>>
> >>>>
> >>>>
> >>>      as I am assuming that hello supression should not be done
> >>>      until after at least 2-way state is attempted to be achieved.
> >>>
> >>>      No, I am not 100% sure whether hellos should be
> >>>      sent on a DC link if their is a hello mismatch at the
> >>>      normal hello-interval or some less freq 2x interval
> >>>      should be chosen. Cost versus reliability / notification.
> >>>
> >>>      Thus, it is assumed that the repeated hellos on a DC link could
> >>>      be an indication that a adj hasn't formed. Need to ask the DC
> >>>      authors..
> >>>
> >>>
> >>>
> >>>
> >>The DC bit is set anytime the hello sender wants to negotiate Demand
> >>Circuit operation. My assumption
> >>is that the DC specification doesn't have any unique changes for OSPFv3
> >>(other than the location
> >>of the option bit in the options). BTW, you are correct that hello
> >>suppression doesn't kick in until
> >>FULL state is reached.
> >>
> >>
> >>
> >
> >       E2)
> >       Should we explicitly add the above phrase to mention that
> >       only after a "full adj" : (Only ... established.) was my
> >       suggestion without the "???".
> >
> >
> No - In this context, "future" means after the adjacency goes full. One
> should go RFC 1793 for
> a precise definition of demand circuits.
> 
> >       And the other question I was raising is whether a mismatch SHOULD
> >       cause some (2x) backoff of the hello as to still reduce cost
> >       with D/C neighborrs.
> >
> >       Seeing hellos on a D/C should say something anyway, so
> >       some are needed in case whatever is causing the mismatch
> >       is administratively fixed.
> >
> >
> >>>
> >>>
> >>>>       4)   transparent functional suggestions
> >>>>
> >>>>           to possibly improve convergence, the first hello pkt can
> >>>>           be sent the moment the interface becomes active
> >>>>
> >>>>
> >>>>
> >>>>
> >>I don't see a need to add this to the specification.
> >>
> >>
> >>
> >
> >       E3)
> >       Yes, this is really a implementation item for
> >       improved convergence. I thought that this is
> >       a transparent change and should be a common
> >       sense item that should be added. I don't know
> >       of a single implementation argument against it.
> >
> >
> There is not agreement in the WG on whether or not these little
> implementation tweaks
> which have been practice for many years should be documented in an
> informational RFC. I suggest you collaborate with authors of
> draft-kou-ospf-immediately-replying-hello-00.txt.
> 
> Thanks,
> Acee
> 
> >
> >
> >
> >>>>           if like routers are used and their is a concern for
> >>>>           hello xmit synchronization, after the first hello is
> >>>>           sent randomize just the next hello between 0 and the
> >>>>           hello interval, then send hellos at the hello interval
> >>>>
> >>>>       5)
> >>>>          3.4.3.2  Network-LSAs
> >>>>
> >>>>       "having two or more attached routers"
> >>>>
> >>>>
> >>>>
> >>>>
> >>Corrected.
> >>
> >>
> >>
> >>>>       to
> >>>>
> >>>>       having one or more attached routers each having a adjacency
> >>>>       with the DR.
> >>>>
> >>>>
> >>>>
> >>>>
> >>>      oh... should be full adjacency...
> >>>
> >>>
> >>>
> >>>
> >>New text states this.
> >>
> >>Thanks,
> >>Acee
> >>
> >>
> >>
> >>>>       Mitchell Erblich
> >>>>       ---------------------
> >>>>
> >>>>Acee Lindem wrote:
> >>>>
> >>>>
> >>>>
> >>>>
> >>>>>Hi Tom,
> >>>>>
> >>>>>Henderson, Thomas R wrote:
> >>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>>>>I missed this thread when it was on rtg-dir in December, else would have
> >>>>>>commented there.
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>This is as good a time as any to comment. I haven't made any changes to
> >>>>>the OSPFv3 update draft :^)
> >>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>>>>We have used MOSPF in MANET experiments in the past (Moy's
> >>>>>>implementation) and found it was convenient in that environment.  Once
> >>>>>>you have an efficient OSPF for MANET, why run a separate multicast
> >>>>>>routing protocol if you can avoid it?
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>I guess for the same reasons you run a separate multicast protocol in a
> >>>>>non-MANET (wired)
> >>>>>environment.   However, the decision for wired networks was made a long
> >>>>>time ago and
> >>>>>perhaps today's technologies and the differences in the MANET environment
> >>>>>would yield a different answer.
> >>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>>>>So unless there is a bit crisis, I think it may be prudent to keep the
> >>>>>>bits for the time being, since OSPF for MANET is IPv6 only.
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>So, you feel that there is a chance that MOSPFv3 may be fully specified
> >>>>>and implemented for
> >>>>>MANET networks sometime in the future (1-4 years). Correct? If there is
> >>>>>serious
> >>>>>consideration of this work, I'll leave the MOSPF specific bits in the
> >>>>>OSPFv3 draft. Any
> >>>>>other comments?
> >>>>>
> >>>>>Thanks,
> >>>>>Acee
> >>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>>>>Tom
> >>>>>>
> >>>>>>
> >>>>>>________________________________
> >>>>>>
> >>>>>>     From: Rohit Dube [mailto:[e-mail]]
> >>>>>>     Sent: Tuesday, January 10, 2006 10:01 PM
> >>>>>>     To: [e-mail]
> >>>>>>     Subject: Re: MOSPF - Multicast OSPF
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>>Also note that back in Nov 2002, we had dropped any further protocol
> >>>>>>work on MOSPF (v2) at the WG meeting.
> >>>>>>
> >>>>>>If anybody has a real problem with deprecating the bits (because they
> >>>>>>are implementing MOSPFv3), now would be a good time to step forward.
> >>>>>>
> >>>>>>Best,
> >>>>>>--rohit.
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>>
> >>>
> >>>
> >>>
> >
> >
> >