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

From: Pyda Srisuresh <[email-masked]>
Date: Tue, 29 Mar 2005 06:25:01 -0800

--- Acee Lindem <[email-masked]> wrote:
> Pyda Srisuresh wrote:
> 
> >--- Acee Lindem <[email-masked]> wrote:
> >  
> >
> >>Pyda Srisuresh wrote:
> >>
> >>    
> >>
> >>>Acee,
> >>>
> >>>I had done some work previously on using new LSAs for advertising topology
> >>>      
> >>>
> >>and
> >>    
> >>
> >>>prefix info into TE networks (draft-srisuresh-ospf-te-07.txt). This draft
> >>>      
> >>>
> >>can
> >>    
> >>
> >>>be a good starting point to use for turning into future MT extensions to
> >>>OSPFv3. 
> >>> 
> >>>
> >>>      
> >>>
> >>Hi Pyda,
> >>I don't see a requirement to mix TE data and the unicast/multicast 
> >>topology information. This has traditionally
> >>been separate and processed by different functional components. The new 
> >>LSAs in our draft correspond
> >>directly to the existing base LSA types (only they are in extendible TLV 
> >>format and support multiple
> >>topologies).
> >>
> >>    
> >>
> >[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. 

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?

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 <[email-masked]> 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
> >>>>
> >>>>   
> >>>>
> >>>>        
> >>>>
> >>> 
> >>>
> >>>      
> >>>
> >
> >  
> >
>

---

From: Acee Lindem <[email-masked]>
Date: Tue, 29 Mar 2005 09:55:38 -0500

Pyda,
See inline.

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

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

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.

Thanks,
Acee

---

From: Pyda Srisuresh <[email-masked]>
Date: Wed, 30 Mar 2005 09:13:30 -0800

Acee,

Pease see my response below inline. Thanks.

regards,
suresh

<... stuff deleted>

> I suspect it would look much like draft-mirtorabi-mt-ospfv3-01.txt.

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

> advantage to be gained in starting with srisuresh-ospf-te as a base 
[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. 

> single individual that must decide. The OSPF WG is always open to other 

[suresh] Thanks.

regards,
suresh