Subject: [Bier] Consensus on how we deliver the multiple ENCAPS section

From: Tony Przygienda <[email-masked]>
Date: Wed, 14 Feb 2018 08:04:13 -0800

So, I don't see consensus how we update the drafts in IETF LC regarding
multiple encapsulations to make sure we don't deliver RFCs that can
blackhole based on different implementations. I don't think it's very
contentious but I suggest we need a consensus on anything from this list
(written in my order of preference but whatever can be consensus-built is
fine for me and I hope we don't have a different one for each protocol ;-):

a) Use the section that I think Les put into ISIS but I basically fully
agree on. Only hole is see there that we won't be able to order the encaps
based on preference but I think it maybe a degree of detail/flexibility
no'one will ever care about.
b) Write that computation in presence of multiple encapsulations is
unspecified currently and future draft/RFC has to be referred to. That's
the "here be dragons" sign which is good enough to make sure that people
test interop and know you have to be careful in such case
c) Leave the original section per ISIS which is overly restrictive (I think
Les thinks it's even wrong)

I do not think "say nothing" is acceptable since that's basically a
blackholing spec we deliver then ...

Read the update of both drafts put out today, it's good and important
technical nit IMO ...

--- tony

---

From: Eric C Rosen <[email-masked]>
Date: Wed, 14 Feb 2018 16:17:42 -0500

I think there are a couple of facts that need to be taken into account:

1. The architecture document was written presupposing that only a single 
encapsulation would be used within a BIER domain.

2. The IGP extension documents do not seem to provide signaling for 
multiple encapsulations.

Given that, I don't see how the IGP documents can say anything more than 
something like:

"In the future, TLVs may be added for the purpose of signaling support 
for additional encapsulations.  The use of multiple encapsulations 
within a single BIER sub-domain is outside the scope of this document."

This is the usual IETF text for "there are possible scenarios that are 
not covered in this document but may be discussed in future 
documents".    I wonder if we can just put in something like this and 
move on.

---

From: Tony Przygienda <[email-masked]>
Date: Wed, 14 Feb 2018 13:22:06 -0800

Eric, the IGP encoding is supporting multiple encaps per subdomain  (unless
we decide to limit that) but I concur, the _current_ drafts do only specify
one codepoint for MPLS. So in fact, yes, it would be viable to remove any
encaps section completely and "kick the can down the road" expecting
another document sending ISIS ether encaps to deal with the problem. And in
fact that may be event the preferred solution. Fair enough  ...

--- tony

On Wed, Feb 14, 2018 at 1:17 PM, Eric C Rosen <[email-masked]> wrote:

> "In the future, TLVs may be added for the purpose of signaling support for
> additional encapsulations.  The use of multiple encapsulations within a
> single BIER sub-domain is outside the scope of this document."
>
> This is the usual IETF text for "there are possible scenarios that are not
> covered in this document but may be discussed in future documents".    I
> wonder if we can just put in something like this and move on.
>
>
>

---

From: "Les Ginsberg (ginsberg)" <[email-masked]>
Date: Thu, 15 Feb 2018 01:35:03 +0000

Apparently I am one of the people affected by the IETF mail processing upgrade, so I did not receive emails on this thread subsequent to this email.
Checking the list archives, I concur with what Eric Rosen has stated, but I offer alternative text.

From Eric’s email:  https://mailarchive.ietf.org/arch/msg/bier/u1nL21omy3LjDvug6c0FReyu70k Eric proposed the following text be added to the IGP documents:

“"In the future, TLVs may be added for the purpose of signaling support
for additional encapsulations.  The use of multiple encapsulations
within a single BIER sub-domain is outside the scope of this document."

I suggest

“This document defines support for MPLS encapsulation as specified in {RFC8296]. Other encapsulation types are not currently defined nor is the use of multiple encapsulation types.”

Eric – the reason I prefer the above text is that I don’t want the IGP documents to even suggest what may or may not happen in the future. I prefer they simply state the limitations of the current versions.

In either case I hope we can close this thread quickly.

   Les

From: BIER [mailto:[email-masked]] On Behalf Of Tony Przygienda
Sent: Wednesday, February 14, 2018 8:04 AM
To: BIER WG <[email-masked]>
Subject: [Bier] Consensus on how we deliver the multiple ENCAPS section

So, I don't see consensus how we update the drafts in IETF LC regarding multiple encapsulations to make sure we don't deliver RFCs that can blackhole based on different implementations. I don't think it's very contentious but I suggest we need a consensus on anything from this list (written in my order of preference but whatever can be consensus-built is fine for me and I hope we don't have a different one for each protocol ;-):
a) Use the section that I think Les put into ISIS but I basically fully agree on. Only hole is see there that we won't be able to order the encaps based on preference but I think it maybe a degree of detail/flexibility no'one will ever care about.
b) Write that computation in presence of multiple encapsulations is unspecified currently and future draft/RFC has to be referred to. That's the "here be dragons" sign which is good enough to make sure that people test interop and know you have to be careful in such case
c) Leave the original section per ISIS which is overly restrictive (I think Les thinks it's even wrong)
I do not think "say nothing" is acceptable since that's basically a blackholing spec we deliver then ...
Read the update of both drafts put out today, it's good and important technical nit IMO ...

--- tony

---

From: Tony Przygienda <[email-masked]>
Date: Wed, 14 Feb 2018 17:56:38 -0800

No opinions. Both read well. If pushed I'd give Eric a slight edge given it
reads more RFC'ish. But happy with either, closes the issue well.

--- tony

On Wed, Feb 14, 2018 at 5:35 PM, Les Ginsberg (ginsberg) <[email-masked]
> wrote:

> Apparently I am one of the people affected by the IETF mail processing
> upgrade, so I did not receive emails on this thread subsequent to this
> email.
>
> From Eric’s email:  https://mailarchive.ietf.org/arch/msg/bier/
> u1nL21omy3LjDvug6c0FReyu70k Eric proposed the following text be added to
> the IGP documents:
>
>
>
> “This document defines support for MPLS encapsulation as specified in
> {RFC8296]. Other encapsulation types are not currently defined nor is the
> use of multiple encapsulation types.”
>
>
>
> Eric – the reason I prefer the above text is that I don’t want the IGP
> documents to even suggest what may or may not happen in the future. I
> prefer they simply state the limitations of the current versions.
>
>
>
> *From:* BIER [mailto:[email-masked]] *On Behalf Of *Tony Przygienda
> *Sent:* Wednesday, February 14, 2018 8:04 AM
> *To:* BIER WG <[email-masked]>
> *Subject:* [Bier] Consensus on how we deliver the multiple ENCAPS section
>
>
>

---

From: "Dolganow, Andrew (Nokia - SG/Singapore)" <[email-masked]>
Date: Thu, 15 Feb 2018 02:06:23 +0000

I think we have an agreement that we have to put some text that we do not currently address multiple encaps. I prefer that text to not be too restrictive or suggest implementations as we did not really cover this. I am OK with either the text proposed by Les or would slightly modify Eric’s text as per below:

"In the future, support may be added for the purpose of signaling
for additional encapsulations.  The use of multiple encapsulations
within a single BIER sub-domain is outside the scope of this document."
Andrew

From: BIER <[email-masked]> on behalf of Toni Przygienda <[email-masked]>
Date: Thursday, February 15, 2018 at 12:05 AM
To: BIER WG <[email-masked]>
Subject: [Bier] Consensus on how we deliver the multiple ENCAPS section

--- tony

---

From: "IJsbrand Wijnands (iwijnand)" <[email-masked]>
Date: Thu, 15 Feb 2018 08:34:01 +0000

+1

On 15 Feb 2018, at 02:57, Tony Przygienda <[email-masked]<mailto:[email-masked]>> wrote:

No opinions. Both read well. If pushed I'd give Eric a slight edge given it reads more RFC'ish. But happy with either, closes the issue well.

--- tony

On Wed, Feb 14, 2018 at 5:35 PM, Les Ginsberg (ginsberg) <[email-masked]<mailto:[email-masked]>> wrote:
Apparently I am one of the people affected by the IETF mail processing upgrade, so I did not receive emails on this thread subsequent to this email.
Checking the list archives, I concur with what Eric Rosen has stated, but I offer alternative text.

I suggest

   Les

From: BIER [mailto:[email-masked]<mailto:[email-masked]>] On Behalf Of Tony Przygienda
Sent: Wednesday, February 14, 2018 8:04 AM
To: BIER WG <[email-masked]<mailto:[email-masked]>>
Subject: [Bier] Consensus on how we deliver the multiple ENCAPS section

--- tony

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

---

From: Eric C Rosen <[email-masked]>
Date: Thu, 15 Feb 2018 09:36:24 -0500

Well, we seem to have consensus now on what needs to be said, we're just 
doing a little nit-picking on how best to say it.

How about:

“This document defines support for MPLS encapsulation as specified in 
[RFC8296].  Support for other encapsulation types is outside the scope 
of this document.  The use of multiple encapsulation types is outside 
the scope of this document.”

That text avoids speculating about the future.

I think the term "outside the scope of this document" is better than 
"currently defined", because "current" is a relative term whose 
denotation changes with the passage of time, while "this document" 
clearly denotes, err, this document.  And "scenario X is outside the 
scope of this document" is the traditional IETF verbiage for "this 
document neither condones nor deplores scenario X".

On 2/14/2018 8:35 PM, Les Ginsberg (ginsberg) wrote:
> From Eric’s email: 
> https://mailarchive.ietf.org/arch/msg/bier/u1nL21omy3LjDvug6c0FReyu70k 
> <https://urldefense.proofpoint.com/v2/url?u=https-3A__mailarchive.ietf.org_arch_msg_bier_u1nL21omy3LjDvug6c0FReyu70k&d=DwMGaQ&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=-DXB84eU9m4cIlq2OOcCJCQQAwJXQQswyu3F0kG0VNo&m=zpxl85RdvcdUcEfj_Jn2krpBK2kgdSMqPNnUb1c_sHs&s=8Y3nA39VIrD78lM4yHWGeiUUNggYmS4A6oxdHv_1zQ4&e=> 
> Eric proposed the following text be added to the IGP documents:
>
> {RFC8296]. Other encapsulation types are not currently defined nor is 
> the use of multiple encapsulation types.”
>
> *From:*BIER [mailto:[email-masked]] *On Behalf Of *Tony Przygienda
> So, I don't see consensus how we update the drafts in IETF LC 
> regarding multiple encapsulations to make sure we don't deliver RFCs 
> that can blackhole based on different implementations. I don't think 
> it's very contentious but I suggest we need a consensus on anything 
> from this list (written in my order of preference but whatever can be 
> consensus-built is fine for me and I hope we don't have a different 
> one for each protocol ;-):
>
> a) Use the section that I think Les put into ISIS but I basically 
> fully agree on. Only hole is see there that we won't be able to order 
> the encaps based on preference but I think it maybe a degree of 
> detail/flexibility no'one will ever care about.
>
> unspecified currently and future draft/RFC has to be referred to. 
> That's the "here be dragons" sign which is good enough to make sure 
> that people test interop and know you have to be careful in such case
>

