Hi Peter, On Apr 18, 2014, at 12:57 PM, Peter Psenak <[email protected]> wrote:
> 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. I agree. > > Separate routing is the possibility, but probably not the easiest one. I > would certainly not enforce it as the only possibility. We started with this as the only migration mechanism. It is still one option and I will attempt to assure both migration paths are clear. Thanks, Acee > > 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 <[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
