Re: [OSPF] OSPFv3 LSA Extendibility - draft-acee-ospfv3-lsa-extend-00.txt

[Acee Lindem <[e-mail]>]

Hi Mike, 
My first thought is that we'd make the dual LSA origination base on
configuration rather than based on the RFC 1793-esque signaling. I will
need to discuss with my co-authors.
Thanks,
Acee 

On 6/28/13 1:55 PM, "Mike Dubrovskiy (mdubrovs)" <[e-mail]>
wrote:

>Hi guys,
>
>Does bellow looks like what you are saying ?
>
>Two mode of operation:
>
>RFC5340Compatibility is off (default)
>
>In this mode router originates only new types of LSAs.
>Router consider only new type of LSAs from other routers.
>Router does not establish adjacencies with old routers.
>
>RFC5340Compatibility is on (non-default; need to be configured during
>transition). 
>
>In this mode router originates both old and new types of LSA.
>Router prefers new type of LSA for SPF calculation.
>Router establish adjacencies with both types for routers.
>
>Old format router LSA  has ExtendedFormatCapable flag set for the case
>when corresponded new format LSA stuck somewhere
>When all old type  LSAs in the router database have ExtendedFormatCapable
>flag, router flushes self-originated LSA in old format.
>The flag ExtendedFormatCapable  should be propagated across area borders
>similar to  OSPF demand circuit-like.
>
>Thank you,
>Mike
>
>> -----Original Message-----
>> From: [e-mail] [mailto:[e-mail]] On Behalf Of
>> Peter Psenak (ppsenak)
>> Sent: Friday, June 28, 2013 6:29 AM
>> To: Acee Lindem
>> Cc: [e-mail]
>> Subject: Re: [OSPF] OSPFv3 LSA Extendibility -
>>draft-acee-ospfv3-lsa-extend-
>> 00.txt
>> 
>> Hi Acee,
>> 
>> On 28.6.2013 11:44, Acee Lindem wrote:
>> > Hi Anton, Peter,
>> > If I were to be convinced that #2 is the way to go, I like making it
>>explicit
>> configurations and only applicable to service provider and large
>>enterprise
>> deployments. That way, OSPFv3 implementations specifically for the
>> homenet environments could omit it.
>> 
>> I'm fine with the config based approach.
>> 
>> thanks,
>> Peter
>> 
>> > Thanks,
>> > Acee
>> > On Jun 28, 2013, at 4:00 AM, Anton Smirnov wrote:
>> >
>> >>    Hi Acee,
>> >>    while I appreciate developer's simplicity of option 1 this
>>approach is good
>> only for greenfield deployment. For any existing sizable OSPFv3 network
>>its
>> migration limitation may become an insurmountable obstacle.
>> >>    My preference is combination of options: start migration as
>>option 2 and
>> when migration is completed lock on 1.
>> >>    Benefits are that migration is possible; LSDB is doubled only for
>>period of
>> migration; and once migration is completed there is no need to worry
>>about
>> dynamics of old-style router entering the domain.
>> >>    Downside is relative complexity of implementation but that's the
>>price
>> to pay for simplicity of OSPFv3. BTW, entering and exiting migration
>>may be
>> manual (via configuration), so this mixed approach may be simpler to
>> implement than 'pure' option 3.
>> >>    Said all that, individual products targeting greenfield deployment
>> scenario may skip implementation of migration. Say, homenet may require
>> support of extended LSAs from day 1. That would mean that homenet
>> products will not be deployable in existing old-style-LSA networks -
>>but that
>> probably is not the intent anyway.
>> >>
>> >> Anton
>> >>
>> >>
>> >> On 06/27/2013 10:18 PM, Acee Lindem wrote:
>> >>> I don't think there is much disagreement that we need a direct way
>> >>> to extend the base OSPFv3 LSAs and I will be presenting this draft
>> >>> at IETF
>> >>> 87 in Berlin. Where there appears to be some amount of disagreement
>> >>> is in the backward compatibility mechanisms. There are basically 3
>> >>> options (as well as subtle variants)
>> >>>
>> >>>
>> >>>          1. The approach in the draft, only allow adjacencies
>> >>> between routers supporting the extended encodings. Backward
>> >>> compatibility would have to be provided with separate instances and
>> topology.
>> >>>
>> >>>         2. Both the current and extended versions of the LSAs are
>> >>> originated as long as there are routers not supporting the new
>> >>> extended encodings at the respective flooding scope. This was the
>> >>> approach taken in "Multi-toplogy routing in OSPFv3 (MT-OSPFV3)",
>> >>> draft-ietf-ospf-mt-ospfv3-04.txt. However, it has the undesirable
>> >>> property of roughly doubling the size of the LSDB.
>> >>>
>> >>>        3. Switch to the extended format only after all the routers
>> >>> at the flooding scope support it. Use OSPF demand circuit-like (RFC
>> >>> 1793) signaling to determine whether or not all routers in the
>> >>> flooding scope support the new format. The only potential problem
>> >>> with this approach is a dynamics when a router not supporting the
>> >>> extended format successively leaves and enters the routing domain.
>> >>>
>> >>> What is the WG preference? I'm still in favor of the approach in the
>> >>> draft (#1) given the simplicity and stability properties. What we'd
>> >>> lose in slowed deployment would be more than made up
>> standardization
>> >>> and availability. Also, it would satisfy the homenet requirements we
>> >>> desperately need to satisfy.
>> >>>
>> >>> Thanks,
>> >>> Acee
>> >>>
>> >>>
>> >>>
>> >>> _______________________________________________
>> >>> OSPF mailing list
>> >>> [e-mail]
>> >>> https://www.ietf.org/mailman/listinfo/ospf
>> >>>
>> >> _______________________________________________
>> >> OSPF mailing list
>> >> [e-mail]
>> >> https://www.ietf.org/mailman/listinfo/ospf
>> >
>> >
>> >
>> 
>> 
>> _______________________________________________
>> OSPF mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/ospf
>_______________________________________________
>OSPF mailing list
>[e-mail]
>https://www.ietf.org/mailman/listinfo/ospf