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

[Philip Christian <[e-mail]>]

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.

> 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 of encapsulation capabilities.  Provided that it doesn't break
G.7712 it can be changed but remain compatible.

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

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.

regards, Philip