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

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

Juniper also has an implementation of various parts of the draft, as 
needed to support the segment-routing-te-policy draft.  Some other parts 
of the draft have also been implemented as well.

On 5/26/2017 11:26 AM, Acee Lindem (acee) wrote:
> 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