Subject: [Isis-wg] Relationship between draft-xu-isis-encapsulation-cap and draft-ietf-isis-auto-encap-03

From: "Les Ginsberg (ginsberg)" <[email-masked]>
Date: Thu, 10 Mar 2016 15:40:57 +0000

(Subject was " Re: [Isis-wg] WG Adoption Call for draft-xu-isis-encapsulation-cap")

(I have deliberately changed the subject and removed (most of) the original thread.)

Philip/Xiaohu -

For me the debate about whether the same codepoint  should be used in the two drafts serves neither constituency. 

The two drafts are trying to address two qualitatively different issues.

In the case of draft-xu-isis-encapsulation-cap the authors are suggesting that explicitly advertising supported tunnel encaps/endpoints is useful in order to support partial deployment of some existing encap (MPLS, SR) over a common L3 layer or to support some form of traffic engineering (RLFA example is cited).  The debate going on is NOT about the encoding of the advertisement, it is about whether the advertisement is needed at all. Some of us have suggested that there are existing mechanisms which will serve just as well - if not better.

In the case of draft-ietf-isis-auto-encap-03, the draft is trying to address the case of islands where a common network layer is not supported (notably an IP island in a CLNS network - or vice versa) - in which case forwarding is not possible at all without introducing some tunneling encap. The debate (if memory serves...it has been 12 years :-) ) was about whether this is a problem which needs solving. For the SONET deployment community this issue did exist (not sure whether it still does) - but from the IP/IPv6 community the need for solving this problem was not perceived as great.

I think Philip has a point that it could be possible to use the codepoint from the auto-encap draft in support of draft-xu-isis-encapsulation-cap - but focusing on that debate when the need for draft-xu-isis-encapsulation-cap is still being debated seems at best premature.

I also think that using draft-xu-isis-encapsulation-cap to try to advance draft-ietf-isis-auto-encap-03 is inappropriate. The need to support the use case defined in the auto-encap draft should be discussed on its own merits. It was discussed years ago - whether it needs to be revived should be the subject of a separate thread (if at all). I am concerned that there might be a codepoint in use which is not documented in the IANA registry - so it would be useful to hear whether this technology is in active use in SONET deployments. The draft itself states this is a migration tool - if the migration has already occurred then obviously this makes reviving auto-encap moot.

   Les

> -----Original Message-----
> From: Isis-wg [mailto:[email-masked]] On Behalf Of Philip Christian
> Sent: Monday, February 29, 2016 3:30 AM
> To: [email-masked]
> Subject: Re: [Isis-wg] WG Adoption Call for draft-xu-isis-encapsulation-cap
> 
> Please can people explain how
> 
> https://datatracker.ietf.org/doc/draft-xu-isis-encapsulation-cap/
> 
> might fit in with, or cause problems with this
> 
> https://tools.ietf.org/html/draft-ietf-isis-auto-encap-03
> 
> which was adopted by the ITU-T and appears to be still very much part of IT-T
> G.7712.

---

From: Philip Christian <[email-masked]>
Date: Thu, 10 Mar 2016 16:53:30 +0000

Hi Les & Xiaohu,

I understand your point that they are different use cases of encapsulation.
However I also think that a single code point could be used for both as
they are so similar.

The old draft for G.7712 / isis-auto-encap was too narrow in scope to
cover both use cases, but that is a problem with the words in the draft,
not with using the code point.  The words in the draft can be changed,
they are just words.  I can do it in a few hours if this wg wants me to,
or Xiaohu and me can do it together; I don't mind.

Equally the two use cases could use two different code points.  The two
technologies would just ignore each other.

This WG needs to decide whether these two things should use the same
codepoint, which would be a generalised encapsulation capability TLV=16
with two or more usecases, or whether the "tunnelling over the hole"
usecase should use 16 and the "meshing of tunnels over IP" usecase
should use router-capability TLV=242.  Both views are probably valid,
and I don't think that either Xiaohu or me are going to "win" such an
argument, so the WG will need to decide.

Concerning the use of auto-encap in G.7712 I have started to put feelers
out to see whether it actually got deployed or not.  This is going to
take weeks or months of research because the SONET/SDH guys are buried
very deep in major telcos and not easy to find.  The routing stacks are
also written by different vendors to those who actually sell the kit and
some of these vendors no longer exist, but the boxes are still there
connecting countries and cities together.

I would not expect a "migration" away from CLNP to be complete until the
lasers burn out in the multiplexers to be honest.  Once these things are
installed and forwarding traffic the operators will never, never touch
them. Unnecessary upgrades will always be avoided.  This was the whole
reason that tunnelling across them was needed.

I was quite cross that IANA would not document the use of TLV 16 by
G.7712 in an ITU-T official document.  It would cost them nothing and
could have protected against a massive network meltdown of a national or
international optical network, or at least the status panel of a major
telco all going red and the ops guys having a panic wondering if they
just trashed an entire national network or not.  Fortunately no-one has
chosen to use TLV 16 for something else but I still think it was a mistake.

