Re: OSPFv3 Extension Future Direction (this ought to get your attention)

[Pyda Srisuresh <srisuresh at YAHOO.COM>]

Acee,

Pease see my response below inline. Thanks.

regards,
suresh

<... stuff deleted>

> >>>[suresh] Acee - I am referign to usign the srisuresh-ospf-te draft as a
> >>>      
> >>>
> >>basis
> >>    
> >>
> >>>to make MT extensions. Specifically, the suggestion is to add new LSA
> types
> >>>with MT protocol extensions. And, the new LSA types could have topology
> >>>specific TLVs. The LSAs may be restricted to being advertised within the
> >>>topology boundary.
> >>> 
> >>>
> >>>      
> >>>
> >>Pyda,
> >>
> >>I took another look at your draft and don't see a good reason to use it 
> >>as a starting point
> >>for OSPFv3 extension including MTR and AFs:
> >>
> >>   1. It is targeted at TE extensions
> >>   2. It is based on OSPFv2
> >>   3. It doesn't specify the changes needed to base OSPFv3 needed to 
> >>support it.
> >>   4. To the best of my knowledge, there is not a large base of 
> >>deployments or even
> >>       implementations that would benefit from using it as a base.
> >>
> >>    
> >>
> >
> >Acee,
> >
> >Items 1, 2 and 3 are true. However, that is not to say that the concepts in
> the
> >draft cannot be used as the base to add new LSA types with MT protocol
> >extensions, restrict scope of LSA advertisements etc. The draft will need
> >rework and will look much different from the current draft when done. 
> >  
> >
> I suspect it would look much like draft-mirtorabi-mt-ospfv3-01.txt.
> 

[suresh] I will give the mirtorabi-mt-ospfv3 draft a read. 

> >As for Item 4, you are postulating that if we did have a new draft using the
> >concepts in srisuresh-ospf-te, you dont think it woudl benefit the existing
> >deployments. That seems a bit presumptious. Sound like, you are declaring
> that
> >adding new LSAs will not benefit existing deployments and hence not
> beneficial
> >to pursue. If so, it seems you have already made up your mind to go with the
> >TLV based approach. Is that the case?
> >  
> >
> That is not the case at all. #4 was in direct response to the 
> presumption that there was tremendous
> advantage to be gained in starting with srisuresh-ospf-te as a base 
> since it already exists.
> 
[suresh] Acee - This seems to be a semantics issue. I was refering to using the
concepts in the draft as a base, not the draft as is. The srisuresh-ospf-te
draft was conceived with the notion of making OSPF extendible for different
topologies and distribution needs. Yet, the scope of the draft was OSPF-xTE. 
You may have misunderstood what I said. I certainly did not mean for anyone to
taking the draft as is and turn it into a mt-ospfv3 draft. However, I would
have little problem taking the current draft as is  and turning it around to
come up with a a mt-ospfv3 version of it. But, the mt-ospfv3 version of the
draft would look different from the ospf-te draft. Hope you get the drift of
what I mean.

As I said earlier, I will give the mirtorabi draft a read to see If the draft
already incorporates concepts from my draft. 

> As for the TLV approach, I do think it is the right way to go but it is 
> the OSPF WG and not any
> single individual that must decide. The OSPF WG is always open to other 
> proposals.

[suresh] Thanks.

regards,
suresh

> 
> Thanks,
> Acee
> 
> 
> >cheers,
> >suresh
> >
> >  
> >
> >>Thanks,
> >>Acee
> >>
> >>    
> >>
> >>>cheers,
> >>>suresh
> >>>
> >>> 
> >>>
> >>>      
> >>>
> >>>>Thanks,
> >>>>Acee
> >>>>
> >>>>   
> >>>>
> >>>>        
> >>>>
> >>>>>I have not been active on this work recently due to my work priorities.
> >>>>>However, if there are folks on the list interested in pursuing, I would 
> >>>>>          
> >>>>>
> >>be
> >>    
> >>
> >>>>>happy to work with you on the effort and discussion. 
> >>>>>
> >>>>>Thanks.
> >>>>>
> >>>>>cheers,
> >>>>>suresh 
> >>>>>
> >>>>>--- Acee Lindem <acee at CISCO.COM> wrote:
> >>>>>
> >>>>>
> >>>>>     
> >>>>>
> >>>>>          
> >>>>>
> >>>>>>Content-Type: text/plain; charset=ISO-8859-1; format=flowed
> >>>>>>Content-Transfer-Encoding: 7bit
> >>>>>>
> >>>>>>At the Minneapolis IETF, I presented a comparision of  the
> >>>>>>various options we have for extending OSPFv3. The reaction to the
> >>>>>>presentation was very positive. However, it was last on the agenda and
> >>>>>>the OSPF WG coincided with other WGs (most notably L2VPN).
> >>>>>>
> >>>>>>At this point, I would like to initiate more discussion. The basic
> >>>>>>question is whether we go with a TLV based approach or continue
> >>>>>>to add new LSAs which need to be synchronized with the LSAs
> >>>>>>advertising topology and prefix information. A TLV based approach
> >>>>>>is described in:
> >>>>>>
> >>>>>>http://www.ietf.org/internet-drafts/draft-mirtorabi-mt-ospfv3-01.txt
> >>>>>>
> >>>>>>The crux of my presentation would be that this is gives us the powerful
> >>>>>>extension capability while still allowing us to advertise information
> >>>>>>            
> >>>>>>
> >>that
> >>    
> >>
> >>>>>>does not need to be synchronized in separate LSAs.
> >>>>>>
> >>>>>>Thanks,
> >>>>>>Acee
> >>>>>>
> >>>>>>  
> >>>>>>
> >>>>>>       
> >>>>>>
> >>>>>>            
> >>>>>>
> >>>>>     
> >>>>>
> >>>>>          
> >>>>>
> >>> 
> >>>
> >>>      
> >>>
> >
> >  
> >
>