Re: [OSPF] FW: New Version Notification for draft-ietf-ospf-ospfv3-lsa-extend-02.txt

[Peter Psenak <[e-mail]>]

Hi Acee,

I do not see any problem with routers with various compatibility modes 
living in area/network together. With all the modes we have, we provide 
the possibility of graceful migration from old to new LSA types. I don't 
think we need to restrict any combination. Sure, if someone mix "full" 
and "none", then it can not expect the full reachability between them, 
but that does not mean we have to prohibit it.

Separate routing is the possibility, but probably not the easiest one. I 
would certainly not enforce it as the only possibility.

thanks,
Peter

On 4/18/14 18:22 , Acee Lindem wrote:
> Hi Peter,
> You are correct - I’d thought about these situations myself but didn’t strike this statement. I’m thinking I will remove this and discuss the options of separate routing domains in more detail.
> Thanks,
> Acee
> On Apr 18, 2014, at 12:18 PM, Peter Psenak <[e-mail]> wrote:
>
>> Hi Acee,
>>
>> quote From section (5):
>>
>>    "In this manner, OSPFv3 routers using new encodings can be
>>    completely isolated from those OSPFv3 routers depending on the RFC
>>    5340 encoding and not setting their options field EL-bits since the
>>    default setting indicates no support for extended LSAs."
>>
>> Even though you prevent adjacency to be formed between routers with certain compatibility modes, it still does not prevent all modes to coexist in the area/network.
>>
>> Let's imagine you have a chain of routers with following modes:
>>
>> Full---MixedModeOriginateSPF----MixedModeOriginateOnly-----None
>>
>>
>> thanks,
>> Peter
>>
>> On 4/18/14 17:58 , Acee Lindem wrote:
>>> All,
>>> This version has been reorganized to separate the definitions of the TLVs
>>> and sub-TLVs from the Extended LSAs (Alan Davey's suggestion).
>>> It also includes the changes to the compatibility section discussed during
>>> the OSPF WG meeting in London (David Lamparter's input).
>>> Thanks,
>>> Acee
>>>
>>> On 4/18/14 8:36 AM, "[e-mail]" <[e-mail]>
>>> wrote:
>>>
>>>>
>>>> A new version of I-D, draft-ietf-ospf-ospfv3-lsa-extend-02.txt
>>>> has been successfully submitted by Acee Lindem and posted to the
>>>> IETF repository.
>>>>
>>>> Name:		draft-ietf-ospf-ospfv3-lsa-extend
>>>> Revision:	02
>>>> Title:		OSPFv3 LSA Extendibility
>>>> Document date:	2014-04-18
>>>> Group:		ospf
>>>> Pages:		35
>>>> URL:
>>>> http://www.ietf.org/internet-drafts/draft-ietf-ospf-ospfv3-lsa-extend-02.t
>>>> xt
>>>> Status:
>>>> https://datatracker.ietf.org/doc/draft-ietf-ospf-ospfv3-lsa-extend/
>>>> Htmlized:
>>>> http://tools.ietf.org/html/draft-ietf-ospf-ospfv3-lsa-extend-02
>>>> Diff:
>>>> http://www.ietf.org/rfcdiff?url2=draft-ietf-ospf-ospfv3-lsa-extend-02
>>>>
>>>> Abstract:
>>>>    OSPFv3 requires functional extension beyond what can readily be done
>>>>    with the fixed-format Link State Advertisement (LSA) as described in
>>>>    RFC 5340.  Without LSA extension, attributes associated with OSPFv3
>>>>    links and advertised IPv6 prefixes must be advertised in separate
>>>>    LSAs and correlated to the fixed-format LSAs.  This document extends
>>>>    the LSA format by encoding the existing OSPFv3 LSA information in
>>>>    Type-Length-Value (TLV) tuples and allowing advertisement of
>>>>    additional information with additional TLVs.  Backward compatibility
>>>>    mechanisms are also described.
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> Please note that it may take a couple of minutes from the time of
>>>> submission
>>>> until the htmlized version and diff are available at tools.ietf.org.
>>>>
>>>> The IETF Secretariat
>>>>
>>>
>>> _______________________________________________
>>> OSPF mailing list
>>> [e-mail]
>>> https://www.ietf.org/mailman/listinfo/ospf
>>>
>>
>
> .
>