Re: [Idr] I-D Action: draft-ietf-idr-tunnel-encaps-00.txt

[Eric C Rosen <[e-mail]>]

Originally I was hoping to leave RFC5512 in place, and just have the
tunnel-encaps draft update it.  But the feedback (both public and
private) has been overwhelmingly in favor of obsoleting RFC5512, with
the goal of having a single RFC that specifies the tunnel encapsulation
attribute.  Then folks won't have to figure out exactly which parts of
RFC5512 still apply and which parts don't.

With regard to encaps-SAFI, given that there are zero implementations
(assuming that Lou withdraws his ;-)), zero deployments, and (as far as
I can tell) no current interest in implementing or deploying it, I don't
think it makes sense to carry it forward in the new document.

Of course, nothing stops someone from writing a new draft specifying
something like the Encaps-SAFI, and specifying the semantics of
attaching various attributes (including the tunnel encapsulation
attribute) to it.

If the tunnel-encaps draft is to obsolete RFC5512, I think it will need
to incorporate the material on the encapsulation extended community, and
on the various sub-tlvs that are defined in RFC5512.  Note that the
tunnel-encaps draft already specifies how the encapsulation extended
community interacts with the tunnel encapsulation attribute.

I believe that the material in RFC5566 (on using the tunnel
encapsulation attribute to specify various sorts of IPsec tunnels) is
complex enough to merit an RFC of its own.  So I would propose that the
tunnel-encaps draft not include material from RFC5566, but that a
separate rfc5566bis draft be prepared.