Subject: [Bier] Proposed mods for architecture draft

From: Eric C Rosen <[email-masked]>
Date: Tue, 20 Jun 2017 15:54:19 -0400

We need to remember that we have begun the process of moving the initial 
set of standards to RFC status.  Thus, this is not a good time to be 
adding features.  It is also not a good time to be changing the 
assumptions we've been working with for the past few years.  So I want 
to take a fairly conservative approach to making changes.

With that in mind, I would like to propose replacing the first two 
paragraphs of section 2 with the following four paragraphs:

--------

2.  The BFR Identifier and BFR-Prefix

    Each BFR MUST be assigned a "BFR-Prefix".  A BFR's BFR-Prefix MUST be
    an IP address (either IPv4 or IPv6) of the BFR, and MUST be routable
    within the BIER domain.  It is RECOMMENDED that the BFR-prefix be a
    loopback address of the BFR.  Note that a BFR in a given BIER domain
    has the same BFR-prefix in all the sub-domains of that BIER domain.

    This document assumes that, within a domain, the mapping between BFR
    and BFR-Prefix is one-to-one.  Situations in which that assumption
    does not hold are outside the scope of this document.

    A "BFR Identifier" (BFR-id) is a number in the range [1,65535].  In a
    given BIER sub-domain, each BFR-Prefix is associated with a number
    from this range.  If it is known that a given BFR will never need to
    function as a BFER or BFIR in a given sub-domain, then it is not
    necessary to assign a BFR-id for that sub-domain to that BFR.

    This document assumes that, within a sub-domain, the mapping between
    BFR-id and BFR-Prefix is one-to-one.  Situations in which that
    assumption does not hold are outside the scope of this document.

--------

This maintains the same assumptions we've worked with for the past 
several years, but leaves it open for future documents to consider 
whether it makes sense to loosen some of the assumptions.

Comments?

I think this is the only area of controversy that has come up recently.

I don't think we want to consider now what all the possible implications 
might be of changing the assumptions, so I think our only two 
alternatives are (a) leave the text as is, or (b) something like I've 
suggested above.

We certainly do not want to design a v4-to-v6 transition scheme before 
advancing the document, and I'm at all sure that there will be a "one 
size fits all" solution.

The other LC comments are more straightforward:

- Make the document more even-handed between the MPLS and non-MPLS 
encapsulations (which required textual changes in about half a dozen 
places),

- Add a few remarks about the decapsulation procedure,

- RECOMMEND a BitStringLength fallback value of 256,

- Fix a bug in the F-BM values in some of the examples.

These are fixed in the XML source, but I don't want to post a new rev 
until we have some consensus on how to deal with the one area of 
controversy.

---

From: Xuxiaohu <[email-masked]>
Date: Wed, 21 Jun 2017 02:13:26 +0000

Hi all,

It's great to see that the concept of non-MPLS encapsulation is eventually accepted by the WG. However, the current non-MPLS BIER header as defined in draft-ietf-bier-mpls-encapsulation has no significant difference from the MPLS-BIER header, IMHO. The major change is just to rename the 20-bit MPLS label as the Bit Index Forwarding Table (BIFT) ID with realignment of fields. That's to say, no matter in the MPLS-BIER header or the non-MPLS-BIER header, the SI and Sub-domain values which are needed for BIFT lookup are not explicitly contained in the BIER packet. My question is why not directly encode the SI and Sub-domain in the BIER packet?

Best regards,
Xiaohu

---

From: Tony Przygienda <[email-masked]>
Date: Wed, 21 Jun 2017 00:04:33 -0700

Eric, I'm for it with few clarifying nits:

1. "Each BFR MUST be assigned *a BIER domain-wide unique* "BFR-Prefix". A
*<deleted>* BFR-Prefix MUST be
   *a) *an IP *prefix *(*one and only one *of either IPv4 or IPv6) of the
BFR *and *
*  b) MUST come from** the same AF for all BFRs in the BIER domain* and
  c) MUST be routable within the BIER domain.

<deleted> Situations in which *those assumptions*
   does not hold are outside the scope of this document.

"

2. "This document assumes that, within a sub-domain, the mapping between
   BFR-id and BFR-Prefix is one-to-one.  Situations in which that
   assumption does not hold are outside the scope of this document."

   is strictly speaking a tautology of the previous two paragraphs.

This allows BTW a clean future flexibility where we can declare two BIER
domains overlapping same physical topology, one being IPv4-prefix carrying
and another IPv6-prefix carrying and for controllers one possibly without
even a routing underlay or in other terms BIER domains distinguished by
different signaling types ...

 --- tony

