Re: [Isis-wg] WG Adoption Call for draft-xu-isis-encapsulation-cap

[Philip Christian <[e-mail]>]

Hi Xiaohu,

On 09/03/16 02:00, Xuxiaohu wrote:
> 
> First, these two drafts are intended to address different problems.
> draft-ietf-isis-auto-encap is only used to address the IPv4-IPv6
> co-existence issue. My draft is intended to address the issues as
> mentioned in the Introduction section.

This is not true.  G.7712/isis-auto-encap only defines one sub-TLV out
of 255 for GRE tunnelling.  This sub-TLV can be used to describe any
protocol in any other protocol which has an ITU-T X.263 NLPID defined.
Therefore it is not limited to IPv4 and IPv6 (and CLNP).

If mechanisms other than GRE are wanted such as L2TPv3 or IPSec, then
there are 254 sub-TLVs left to define them, this is why we went for a
sub-TLV approach.

> Second, the approaches as described in these two drafts are
> different. For example, draft-ietf-isis-auto-encap proposes to include
> an "Encapsulation Capability" TLV in LSPs that have LSP number 0. In
> addition, it has impact on the IP routing calculation process, see the
> following text quoted from this draft:
> 
> "   If an IS finds that the next hop does not support the type of packet
>    that it is attempting to forward, then it MUST search along the
>    shortest path from itself to the destination, and MUST inspect the
>    "encapsulation capability" TLV of LSP 0 of each IS until it finds an
>    IS that it is able to send the packet to in an encapsulated form.
>  " 
> My draft proposes to use a Encapsulation Capability sub-TLV of the
> Router Capability TLV and it has no impact on the IP routing calculation
> process at all. The only thing in common that I can see is the name
> (i.e., encapsulation capability).

The IP routing calculation process is in Annex rather than the main text
for this reason.  It was given as an example to show that the solution
is actually workable.  If you remove the Annex then the two documents
become two incompatible ways of achieving the same thing.  Moreover for
your draft to be an actual working solution there must be a way to
calculate routes for the encapsulated packets.  It seems to me to be a
partial solution as it does not describe this.

> Third, draft-ietf-isis-auto-encap has been expired 13 years before.
> Therefore, I think it should be safe to reuse the name
> (i.e., encapsulation capability).

auto-encap is (was :-) ) quite clear that it is communicating a solution
adopted by another standards body, the ITU-T.  ITU-T G.7712 most
definitely has not expired and there is evidence of possible
implementations in existence.  I don't think that the problem is the
name; I think that the problem is having two incompatible standards for
achieving essentially the same thing.

I don't speak for the ITU-T; and so I don't know if they have a problem
with this.  I do think that it would be wise to liaise with them, and to
find out if anyone actually installed a G.7712 auto-encap solution into
a live network.

regards, Philip