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 <[email protected]> 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, "[email protected]" <[email protected]> >> 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 >> [email protected] >> https://www.ietf.org/mailman/listinfo/ospf >> > _______________________________________________ OSPF mailing list [email protected] https://www.ietf.org/mailman/listinfo/ospf
