Re: draft comments : 2740 update

[Acee Lindem <[e-mail]>]

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