Subject: Re: [i2rs] Regarding Multicast Use Cases for I2RS

From: Jeffrey Haas <[email-masked]>
Date: Mon, 5 Jan 2015 16:12:36 -0500

Robin,

On Tue, Dec 23, 2014 at 07:18:14PM +0000, Lizhenbin wrote:
> Now multicast is an important service in the network such as IPTV, etc.
> But there are complex choice for multicast solutions including L2
> multicast vs. L3 multicast, public multicast vs. multicast VPN, multicast
> based on PIM/BGP/mLDP/P2MP TE/IGP/Ingress replication which make the
> multicast provision difficult. This may be simplified through the I2RS
> intefaces. Could we define the multicast usecase in I2RS WG? And how will
> we define the multicast usecase: enhancing the
> draft-ietf-i2rs-usecase-reqs-summary-00 to incorporate multicast use cases
> or proposing independent multicast use case draft?

Multicast is currently not in charter and our AD has given strong guidance
that we need to finish existing work before we pick up anything new.  That
said, nothing stops you or others from creating an individual submission to
discuss this work.  It may be some time before such a submission could be
adopted by the group though.

Speaking as an individual contributor, multicast provides a significant
number of interesting problems that all must be solved in order to provide
an I2RS-like interface.  For example, these might include:
- Interaction with interface/port yang modules.
- Definition of OIF-lists in YANG.
- Prefix filters (already a coordination issue IETF-wide) for managing
  traffic filtering.
- Interaction with underlying layer 2 technologies for that layer multicast.
  (And the requisite yang that would have to describe layer 2.)
- Interactions with MPLS technologies, most of which are still very new in
  YANG or work has yet to even begin.

While I believe such work is tractable, it is *quite* a bit of work.  It
does have the interesting property that such work may drive requirements for
several other technologies. 

If you feel up to that particular challege this early in IETF Yang work, I
look forward to seeing your drafts. 

-- Jeff

---

From: Behcet Sarikaya <[email-masked]>
Date: Tue, 6 Jan 2015 11:49:18 -0600

Hi Jeff,

> look forward to seeing your drafts.

I have no issue on this decision.

You mentioned YANG three times above, that's where I have a question.
I checked i2rs charter, it does not even mention YANG.
My question is why YANG models became so essential, is it because they
will be the way i2rs solution is developed?
How could this be a solution by rewriting the protocol, e.g. bgp
procedures in YANG format?

A followup question: how can IESG evaluate a thousand or more line YANG program?

I'll appreciate if you could shed some light into this.

Regards,

Behcet

>
> -- Jeff
>
> _______________________________________________
> i2rs mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/i2rs

---

From: Jeffrey Haas <[email-masked]>
Date: Tue, 6 Jan 2015 13:03:28 -0500

Behcet,

> I checked i2rs charter, it does not even mention YANG.

We're remiss in getting our charter updated, and I believe Sue and I will be
discussing that this afternoon.  There had been a decision middle of last
year that we would be pursuing yang as our modeling language and
netconf/restconf as our protocol.  Recent analysis of the suitability of
netconf for our use cases has shown it's not the best fit and we appear to
be moving to restconf.

> procedures in YANG format?

We wouldn't rewrite BGP into yang.  We'd write yang modules for managing
I2RS behaviors for BGP.  In some cases, these may involve extending the yang
modules for BGP that are maintained by other groups such as IDR.

> A followup question: how can IESG evaluate a thousand or more line YANG program?

I think your comment is confused, but please also see the discussion on
[email-masked] regarding a third RTG area director. :-)

-- Jeff

---

From: William Atwood <[email-masked]>
Date: Tue, 06 Jan 2015 13:47:34 -0500

> [email-masked] regarding a third RTG area director. :-)

I don't think this comment is confused at all.  It is clear to me that
the present approach to IETF last call at the IESG level (i.e., all the
Area Directors reading the document) is not going to be particularly
effective when the I-D consists of 1000 lines of Yang code.  This is
quite independent of the number of RTG area directors...

I believe that the WG chairs who are involved in Yang models at any
level need to signal this issue to their Area Director(s), if this has
not already been done.

  Bill

-- 
Dr. J.W. Atwood, Eng.             tel:   +1 (514) 848-2424 x3046
Distinguished Professor Emeritus  fax:   +1 (514) 848-2830
Department of Computer Science
   and Software Engineering
Concordia University EV 3.185     email:[email-masked]
1455 de Maisonneuve Blvd. West    http://users.encs.concordia.ca/~bill
Montreal, Quebec Canada H3G 1M8

---

From: Alia Atlas <[email-masked]>
Date: Tue, 6 Jan 2015 14:02:27 -0500

Hi Bill,

> level need to signal this issue to their Area Director(s), if this has

Do you have recommendations on how the reviews should be done?  Obviously,
verifying that the YANG models compile and having the WG and YANG experts
do a review is quite useful and important beforehand.   The trick with this
is
frequently getting the semantics and details right; obviously, we're all
used to
doing long code reviews too.

