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

[Xuxiaohu <[e-mail]>]

> -----Original Message-----
> From: Philip Christian [mailto:[e-mail]]
> Sent: Thursday, March 10, 2016 12:46 AM
> 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,
> 
> >> 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?
> 
> It would be simple to define a new sub-TLV for MPLS-in-IP in the existing G.7712
> auto-encap TLV.  There is no need to define an entire new way of advertising
> encapsulation capability.  It would basically consist of taking your RFC5512
> sub-TLVs out of Router Capability TLVs and putting them into the auto-encap
> TLVs instead.  All you would need to do is avoid sub-TLV 1.

It's not that simple as you imagined.

> > I would have to remind you that the above text is quoted from the main
> > text (see section 3.3) rather than the annex.
> 
> The main text can be changed.  In the end these are both standards for flooding

The whole document can be changed:)

> of encapsulation capabilities.  Provided that it doesn't break
> G.7712 it can be changed but remain compatible.

Remain compatible? See below.

> > 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.
> >
> 
> This is the most difficult aspect.  Router Capability TLVs have the flags to control
> whether features are advertised out of area or not.
> When the auto-encap feature of G.7712 was written this was not considered.
> An auto-encap TLV can be using in either L1 or L2 but the flooding of the
> information across the boundary was not considered.  At the time this seemed
> dangerous, and the idea really was that the L1-L2 router should natively support
> all protocols which means that no tunnels would ever need to cross the
> boundary, and so no leaking of encap capability across the boundary would be
> needed either.  This feature would have to be replicated with a new sub-TLV to
> tell the L1-L2 router whether to flood the information in/out of an area, with the
> default being to not flood it I suppose.

It seems that you wanna reinvent a new instance of router capability TLV:). Even so, how do you ensure that " it doesn't break G.7712 it can be changed but remain compatible."

> Because G.7712 auto-encap was written from the beginning with sub-TLVs, just
> like Router Capability, it can expanded to contain any feature you wish, including
> all of the ones present in draft-xu-isis-encapsulation-cap.

According to the following text from RFC4271:

"   This document defines a new optional IS-IS TLV named CAPABILITY,
   formed of multiple sub-TLVs, which allows a router to announce its
   capabilities within an IS-IS level or the entire routing domain.  The
   applications mentioned above require the specification of new sub-
   TLVs carried within the CAPABILITY TLV defined in this document.

   Definition of these sub-TLVs is outside the scope of this document."

It's straightforward to use a sub-TLV of the Router Capability TLV to advertise a certain capability of a router.

Anyway, even there was some implementation of G.7712 which in turn depends on an expired I-D, it should not prevent the IETF to define a more reasonable solution. The relationship between RFC5512 and https://tools.ietf.org/html/draft-ietf-idr-tunnel-encaps-01 is a good example.

Best regards,
Xiaohu

> regards, Philip