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

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

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


> -----Original Message-----
> From: Philip Christian [mailto:[e-mail]]
> Sent: Thursday, March 10, 2016 8:53 AM
> To: Les Ginsberg (ginsberg); [e-mail]; [e-mail]
> Subject: Re: Relationship between draft-xu-isis-encapsulation-cap and draft-
> ietf-isis-auto-encap-03
> 
> 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
> 
> On 10/03/2016 15:40, Les Ginsberg (ginsberg) wrote:
> > (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:[e-mail]] On Behalf Of Philip
> >> Christian
> >> Sent: Monday, February 29, 2016 3:30 AM
> >> To: [e-mail]
> >> 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.