Re: draft comments : 2740 update

[Acee Lindem <[e-mail]>]

Mitchell,

Erblichs wrote:

>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.
>  
>
Characterizing an NSSA or stub area with ImportSummaries enabled as a 
"Totally Stubby"
is not necessary to understand or implement the NSSA specification. I 
believe the
term was coined by my current employer and later adopted by other 
vendors. However,
that doesn't mean it needs to be part of the standard. Notice that 
nobody has you configure
these as new area types. I did add "ImportSummaries" to appendix C.2.

Any other opinions?

Thanks,
Acee

>
>		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.
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>                    
>>>>>>>>>>
>>>>>>>
>>>>>>>              
>>>>>>>
>>>>>
>>>>>          
>>>>>
>>>
>>>      
>>>
>
>  
>