On Tue, Jun 20, 2017 at 12:54 PM, Eric C Rosen <[email-masked]> wrote:

> set of standards to RFC status.  Thus, this is not a good time to be adding
> features.  It is also not a good time to be changing the assumptions we've
> been working with for the past few years.  So I want to take a fairly
> conservative approach to making changes.
>
> This maintains the same assumptions we've worked with for the past several
> years, but leaves it open for future documents to consider whether it makes
> sense to loosen some of the assumptions.
>
> Comments?
>
> might be of changing the assumptions, so I think our only two alternatives
> are (a) leave the text as is, or (b) something like I've suggested above.
>
> advancing the document, and I'm at all sure that there will be a "one size
> fits all" solution.
>
> _______________________________________________
> BIER mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/bier
>

-- 
*We’ve heard that a million monkeys at a million keyboards could produce
the complete works of Shakespeare; now, thanks to the Internet, we know
that is not true.*
—Robert Wilensky

---

From: Tony Przygienda <[email-masked]>
Date: Wed, 21 Jun 2017 00:10:15 -0700

Xiaohu, the BIER mailing list archived several discussions dealing with
that very issue and a widely announced interim has been held to converge
the different strains of thought. I suggest to reference the according mail
archives/meeting minutes for documentation how the consensus process ran
its due course ...

thanks

--- tony

On Tue, Jun 20, 2017 at 7:13 PM, Xuxiaohu <[email-masked]> wrote:

> Hi all,
>
> It's great to see that the concept of non-MPLS encapsulation is eventually
> accepted by the WG. However, the current non-MPLS BIER header as defined in
> draft-ietf-bier-mpls-encapsulation has no significant difference from the
> MPLS-BIER header, IMHO. The major change is just to rename the 20-bit MPLS
> label as the Bit Index Forwarding Table (BIFT) ID with realignment of
> fields. That's to say, no matter in the MPLS-BIER header or the
> non-MPLS-BIER header, the SI and Sub-domain values which are needed for
> BIFT lookup are not explicitly contained in the BIER packet. My question is
> why not directly encode the SI and Sub-domain in the BIER packet?
>
> Best regards,
> Xiaohu
>

---

From: IJsbrand Wijnands <[email-masked]>
Date: Wed, 21 Jun 2017 09:52:48 +0200

Eric, WG,

Sub-domains are signalled independently and operate independently of each other. I think that the text "Note that a BFR in a given BIER domain has the same BFR-prefix in all the sub-domains of that BIER domain.” is an textual restriction, but not a restriction in the architecture as how we defined it.

Based on Alia’s comment and the discussion we just had, I see no problem to allow different sub-domain’s on a given BFR to be associated with a different BFR-prefix.

I agree we don’t want to add new features to the architecture draft at this stage, but in this case, the feature is already there, we’re just restricting it by the current text.

Thx,

Ice.

> On 20 Jun 2017, at 21:54, Eric C Rosen <[email-masked]> wrote:
> 
> We need to remember that we have begun the process of moving the initial set of standards to RFC status.  Thus, this is not a good time to be adding features.  It is also not a good time to be changing the assumptions we've been working with for the past few years.  So I want to take a fairly conservative approach to making changes.
> 
> With that in mind, I would like to propose replacing the first two paragraphs of section 2 with the following four paragraphs:
> 
> --------
> 
> This maintains the same assumptions we've worked with for the past several years, but leaves it open for future documents to consider whether it makes sense to loosen some of the assumptions.
> 
> Comments?
> 
> I don't think we want to consider now what all the possible implications might be of changing the assumptions, so I think our only two alternatives are (a) leave the text as is, or (b) something like I've suggested above.
> 
> We certainly do not want to design a v4-to-v6 transition scheme before advancing the document, and I'm at all sure that there will be a "one size fits all" solution.
> 
> - Make the document more even-handed between the MPLS and non-MPLS encapsulations (which required textual changes in about half a dozen places),
> 
> These are fixed in the XML source, but I don't want to post a new rev until we have some consensus on how to deal with the one area of controversy.
> 
>

---

From: Eric C Rosen <[email-masked]>
Date: Wed, 21 Jun 2017 11:13:11 -0400

Based on the comments from Ice and Tony, I propose to begin Section 2 
with the following text:

