Re: [Lsr] I-D Action: draft-ietf-lsr-isis-area-proxy-03.txt

[[e-mail]]

Hi Tony,

Thanks for your reply.
At this point, area proxy spec is clear with regards to nominal behavior. So indeed we are discussing error handling / transitions. (and thank you for considering those cases, much appreciated).

From memory, my understanding is the area proxy nominal behaviour requires:

-          All routers in the area are L1 & L2

-          All inside routers advertise the area proxy TLV

-          An area leader advertises the Area Proxy System Identifier Sub-TLV

If the above is not fulfilled, what is the expected behaviour? There is a priori 2 options:

-          A) Return to regular IS-IS behaviour. i.e. all L2 LSPs from inside routers are flooded to L2 outside routers

o   Pro: no new behaviour/code as this is regular IS-IS. Correct transit forwarding across the area.

o   Con: suddenly increase size of L2 LSDB

-          B) Keep filtering L2 LSP from inside routers

o   Pro: no sudden increase of L2 LSDB size

o   Con: transit traffic is partially dropped (if area LSP advertised while some routers are L1 only), no transit is possible (if area LSP is not advertised), or partial transit (some inside edge node do not advertise the area proxy TLV).

§  Lack of transit is not an issue if there is a backup proxy area (e.g. a proxy area a replace a big single chassis).  It’s likely an issue is there is no backup proxy area (e.g. the area has built-in redundancy (e.g. spife/leaf) hence there is no need for another/backup proxy area. Network operator needs to be well aware in order to choose the correct design (rather than experience a bad surprise)

That’s an open question.
As this point I do not have a preference, although naively I had “A” in mind. From your below answer, I think that you have “B” in mind.
A priori the choice may be dependent on the missing condition.
Possibly this could be clarified in a “operational consideration” or “error handling” section for network operator to be aware of the behaviour under failure/transition condition.
FYI, I’m considering such failure to be plausible over the years as all it need is one L1 router to boot and not advertise the area proxy TLV or be configured as L1 only.

Regards,
--Bruno
From: Lsr [mailto:[e-mail]] On Behalf Of [e-mail]
Sent: Saturday, September 5, 2020 2:43 AM
To: DECRAENE Bruno TGI/OLN <[e-mail]>
Cc: [e-mail]
Subject: Re: [Lsr] I-D Action: draft-ietf-lsr-isis-area-proxy-03.txt


Hi Bruno,



“A Level 2 LSP that contains the Area Proxy TLV MUST NOT be flooded to an Outside Router. »
Agreed (so far)

“A Level 2 LSP with a source system identifier that is found in the Level 1 LSDB MUST NOT be flooded to an Outside Router.”
I’m not sure to agree.
If that LSP carries the Area Proxy TLV, the previous rule is enough.
If that LSP does not carry the Area Proxy TLV, then no Area Leader advertise the Area Proxy System Identifier Sub-TLV and hence the new Area Proxy is not enabled. In which case I feel that normal IS-IS flooding should occur, and L1-L2 nodes should have their L2 LSP flooded.
So, I would propose to remove that sentence which doesn’t seem needed.


This was intentional. We are trying to protect against a case where a router boots and has not yet processed its full configuration yet.  It could easily generate an LSP prior to adding the Area Proxy TLV.
This could also happen during the transition to Area Proxy, where an Inside Node has not yet been configured for Area Proxy.

We are trying to prevent flooding of its LSP to the Outside Area because that may confuse other L2 nodes.


“A Level 2 LSP that contains the Area Proxy TLV MUST NOT be flooded to an Outside Router. »
I think we additionally need that an Area Leader advertise the Area Proxy System Identifier Sub-TLV.


We already say:

          The Area Leader has several responsibilities.  First, it MUST
       inject the Area Proxy System Identifier into the Level 2
       LSDB.



Otherwise, hence the new Area Proxy is not enabled. I which case I feel that normal IS-IS flooding should occur, and L1-L2 nodes should have their L1 & L2 LSP flooded.
That condition would seem application to the whole section 5.2 or even to the whole section 5



Again, we want to restrict flooding if Area Proxy is configured, even if it’s not fully enabled.  Again, we’re just trying to make the transition as smooth as possible.


Tony



_________________________________________________________________________________________________________________________

Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.

This message and its attachments may contain confidential or privileged information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.
Thank you.