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

From: <[email-masked]>
Date: Fri, 4 Sep 2020 12:28:56 +0000

Hi Tony,

I've read the diff for -03 and -04.
The new encoding of the Area SID is good for me.

And thank you for listening to my use case and suggestion.

Thanks,
--Bruno

From: Lsr [mailto:[email-masked]] On Behalf Of [email-masked]
Sent: Monday, August 24, 2020 7:02 PM
To: [email-masked]
Subject: [Lsr] Fwd: I-D Action: draft-ietf-lsr-isis-area-proxy-03.txt

Hi folks,

This updated draft has been published for a few weeks now.  We would like to solicit your opinion on this.  In particular, we have changed the encoding of the Area SID.  Do you find this encoding adequate and appropriate?

Thanks,
Tony

Begin forwarded message:

From: [email-masked]<mailto:[email-masked]>
Subject: I-D Action: draft-ietf-lsr-isis-area-proxy-03.txt
Date: August 5, 2020 at 1:17:39 PM PDT
To: <[email-masked]<mailto:[email-masked]>>
Cc: [email-masked]<mailto:[email-masked]>
Reply-To: [email-masked]<mailto:[email-masked]>, [email-masked]<mailto:[email-masked]>

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Link State Routing WG of the IETF.

       Title           : Area Proxy for IS-IS
       Authors         : Tony Li
                         Sarah Chen
                         Vivek Ilangovan
                         Gyan S. Mishra
          Filename        : draft-ietf-lsr-isis-area-proxy-03.txt
          Pages           : 19
          Date            : 2020-08-05

Abstract:
  Link state routing protocols have hierarchical abstraction already
  built into them.  However, when lower levels are used for transit,
  they must expose their internal topologies to each other, leading to
  scale issues.

  To avoid this, this document discusses extensions to the IS-IS
  routing protocol that would allow level 1 areas to provide transit,
  yet only inject an abstraction of the level 1 topology into level 2.
  Each level 1 area is represented as a single level 2 node, thereby
  enabling greater scale.

The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-lsr-isis-area-proxy/

There are also htmlized versions available at:
https://tools.ietf.org/html/draft-ietf-lsr-isis-area-proxy-03
https://datatracker.ietf.org/doc/html/draft-ietf-lsr-isis-area-proxy-03

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-lsr-isis-area-proxy-03

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.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

_______________________________________________
I-D-Announce mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/i-d-announce
Internet-Draft directories: http://www.ietf.org/shadow.html
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

_________________________________________________________________________________________________________________________

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.

---

From: <[email-masked]>
Date: Fri, 4 Sep 2020 14:12:35 +0000

Hi Tony,

Please find below some nits/minor comments. Please feel free to silently discard.

1)

OLD: The
   advertisement in the Proxy LSP informs the remainder of the network
   that packets directed to the SID will be forwarded by one of the
   Inside Edge Nodes and the Area SID will be consumed.

NEW:

The

   advertisement in the Proxy LSP informs the outside area

   that packets directed to the SID will be forwarded to one of the

   Inside Edge Nodes and the Area SID will be consumed.

Motivation:

1)      More precise/descriptive and use the terminology defined in the draft

2)      The SID is a priori global in the outside area and hence will be forwarded by all nodes in the outside area (and not just by the Inside Edge Nodes). The destination is anycast to/toward any Inside Edge node.

2)
§ 4.3.2.  The Area SID Sub-TLV

The Area SID Sub-TLV allows the Area Leader to advertise a prefix and

   SID

§4.4.13.  The Area SID

  The Area Leader SHOULD advertise the Area SID information in the

   Proxy LSP as a Node SID as defined in [RFC8667] Section 2.1<https://tools.ietf.org/html/rfc8667#section-2.1>.

RFC8667 requires that for a Node SID, the prefix be an IP address (/32 or /138) (rather than an IP prefix of an arbitrary length) [1].
[1] https://tools.ietf.org/html/rfc8667#section-2.1.1.2

You may want to refer to this restriction when defining the Area SID Sub-TLV in section 4.3.2 . e.g. :s/advertise a prefix/advertise an IP address. Alternatively open the option to advertise a prefix SID without the N-Flag if this is a prefix.

3)
1 typo in -04 :s/ Inisde/ Inside

4)
OLD:
The Area Leader will generate a Proxy LSP that must be flooded across
   the Inside Area.  Inside Routers MUST ignore the contents of the
   Proxy LSP other than for flooding

My personal preference would be
NEW
The Area Leader will generate a Proxy LSP that will be flooded across
   the Inside Area.  Inside Routers MUST ignore the contents of LSP(s) originated with the Area Proxy System Identifier other than for flooding.

Motivation:

a)      Clarify that no new behavior is involved

b)      Specifies how the proxy LSP is to be identified as a proxy LSP.

5) Open question: is the Area Proxy LSP to be advertised/read from L1 or L2 LSP/LSDB or both?

"All routers within the Inside Area speak Level 1 and Level 2 IS-IS on all of the links within the topology."
OK.

"A node advertises the Area Proxy TLV in its L2 LSP"
So my reading/guessing is that the Area Proxy TLV is only sent in the L2 LSP of all Inside routers. (i.e. not in the L1 LSP).
If so:

-          Can you clarify the behavior when an Area Proxy TLV is received in an L1 LSP? (e.g. ignore, and if not, what is the behavior when the TLV is different in L1 and L2).

-          "they will advertise the Area Proxy TLV." May be adding "in their L2 LSP"

-          "All Inside Edge Routers learn the Area Proxy System Identifier from the Level 1 LSDB". I would have assumed  "from the Area Proxy TLV advertised in the level 2 LSDB.  So it may be a typo or I'm missing something, which is very possible.