----------

    Each BFR MUST be assigned a single "BFR-Prefix" for each sub-domain
    to which it belongs.  A BFR's BFR-Prefix MUST be an IP address
    (either IPv4 or IPv6) of the BFR.  It is RECOMMENDED that the
    BFR-prefix be a loopback address of the BFR.

    If a BFR belongs to more than one sub-domain, it may (though it need
    not) have a different BFR-prefix in each sub-domain.

    All BFR-Prefixes used within a given sub-domain MUST belong to the
    same address family (either IPv4 or IPv6).

    The BFR-prefix of a given BFR in a given sub-domain MUST be routable
    in that sub-domain.  Whether a particular BFR-Prefix is routable in a
    given sub-domain depends on the "routing underlay" associated with
    that sub-domain.  The notion of "routing underlay" is described in
    Section 4.1.

    A "BFR Identifier" (BFR-id) is a number in the range [1,65535].
    Within a given sub-domain, every BFR that may need to function as a
    BFIR or BFER MUST have a single BFR-id, which identifies it uniquely
    within that sub-domain.  A BFR that does not need to function as a
    BFIR or BFER in a given sub-domain does not need to have a BFR-id in
    that sub-domain.

    The value 0 is not a legal BFR-id.

-----------

We thus retain the requirements that in a given sub-domain, (a) a BFR 
has one BFR-Prefix, (b) a BFR-id maps to a single BFR-Prefix, and (c) a 
BFR-Prefix maps to at most one BFR-id.  But we eliminate the unnecessary 
requirement that a BFR has the same BFR-Prefix in all sub-domains.

I was wondering whether we really want to require that all BFR-Prefixes 
in a given sub-domain be of the same address family.  It might be enough 
to require only that all such prefixes are routable in the routing 
underlay of that sub-domain.  However, restricting a sub-domain to a 
single AF is probably a good simplifying assumption.  (It will be nice 
if the overlay signaling doesn't have to deal with multiple address 
families in a single sub-domain.)

It's been pointed out that this prevents a set of BFERs from having a 
shared anycast address as an additional BFR-Prefix.  I am not too 
bothered by this as the use of anycast addresses by multicast receivers 
doesn't seem too crucial, and allowing that would count as a "new feature".

Objections?

On related issues ...

Taking a quick look at the OSPF and ISIS drafts, I think it would be a 
good idea if each draft had a sentence saying precisely where the 
BFR-Prefix appears in the advertisements.

The MVPN draft needs a modification to require that the "Originating 
Router's IP Address" field of the Leaf A-D route NLRI be set to the 
originating router's BFR-Prefix in the sub-domain on which it intends to 
receive the packets.  I don't know if there is a similar issue for other 
overlay signaling drafts.

---

From: Alia Atlas <[email-masked]>
Date: Wed, 21 Jun 2017 11:26:26 -0400

This discussion and the proposed text satisfy my concerns.

Thanks,
Alia

On Wed, Jun 21, 2017 at 11:13 AM, Eric C Rosen <[email-masked]> wrote:

> Based on the comments from Ice and Tony, I propose to begin Section 2 with
> the following text:
>
> ----------
>
> We thus retain the requirements that in a given sub-domain, (a) a BFR has
> one BFR-Prefix, (b) a BFR-id maps to a single BFR-Prefix, and (c) a
> I was wondering whether we really want to require that all BFR-Prefixes in
> a given sub-domain be of the same address family.  It might be enough to
> require only that all such prefixes are routable in the routing underlay of
> that sub-domain.  However, restricting a sub-domain to a single AF is
> probably a good simplifying assumption.  (It will be nice if the overlay
> signaling doesn't have to deal with multiple address families in a single
> sub-domain.)
>
> shared anycast address as an additional BFR-Prefix.  I am not too bothered
> by this as the use of anycast addresses by multicast receivers doesn't seem
> too crucial, and allowing that would count as a "new feature".
>
> Objections?
>
>
>
> On related issues ...
>

---

From: IJsbrand Wijnands <[email-masked]>
Date: Wed, 21 Jun 2017 18:24:12 +0200

Thanks Eric, this text works for me!

> It's been pointed out that this prevents a set of BFERs from having a shared anycast address as an additional BFR-Prefix.  I am not too bothered by this as the use of anycast addresses by multicast receivers doesn't seem too crucial, and allowing that would count as a "new feature".
> 
> Objections?

Nope!

Thx,

Ice.

---

From: Greg Shepherd <[email-masked]>
Date: Wed, 21 Jun 2017 09:30:15 -0700

Great! Looks like we have consensus on the issues.

Alia,

Do this changes warrant are revision or editor notes?

Greg

---

From: Tony Przygienda <[email-masked]>
Date: Wed, 21 Jun 2017 10:11:54 -0700

Looks good to me now, Eric.  I do vote for keeping the *"v4 XOR v6 BFR
prefix for all BFRs in a subdomain"* relationship as KISS

Attached what I see we are talking about here now given the language is
being stretched here quite a bit ...

--- tony

---

