[Lsr] Fwd: New Version Notification for draft-ietf-lsr-isis-area-proxy-02.txt

[[e-mail]]

Hi folks,

This version of the draft reflects major changes in line with the discussions that we’ve had so far.

To wit:
- The Area Proxy TLV is now moved to be in L2 LSPs and indicates that the advertising node is an Inside Node and Area Proxy is active.
- The Area Proxy Router Capability has been removed.
- The Inside Node TLV has been removed.
- The Area Segment SID TLV has been replaced by extending the Binding SID TLV.

We know that some folks disagree with this last point, so we welcome discussion on this. We would like to reach consensus as quickly as possible.

Thanks,
Tony


> Begin forwarded message:
> 
> From: [e-mail]
> Subject: New Version Notification for draft-ietf-lsr-isis-area-proxy-02.txt
> Date: July 25, 2020 at 6:46:05 PM PDT
> To: "Vivek Ilangovan" <[e-mail]>, "Sarah Chen" <[e-mail]>, "Gyan S. Mishra" <[e-mail]>, "Gyan Mishra" <[e-mail]>, "Yunxia Chen" <[e-mail]>, "Tony Li" <[e-mail]>
> 
> 
> A new version of I-D, draft-ietf-lsr-isis-area-proxy-02.txt
> has been successfully submitted by Tony Li and posted to the
> IETF repository.
> 
> Name:		draft-ietf-lsr-isis-area-proxy
> Revision:	02
> Title:		Area Proxy for IS-IS
> Document date:	2020-07-25
> Group:		lsr
> Pages:		20
> URL:            https://www.ietf.org/internet-drafts/draft-ietf-lsr-isis-area-proxy-02.txt
> Status:         https://datatracker.ietf.org/doc/draft-ietf-lsr-isis-area-proxy/
> Htmlized:       https://tools.ietf.org/html/draft-ietf-lsr-isis-area-proxy-02
> Htmlized:       https://datatracker.ietf.org/doc/html/draft-ietf-lsr-isis-area-proxy
> Diff:           https://www.ietf.org/rfcdiff?url2=draft-ietf-lsr-isis-area-proxy-02
> 
> 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.
> 
> 
> 
> 
> 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.
> 
> The IETF Secretariat
> 
>