Regards,
Alia

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Tue, 6 Jan 2015 20:44:29 +0100

> [email-masked] regarding a third RTG area director. :-)

Big data models	have happened in the past:

$ wc -l RMON-MIB RMON2-MIB
    3952 RMON-MIB
    6019 RMON2-MIB

Even in routing:

$ wc -l BGP4-MIB OSPFV3-MIB
    1298 BGP4-MIB
    4241 OSPFV3-MIB

In addition, things do not have to be monolithic. That said, it is a
good idea to try to keep it simple, stupid.

/js

-- 
Juergen Schoenwaelder           Jacobs University Bremen gGmbH
Phone: +49 421 200 3587         Campus Ring 1, 28759 Bremen, Germany
Fax:   +49 421 200 3103         <http://www.jacobs-university.de/>

---

From: Behcet Sarikaya <[email-masked]>
Date: Tue, 6 Jan 2015 13:49:37 -0600

> $ wc -l BGP4-MIB OSPFV3-MIB

So you are saying that these are MIBs in Yang format?

I see a bgp info model and a data model.
I am confused.

> good idea to try to keep it simple, stupid.

+1

Regards,

Behcet

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Tue, 6 Jan 2015 21:54:05 +0100

> So you are saying that these are MIBs in Yang format?

No. But an argument that the IESG is not able to process 'a thousand
or more line YANG' seems a bit questionable given that they were able
to process data models of thousand of lines in the past.

/js

---

From: William Atwood <[email-masked]>
Date: Thu, 08 Jan 2015 17:53:08 -0500

Alia,

No, I don't have anything specific---my expertise is not in software
evaluation.  I was just concerned that Jeffrey's comment implied that 3
Routing Area directors could solve this problem.

Your response has assured me that some mechanisms are in place, and
(given that fact) I assume that these mechanisms will be refined over
time if the need arises.  :-)

  Bill

On 06/01/2015 2:02 PM, Alia Atlas wrote:
> Hi Bill,
>
> On Tue, Jan 6, 2015 at 1:47 PM, William Atwood
> <[email-masked] <mailto:[email-masked]>> wrote:
>
>
>
>     > [email-masked] <mailto:[email-masked]> regarding a third RTG area
>     director. :-)
>
> do a review is quite useful and important beforehand.   The trick with
> this is 
> frequently getting the semantics and details right; obviously, we're
> all used to
>     <tel:%2B1%20%28514%29%20848-2424%20x3046>
>     <tel:%2B1%20%28514%29%20848-2830>
>     <mailto:[email-masked]>
>     <http://users.encs.concordia.ca/%7Ebill>
>     [email-masked] <mailto:[email-masked]>

---

From: Jeffrey Haas <[email-masked]>
Date: Fri, 9 Jan 2015 10:05:53 -0500

> Routing Area directors could solve this problem.

Note that I didn't say that a third AD will solve this problem.  I referred
people to the discussion about the motivations for adding one.

In general, document review in IETF should follow a well defined process
similar to what is seen in many large software organizations:
- Reviewed by those working on it. (Authors)
- Reviewed by their peers. (Working Group)
- Reviewed by targeted experts, especially for cross-area work.
  (Directorates)
- Reviewed for big-picture architecture. (IESG)

Where things have the appearance of breaking down is when there has been
insufficient review at the lowest layers.  WG chairs should not send along
documents for directorate or AD review without having some certitude about
the document being of high enough quality to do so.  In project management
parlance, they're the gatekeepers.

Yang modules, and MIBs before them, have a few interesting issues that
complicate the normal review process:
- Modeling as a discipline is something that not everyone is good at.  IETF
  tends to attract people who like working bits-on-the-wire, not management
  and operations front-ends.  
- The recognition and inherent rewards for participating in such models in
  IETF lacks quite the same level of prestige from many people's
  perspective.  Basically, "it's not sexy".
- Review of models requires not only the depth of experience in the thing
  being modeled, operations for that thing (which may not have practices if
  it is new) but also strong familiarity with the modeling language and its
  semantics.
  + Yang is new.  That's going to cause some bumps as people learn.
  + As MIBs have demonstrated, sometimes it's less whether something is
    syntactically or semantically correct, it's whether it follows a
    best-practice style.  Those styles are still evolving for Yang.

If the above hold true, the likely fixes are:
- Get many more people familiar with Yang.
- Make sure as best practices evolve that they are rapidly and widely
  disseminated.  (See rtg-yang-coord as one example.)
- Provide the same level of prestige for doing this hard work as for doing a
  new protocol.  "Egoboo"/"Karma" is a valid currency in volunteer run
  organizations such as ours, even though most of our membership tends to be
  sponsored via their jobs.

-- Jeff

---

From: Behcet Sarikaya <[email-masked]>
Date: Fri, 9 Jan 2015 11:59:28 -0600

>   sponsored via their jobs.

I also would like to clarify that my mail was in no way against the
Yang work being done in i2rs, I have great respect in the draft
authors, they are doing great admirable work.

Regards,

Behcet