From: Alia Atlas <[email-masked]>
Date: Wed, 21 Jun 2017 13:26:15 -0400

New revision please.  It's easier to have the document fully updated for
various reviews.

Thanks,
Alia

---

From: Greg Shepherd <[email-masked]>
Date: Wed, 21 Jun 2017 10:34:56 -0700

Good. :)

Which ever author has the cookie, can you please rev and resubmit. We'll
restart the timer from there.

Thanks,
Greg

---

From: Greg Shepherd <[email-masked]>
Date: Wed, 21 Jun 2017 10:35:40 -0700

Uh, oh.. Looks like that was just done. Thanks!

Greg

---

From: Xuxiaohu <[email-masked]>
Date: Thu, 22 Jun 2017 06:11:28 +0000

Hi Tony,

Many initial rationales of using BIER-labels to retrieve SI/Sub-domain values rather than encoding them directly in the BIER packet has been shaken:

1)    The use of the BIER-label as a lookup key was thought better than the use of the combination of SI, Sub-domain and BSL as a lookup key from the BIFT lookup efficiency perspective. Initially, the MPLS-BIER label is used to retrieve SI, Sub-domain and BSL values. However, the BSL value has now been encoded directly in the BIER header. As a result, the MPLS-BIER label is now only used to retrieve SI/Sub-domain values. Therefore, the advantage of the BITF lookup efficiency is gone.

2)    There was no need to request an Ethernet type code for the BIER header due to the BIER-MPLS label. Now since the WG has decided to specify a non-MPLS encapsulation anyway. The advantage of avoiding the assignment of an Ethernet type code is gone as well.

3)    It was possible to add additional fields into the BIER forwarding decision by using the MPLS-BIER label as an indirection. However, since the BIER header itself has a version field and the BIER specifications are now defined as Experimental rather than Standard Track, and most importantly, there has been no hardware implementation of BIER yet AFAIK, the above advantage is much trivial.

Hence, I think it’s worthwhile for the WG to revaluate the necessity of introducing the BIER-label into the BIER header, especially when the WG has agreed to define a generic BIER header.

Best regards,
Xiaohu

发件人: Tony Przygienda [mailto:[email-masked]]
发送时间: 2017年6月21日 15:10
收件人: Xuxiaohu
抄送: Eric C Rosen; BIER ([email-masked])
主题: Re: [Bier] comments on draft-ietf-bier-mpls-encapsulation

Xiaohu, the BIER mailing list archived several discussions dealing with that very issue and a widely announced interim has been held to converge the different strains of thought. I suggest to reference the according mail archives/meeting minutes for documentation how the consensus process ran its due course ...

thanks

--- tony

On Tue, Jun 20, 2017 at 7:13 PM, Xuxiaohu <[email-masked]<mailto:[email-masked]>> wrote:
Hi all,

Best regards,
Xiaohu

_______________________________________________
BIER mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/bier

--
We’ve heard that a million monkeys at a million keyboards could produce the complete works of Shakespeare; now, thanks to the Internet, we know that is not true.
—Robert Wilensky

---

From: "Jeffrey (Zhaohui) Zhang" <[email-masked]>
Date: Mon, 26 Jun 2017 15:20:56 +0000

Hi Xiaohu,

Please see zzh> below.

From: BIER [mailto:[email-masked]] On Behalf Of Xuxiaohu
Sent: Thursday, June 22, 2017 2:11 AM
To: Tony Przygienda <[email-masked]>
Cc: BIER ([email-masked]) <[email-masked]>; Eric Rosen <[email-masked]>
Subject: [Bier] 答复: comments on draft-ietf-bier-mpls-encapsulation

Hi Tony,

Zzh> Please see the following text on page 8:

   BSL:

      This 4-bit field encodes the length in bits of the BitString.

      Note: When parsing the BIER header, a BFR MUST infer the length of
      the BitString from the BIFT-id, and MUST NOT infer it from the
      value of this field.  This field is present only to enable off-
      line tools (such as LAN analyzers) to parse the BIER header.

Zzh> Since we want to be able to support BIER in a non-MPLS environment, we have to request an ethernet type code. That does not mean a critical pillar of the BIER-MPLS label method is gone.

Zzh> Even though the version number could increase, we don’t want to spin new hardware too often, right?

Jeffrey

Best regards,
Xiaohu

发件人: Tony Przygienda [mailto:[email-masked]]
发送时间: 2017年6月21日 15:10
收件人: Xuxiaohu
抄送: Eric C Rosen; BIER ([email-masked]<mailto:[email-masked]>)
主题: Re: [Bier] comments on draft-ietf-bier-mpls-encapsulation

thanks

--- tony

Best regards,
Xiaohu