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

"Susan Hares" <> Tue, 23 July 2019 14:10 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 0F5F4120306; Tue, 23 Jul 2019 07:10:22 -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 7gNgoqTZVO2n; Tue, 23 Jul 2019 07:10:19 -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 52834120350; Tue, 23 Jul 2019 07:10:09 -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 10:10:02 -0400
Message-ID: <003401d54160$537378c0$fa5a6a40$>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_NextPart_000_0035_01D5413E.CC6CD540"
X-Mailer: Microsoft Outlook 14.0
Thread-Index: AQK7ZHnmeDdYD+Vk9NzGvEj5rX8HVaUL9lyA
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 14:10:30 -0000



#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 three components to proposals:   management of the
E-BGP, enhancements to E-BGP best path selection, and 

                new E-BGP based IP Services. 


                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.    IDR looks at E-BGP best path and the 

               BGP changes for new E-BGP based IP Services.   BESS has been
chartered to work on specifications BGP IP Services.  


                Charter:  Chairs suggest continuing this approach for E-BGP



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?