Subject: [spring] Clarification on Instance in draft-ietf-ospf-prefix-link-attr-03.txt

From: Santanu Kar <[email-masked]>
Date: Wed, 25 Mar 2015 18:38:12 +0530

Hi Authors

The Section 2, doesn't provide any clarification on the 'Instance' part of
the Link ID of
OSPFv2 Extended Prefix Opaque LSA.

There can be two possible implementations

1) When a Segment routing enabled router is advertising multiple Ext Prefix
TLV, it can keep repacking it into a single Ext Prefix LSA, as has been
mentioned in end of section 2 and keep increasing the instance . The lowest
instance is taken. Higher instance from same router for same prefix is
ignored.

2) Another possible way is, not to go for this repacking. Instead it should
be possible to originate separate Ext Prefix LSAs for every Ext Prefix TLV,
and only one TLV per LSA. The instance number or Opaque id can be derived
from the prefix/interface so as to ensure its unique for every prefix
originating from the same advertising router.

The draft is not clear on whether (2) can be allowed. It hasn't mentioned
that the instance is topology independent and dependent on how we choose to
implement it. The TE RFC however has a section devoted to this
https://tools.ietf.org/html/rfc3630#section-2.2

Please give your thoughts on this.

Regards
Santanu

---

From: Peter Psenak <[email-masked]>
Date: Wed, 25 Mar 2015 14:33:16 +0100

Hi Santanu,

On 3/25/15 14:08 , Santanu Kar wrote:
> Hi Authors
>
> The Section 2, doesn't provide any clarification on the 'Instance' part
> of the Link ID of

Instance is an arbitrary number to make each OSPFv2 Extended Prefix 
Opaque LSA's LSID unique, please see RFC5250, section abut Opaque-ID.

> 1) When a Segment routing enabled router is advertising multiple Ext
> Prefix TLV, it can keep repacking it into a single Ext Prefix LSA, as
> has been mentioned in end of section 2 and keep increasing the instance
> . The lowest instance is taken. Higher instance from same router for
> same prefix is ignored.

above only applies to the case where OSPFv2 Extended Prefix TLV is 
advertised for the _same_ prefix in multiple different OSPFv2 Extended 
Prefix Opaque LSAs, which is either an error or temporary condition.

>
> 2) Another possible way is, not to go for this repacking. Instead it
> should be possible to originate separate Ext Prefix LSAs for every Ext
> Prefix TLV, and only one TLV per LSA. The instance number or Opaque id
> can be derived from the prefix/interface so as to ensure its unique for
> every prefix originating from the same advertising router.

yes above is correct, but the draft allows to pack multiple Ext
Prefix TLVs in the single Extended Prefix Opaquer LSA if the 
implementation prefers to do so.

>
> The draft is not clear on whether (2) can be allowed. It hasn't

the draft says:

Multiple OSPF Extended Prefix TLVs MAY be advertised in each OSPFv2 
Extended Prefix Opaque LSA."

That means it can be one or more.

> mentioned that the instance is topology independent and dependent on how
> we choose to implement it. The TE RFC however has a section devoted to this

I can add a similar text to draft-ietf-ospf-prefix-link-attr.

thanks,
Peter

---

From: Santanu Kar <[email-masked]>
Date: Mon, 30 Mar 2015 12:37:43 +0530

Hi Peter

Thanks for the clarification.

I still do not completely agree that scenario (1) is a 'error or temporary
condition'.

Scenario A: Lets consider we have a network of routers and each router has
48 ports and OSPF routing enabled on all. We want to replace LDP in the
network and have Prefix Segment based label  mappings for all prefixes in
the network. So while configuring for the first time, each prefix with a
prefix SID one by one, OSPF will send out 48 Ext Prefix LSAs. The first one
will have only one Prefix TLV, the next one two, and subsequent ones keep
adding the additional Prefix TLVs and repacking into the LSA. All the LSAs
will keep having incremental instance. So the first prefix is advertised 48
times by the same router in different Ext Prefix LSAs.

There are few more scenarios that needs to be considered for
Multiple-Prefix TLV .Consider the following.

Scenario B: Withdrawing of Prefix TLV. If on a particular router the prefix
SID configured for one of its prefixes is unconfigured, the router needs to
withdraw that specific Prefix TLV from the OSPF network. If this Prefix TLV
was part of one or more LSA as described in scenario A, then all such LSAs
needs to be withdrawn by issuing a LSA of MaxAge. Also since each LSA has
multiple Prefix TLVs , all other Prefix-TLVs in that LSA will also get
effected. This is undesirable. Even if there is no duplicate prefix TLVs
across LSAs, this problem is applicable for the LSA which is withdrawn.

