Subject: Genart telechat review of draft-ietf-bier-mpls-encapsulation-09

From: Peter Yee <[email-masked]>
Date: Mon, 16 Oct 2017 14:22:06 -0700

Reviewer: Peter Yee
Review result: Ready with Issues

I am the assigned Gen-ART reviewer for this draft. The General Area
Review Team (Gen-ART) reviews all IETF documents being processed
by the IESG for the IETF Chair. Please wait for direction from your
document shepherd or AD before posting a new version of the draft.

For more information, please see the FAQ at

<https://trac.ietf.org/trac/gen/wiki/GenArtfaq>.

Document: draft-ietf-bier-mpls-encapsulation-09
Reviewer: Peter Yee
Review Date: 2017-10-16
IETF LC End Date: 2017-10-16
IESG Telechat date: 2017-10-26

Summary:  This well-written draft is an Experimental specification for how
encapsulation is performed in the BIER architecture in order to optimally
forward a packet through a multicast domain while not being burdensome to
intermediate routers.

This draft is ready with issues.

Major issues: None.

Minor issues: This Experimental draft specifies that entries to its BIER Next
Protocol Identifiers registry are to be done according to the "Standards
Action" policy of RFC 8126.  It's not entirely clear to me whether RFC 8126's
requirement that such entries be from Standards Track or BCP documents applies
to the initial set of values.  If it does, then there's an issue here between
RFC 8126 and this draft's desired status.

Nits/editorial comments:

General:

Replace "ethernet" with "Ethernet" throughout.

Replace "ethertype" with "Ethertype" or "EtherType" throughout.  (IEEE usage is
varies between the two, unfortunately.)

Specific:

Page 3, second bullet item: change "is" to "are".

Page 4, last paragraph: this paragraph is redundant to one it follows fairly
closely in Section 1.  Consider striking it, although it's not harmful.

Page 5, Section 2.1.1.1, 1st paragraph, 3rd sentence: change "ISIS" to "IS-IS".

Page 9, OAM definition, 1st paragraph, second sentence: delete a duplicated
"the" in the sentence.

Page 10, Section 2.1.3, 1st paragraph, 2nd sentence: delete a duplicated "in"
from the sentence.

---

From: Tony Przygienda <[email-masked]>
Date: Mon, 16 Oct 2017 14:32:59 -0700

Valid issue, probably for the AD to ponder on ;-)

 Maybe the following will serve us best here

* 4.6 Specification Required +

* 4.7 RFC Required +

* 4.8 IETF Review

which doesn't precondition Standards track but for all practical purposes
does the full rigmarole otherwise ...

thanks

--- tony

---

From: Alia Atlas <[email-masked]>
Date: Mon, 16 Oct 2017 20:01:32 -0400

I don't believe that a document has to be Standards Track to create a
registry that will require Standards Track going forward.
It is a bit unusual, but I don't see a process problem.

Regards,
Alia

---

From: Eric C Rosen <[email-masked]>
Date: Tue, 17 Oct 2017 09:27:04 -0400

> It is a bit unusual, but I don't see a process problem.

If our documents get converted to Standards Track, this won't be a 
problem.  But if they stay Experimental for an extended period of time, 
an issue could arise the next time we need to allocate a codepoint.   
("Since you have no Standards Track documents, we can't allow you to 
register any codepoints in registries with "Standards Action" policy.)  
So we might want a registration policy that will allow codepoint 
allocations to be done in Experimental track documents that are accepted 
by the WG.  Maybe we should change the registration policy to "IETF 
Review".  That seems to be almost the same as Standard Action, but does 
not require Standards Track documents.  And it is still eligible for 
Early Allocation.

---

From: Alia Atlas <[email-masked]>
Date: Tue, 17 Oct 2017 11:01:50 -0400

On Tue, Oct 17, 2017 at 9:27 AM, Eric C Rosen <[email-masked]> wrote:

> problem.  But if they stay Experimental for an extended period of time, an
> issue could arise the next time we need to allocate a codepoint.   ("Since
> you have no Standards Track documents, we can't allow you to register any
> codepoints in registries with "Standards Action" policy.)  So we might want
> a registration policy that will allow codepoint allocations to be done in
> Experimental track documents that are accepted by the WG.  Maybe we should
> change the registration policy to "IETF Review".  That seems to be almost
> the same as Standard Action, but does not require Standards Track
> documents.  And it is still eligible for Early Allocation.

True enough.  That could work as well.  I don't see near-term updates to
the Next Protocol registry as very likely, but I'd be fine with this
approach.

Regards,
Alia

---

From: Antoni Przygienda <[email-masked]>
Date: Tue, 17 Oct 2017 15:03:24 +0000

There was already a half-way animated discussion whether we should carry VxLAN natively ;-)

Just saying …

And IMO IETF review would work …

--- tony

<[email-masked]<mailto:[email-masked]>> spake:

On Tue, Oct 17, 2017 at 9:27 AM, Eric C Rosen <[email-masked]<mailto:[email-masked]>> wrote:
On 10/16/2017 8:01 PM, Alia Atlas wrote:
I don't believe that a document has to be Standards Track to create a registry that will require Standards Track going forward.
It is a bit unusual, but I don't see a process problem.

If our documents get converted to Standards Track, this won't be a problem.  But if they stay Experimental for an extended period of time, an issue could arise the next time we need to allocate a codepoint.   ("Since you have no Standards Track documents, we can't allow you to register any codepoints in registries with "Standards Action" policy.)  So we might want a registration policy that will allow codepoint allocations to be done in Experimental track documents that are accepted by the WG.  Maybe we should change the registration policy to "IETF Review".  That seems to be almost the same as Standard Action, but does not require Standards Track documents.  And it is still eligible for Early Allocation.

True enough.  That could work as well.  I don't see near-term updates to the Next Protocol registry as very likely, but I'd be fine with this approach.

Regards,
Alia