Subject: [Lsr] RFC8500 Reverse Metric and ITU-T G.7712 both using IS-IS TLV 16

From: Philip Christian <[email-masked]>
Date: Wed, 8 Jan 2020 18:55:59 +0000

Hello

I have been monitoring using of IS-IS TLV16 on and off for seventeen
years but it seems that this past year I failed to notice it being
assigned to Reverse Metric.

My understanding is that there are now two separate IS-IS protocol
extensions now using TLV16.

The one from eighteen years ago is Automatic Encapsulation which was not
accepted by the IETF but was written into ITU-T G.7712.

The second is Reverse Metric.

However all is not lost.
Automatic Encapsulation specified the use of subTLVs and only ever
assigned SubTLV 1.
I notice that Reverse Metric appears to have subTLVs 1-17 listed as
Unassigned.

In my opinion the safest thing to do would be to update the IANA TLV
codepoint document and under the section "Sub-TLVs for TLV 16 (Reverse
Metric TLV)" simply mark subTLV 1 as something like "used in ITU G.7712".

This would make the situation 100% safe for Reverse Metric implementors
IMHO.  Provided that subTLV 1 is ignored then I think it wouldn't matter
if the million to one happened and an SDH/SONET optical network overhead
channel somehow got bridged to a modern IS-IS thing.  Probably if that
did happen then much worse stuff would happen anyway, like all of the
CLNP packets rushing off towards an Internet of nothing causing panic in
a telco ops room somewhere.  Or maybe a corporate network trying to
route itself down a SONET/SDH 128kb overhead channel.

I was tasked several years ago with trying to find an actual
implementation of Automatic Encapsulation and the only evidence that I
can find is a Vertel document here
http://www.vertel.com/docs/g7712.pdf
There was a rumour of one Telecom vendor building something but I could
not get to the bottom of it.
I know that Nortel was also working on an implementation for their
SONET/SDH multiplexers but my relationship (and probably my pension)
with them ended in 2003.  I have no idea if Nortel optical equipment is
actually still used in a live network.

Folks can read about G.7712 here
https://www.itu.int/rec/T-REC-G.7712-201908-I/en

Note that I do not speak on behalf of any standards group or company on
this matter.  It is purely a personal interest. I have since 2003
followed a completely different carrier path.

Also note that I have not done any serious amount of research or
checking into how Reverse Metric works or particularly read any of the
documents.

I hope that you are all still well. Happy new year.

Regards, Philip Christian, CEng, CISSP, London UK

---

From: [email-masked]
Date: Wed, 8 Jan 2020 11:01:31 -0800

> On Jan 8, 2020, at 10:55 AM, Philip Christian <[email-masked]> wrote:
> 

This seems like it would bust every single implementation of reverse metric.

Given that you can’t find an implementation of Automatic Encapsulation and they never
filed anything with LSR (or IS-IS or IANA), why would we do that?

Seems to me like this is a problem for Automatic Encapsulation folks to figure out…

Tony

---

From: Philip Christian <[email-masked]>
Date: Wed, 8 Jan 2020 19:08:06 +0000

[quote]they never filed anything with LSR (or IS-IS or IANA)[/quote]
In my defense I did try.

I also notice that Reverse Metric seems to use TLV 16 only in IIH and
that G.7712 only uses it in LSPs.

regards, Philip

On 08/01/2020 19:01, [email-masked] wrote:
> 
> 
>> On Jan 8, 2020, at 10:55 AM, Philip Christian
>> <[email-masked]
>> <mailto:[email-masked]>> wrote:
>>

---

From: "Les Ginsberg (ginsberg)" <[email-masked]>
Date: Wed, 8 Jan 2020 19:46:46 +0000

Philip -

Always good to renew our acquaintance.

As the format of the TLV itself is different between Reverse Metric and Auto-Encap, simply reserving a sub-TLV code-point for Auto-Encap isn't sufficient.

Suggesting that one form of the TLV be used in IIHs(Reverse Metric) and another in LSPs(Autoencap) is a creative solution - but I think we could both agree this is  a hack and less than desirable.

I think realistically there are two paths which can be followed - the need for either of them is of course dependent on the existence of deployments of auto-encap.

1)Auto-encap can continue to use TLV 16 so long as it never has to coexist with Reverse metric.
It does so understanding that it is using a proprietary codepoint which has not been standardized.
(Apologies to anyone in the ITU whom I have just offended.)

2)If there is sufficient justification, ITU would need to apply for a new codepoint which could be added to the IANA registry.
Existing implementations of auto-encap would need to introduce support for transition from the proprietary codepoint to the standard codepoint.

I respect your tireless advocacy for this functionality, but I think there needs to be some larger consensus before Option #2 could be considered.

Does this seem like a fair summary of options?

   Les

> -----Original Message-----
> From: Philip Christian <[email-masked]>
> Sent: Wednesday, January 08, 2020 11:08 AM
> To: [email-masked]
> Cc: [email-masked]; Les Ginsberg (ginsberg) <[email-masked]>;
> [email-masked]; [email-masked]
> Subject: Re: [Lsr] RFC8500 Reverse Metric and ITU-T G.7712 both using IS-IS
> TLV 16
>

---

From: Philip Christian <[email-masked]>
Date: Wed, 8 Jan 2020 20:18:59 +0000

Hello Les

I think we all know that option 1 is what will happen because no one
cares enough to bother with 2.  For the record TLV16 was assigned by
this group to autoencap at the time and the code point doc didn't exist
back then.  When the code point document was then invented I asked for
TLV16 to be reserved but was rebuffed.

The actual fact is that it probably doesn't matter because if anyone was
stupid enough to bridge a SONET/SDH IS-IS network to a modern IP router
network it would probably spectacularly explode anyway, and because I
suspect (but not 100% sure) that an autoencap network was ever actually
built.

So it just becomes a little piece of history and probably of no importance.

You never know when a similar scenario might happen in another
technology area though (one protocol, multiple standards orgs?) and so I
hope a little reminder is more valuable than annoying.  Maybe it isn't :-;

regards, Philip

On 08/01/2020 19:46, Les Ginsberg (ginsberg) wrote:
> _______________________________________________
> Lsr mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/lsr
>

---

From: Philip Christian <[email-masked]>
Date: Wed, 8 Jan 2020 20:21:43 +0000

sorry I meant "never", not "ever". The n totally changes the meaning....