Subject: [OSPF] OSPFv3 LSA Extendibility - draft-acee-ospfv3-lsa-extend-00.txt

From: Acee Lindem <[email-masked]>
Date: Thu, 27 Jun 2013 20:18:00 +0000

I don't think there is much disagreement that we need a direct way to extend the base OSPFv3 LSAs and I will be presenting this draft at IETF 87 in Berlin. Where there appears to be some amount of disagreement is in the backward compatibility mechanisms. There are basically 3 options (as well as subtle variants)

        1. The approach in the draft, only allow adjacencies between routers supporting the extended encodings. Backward compatibility would have to be provided with separate instances and topology.

       2. Both the current and extended versions of the LSAs are originated as long as there are routers not supporting the new extended encodings at the respective flooding scope. This was the approach taken in "Multi-toplogy routing in OSPFv3 (MT-OSPFV3)", draft-ietf-ospf-mt-ospfv3-04.txt. However, it has the undesirable property of roughly doubling the size of the LSDB.

      3. Switch to the extended format only after all the routers at the flooding scope support it. Use OSPF demand circuit-like (RFC 1793) signaling to determine whether or not all routers in the flooding scope support the new format. The only potential problem with this approach is a dynamics when a router not supporting the extended format successively leaves and enters the routing domain.

What is the WG preference? I'm still in favor of the approach in the draft (#1) given the simplicity and stability properties. What we'd lose in slowed deployment would be more than made up standardization and availability. Also, it would satisfy the homenet requirements we desperately need to satisfy.

Thanks,
Acee

---

From: Michael Barnes <[email-masked]>
Date: Thu, 27 Jun 2013 13:28:28 -0700

My preference would be for Option 2. This will allow the new LSAs to be 
used for enhancements that we have not yet envisioned. Regarding the 
doubling of the LSDB size, I would say that there should be 
configuration options on whether the new LSAs should be used so that an 
operator can control this. It would allow an operator to keep the new 
LSAs from being originated until all of the routers can originate them. 
On the other hand, another operator might have a need for new LSAs 
before the area fully supports them and choose to live with the 
increased LSDB size. IMHO that flexibility is very desirable.

I would also say that the U bit should be set. This would allow, for 
example, the External LSA to be enhanced to carry some information that 
would only be of interest to another ASBR or an ABR, and it wouldn't 
matter if other routers understood it.

Regards,
Michael

