Re: [Idr] IDR Re-Charter - Issues for Charter

"Susan Hares" <> Tue, 23 July 2019 13:08 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id B8DDB1202BF; Tue, 23 Jul 2019 06:08:52 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: 0.949
X-Spam-Status: No, score=0.949 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DOS_OUTLOOK_TO_MX=2.845, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id q3nw0E0JPNbe; Tue, 23 Jul 2019 06:08:51 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 92A7B1202D9; Tue, 23 Jul 2019 06:08:50 -0700 (PDT)
X-Default-Received-SPF: pass (skip=forwardok (res=PASS)) x-ip-name=;
From: Susan Hares <>
References: <011801d54157$117d6b50$347841f0$>
In-Reply-To: <011801d54157$117d6b50$347841f0$>
Date: Tue, 23 Jul 2019 09:08:45 -0400
Message-ID: <013f01d54157$c2b10940$48131bc0$>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_NextPart_000_0140_01D54136.3BA42430"
X-Mailer: Microsoft Outlook 14.0
Thread-Index: AQK7ZHnmeDdYD+Vk9NzGvEj5rX8HVaUL5k8Q
Content-Language: en-us
X-Antivirus: AVG (VPS 190723-0, 07/23/2019), Outbound message
X-Antivirus-Status: Not-Tested
Archived-At: <>
Subject: Re: [Idr] IDR Re-Charter - Issues for Charter
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Inter-Domain Routing <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Tue, 23 Jul 2019 13:08:53 -0000



I just got an email that I missed some suggestions in my summary.   If I
have missed your suggestion, please let me know or send a note to IDR. 


Cheerily, Sue Hares 


From: Idr [] On Behalf Of Susan Hares
Sent: Tuesday, July 23, 2019 9:04 AM
Subject: [Idr] IDR Re-Charter - Issues for Charter


Greetings all: 


We had the following 9 charter issues that were sent to the IDR list for
consideration.   Below I've included summaries of each of these issues, and
ways these issues could be included in the next IDR Charter.   Based on
these issues, John and I will propose Charter later today.   


Please let us know if you have issues with my summary or if something else
should be added. 


One of the charter items, Next-Hop Definitions will be discussed at BESS
today (15:20-16:50).    The BESS Chairs would like to have IDR look at this
topic during the next charter in conjunction with the BESS
usage/specification in EVPN and other VPNS.   


Cheerily, Susan Hares 




1)      Working on  IPSEC tunnels and other enhancements to the tunnel
encapsulation work


    Summary: draft-ietf-tunnel-encaps-13.txt is ready for publication.  

    There is interest to continue to define other tunnel types. 

     IDR should continue to define the mechanisms, and 

     aid other groups in use case and application. 

     As draft-ietf-tunnel-encaps-13.txt states, Extended 

     Community tunnel encapsulation support should be 

      transition to the new attribute draft


     Charter should include:  New tunnel encapsulation,  RFC5566 revision,
aid to review use cases for BESS 


2)      Auto-configuration 


Summary: Interest exists in auto-configuration, but the first step

                is to get a firm grasp on IDR specific requirements. 

LSVR work is continuing in parallel.


                Charter should include:   IDR general support requirement

                (Zero-touch, peer finding at L2/L3/L4), and then

                Auto-configuration requirement setting should include

                requirements for NETCONF/RESTCONF Yang module interaction.


3)      BGP Security 

Summary:  Concern exists regarding BGP security and the 

peering trust models emerged in the BGP Next-Hop discussion 


Charter:  Understanding the isseus of BGP Security should continue to be a
part of IDR Charter.  The BGP peerin


4)      BGP-LS 



.         IDR needs to guide the general BGP-LS to determine error handling
and growth mechanisms.  

.         Drafts specifying the BGP-LS TLVs created by LSR (ISIS/OSPF)
should be done in combinational drafts, 

And just reviewed by IDR rather than having 2 drafts (LSR and BGP). 


              New Work:  Adopting new error handling ( RFC7752bis) and key
new growth (Segment Routing (mpls and SRV6)) drafts, 

              Review work:  Aiding rapid review of specific new features by

              Gray area:  Where do we place specific new features (policy in
Segment routing, inter-domain BGP-LS) as key growth or features. 


               Charter: Will differentiate between IDR new work and
review/guidance of other WGs. 


5)      IDR as a non-Routing Transport  (N-RIT) 


Summary: no significant discussion on the list.  Chairs will call for input
on 7/24 Meeting 

Note:  Alvaro Retana indicated he would form a BOF if desired on this


Charter:  No additions planned 


6)      E-BGP enhancements


Summary:  E-BGP topic received little discussion on the list.
Traditionally E-BGP enhancements have been an IDR Topic. 

                There are two components to proposals:   management of the
E-BGP and E-BGP enhancements to create new BGP functions.  

                IDR has traditionally leaned on OPS groups (Grow and others)
to get the requirements for the management of E-BGP and the 

                allowed management specific protocols (BMP) to be done
outside of IDR.     


Charter:  Chairs will ask WG if problem continuing the past methodology.


Past methodology: Anything enhancing BGP packets will be done in IDR.  Any
YANG models on the base BGP protocol or E-BGP enhancements.  Anything
proposals in the management of E-BGP will be coordinated with NM/OPS
appropriate group. 



7)      Flowspec 


Summary:  Lengthy debates on RFC5575bis has left a number of
flow-specification drafts with implementations, but no 

RFC.  It is important to push current drafts out to completion. 


               Charter: Rapid completion of existing drafts and new flowspec
drafts included in charter. 



8)      Next-Hop Encoding


Summary:  MPLS, BESS, SPRING and IDR are discussion Next-Hop encodings in
the BGP protocols.  Since IDR is the key place 

to review BGP NextHop encodings, it is important that IDR take an active
stance in making sure the Next-Hop encoding work in 

all revisions of the protocol.   It is also important to know if you can
"trust" the Next-Hop sent or at what level you can trust. 



9)      RFC4271 revision 


Summary:  As far as I can tell, no one has called for a revision of RFC4271.
The BGP specification effort of 

layering other documents on top of RFC4271 seems to continue to work.  Is
this correct?