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

Great Peter - I'll discuss with my co-authors and update before cut-off.
Thanks,
Acee

On 6/28/13 6:29 AM, "Peter Psenak" <ppsenak@cisco.com> wrote:

>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
>>>> OSPF@ietf.org
>>>> https://www.ietf.org/mailman/listinfo/ospf
>>>>
>>> _______________________________________________
>>> OSPF mailing list
>>> OSPF@ietf.org
>>> https://www.ietf.org/mailman/listinfo/ospf
>>
>>
>>
>
>