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

["Susan Hares" <[e-mail]>]

Greetings: 

 

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 [mailto:[e-mail]] On Behalf Of Susan Hares
Sent: Tuesday, July 23, 2019 9:04 AM
To: [e-mail]
Cc: [e-mail]; [e-mail]
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
setting 

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

                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 

 

Summary:  

.         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
review 

              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
subject. 

 

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?