Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 37102120363; Tue, 23 Jul 2019 06:03:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.948 X-Spam-Level: X-Spam-Status: No, score=0.948 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] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qPr4aHRDHj9O; Tue, 23 Jul 2019 06:03:57 -0700 (PDT) Received: from hickoryhill-consulting.com (50-245-122-100-static.hfc.comcastbusiness.net [50.245.122.100]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6C99E120344; Tue, 23 Jul 2019 06:03:56 -0700 (PDT) X-Default-Received-SPF: pass (skip=loggedin (res=PASS)) x-ip-name=207.115.96.130; From: "Susan Hares" To: Cc: , , "'Alvaro Retana'" , "'Vigoureux, Martin \(Nokia - FR/Paris-Saclay\)'" Date: Tue, 23 Jul 2019 09:03:48 -0400 Message-ID: <011801d54157$117d6b50$347841f0$@ndzh.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0119_01D54135.8A6BCB50" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AdVBVwQxTW730i6NTCewzi9PkYiW7g== Content-Language: en-us X-Antivirus: AVG (VPS 190723-0, 07/23/2019), Outbound message X-Antivirus-Status: Not-Tested X-Authenticated-User: skh@ndzh.com Archived-At: Subject: [Idr] IDR Re-Charter - Issues for Charter X-BeenThere: idr@ietf.org 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:04:03 -0000 This is a multipart message in MIME format. ------=_NextPart_000_0119_01D54135.8A6BCB50 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit 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? ------=_NextPart_000_0119_01D54135.8A6BCB50 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

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

      transitio= n 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

         &= nbsp;      is to get a firm grasp on IDR = specific requirements.

LSVR work is continuing in = parallel.

 

         &= nbsp;      Charter should include:  =  IDR general support requirement setting

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

         &= nbsp;      Auto-configuration requirement = setting should include

         &= nbsp;      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).

 

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

         &= nbsp;    Review work:  Aiding rapid review of = specific new features by review

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

 

=             &= nbsp;  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.

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

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

         &= nbsp;      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. =

 

         &= nbsp;      

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.

 

         &= nbsp;     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? =

------=_NextPart_000_0119_01D54135.8A6BCB50--