I propose the following solutions for this problem.
i) The Ext Prefix LSA can have a fixed instance number associated with it.
Whenever a prefix-TLV is received, as part of any Ext Prefix LSA, it needs
to check for any modifications from the previous LSA. If none, it will
ignore that prefix-TLV. Else it will be updated. In this way, even if a
particular prefix-TLV is sent multiple times , and the latest one is
considered as per the age of LSA, it will have no impact internally on the
routes corresponding to that Prefix. Also it will significantly reduce the
Link State Database to be maintained, and it will always be one per router.
Any new prefix TLV in the new LSA will be added, and if any prefix TLV
previously advertised is missing, will be removed.

ii) The Ext Prefix LSA can allow only a single Top Level TLV per LSA. Here
announcing new Prefix and its withdraw can happen individually and will be
a much simpler approach. This is similar to approach followed in OSPF TE (
https://tools.ietf.org/html/rfc3630#section-2.4)

Regards
Santanu

On Wed, Mar 25, 2015 at 7:03 PM, Peter Psenak <[email-masked]> wrote:

> Instance is an arbitrary number to make each OSPFv2 Extended Prefix Opaque
> LSA's LSID unique, please see RFC5250, section abut Opaque-ID.
>
>

-- 
Best Regards
Santanu Kar
----------------------------------------------------------------------------------------------
When you really want something to happen, the whole universe
conspires so that your wish comes true
----------------------------------------------------------------------------------------------

---

From: Peter Psenak <[email-masked]>
Date: Mon, 30 Mar 2015 10:03:32 +0200

Santanu,

On 3/30/15 09:07 , Santanu Kar wrote:
> I still do not completely agree that scenario (1) is a 'error or
> temporary condition'.
>
> Scenario A: Lets consider we have a network of routers and each router
> has 48 ports and OSPF routing enabled on all. We want to replace LDP in
> the network and have Prefix Segment based label  mappings for all
> prefixes in the network. So while configuring for the first time, each
> prefix with a prefix SID one by one, OSPF will send out 48 Ext Prefix
> LSAs. The first one will have only one Prefix TLV, the next one two, and

more specifically, it will send 48 instances if the same LSA.

> subsequent ones keep adding the additional Prefix TLVs and repacking
> into the LSA. All the LSAs will keep having incremental instance. So the
> first prefix is advertised 48 times by the same router in different Ext
> Prefix LSAs.

yes, what is wrong with the above? The exact same thing happens with 
Router LSA today. If you do not like it, your implementation can 
generate a dedicated Ext. Prefix LSA for each prefix. Both ways are 
allowed. But your implementation MUST be able to deal with the received 
Ext. Prefix LSAs that have multiple Ext Prefix TLVs.

> Scenario B: Withdrawing of Prefix TLV. If on a particular router the
> prefix SID configured for one of its prefixes is unconfigured, the
> router needs to withdraw that specific Prefix TLV from the OSPF network.
> If this Prefix TLV was part of one or more LSA as described in scenario

each prefix should be only advertised in a single Ext Prefix LSA...

> A, then all such LSAs needs to be withdrawn by issuing a LSA of MaxAge.
> Also since each LSA has multiple Prefix TLVs , all other Prefix-TLVs in
> that LSA will also get effected. This is undesirable. Even if there is
> no duplicate prefix TLVs across LSAs, this problem is applicable for the
> LSA which is withdrawn.

what you described above is incorrect. When Ext Prefix LSA has multiple 
Ext Prefix TLVs and you want to remove one of them, you simply 
regenerate the Ext Prefix LSA without the Ext Prefix TLV that 
corresponds to that prefix and keep the rest of the Ext Prefix TLVs in 
the LSA - these prefixes are NOT affected.

> i) The Ext Prefix LSA can have a fixed instance number associated with

above is by definition - Instance (or Opaque-ID), is part of the LSID, 
which together with the Adv-Rtr-ID uniquely identifies the LSA itself.