---

From: "Les Ginsberg (ginsberg)" <[email-masked]>
Date: Thu, 15 Feb 2018 15:21:28 +0000

+1

Thanx Eric.

   Les

From: BIER [mailto:[email-masked]] On Behalf Of Eric C Rosen
Sent: Thursday, February 15, 2018 6:36 AM
To: Les Ginsberg (ginsberg) <[email-masked]>; Tony Przygienda <[email-masked]>; BIER WG <[email-masked]>
Subject: Re: [Bier] Consensus on how we deliver the multiple ENCAPS section

Well, we seem to have consensus now on what needs to be said, we're just doing a little nit-picking on how best to say it.

How about:

“This document defines support for MPLS encapsulation as specified in [RFC8296].  Support for other encapsulation types is outside the scope of this document.  The use of multiple encapsulation types is outside the scope of this document.”

I think the term "outside the scope of this document" is better than "currently defined", because "current" is a relative term whose denotation changes with the passage of time, while "this document" clearly denotes, err, this document.  And "scenario X is outside the scope of this document" is the traditional IETF verbiage for "this document neither condones nor deplores scenario X".
On 2/14/2018 8:35 PM, Les Ginsberg (ginsberg) wrote:
Apparently I am one of the people affected by the IETF mail processing upgrade, so I did not receive emails on this thread subsequent to this email.
Checking the list archives, I concur with what Eric Rosen has stated, but I offer alternative text.