On 06/27/2013 01:18 PM, Acee Lindem wrote:
> I don't think there is much disagreement that we need a direct way to
> extend the base OSPFv3 LSAs and I will be presenting this draft at IETF
> 87 in Berlin. Where there appears to be some amount of disagreement is
> in the backward compatibility mechanisms. There are basically 3 options
> (as well as subtle variants)
>
>
>          1. The approach in the draft, only allow adjacencies between
> routers supporting the extended encodings. Backward compatibility would
> have to be provided with separate instances and topology.
>
>         2. Both the current and extended versions of the LSAs are
> originated as long as there are routers not supporting the new extended
> encodings at the respective flooding scope. This was the approach taken
> in "Multi-toplogy routing in OSPFv3 (MT-OSPFV3)",
> draft-ietf-ospf-mt-ospfv3-04.txt. However, it has the undesirable
> property of roughly doubling the size of the LSDB.
>
>        3. Switch to the extended format only after all the routers at
> the flooding scope support it. Use OSPF demand circuit-like (RFC 1793)
> signaling to determine whether or not all routers in the flooding scope
> support the new format. The only potential problem with this approach is
> a dynamics when a router not supporting the extended format successively
> leaves and enters the routing domain.
>
> What is the WG preference? I'm still in favor of the approach in the
> draft (#1) given the simplicity and stability properties. What we'd lose
> in slowed deployment would be more than made up standardization and
> availability. Also, it would satisfy the homenet requirements we
> desperately need to satisfy.
>
> Thanks,
> Acee
>
>
>
> _______________________________________________
> OSPF mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ospf
>

---

From: Peter Psenak <[email-masked]>
Date: Thu, 27 Jun 2013 22:43:42 +0200

Hi Acee,

my preference is option (2).

thanks,
Peter

---

From: Acee Lindem <[email-masked]>
Date: Thu, 27 Jun 2013 20:53:08 +0000

Peter, Michael, 
I guess you guys have considered the complexity this adds. For example,
you now need rules for LSDB entry selection during the SPF given that the
calculation will now have to handle a mix of extended and non-extended
LSAs. #2 is actually my least favorite of the three options given the
complexity it burdens us with forever.

Acee

---

From: Peter Psenak <[email-masked]>
Date: Thu, 27 Jun 2013 23:42:55 +0200

Hi Acee,

yes, I have considered the complexity of (2). On the other hand (2) is 
also the most flexible one from the deployment perspective. It allows 
you to use new LSAs to advertise some new attributes for a link/prefix, 
while keeping the old LSA for what you use them today. Later when all 
routers understand the new format old LSAs can be removed.

Option (1) is not a realistic one from the deployment perspective IMHO.

thanks,
Peter

---

From: Anton Smirnov <[email-masked]>
Date: Fri, 28 Jun 2013 10:00:22 +0200

Hi Acee,
    while I appreciate developer's simplicity of option 1 this approach 
is good only for greenfield deployment. For any existing sizable OSPFv3 
network its migration limitation may become an insurmountable obstacle.
    My preference is combination of options: start migration as option 2 
and when migration is completed lock on 1.
    Benefits are that migration is possible; LSDB is doubled only for 
period of migration; and once migration is completed there is no need to 
worry about dynamics of old-style router entering the domain.
    Downside is relative complexity of implementation but that's the 
price to pay for simplicity of OSPFv3. BTW, entering and exiting 
migration may be manual (via configuration), so this mixed approach may 
be simpler to implement than 'pure' option 3.
    Said all that, individual products targeting greenfield deployment 
scenario may skip implementation of migration. Say, homenet may require 
support of extended LSAs from day 1. That would mean that homenet 
products will not be deployable in existing old-style-LSA networks - but 
that probably is not the intent anyway.

Anton

---

From: Acee Lindem <[email-masked]>
Date: Fri, 28 Jun 2013 05:44:25 -0400

Hi Anton, Peter, 
If I were to be convinced that #2 is the way to go, I like making it explicit configurations and only applicable to service provider and large enterprise deployments. That way, OSPFv3 implementations specifically for the homenet environments could omit it. 
Thanks,
Acee
On Jun 28, 2013, at 4:00 AM, Anton Smirnov wrote:

>   Hi Acee,
>   while I appreciate developer's simplicity of option 1 this approach is good only for greenfield deployment. For any existing sizable OSPFv3 network its migration limitation may become an insurmountable obstacle.
>   My preference is combination of options: start migration as option 2 and when migration is completed lock on 1.
>   Benefits are that migration is possible; LSDB is doubled only for period of migration; and once migration is completed there is no need to worry about dynamics of old-style router entering the domain.
>   Downside is relative complexity of implementation but that's the price to pay for simplicity of OSPFv3. BTW, entering and exiting migration may be manual (via configuration), so this mixed approach may be simpler to implement than 'pure' option 3.
>   Said all that, individual products targeting greenfield deployment scenario may skip implementation of migration. Say, homenet may require support of extended LSAs from day 1. That would mean that homenet products will not be deployable in existing old-style-LSA networks - but that probably is not the intent anyway.
> 
> Anton
> 
>

---

From: Anton Smirnov <[email-masked]>
Date: Fri, 28 Jun 2013 12:11:47 +0200

Hi Acee, Peter,
    IMO pure option 2 has its own problems. It is easy to imagine some 
future feature requiring all routers in the area understanding 
information the feature is sending in extended LSA. So if backward 
compatibility is preserved indefinitely then there is a risk of 
old-style-LSA router joining the domain and breaking the feature.
    That's why I think migration from the old-style LSA MUST be provided 
by the solution but solution should also define a point where backward 
compatibility is undesirable.
    Something like this:
0). Router is sending and using in SPF old-style LSA
1). Router is sending both old-style and extended LSAs but using only old
2). Router is sending both old-style and extended LSAs but using only 
extended
3). Router is sending and using only extended LSAs