> it. Whenever a prefix-TLV is received, as part of any Ext Prefix LSA, it
> needs to check for any modifications from the previous LSA. If none, it
> will ignore that prefix-TLV. Else it will be updated. In this way, even
> if a particular prefix-TLV is sent multiple times , and the latest one
> is considered as per the age of LSA, it will have no impact internally
> on the routes corresponding to that Prefix. Also it will significantly
> reduce the Link State Database to be maintained, and it will always be
> one per router. Any new prefix TLV in the new LSA will be added, and if
> any prefix TLV previously advertised is missing, will be removed.
>

none of the above needs to be standardized. Base OSPF spec specifies 
that newer version of LSA replaces the old one. The way you deal with it 
is up to you. The only requirement is that you only use info that is in 
the latest version of the LSA.

> ii) The Ext Prefix LSA can allow only a single Top Level TLV per LSA.

no, we want to have the flexibility in packing the single or multiple 
TLVs in the Ext Prefix LSA.

regards,
Peter

> Here announcing new Prefix and its withdraw can happen individually and
> will be a much simpler approach. This is similar to approach followed in
> OSPF TE (https://tools.ietf.org/html/rfc3630#section-2.4)
>
> Regards
> Santanu
>
> On Wed, Mar 25, 2015 at 7:03 PM, Peter Psenak <[email-masked]
> <mailto:[email-masked]>> wrote:
>
>     Hi Santanu,
>
>     advertised for the _same_ prefix in multiple different OSPFv2
>     Extended Prefix Opaque LSAs, which is either an error or temporary
>     condition.
>
>
>
>         https://tools.ietf.org/html/__rfc3630#section-2.2
>         <https://tools.ietf.org/html/rfc3630#section-2.2>
>
>
>     I can add a similar text to draft-ietf-ospf-prefix-link-__attr.
>
>
>     thanks,
>     Peter
>
>
>

---

From: Santanu Kar <[email-masked]>
Date: Mon, 30 Mar 2015 19:23:50 +0530

Hi Peter

Yeah, I understand that for updates of Ext Prefix LSA (when we are
adding/modifying/deleting Prefix TLVs) if we keep the Link ID (Type number,
Opaque ID/Instance) same, then by general OSPF rules we will take only the
latest LSA , and scenarios mentioned above will work perfectly. When the
link ID remains same, the working is very similar to the router LSA.

My only concern is on the text which talks about different instances of Ext
Prefix LSA from same router.

If this TLV is advertised multiple times for the same prefix in
   different OSPFv2 Extended Prefix Opaque LSAs originated by the same
   OSPF router, the OSPF advertising router is re-originating Extended
   Prefix Opaque LSAs for multiple prefixes and is most likely repacking
   Extended-Prefix-TLVs in Extended Prefix Opaque LSAs.  In this case,
   the Extended-Prefix-TLV in the Extended Prefix Opaque LSA with the
   smallest Instance is used by receiving OSPFv2 Routers.  This
   situation MAY be logged as a warning.

What are the conditions on which a router will generate different
instances (in effect different link IDs) of Ext Prefix LSA?

So if there are say 5 prefix TLVs to send, the router can choose to send
i) All in one LSA, or
ii)Send 2 TLVs in one instance and 3 in other, or may be even

iii) 5 LSAs each having one TLV  ?

Regards

Santanu

On Mon, Mar 30, 2015 at 1:33 PM, Peter Psenak <[email-masked]> wrote:

> Router LSA today. If you do not like it, your implementation can generate a
> dedicated Ext. Prefix LSA for each prefix. Both ways are allowed. But your
> implementation MUST be able to deal with the received Ext. Prefix LSAs that
> have multiple Ext Prefix TLVs.
>
>
> Ext Prefix TLVs and you want to remove one of them, you simply regenerate
> the Ext Prefix LSA without the Ext Prefix TLV that corresponds to that
> prefix and keep the rest of the Ext Prefix TLVs in the LSA - these prefixes
> are NOT affected.
>
>
> none of the above needs to be standardized. Base OSPF spec specifies that
> newer version of LSA replaces the old one. The way you deal with it is up
> to you. The only requirement is that you only use info that is in the
> latest version of the LSA.
>
> no, we want to have the flexibility in packing the single or multiple TLVs
> in the Ext Prefix LSA.
>
> regards,
> Peter
>
>
>

---

From: Peter Psenak <[email-masked]>
Date: Mon, 30 Mar 2015 16:08:41 +0200

Santanu,