From Eric’s email:  https://mailarchive.ietf.org/arch/msg/bier/u1nL21omy3LjDvug6c0FReyu70k<https://urldefense.proofpoint.com/v2/url?u=https-3A__mailarchive.ietf.org_arch_msg_bier_u1nL21omy3LjDvug6c0FReyu70k&d=DwMGaQ&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=-DXB84eU9m4cIlq2OOcCJCQQAwJXQQswyu3F0kG0VNo&m=zpxl85RdvcdUcEfj_Jn2krpBK2kgdSMqPNnUb1c_sHs&s=8Y3nA39VIrD78lM4yHWGeiUUNggYmS4A6oxdHv_1zQ4&e=> Eric proposed the following text be added to the IGP documents:

I suggest

   Les

From: BIER [mailto:[email-masked]] On Behalf Of Tony Przygienda
Sent: Wednesday, February 14, 2018 8:04 AM
To: BIER WG <[email-masked]><mailto:[email-masked]>
Subject: [Bier] Consensus on how we deliver the multiple ENCAPS section

--- tony

---

From: Greg Shepherd <[email-masked]>
Date: Thu, 15 Feb 2018 07:24:29 -0800

Looks good!

On Thu, Feb 15, 2018 at 6:36 AM, Eric C Rosen <[email-masked]> wrote:

> [RFC8296].  Support for other encapsulation types is outside the scope of
> this document.  The use of multiple encapsulation types is outside the
> scope of this document.”
>
> "currently defined", because "current" is a relative term whose denotation
> changes with the passage of time, while "this document" clearly denotes,
> err, this document.  And "scenario X is outside the scope of this document"
> is the traditional IETF verbiage for "this document neither condones nor
> deplores scenario X".
>
>
> u1nL21omy3LjDvug6c0FReyu70k
> *From:* BIER [mailto:[email-masked] <[email-masked]>] *On
> Behalf Of *Tony Przygienda
> *To:* BIER WG <[email-masked]> <[email-masked]>
> [email-masked]

---

From: Tony Przygienda <[email-masked]>
Date: Thu, 15 Feb 2018 07:42:05 -0800

+1

---

From: "Dolganow, Andrew (Nokia - SG/Singapore)" <[email-masked]>
Date: Thu, 15 Feb 2018 16:18:41 +0000

+1

Andrew

Sent from my iPhone

On Feb 15, 2018, at 10:36 PM, Eric C Rosen <[email-masked]<mailto:[email-masked]>> wrote:

How about:

I suggest

   Les

--- tony