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 <[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