On 3/30/15 15:53 , Santanu Kar wrote:
> adding/modifying/deleting Prefix TLVs) if we keep the Link ID (Type
> number, Opaque ID/Instance) same, then by general OSPF rules we will
> take only the latest LSA , and scenarios mentioned above will work
> perfectly. When the link ID remains same, the working is very similar to
> the router LSA.
>
> My only concern is on the text which talks about different instances of
> Ext Prefix LSA from same router.
>
>
> What are the conditions on which a router will generate different instances (in effect different link IDs) of Ext Prefix LSA?
>

any combination is allowed. Each prefix should only be present in a 
single LSA.

Temporarily, during repacking, same prefix may be present in multiple 
LSA, in which case the above paragraph applies.

thanks,
Peter
>
>
> Regards
>
> Santanu
>
>
>
> On Mon, Mar 30, 2015 at 1:33 PM, Peter Psenak <[email-masked]
>     allowed. But your implementation MUST be able to deal with the
>     received Ext. Prefix LSAs that have multiple Ext Prefix TLVs.
>
>
>     what you described above is incorrect. When Ext Prefix LSA has
>     multiple Ext Prefix TLVs and you want to remove one of them, you
>     simply regenerate the Ext Prefix LSA without the Ext Prefix TLV that
>     corresponds to that prefix and keep the rest of the Ext Prefix TLVs
>     in the LSA - these prefixes are NOT affected.
>
>
>     above is by definition - Instance (or Opaque-ID), is part of the
>     LSID, which together with the Adv-Rtr-ID uniquely identifies the LSA
>     itself.
>
>     that newer version of LSA replaces the old one. The way you deal
>     with it is up to you. The only requirement is that you only use info
>     that is in the latest version of the LSA.
>
>     no, we want to have the flexibility in packing the single or
>     multiple TLVs in the Ext Prefix LSA.
>
>     regards,
>     Peter
>
>
>
>         OSPF TE (https://tools.ietf.org/html/__rfc3630#section-2.4
>         <https://tools.ietf.org/html/rfc3630#section-2.4>)
>
>         Regards
>         Santanu
>
>         <mailto:[email-masked]>
>         <mailto:[email-masked] <mailto:[email-masked]>>> wrote:
>
>              Hi Santanu,
>
>                  Prefix TLV, it can keep repacking it into a single Ext
>         Prefix
>                  LSA, as
>                  has been mentioned in end of section 2 and keep
>         increasing the
>                  instance
>                  should be possible to originate separate Ext Prefix
>         LSAs for
>                  every Ext
>                  Prefix TLV, and only one TLV per LSA. The instance
>         number or
>                  Opaque id
>                  can be derived from the prefix/interface so as to
>         ensure its
>                  unique for
>         https://tools.ietf.org/html/____rfc3630#section-2.2
>         <https://tools.ietf.org/html/__rfc3630#section-2.2>
>                  <https://tools.ietf.org/html/__rfc3630#section-2.2
>         <https://tools.ietf.org/html/rfc3630#section-2.2>>
>
>
>              I can add a similar text to
>         draft-ietf-ospf-prefix-link-____attr.
>
>
>              thanks,
>              Peter
>
>
>
>         ------------------------------__------------------------------__------------------------------__----
>         ------------------------------__------------------------------__------------------------------__----
>
>
>
>
>
> --
> Best Regards
> Santanu Kar

---

From: Santanu Kar <[email-masked]>
Date: Tue, 31 Mar 2015 08:41:59 +0530

Hi Peter

Yeah, its quite clear now.
The Link ID is very essential to the Link State DB design. So I would
request you to add more clarifications on the text, and possibly have one
section on the Link ID , and highlight the various possible ways it can be
used. Currently the only text appearing on the link id is the different
instances scenario of repacking, which is somewhat misleading, regarding
the other ways which are also allowed .
As an implementation can choose to have a i)single link id or instance and
pack all TLVs within it or ii) optionally have different link ids and
distribute the TLVs among the instances, or iii) may even have one instance
for every TLV. The receiver should be able to handle all modes.

Regards
Santanu

On Mon, Mar 30, 2015 at 7:38 PM, Peter Psenak <[email-masked]> wrote:

> any combination is allowed. Each prefix should only be present in a single
> LSA.
>
> Temporarily, during repacking, same prefix may be present in multiple LSA,
> in which case the above paragraph applies.
>
> thanks,
> Peter
>
>>
>>
>> Regards
>>
>> Santanu
>>
>>
>>
>>                  we choose to implement it. The TE RFC however has a
>> section
>>                  devoted to this