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

[Lou Berger <[e-mail]>]

Eric,
    I (obviously) support deprecating the Encap SAFI.  If this is the WG
consensus, then I sign up to  doing/driving a 5566bis that is aligned
with your new draft (I already have the core text done.)

If for some reason the WG decides to preserve  the Encap SAFI, I think
draft-ietf-idr-tunnel-encaps needs to cover how 5566 functionality works
with just using Encap Attribute.

Lou

On 9/2/2015 12:35 PM, Eric C Rosen wrote:
> 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.
>
>
>
>
>
>