[bess] Update to draft-ietf-bess-mvpn-mib-06
Dear Glenn, Thank you for waiting the update. I have submitted the updated version of draft-ietf-bess-mvpn-mib. Links to the draft and diff are as follows. URL: https://www.ietf.org/internet-drafts/draft-ietf-bess-mvpn-mib-06.txt Htmlized: https://tools.ietf.org/html/draft-ietf-bess-mvpn-mib-06 Htmlized: https://datatracker.ietf.org/doc/html/draft-ietf-bess-mvpn-mib Diff: https://www.ietf.org/rfcdiff?url2=draft-ietf-bess-mvpn-mib-0 This version contains some major changes as follows. I hope this update make the role and usage of the MIB clear for you. +--+ Changes: 1. Support for row creation in all tables is removed Reason: The utility of row creation is dubious. It increases complexity of the MIB implementation. Unless an immediate need for row creation, we will go ahead with the current draft and review the need for row creation at a later date if and when it arises. 2. Added objects to make the role and usage of this MIB clear. Reason: This MIB will provide the following management functions. - Configuration of MVRF related timers - Generation of Notifications to indicate creation, deletion, and/or modification of MVRFs - Generation of Notification when a member joins or leaves a multicast group - Monitoring of the following - attributes of MVRFs of MVPNs - PMSIs - statistics of advertisements exchanged by a PE - routing entries in a MVRF - next-hops for a multicast destination in a MVRF +--+ -- tsuno ___ BESS mailing list BESS@ietf.org https://www.ietf.org/mailman/listinfo/bess
[bess] I-D Action: draft-ietf-bess-mvpn-mib-06.txt
A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the BGP Enabled ServiceS WG of the IETF. Title : BGP/MPLS Layer 3 VPN Multicast Management Information Base Authors : Zhaohui (Jeffrey) Zhang Saud Asif Andy Green Cisco Systems Pradeep G. Jain Hiroshi Tsunoda Filename: draft-ietf-bess-mvpn-mib-06.txt Pages : 67 Date: 2018-04-30 Abstract: This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it describes managed objects to configure and/or monitor MVPN, Multicast in MultiProtocol Label Switching/Border Gateway Protocol (MPLS/BGP) IP Virtual Private Networks (VPNs) on a Provider Edge router. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-bess-mvpn-mib/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-bess-mvpn-mib-06 https://datatracker.ietf.org/doc/html/draft-ietf-bess-mvpn-mib-06 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-bess-mvpn-mib-06 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ ___ BESS mailing list BESS@ietf.org https://www.ietf.org/mailman/listinfo/bess
Re: [bess] Shepherd's review of draft-ietf-bess-df-election-framework
On 4/30/2018 12:40 PM, Ali Sajassi (sajassi) wrote: The DF type is an 8-bit type, so there can be a single valid value. Sorry, for some reason I thought it was a set of flags. My mistake ;-( ___ BESS mailing list BESS@ietf.org https://www.ietf.org/mailman/listinfo/bess
Re: [bess] Shepherd's review of draft-ietf-bess-df-election-framework
Eric, Thank you for the comments. Please see in-line. -Original Message- From: Eric C Rosen Date: Monday, April 30, 2018 at 7:46 AM To: "Satya Mohanty (satyamoh)" , "stephane.litkow...@orange.com" , "bess@ietf.org" , "draft-ietf-bess-evpn-df-election-framework.auth...@ietf.org" Subject: Re: [bess] Shepherd's review of draft-ietf-bess-df-election-framework Resent-From: Resent-To: , , , , , Resent-Date: Monday, April 30, 2018 at 7:46 AM Let me add a couple of minor comments: - The draft should state the action to be taken when receiving a route that has more than one DF Election Extended Community. I think the two possible options are "treat the route as if it did not have any DF Election Extended Community", and "treat-as-withdraw" (defined in RFC 7606). [JORGE] we are fixing that in the next rev. Satya can comment too, but we should treat this in the same way we are treating inconsistencies among the PEs in the ES, i.e. fall back to default DF Election. So that matches your "treat the route as if it did not have any DF Election Extended Community". - The draft should state the action to be taken when receiving a route whose DF Election Extended Community has more than one DF Type bit set. I think the procedures in the draft assume that at most one DF Type bit is set, and may not work properly if multiple DF Type bits are set. [JORGE] I assume you mean "more than one bit in the Bitmap set". The DF Type is a single 0-255 value. This draft sets up the registry and defines only one bit in the Bitmap. For that one we say it can be set or not. As far as this draft is concerned, the other bits have no meaning. New specs with different types of capabilities should clearly state if the new defined bit can be set along with existing capabilities and/or types. Stephane also made a comment similar to this and suggested something like this, that we are adding: o For any new capability defined in the future, the applicability/compatibility of this new capability to the existing DF types must be assessed on a per case by case basis. o Likewise, for any new DF type defined in future, its applicability/compatibility to the existing capabilities must be assessed on a per case by case basis. ___ BESS mailing list BESS@ietf.org https://www.ietf.org/mailman/listinfo/bess
Re: [bess] Shepherd's review of draft-ietf-bess-df-election-framework
Hi Eric, On 4/30/18, 7:46 AM, "Eric C Rosen" wrote: Let me add a couple of minor comments: - The draft should state the action to be taken when receiving a route that has more than one DF Election Extended Community. I think the two possible options are "treat the route as if it did not have any DF Election Extended Community", and "treat-as-withdraw" (defined in RFC 7606). I think treating the route as if it didn't have any DF Election EC, would be preferable IMO because its action is consistent with other scenarios where there is ambiguity and no single DF type can be selected. - The draft should state the action to be taken when receiving a route whose DF Election Extended Community has more than one DF Type bit set. I think the procedures in the draft assume that at most one DF Type bit is set, and may not work properly if multiple DF Type bits are set. The DF type is an 8-bit type, so there can be a single valid value. If you are talking about capability bits, then there a PE can have as many of them set as they can support. Cheers, Ali ___ BESS mailing list BESS@ietf.org https://www.ietf.org/mailman/listinfo/bess
Re: [bess] Shepherd's review of draft-ietf-bess-df-election-framework
Let me add a couple of minor comments: - The draft should state the action to be taken when receiving a route that has more than one DF Election Extended Community. I think the two possible options are "treat the route as if it did not have any DF Election Extended Community", and "treat-as-withdraw" (defined in RFC 7606). - The draft should state the action to be taken when receiving a route whose DF Election Extended Community has more than one DF Type bit set. I think the procedures in the draft assume that at most one DF Type bit is set, and may not work properly if multiple DF Type bits are set. ___ BESS mailing list BESS@ietf.org https://www.ietf.org/mailman/listinfo/bess
