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: Wednesday, March 09, 2016 5:44 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
> 
> 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.

What about MPLS-in-IP?

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

I would have to remind you that the above text is quoted from the main text (see section 3.3) rather than the annex.

> 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

It's great to hear that the auto-discovery of tunnel capability is really needed within the scope of a single ISIS domain (oh no, a single area). Thanks:)

> think that the problem is the name; I think that the problem is having two
> incompatible standards for achieving essentially the same thing.

Is the approach as described in draft-ietf-isis-auto-encap workable in the inter-area/inter-level scenario? In other words, could a router advertise its encapsulation capability across levels? If the answer is no, then they are not the same thing since the approach as described in my draft is workable in both intra- and inter-area scenario.

Best regards,
Xiaohu

> 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