Tony –

The new definitions in the latest version in the draft are very close to what 
we discussed in the earlier thread – so this looks pretty good to me.

I still have some concerns regarding the Area Segment SID.
You propose to advertise this in two places:

1)As a sub-TLV of the new Area Proxy TLV
2)As a new sub-TLV of the existing Binding TLVs (149, 150)

I am not sure why you need this in the Area Proxy TLV as you allow Binding TLVs 
to be advertised in the Proxy LSPs (Section 4.4.10).
???

If this is what is intended, it raises a number of concerns:

If both are present and inconsistent how are they used?
As Area Proxy TLV does not support MT (not suggesting that it should) it isn’t 
clear how this relates to MT context – which exists for TLVs 149/150.

Encoding wise, if we are to support Area Segment SID in the Binding TLVs, I 
think more detail needs to be provided as to flag settings when the new sub-TLV 
is present.
The following flags are currently defined for the Binding TLVs:

0 1 2 3 4 5 6 7
+-+-+-+-+-+-+-+-+
|F|M|S|D|A|     |
+-+-+-+-+-+-+-+-+

F,S,D flags seem applicable w/o change.
However, M flag would need to be clear when Area Segment SID is present.
The A flag seems not applicable to Area Segment SID
And your encoding violates the current definition of Binding TLVs.
Specifically, https://www.rfc-editor.org/rfc/rfc8667.html#section-2.4.4 states:

“The Prefix-SID sub-TLV is defined in Section 
2.1<https://www.rfc-editor.org/rfc/rfc8667.html#PREFIXSIDSUBTLV> and contains 
the SID/Index/Label value associated with the prefix and range.
 The Prefix-SID sub-TLV MUST be present in the SID/Label Binding TLV when the 
M-Flag is clear.
 The Prefix-SID sub-TLV MUST NOT be present when the M-Flag is set.”

While some changes to this definition are likely required to support Area 
Segment SID no matter what, it is hard for me to see a good way to do this w/o 
adding a new flag.

   Les


From: Lsr <lsr-boun...@ietf.org> On Behalf Of tony...@tony.li
Sent: Tuesday, July 07, 2020 8:20 AM
To: lsr@ietf.org
Subject: [Lsr] Fwd: New Version Notification for 
draft-ietf-lsr-isis-area-proxy-01.txt


Hi all,

We’ve updated our draft to revise the TLV encodings along the lines of the 
discussions we’ve been having.

1) The Area Proxy Router Capability is removed.
2) The Inside Node TLV is removed. Instead, the Area Proxy TLV is used instead.
3) The Area Segment SID is advertised inside of a SID/Label Binding TLV. While 
we discussed using
a flag within this TLV to denote that this was an Area Segment SID, after 
looking at it, it seemed simpler
and more consistent to use a sub-TLV.

Please review and comment.

Thanks,
Sarah, Vivek, Gyan, and Tony



Begin forwarded message:

From: internet-dra...@ietf.org<mailto:internet-dra...@ietf.org>
Subject: New Version Notification for draft-ietf-lsr-isis-area-proxy-01.txt
Date: July 7, 2020 at 8:14:58 AM PDT
To: "Gyan Mishra" 
<gyan.s.mis...@verizon.com<mailto:gyan.s.mis...@verizon.com>>, "Vivek 
Ilangovan" <ilango...@arista.com<mailto:ilango...@arista.com>>, "Sarah Chen" 
<sarahc...@arista.com<mailto:sarahc...@arista.com>>, "Tony Li" 
<tony...@tony.li<mailto:tony...@tony.li>>, "Gyan S. Mishra" 
<gyan.s.mis...@verizon.com<mailto:gyan.s.mis...@verizon.com>>, "Yunxia Chen" 
<sarahc...@arista.com<mailto:sarahc...@arista.com>>


A new version of I-D, draft-ietf-lsr-isis-area-proxy-01.txt
has been successfully submitted by Tony Li and posted to the
IETF repository.

Name:                draft-ietf-lsr-isis-area-proxy
Revision:           01
Title:                    Area Proxy for IS-IS
Document date:             2020-07-07
Group:                               lsr
Pages:                19
URL:            
https://www.ietf.org/internet-drafts/draft-ietf-lsr-isis-area-proxy-01.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-01
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-01

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<http://tools.ietf.org>.

The IETF Secretariat


_______________________________________________
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

Reply via email to