Steps 1 and 2 are in fact option 2 from the original email and at step 3 
we arrived to option 1 but with gradual migration.

Anton

---

From: Acee Lindem <[email-masked]>
Date: Fri, 28 Jun 2013 12:41:22 +0000

Hi Anton,

On Jun 28, 2013, at 6:11 AM, Anton Smirnov wrote:

>   Hi Acee, Peter,
>   IMO pure option 2 has its own problems. It is easy to imagine some future feature requiring all routers in the area understanding information the feature is sending in extended LSA. So if backward compatibility is preserved indefinitely then there is a risk of old-style-LSA router joining the domain and breaking the feature.

Supporting the extended LSAs doesn't imply that the implementation will support all the attendant TLVs. Backward compatibility and/or partial deployment will need to be addressed in the documents defining the extensions using the TLVs. The backward compatibility problem for future extensions can't be solved here - this is about extendible encoding for the base OSPFv3 fixed format LSAs and nothing more.

Thanks,
Acee 

>   That's why I think migration from the old-style LSA MUST be provided by the solution but solution should also define a point where backward compatibility is undesirable.
>   Something like this:
> 2). Router is sending both old-style and extended LSAs but using only extended
> Steps 1 and 2 are in fact option 2 from the original email and at step 3 we arrived to option 1 but with gradual migration.
> 
> Anton
> 
>

---

From: Peter Psenak <[email-masked]>
Date: Fri, 28 Jun 2013 15:29:14 +0200

Hi Acee,

> If I were to be convinced that #2 is the way to go, I like making it explicit configurations and only applicable to service provider and large enterprise deployments. That way, OSPFv3 implementatio…

I'm fine with the config based approach.

thanks,
Peter

---

From: "Mike Dubrovskiy (mdubrovs)" <[email-masked]>
Date: Fri, 28 Jun 2013 20:55:43 +0000

Hi guys,

Does bellow looks like what you are saying ?

Two mode of operation:

RFC5340Compatibility is off (default)

In this mode router originates only new types of LSAs.
Router consider only new type of LSAs from other routers.
Router does not establish adjacencies with old routers. 

RFC5340Compatibility is on (non-default; need to be configured during transition). 

In this mode router originates both old and new types of LSA.
Router prefers new type of LSA for SPF calculation.
Router establish adjacencies with both types for routers.

Old format router LSA  has ExtendedFormatCapable flag set for the case when corresponded new format LSA stuck somewhere
When all old type  LSAs in the router database have ExtendedFormatCapable flag, router flushes self-originated LSA in old format.
The flag ExtendedFormatCapable  should be propagated across area borders similar to  OSPF demand circuit-like.

