Re: [Idr] Working group last call for draft-ietf-idr-tunnel-encaps-04

["Acee Lindem (acee)" <[e-mail]>]

Hi Job, 
Cisco is supporting Tunnel Attribute parsing and propagation as well as
the TE-Policy tunnel type in an unreleased version of IOS-XR. The SR-TE
Policy draft is 
https://www.ietf.org/id/draft-previdi-idr-segment-routing-te-policy-05.txt.
Thanks,
Acee 

On 5/25/17, 9:54 AM, "Idr on behalf of Job Snijders" <[e-mail]
on behalf of [e-mail]> wrote:

>Dear all,
>
>TL;DR: I do not support advancing this document at this time. Lack of
>full-spec implementation experience, and little feedback from actual
>implementers, lead me to not support progression of this document. I
>understand that this position has little to do with the actual contents
>of the document.
>
>On Sun, May 21, 2017 at 03:58:29PM -0400, Lou Berger wrote:
>> On 05/20/2017 03:47 PM, John G. Scudder wrote:
>> > A working group last call has been requested for
>> > draft-ietf-idr-tunnel-encaps-04. Please reply to the list with your
>> > comments. As usual note we cannot advance the draft without
>> > participation from the group. Please get your comments in before
>> > June 5, 2017.
>> 
>> - Since the question was raised on list: a partial implementation of
>> this draft can be found in FRRouting, notably bgp_encap_tlv.{h,c} in
>> https://github.com/FRRouting/frr/tree/master/bgpd . It supports:
>> 
>>  o encap attribute sent with other safis.  The code uses it with the
>>    VPN safi to provide underlay tunnel information for VPN routes for
>>    NVO3 type applications.
>> 
>>  o "Remote Endpoint Address sub-TLV" for v4 and v6
>> 
>>  o encode/decode of type specific and sub-TLV formats
>>    per draft -00 or -01 rev (this means it is a subset implementation.
>
>Cool stuff, thanks for sharing that!
>
>While John Scudder pointed out that there is no blocking requirement for
>a document to have implementations before passing through WG LC. I (and
>probably participants too) am of the opinion that actual feedback from
>implementers is extremely valuable.
>
>Should an implementer find an actual technology issue, or lack of
>clarity in the wording of the document, as long as the document in the
>WG it'll be trivial to resolve any issues. I understand that there are
>ways to modify a document after WG LC, but I think its simpler to be
>able to say to the working group itself "this technology works, i have
>an implementation".
>
>Should someone write a partial implementation, that might be a hint that
>the document needs to be split up (or perhaps it is of no significance).
>To properly assess a document, I hope for feedback from full
>implementations (perhaps two technology components within a doc conflict
>with each other). If parts of an Internet-Draft are not implemented by
>anyone, I'd advocate the document should not (yet) progress further.
>
>With "implementation" i don't mean that you are shipping code to
>customers, I'm fine with stuff hanging in private beta branches - all
>I'm looking for is an attestation that the implementer found the
>full specification implementable. RFC7942 is good guidance.
>
>I'd like to request the chairs to consider a slight adjustment of the
>procedure: encourage the working group to create implementations
>_before_ WGLC, so the working group can take implementer feedback into
>account when assessing the proposed document.
>
>Kind regards,
>
>Job
>
>ps. if two full implementations show up during this WGLC, I will
>ofcourse withdraw my non-support.
>
>_______________________________________________
>Idr mailing list
>[e-mail]
>https://www.ietf.org/mailman/listinfo/idr