Re: draft comments : 2740 update

[Erblichs <[e-mail]>]

Acee,
		This is an example of items that IMO SHOULD have
		at least mention the new area type within
		the V2 and V3 mods to OSPF.
	
		FYI to readers: Well known OSPF implimentors
		had publicly documented an area type
		known as "Totally Stubby" that removes
		all Type-3 LSAs, except a single type-3
		to advertise the default route. This was
		done YEARS ago.
		
		3101 now has the ImportSummmaries
		of the NSSA RFC that covers the usage
		of Type-3 LSAs and when NOT-ENABLED,
		transforms support for the "Totally Stubby"
		area type.

		---->RFC 3101 Suggested line addition.

		2.7 Optionally Importing Summary Routes
		"This alternate type-3 behaviour is part of a 
		sub-area type known as "Totally Stubby".
		--------------

		So, In general I would have expected that the
		original and newer v3 specs to explicitly mention
		the sub, NSSA, and the totally
		stubby area type, with the last one mentioning a
		possible change of behaviour of LSA type-3s. This
		is because alot of readers will not associate the
		well known area type of "Totally Stubby", with
		this new change.


		Mitchell Erblich
		===================
		
		
	

Acee Lindem wrote:
> 
> Mitchell,
> 
> Erblichs wrote:
> 
> >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.
> >
> >
> When the exception needs to be documented for the specification to be
> correct, I'll
> add it or re-word the text. I am not going to document every exception
> every time
> a given protocol construct is mentioned. As Editor, I'll make the
> determination of
> whether or not a suggestion adds value or simply bulk.
> 
> >       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.
> >
> >
> RFC 3101 is the definitive source for OSPF NSSA. The OSPFv3 unique encodings
> and protocol processing are included in the draft. If any are missing,
> please bring them
> forward.

		
> 
> >       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.
> >
> >
> This section describes the hello packet format.
> 
> >
> >
> >>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.
> >
> >
> I disagree. It isn't really necessary. If one is going to implement
> demand circuits one must
> consult RFC 1793. I'd reconsider if you can garner the support of
> others. Otherwise, give it
> up.
> 
> >
> >
> >
> >
> >>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.
> >
> >
> My previous suggestion on who to collaborate with still holds.
> 
> Thanks,
> Acee
> 
> >       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.
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>
> >>>
> >>>
> >
> >
> >