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

[Xuxiaohu <[e-mail]>]

Hi Philip,

> -----Original Message-----
> From: Philip Christian [mailto:[e-mail]]
> Sent: Tuesday, March 08, 2016 7:09 PM
> To: Xuxiaohu; Marc Binderberger; [e-mail] list
> Cc: Les Ginsberg; Christian Hopps
> Subject: Re: [Isis-wg] WG Adoption Call for draft-xu-isis-encapsulation-cap
> 
> Please can you explain why you are proposing a new protocol extension to do
> this when there is an existing extension which already achieves exactly the same
> thing? i.e. the Encapsulation capability TLV described in ITU-T G.7712 and in
> draft-ietf-isis-auto-encap-03.

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.

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

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

Best regards,
Xiaohu 

> thanks, Philip
> 
> >
> > Your understanding is correct that this draft follows the idea of
> > RFC5512. That's to say, it allows automatical discovery of the tunnel
> > decapsulation capability of tunnel egress nodes). The tunnel
> > decapsulation capability includes but not limited to tunnel types,
> > tunnel parameters (e.g., GRE key, L2TP session ID and cookie) and
> > encapsulated protocols. In contrast with the tag proposal, there is no
> > need for operators to manually configure many mappings between tags
> > and tunnel decapsulation capabilities on each router. The manual
> > configuration of such mappings is error-prone and therefore should be
> > avoided if possible, IMHO.
> >
> > Best regards,
> > Xiaohu
> >