Re: [OSPF] Notes on draft-acee-ospfv3-lsa-extend-02.txt

[Acee Lindem <[e-mail]>]

Hi Anton, 

Thanks for the review. 

On Sep 17, 2013, at 9:23 AM, Anton Smirnov wrote:

>    Hi,
>    a few notes on current revision of ELSA draft  (starting from editorial going to more important).
> 
> Cosmetic notes:
> 
>> 6.  OSPFv3 E-Inter-Area-Prefix-LSA
>> ...
>>    All LSA Header fields are the same as defined for the Network-LSA.
> 
> Should be IAP LSA.

Yup. Good catch. 


> 
> 
>> Lindem, et al.           Expires March 14, 2014                [Page 20]
>> 
>> Internet-Draft          OSPFv3 LSA Extendibility          September 2013
>> 
>> 
>>    families as defined in [OSPFV3-AF].  The IPv6 Link-Local Address TLV
>>    is only applicable to the E-Link-LSA.  Inclusion in other Extended
>>    LSAs MUST be ignored.  Only a single instance of the IPv6 Link-Local
>>    Address family SHOULD be included in the E-Link-LSA.  Instances
>>    preceding the first MUST be ignored.
> 
> It is probably meant to be "instances following the first ..."

Yes. 


> 
> 
> 
> Page 21:
>>    Address family SHOULD be included in the E-Link-LSA.  Instances
>>    preceding the first MUST be ignored.  For IPv6 address families as
>>    defined in [OSPFV3-AF]. 
> Incomplete sentence.

Thanks - I've fixed this sentence to indicate that the TLV will be ignored for OSPFv3 IPv6 address families. 

> 
> 
>>    For simplicity and to avoid the scaling impact of maintaining both
>>    TLV and non-TLV based versions of the same LSA within a routing
>>    domain, the basic backward compatibility mode will not allow mixing
>>    of LSA formats. Different formats could still be supported with
>>    multiple OSPFv3 instances and separate OSPFv3 routing domains.
> "Basic compatibility mode" is confusing name for a mode when instance enabled with new functionality will not even talk to instance not enabled for (or not supporting) it.

There are many ways to provide compatibility. One is to not allow incompatible neighbor to form adjacencies. 

> 
> 
> 
> Notes to functionality:
> 
> Tag field in E-ASE-LSAs is made optional.
> Subject of propagating tags together with Intra- and Inter- area routes was raised more than once. It is very likely that sooner or later tag sub-TLVs will be proposed for Intra- and Inter- Area E-LSA. In this case implementations will have to deal with optional tag field in E-ASE LSA and tag sub-TLV in Intra-/Inter- Prefix TLV. This is inconvenient. It is better to avoid optional field in E-ASE-LSA and define tag sub-TLV for External-Prefix TLV from the beginning.

I agree that this would clean up the encoding. However, if an implementation already supports the AS-External-LSA, they need to support the optional tag and forwarding address anyway. With respect to future tags, I see the E-AS-External LSA as always having more affinity with the AS-External-LSA than other LSAs where tags would be specified. 
> 
> 
> 
>>    In order to retain compatibility and semantics with the current
>>    OSPFv3 specification, each LSA MUST contain a single Inter-Area
>>    Prefix TLV.  This will facilitate migration and avoid changes to
>>    functions such as incremental SPF computation.
> I appreciate ease of migration. OTOH, for better or worse but E-Intra-Area-Prefix LSA can propagate multiple prefixes in single LSA. So well-developed implementation will have to be able to work with an LSA advertising multiple prefixes. It is a pity to restrict once and forever Inter- and Ex- Prefix TLVs if Intra- does not have such limitation.
>    To give implementations possibility of future optimizations (advertising multiple prefixes in single LSA) and still keep advantage of faster standardization and deployment I propose:
> - Allow Inter- and Ex- TLVs to be present more than once in respective LSAs
> - Stipulate that routers running in any Migration mode MUST advertise TLV only once per LSA.

We can discuss further in an E-mail thread just on this subject. The goal of this draft is to get OSPFv3 to flexible LSA format as quickly as possible. Hence, changes are kept to what is necessary. Since you are an implementer, you can appreciate that this is much more than an encoding change as it changes the underlying semantics of the LSAs impacting areas including incremental route computation, summary route origination in ABRs, and NSSA translation. As for migration, we certainly don't want more than  one level of encoding. However, I think we are open to discussions. 

Thanks,
Acee 











> 
> Thanks,
> 
> Anton
> 
> 
> 
> _______________________________________________
> OSPF mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/ospf