Subject: [Yang-multicast] FW: [YANG] Emailing IETF about planned alarm and multicast work

From: Marta Seda <[email-masked]>
Date: Tue, 28 Mar 2017 14:24:35 +0000

Hello William,
You asked me to help with what we need to communicate back to IETF.  I’ve seen IETF layer 2 model and it is missing multicast features (not useful in its present form).  The communication to IETF should note those discrepancies and what the multicast model is based (what drove bbf to create a multicast model). Below is suggested text to send to them (explains what the current multicast model contains).   Please feel free to critique.  I wasn’t quite sure what “state” to call the bbf multicast model (rationale for marking it red”).

Regards

Marta

-------------------------------------------------------------------------

The Broadband Forum has developed multicast yang for access network devices that support IGMP/MLD functions.  The BBF multicast yang is designed to support multicast requirements contained in ITU G.988, Broadband forum TR-101, TR-156, and TR-167.  The functions described in those requirement documents include (but not limited to):

  *   Support of proxy and snoop (transparent/snoop with proxy reporting) functions
  *   Support of open access
  *   Support of preview channels and packages
  *   Support of admission control (e.g., maximum number of channels and bandwidth)
  *   Support of static groups (e.g., for testing purposes)
  *   Support of performance monitoring
  *   Support of unregistered joins
We are sending this liaison to inform you about this activity.  The BBF multicast yang is draft and being updated based on straw ballot comments (what state describes the current state of multicast – this or draft? (need editor’s view of the state of the document)).  We understand that IETF has proposed support of layer 2 devices.  The IETF model is missing functionality and it is unclear if it is intended to cover the access product space.   We would like to avoid duplicate work among the SDOs and coordinate yang development for multicast (IGMP/MLD) with you.  There are some areas of collaboration (for example, statistics) that could be coordinate between the SDOs.

From: [email-masked] [mailto:[email-masked]] On Behalf Of William Lupton
Sent: Monday, March 27, 2017 6:09 AM
To: [email-masked]
Subject: [YANG] Emailing IETF about planned alarm and multicast work

All,

In the Common YANG discussions last week, we agreed to discuss sending some emails to the appropriate IETF mailing lists to inform them of our work and plans:

  *   Arising from bbf2017.188.00: Proposal bbf-alarm-management : we want to tell the NETMOD list that we are basing our alarm work on the Vallin draft and will send details of proposed changes asap, plus we’d like to encourage them to adopt the Vallin draft as a WG draft
  *   Arising from bbf2017.101.00: Multicast YANG model : we want to tell the Multicast (and also NETMOD?) list(s) what we are doing (details TBD)
The first NETMOD meeting (here at IETF in Chicago) is Tuesday morning, so ideally we’d send these messages today. I think I know enough to formulate the first (alarm) email but don’t know enough about the multicast work (or how we should present it) to write the second email.

I’ll send a draft first (alarm) email for discussion soon. It will say what I mentioned above, plus I think that we can give some high-level indications of the sorts of changes that we would like to see (they will undoubtedly ask!). I’d appreciate it if others could do the same for the second (multicast) email.

I’m happy to send these emails when they are ready (so that, although not formal liaisons, they can be seen as coming from BBF rather than from an individual member). But any of you can of course at any time post directly to the IETF mailing lists.

Thanks,
William

---

From: Marta Seda <[email-masked]>
Date: Tue, 28 Mar 2017 15:08:21 +0000

Apologies, please ignore the previous email (outlook was a bit too "helpful" and suggested an email alias that was close to the one this email was supposed to go to (but not the same).

Marta