o   "it MUST inject   the Area Proxy System Identifier into the Level 1 LSDB." Same comment.

Thanks,
--Bruno

From: Lsr [mailto:[email-masked]] On Behalf Of [email-masked]<mailto:[email-masked]>
Sent: Friday, September 4, 2020 2:29 PM
To: [email-masked]<mailto:[email-masked]>
Cc: [email-masked]<mailto:[email-masked]>
Subject: Re: [Lsr] Fwd: I-D Action: draft-ietf-lsr-isis-area-proxy-03.txt

Hi Tony,

Thanks,
--Bruno

From: Lsr [mailto:[email-masked]] On Behalf Of [email-masked]<mailto:[email-masked]>
Sent: Monday, August 24, 2020 7:02 PM
To: [email-masked]<mailto:[email-masked]>
Subject: [Lsr] Fwd: I-D Action: draft-ietf-lsr-isis-area-proxy-03.txt

Hi folks,

Thanks,
Tony

Begin forwarded message:

Abstract:

Thank you.

---

From: <[email-masked]>
Date: Fri, 4 Sep 2020 14:12:47 +0000

Hi Tony,

I may have a comment on 5.2.  Filtering LSP information.
This is old text, but new re-reading.

"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.

"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. 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

Thanks,
--Bruno

Hi Tony,

Thanks,
--Bruno

Hi folks,

Thanks,
Tony

Begin forwarded message:

Abstract:

Thank you.

---

From: [email-masked]
Date: Fri, 4 Sep 2020 17:18:24 -0700

Hi Bruno,

Thank you for your comments.

> 2)      The SID is a priori global in the outside area and hence will be forwarded by all nodes in the outside area (and not just by the Inside Edge Nodes). The destination is anycast to/toward any…

Ok.

>    Proxy LSP as a Node SID as defined in [RFC8667] Section 2.1 <https://tools.ietf.org/html/rfc8667#section-2.1>. 
>  
>  
> [1] https://tools.ietf.org/html/rfc8667#section-2.1.1.2 <https://tools.ietf.org/html/rfc8667#section-2.1.1.2>
>  

We are implicitly doing that by permitting a prefix.  

> 1 typo in -04 :s/ Inisde/ Inside

Fixed, thanks.

> b)      Specifies how the proxy LSP is to be identified as a proxy LSP.

?  Ignoring the contents of an LSP is a new behavior.  I propose something slightly different:

	 The Area Leader will generate a Proxy LSP that will be
	 flooded across the Inside Area.  Inside Routers MUST ignore
	 the contents of the Proxy LSP other than for flooding.  The
	 Proxy LSP uses the Area Proxy System Identifier as its Source
	 ID.

> “All routers within the Inside Area speak Level 1 and Level 2 IS-IS on all of the links within the topology.”
> OK.
>  
> “A node advertises the Area Proxy TLV in its L2 LSP”

We already say:

           The Area Leader MUST advertise the Area Proxy System
           Identifier Sub-TLV when it observes that all Inside Routers
           are advertising the Area Proxy TLV.

The statement that you quote is pretty clear that the Area Proxy TLV is found in the L2 LSP.  I take it that you feel that this is insufficient.
I propose to add:

         Nodes MUST NOT advertise the Area Proxy TLV in a L1 LSP. Nodes MUST
	 ignore the Area Proxy TLV if it is found in a L1 LSP. 

> -          “they will advertise the Area Proxy TLV.” May be adding “in their L2 LSP”

Ok.

> -          “All Inside Edge Routers learn the Area Proxy System Identifier from the Level 1 LSDB”. I would have assumed  “from the Area Proxy TLV advertised in the level 2 LSDB.  So it may be a typo or I’m missing something, which is very possible.

That was a bug, thanks.  I changed it to: “ … from the Area Proxy TLV advertised by the Area Leader … “

> o   “it MUST inject   the Area Proxy System Identifier into the Level 1 LSDB.” Same comment.

Also a bug.  Should be L2.  Fixed.

Thanks for the detailed review!

Tony

---

From: [email-masked]
Date: Fri, 4 Sep 2020 17:42:30 -0700

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

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

---

From: <[email-masked]>
Date: Mon, 7 Sep 2020 09:19:28 +0000

Hi Tony,

Thanks for your reply.
All good to me.

Thanks,
--Bruno

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

Hi Bruno,

1)

OLD: The

NEW:

The

Motivation:

Ok.

2)

   SID

§4.4.13.  The Area SID

3)

Fixed, thanks.

4)
OLD:

Motivation:

We already say:

Ok.

Tony

---

From: <[email-masked]>
Date: Mon, 7 Sep 2020 11:00:05 +0000

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:[email-masked]] On Behalf Of [email-masked]
Sent: Saturday, September 5, 2020 2:43 AM
To: DECRAENE Bruno TGI/OLN <[email-masked]>
Cc: [email-masked]
Subject: Re: [Lsr] I-D Action: draft-ietf-lsr-isis-area-proxy-03.txt

Hi Bruno,

We already say:

Tony

---

From: [email-masked]
Date: Mon, 7 Sep 2020 07:27:44 -0700

Hi Bruno,

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

Something that we’re not allowed to talk about in the spec is that we’re assuming that ALL routers in the Inside Area are configured to enable Area Proxy.  Partial configuration is a misconfiguration or transitional to full configuration.

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

Yes. Given the above assumption, we want to assume transition.

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

I’m open to suggestions and/or contributions.

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

30 years of doing this says that any crazy thing is possible and WILL happen somewhere, someplace in the fullness of time. Yes, ok, withdrawing the Proxy LSP in these cases is probably not optimal.  What should we say instead? Some failures are clearly fatal, some are not. What’s the right thing to do without a dissertation worth of analysis and special cases?

Tony