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

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

(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.