Re: draft comments : 2740 update

[Acee Lindem <[e-mail]>]

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