Thank you,
Mike

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of
> Peter Psenak (ppsenak)
> Sent: Friday, June 28, 2013 6:29 AM
> To: Acee Lindem
> Cc: [email-masked]
> Subject: Re: [OSPF] OSPFv3 LSA Extendibility - draft-acee-ospfv3-lsa-extend-
> 00.txt
> 
> Hi Acee,
> 
> > If I were to be convinced that #2 is the way to go, I like making it explicit
> configurations and only applicable to service provider and large enterprise
> deployments. That way, OSPFv3 implementations specifically for the
> homenet environments could omit it.
> 
> >>    while I appreciate developer's simplicity of option 1 this approach is good
> only for greenfield deployment. For any existing sizable OSPFv3 network its
> migration limitation may become an insurmountable obstacle.
> >>    Benefits are that migration is possible; LSDB is doubled only for period of
> migration; and once migration is completed there is no need to worry about
> dynamics of old-style router entering the domain.
> >>    Downside is relative complexity of implementation but that's the price
> to pay for simplicity of OSPFv3. BTW, entering and exiting migration may be
> manual (via configuration), so this mixed approach may be simpler to
> implement than 'pure' option 3.
> products will not be deployable in existing old-style-LSA networks - but that
> probably is not the intent anyway.
> >>
> >> Anton
> >>
> >>
> >>> I don't think there is much disagreement that we need a direct way
> >>> to extend the base OSPFv3 LSAs and I will be presenting this draft
> >>> at IETF
> >>> 87 in Berlin. Where there appears to be some amount of disagreement
> >>> is in the backward compatibility mechanisms. There are basically 3
> >>> options (as well as subtle variants)
> >>>
> >>>
> >>>          1. The approach in the draft, only allow adjacencies
> >>> between routers supporting the extended encodings. Backward
> >>> compatibility would have to be provided with separate instances and
> topology.
> >>>
> >>> originated as long as there are routers not supporting the new
> >>> extended encodings at the respective flooding scope. This was the
> >>> approach taken in "Multi-toplogy routing in OSPFv3 (MT-OSPFV3)",
> >>>        3. Switch to the extended format only after all the routers
> >>> at the flooding scope support it. Use OSPF demand circuit-like (RFC
> >>> 1793) signaling to determine whether or not all routers in the
> >>> flooding scope support the new format. The only potential problem
> >>> with this approach is a dynamics when a router not supporting the
> >>> extended format successively leaves and enters the routing domain.
> >>>
> >>> draft (#1) given the simplicity and stability properties. What we'd
> >>> lose in slowed deployment would be more than made up
> standardization
> >>> and availability. Also, it would satisfy the homenet requirements we

---

From: Acee Lindem <[email-masked]>
Date: Fri, 28 Jun 2013 21:19:45 +0000

Great Peter - I'll discuss with my co-authors and update before cut-off.
Thanks,
Acee

On 6/28/13 6:29 AM, "Peter Psenak" <[email-masked]> wrote:

>> If I were to be convinced that #2 is the way to go, I like making it
>>explicit configurations and only applicable to service provider and
>>large enterprise deployments. That way, OSPFv3 implementations
>>specifically for the homenet environments could omit it.
>
>>>    My preference is combination of options: start migration as option
>>>2 and when migration is completed lock on 1.
>>>period of migration; and once migration is completed there is no need
>>>to worry about dynamics of old-style router entering the domain.
>>>products will not be deployable in existing old-style-LSA networks -
>>>but that probably is not the intent anyway.
>>>
>>> Anton
>>>
>>>
>>>>lose

---

From: Acee Lindem <[email-masked]>
Date: Fri, 28 Jun 2013 21:22:57 +0000

Hi Mike, 
My first thought is that we'd make the dual LSA origination base on
configuration rather than based on the RFC 1793-esque signaling. I will
need to discuss with my co-authors.
Thanks,
Acee 

On 6/28/13 1:55 PM, "Mike Dubrovskiy (mdubrovs)" <[email-masked]>
wrote:

>Old format router LSA  has ExtendedFormatCapable flag set for the case
>when corresponded new format LSA stuck somewhere
>When all old type  LSAs in the router database have ExtendedFormatCapable
>flag, router flushes self-originated LSA in old format.
>>explicit
>> >>    My preference is combination of options: start migration as
>>option 2 and
>> when migration is completed lock on 1.
>>period of
>>price

---

From: Michael Barnes <[email-masked]>
Date: Fri, 28 Jun 2013 17:33:41 -0700

Hi Acee,

Here are some ideas you can consider to reduce the LSDB size and/or the 
complexity of the code.

You could require that any data advertised in an old LSA MUST also be 
advertised in a new LSA. That would reduce the complexity (since all old 
LSAs could be ignored) at the expense of LSDB size.

Alternately, you could allow a router an option of advertising the new 
LSA when it must advertise the old LSA. So in the case that the new LSA 
does not provide any additional information, and the router must 
originate the old LSA regardless, then the LSDB size is reduced without 
any loss of information, but obviously at the cost of complexity.

If it is optional for a router to advertise a new LSA as above, then it 
would be helpful, to reduce code complexity, to require that if the 
router does advertise both old and new LSAs, then a new LSA with the 
same type and LSID as the old must contain a superset of the information 
advertised in the old LSA. This way other routers can know when they can 
safely ignore the old LSA.

Regards,
Michael