Re: [Isis-wg] SRLG Stuff with draft-ginsberg-isis-te-app-00

["Les Ginsberg (ginsberg)" <[e-mail]>]

Uma -

There are no sub-TLVs used in TLVs 138/139. Please take a closer look at RFCs 5307/6119.
If there had been it might have been possible to extend the existing TLVs to support per-APP advertisements - but without sub-TLVs any change would not be backwards compatible.

There are then two options under discussion.

1)Invent a new top level TLV to support per APP advertisements. This is what the draft currently defines.

2)Define a new sub-sub-TLV to be used in TLVs 22, 23, 141, 222, and 223 which would allow per APP srlg advertisement within the scope of the new Application Specific Link Attributes sub-TLV.
This seems to be the option you prefer.

I am saying there are arguments for both approaches - and would be interested in what other folks think would be best.

   Les


From: Uma Chunduri [mailto:[e-mail]]
Sent: Thursday, June 01, 2017 11:10 AM
To: Les Ginsberg (ginsberg); Chris Bowers; [e-mail]
Subject: RE: SRLG Stuff with draft-ginsberg-isis-te-app-00

Les,

As I said:


1.       You intend and initiated change for SRLGs (TLV 138/139) by lifting all the sub-tlvs from there to new top level TLV 238. So it's you have to justify more for doing this and creating yet another top level TLV ..

2.       I still suggest

a.       Either stay with 138/139 and build application knowledge

b.      Bring it to TLVs 22, 23, 141, 222, and 223 (yes, if we have  to move away from 13/139 any ways, let's do this better this time!)

Cheers!
--
Uma C.

From: Les Ginsberg (ginsberg) [mailto:[e-mail]]
Sent: Wednesday, May 31, 2017 6:26 PM
To: Uma Chunduri <[e-mail]<mailto:[e-mail]>>; Chris Bowers <[e-mail]<mailto:[e-mail]>>; [e-mail]<mailto:[e-mail]>
Subject: RE: SRLG Stuff with draft-ginsberg-isis-te-app-00

Uma -

I appreciate your passion - I am just not convinced there is a clear winner here. There are advantages to either approach.
Let's listen for other opinions.

A few more comments inline.


From: Uma Chunduri [mailto:[e-mail]]
Sent: Wednesday, May 31, 2017 5:23 PM
To: Les Ginsberg (ginsberg); Chris Bowers; [e-mail]<mailto:[e-mail]>
Subject: RE: SRLG Stuff with draft-ginsberg-isis-te-app-00

Les,

Changed the title as this is bit side topic.

In-line [Uma]:

--
Uma C.




-          On the new TLV (TLV 238) proposed in https://tools.ietf.org/html/draft-ginsberg-isis-te-app-00

o   Not sure why SRLG need to be a separate TLV to start with as done in RFC 5307 for IPv4 and RFC 6119 for IPv6. This indeed, created lot of grief during BGP-LS time too from  both specification and implementation PoV.

If this need to be fixed these should be brought under T LVs 22, 23, 141, 222, and 223 not a 'new' separate TLV.

o   Hence, strongly disagree to clean-up this SRLG mess with yet another high level TLV

[Les:] I understand your concern. However, we have existing formats. What we have deliberately done with the extensions is to make sure we do NOT change existing formats for attribute advertisements - we only "encapsulate" with the "application bit mask".
This should allow a significant amount of existing TLV parsing code to be reused.
[Uma]: :). Code-reuse argument can be used for TLVs 22, 23, 141, 222, and 223 sub-TLVs too.

[Les2:] Not sure what you are saying. We DO reuse the existing link attribute sub-TLVs. Let's at least recognize when we are in agreement. :)

In the case of SRLG if we followed that model precisely we would have had to define two new top level TLVs - one for IPv4/unnumbered and one for IPv6. We wanted to be more frugal in consuming TLV code points
[Uma]: You arguing against what's been done in draft-ginsberg-isis-te-app i.e., creating yet another high level TLV code point. Sub-TLV format and code point space is far lesser relevance here..
                Section 4.3 Reads -

            A new TLV is defined to advertise application specific SRLGs for a
      given link.  Although similar in functionality to TLV 138 (defined by
      [RFC5307<https://tools.ietf.org/html/rfc5307>]) and TLV 139 (defined by [RFC6119<https://tools.ietf.org/html/rfc6119>] a single TLV provides
      support for IPv4, IPv6, and unnumbered identifiers for a link.


so we elected to make the new TLV format flexible enough to accommodate IPv4/IPv6, and unnumbered.
[Uma]: Why we are burning new TLV is the issue - to fix an already 'not needed' high level TLVs (138 and 139) for representing SRLGs. Issue is not the format of the sub-tlvs under it...



Your proposal is more "ambitious",
[Uma]: I see if you want to fix TLV138/139 - folding under  TLVs 22, 23, 141, 222, and 223 is more tractable way than introducing yet another high level TLV. Else use the same bit-mask/application-identifiers sub-TLVs in existing TLVs 13 & 139.

[Les2:] The conclusion that TLVs 138/139 were never needed isn't indisputable.
I will agree that if more foresight had been applied when writing RFC 5307 the IPv6 case could have been anticipated and TLV 139 would never have been needed - but concluding that advertising SRLG outside of TLV 22 etc. context is completely wrong is a much bigger leap. I do think there are advantages to doing that. You have concluded that TLV138 (and by inference TLV139) was a mistake - but I think opinion may be divided on that.

but I am not sure the benefits are significant enough. There are downsides to advertising SRLG in IS-neighbor TLVs.
AS a link may well have multiple SRLG values it could significantly bloat the TLV space used
[Uma]: Don't agree.  Would argue it other way. You would rather save space in your LSP by not having to use 6-byte system ID and other Interface address, neighbor address etc..


, forcing multiple TLVs for the same neighbor - which would defeat the purpose.
And it is harder for an implementation to determine whether a topology change is signaled by the revised IS-neighbor advertisement - so unnecessary SPFs might be triggered as a result.
[Uma]: I don't think so. A change have to be identified and trigger SPF, if the information is changed under existing TLV 138/139 (as LFA's also can potentially change).
Just by putting under TLVs 22, 23, 141, 222, and 223, won't cause any additional SPFs rather it is all at one place to see/compare and identify the change in topology.


[Les2:] A smart implementation can act optimally - I am only saying that it requires drilling deeper into the content which was updated - and not all implementations may have implemented that logic.

    Les