sorry for the long email, I hate long emails and so now I have made a
hypocrite of myself, Philip

---

From: "Les Ginsberg (ginsberg)" <[email-masked]>
Date: Thu, 10 Mar 2016 17:17:03 +0000

Philip -

My major point is that it is rather silly (no offense intended) to be debating whether the same codepoint should be used before the WG has decided whether to accept draft-xu-isis-encapsulation-cap.
I did indicate that you have a valid point that the same codepoint could be used - but we haven't come to that bridge yet...

As for IANA - don’t be too cross with them. RFC3563 sets up a liason with ISO JTC1/SC6 - not w ITU. I don’t think IANA has any basis on which to add a codepoint to the registry unless either an IETF WG or JTC1/SC6 provides a document to do so. I long ago stopped participating in ISO - but I don't think any IS-IS work has gone on there since the 2002 revision of ISO 10589. That leaves ITU in the middle.

   Les

> From: Philip Christian [mailto:[email-masked]]
> Sent: Thursday, March 10, 2016 8:53 AM
> To: Les Ginsberg (ginsberg); [email-masked]; [email-masked]
> Subject: Re: Relationship between draft-xu-isis-encapsulation-cap and draft-
> ietf-isis-auto-encap-03
> 
> Hi Les & Xiaohu,
> 
> However I also think that a single code point could be used for both as they
> are so similar.
> 
> The old draft for G.7712 / isis-auto-encap was too narrow in scope to cover
> both use cases, but that is a problem with the words in the draft, not with
> using the code point.  The words in the draft can be changed, they are just
> words.  I can do it in a few hours if this wg wants me to, or Xiaohu and me can
> do it together; I don't mind.
> 
> usecase should use 16 and the "meshing of tunnels over IP" usecase should
> use router-capability TLV=242.  Both views are probably valid, and I don't
> think that either Xiaohu or me are going to "win" such an argument, so the
> WG will need to decide.
> 
> Concerning the use of auto-encap in G.7712 I have started to put feelers out
> to see whether it actually got deployed or not.  This is going to take weeks or
> months of research because the SONET/SDH guys are buried very deep in
> major telcos and not easy to find.  The routing stacks are also written by
> different vendors to those who actually sell the kit and some of these
> vendors no longer exist, but the boxes are still there connecting countries
> and cities together.
> 
> installed and forwarding traffic the operators will never, never touch them.
> Unnecessary upgrades will always be avoided.  This was the whole reason
> that tunnelling across them was needed.
> 
> G.7712 in an ITU-T official document.  It would cost them nothing and could
> have protected against a massive network meltdown of a national or
> international optical network, or at least the status panel of a major telco all
> going red and the ops guys having a panic wondering if they just trashed an
> entire national network or not.  Fortunately no-one has chosen to use TLV 16
> for something else but I still think it was a mistake.
> 
> > For me the debate about whether the same codepoint  should be used in
> the two drafts serves neither constituency.
> >
> > In the case of draft-xu-isis-encapsulation-cap the authors are suggesting
> that explicitly advertising supported tunnel encaps/endpoints is useful in
> order to support partial deployment of some existing encap (MPLS, SR) over
> a common L3 layer or to support some form of traffic engineering (RLFA
> example is cited).  The debate going on is NOT about the encoding of the
> advertisement, it is about whether the advertisement is needed at all. Some
> of us have suggested that there are existing mechanisms which will serve
> just as well - if not better.
> >
> > In the case of draft-ietf-isis-auto-encap-03, the draft is trying to address
> the case of islands where a common network layer is not supported (notably
> an IP island in a CLNS network - or vice versa) - in which case forwarding is not
> possible at all without introducing some tunneling encap. The debate (if
> memory serves...it has been 12 years :-) ) was about whether this is a
> problem which needs solving. For the SONET deployment community this
> issue did exist (not sure whether it still does) - but from the IP/IPv6
> community the need for solving this problem was not perceived as great.
> >
> > I think Philip has a point that it could be possible to use the codepoint from
> the auto-encap draft in support of draft-xu-isis-encapsulation-cap - but
> focusing on that debate when the need for draft-xu-isis-encapsulation-cap is
> still being debated seems at best premature.
> >
> > I also think that using draft-xu-isis-encapsulation-cap to try to advance
> draft-ietf-isis-auto-encap-03 is inappropriate. The need to support the use
> case defined in the auto-encap draft should be discussed on its own merits.
> It was discussed years ago - whether it needs to be revived should be the
> subject of a separate thread (if at all). I am concerned that there might be a
> codepoint in use which is not documented in the IANA registry - so it would
> be useful to hear whether this technology is in active use in SONET
> deployments. The draft itself states this is a migration tool - if the migration
> has already occurred then obviously this makes reviving auto-encap moot.
> >
> >    Les
> >
> >
> >> which was adopted by the ITU-T and appears to be still very much part
> >> of IT-T G.7712.