Subject: [Bier] WGLC: draft-ietf-bier-mpls-encapsulation-06

From: Greg Shepherd <[email-masked]>
Date: Fri, 5 May 2017 15:58:07 -0700

At WG meeting, IETF97 in Chicago, we decided to move forward to WGLC for
some of our docs. We learned that even once published the IESG has a
process to change the track of the RFC if the WG makes the case to move the
work from Informational to Standards track. The feedback from operators is
that RFC status was more important than track, and we won't be able to meet
our charter requirements to change track without deployment experience and
operator support.

This email starts a two week timer for feedback on the draft:
https://datatracker.ietf.org/doc/draft-ietf-bier-mpls-encapsulation/

Please read and respond do this thread. EOWGLC - 20/5/17

Thank you,
Chairs

---

From: "Dolganow, Andrew (Nokia - SG/Singapore)" <[email-masked]>
Date: Mon, 8 May 2017 00:31:40 +0000

Support

Andrew

Sent from my iPhone

On May 6, 2017, at 6:58 AM, Greg Shepherd <[email-masked]<mailto:[email-masked]>> wrote:

At WG meeting, IETF97 in Chicago, we decided to move forward to WGLC for some of our docs. We learned that even once published the IESG has a process to change the track of the RFC if the WG makes the case to move the work from Informational to Standards track. The feedback from operators is that RFC status was more important than track, and we won't be able to meet our charter requirements to change track without deployment experience and operator support.

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

---

From: Greg Mirsky <[email-masked]>
Date: Sun, 7 May 2017 19:18:38 -0700

yes/support

Regards,
Greg

On Fri, May 5, 2017 at 3:58 PM, Greg Shepherd <[email-masked]> wrote:

> [email-masked]

---

From: "Jeffrey (Zhaohui) Zhang" <[email-masked]>
Date: Mon, 8 May 2017 05:10:19 +0000

Support.
Please allocate two protocol code points for vxlan/nvgre payload types.

Thanks.
Jeffrey

From: BIER [mailto:[email-masked]] On Behalf Of Greg Shepherd
Sent: Friday, May 5, 2017 6:58 PM
To: [email-masked]
Subject: [Bier] WGLC: draft-ietf-bier-mpls-encapsulation-06

Thank you,
Chairs

---

From: Linda Wang <[email-masked]>
Date: Mon, 8 May 2017 20:45:04 +1000

Support.

BRs,
Linda

---

From: "Nagendra Kumar Nainar (naikumar)" <[email-masked]>
Date: Mon, 8 May 2017 11:21:01 +0000

Support.

Thanks
Nagendra

From: BIER <[email-masked]<mailto:[email-masked]>> on behalf of Greg Shepherd <[email-masked]<mailto:[email-masked]>>
Reply-To: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Date: Friday, May 5, 2017 at 6:58 PM
To: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: [Bier] WGLC: draft-ietf-bier-mpls-encapsulation-06

Thank you,
Chairs

---

From: Stewart Bryant <[email-masked]>
Date: Mon, 8 May 2017 15:52:06 +0100

Please could you clarify whether this document is being reviewed by the 
MPLS WG as part of this process?

Please can you explain how the entropy system works in MPLS?

Are you expecting the P router to look into the BIER header, or are you 
expecting BIER capable nodes to construct an entropy structure in the 
outer label stack.

If the latter, you have two methods available to you the EL system, and 
the FAT PW system. The former is becoming the method of choice where 
available, but you have the option of using the later which will work in 
any network.

I find the title a little strange since the union of MPLS and non-MPLS 
is all networks and thus you ought to cut the title after "Replication".

Best regards

Stewart

On 05/05/2017 23:58, Greg Shepherd wrote:
> At WG meeting, IETF97 in Chicago, we decided to move forward to 
> WGLC for some of our docs. We learned that even once published the 
> IESG has a process to change the track of the RFC if the WG makes the 
> case to move the work from Informational to Standards track. The 
> feedback from operators is that RFC status was more important than 
> track, and we won't be able to meet our charter requirements to change 
> track without deployment experience and operator support.
>

---

From: Eric C Rosen <[email-masked]>
Date: Mon, 8 May 2017 11:29:43 -0400

Hi Stewart,

Thanks for your review!

On 5/8/2017 10:52 AM, Stewart Bryant wrote:
>
> Please could you clarify whether this document is being reviewed by 
> the MPLS WG as part of this process?
>

I'll let the WG chairs answer that ;-)

> Are you expecting the P router to look into the BIER header, or are 
> you expecting BIER capable nodes to construct an entropy structure in 
> the outer label stack.
>

A router that is BIER-capable uses the entropy value from the BIER 
header as part of its BIER forwarding process.  This is discussed in the 
BIER architecture document.

If a packet is being tunneled from one BIER-capable router to another, 
and the tunnel passes through a sequence of intermediate routers, then 
the tunnel encapsulation probably has some entropy mechanism of its 
own.  It would make sense to ensure that if two BIER packets have the 
same entropy value in their respective BIER headers, then they have the 
same entropy in the tunnel encapsulation.  However, the tunnel 
encapsulation is not the BIER encapsulation. and how the tunnel 
encapsulation header is formed is outside the scope of this document.

The BIER entropy field does happen to be 20 bits long, so if the tunnel 
encapsulation is MPLS, the BIER entropy could be copied into the EL.

> If the latter, you have two methods available to you the EL system, 
> and the FAT PW system. The former is becoming the method of choice 
> where available, but you have the option of using the later which will 
> work in any network.
>

This seems like a general issue about MPLS tunnels, not a BIER-specific 
issue.

> is all networks and thus you ought to cut the title after "Replication".

Originally the draft only discussed MPLS networks.  When a non-MPLS 
encaps was added, the title was augmented with "and non-MPLS networks".  
I don't really see a problem with it, as it emphasizes that two 
encapsulation mechanisms are provided.

Eric

---

From: Stewart Bryant <[email-masked]>
Date: Mon, 8 May 2017 16:44:55 +0100

On 08/05/2017 16:29, Eric C Rosen wrote:

Hi Eric,
>  However, the tunnel encapsulation is not the BIER encapsulation. and 
> how the tunnel encapsulation header is formed is outside the scope of 
> this document.

That seems odd. The document seems to be about how you operate BIER in 
an MPLS network, and so I would have expected tunnelling over MPLS to be 
in scope.

- Stewart

---

From: Tony Przygienda <[email-masked]>
Date: Mon, 8 May 2017 09:11:37 -0700

My initial reaction was same as Eric's. You either have outer stack =
tunnel in which case what's inside is irrelevant (well, we know about deep
inspection hacks but that doesn't apply here) or the label/tag is BIER. if
the label is BIER it's processed by definition by a BFR that uses BIER
entropy ...

I have no opinion whether e.g. BIER entropy should be copied onto outer
stack in case BIER is tunneled in MPLS and I consider it an implementation
choice really since I don't see a need for the architecture to mandate this
...

--- tony

On Mon, May 8, 2017 at 8:29 AM, Eric C Rosen <[email-masked]> wrote:

>> expecting BIER capable nodes to construct an entropy structure in the outer
>> label stack.
>>
>>
> A router that is BIER-capable uses the entropy value from the BIER header
> as part of its BIER forwarding process.  This is discussed in the BIER
> architecture document.
>
> If a packet is being tunneled from one BIER-capable router to another, and
> the tunnel passes through a sequence of intermediate routers, then the
> tunnel encapsulation probably has some entropy mechanism of its own.  It
> would make sense to ensure that if two BIER packets have the same entropy
> value in their respective BIER headers, then they have the same entropy in
> the tunnel encapsulation.  However, the tunnel encapsulation is not the
> BIER encapsulation. and how the tunnel encapsulation header is formed is
> outside the scope of this document.
>
> I find the title a little strange since the union of MPLS and non-MPLS is
>> all networks and thus you ought to cut the title after "Replication".
>>
>>
>>
> Originally the draft only discussed MPLS networks.  When a non-MPLS encaps
> was added, the title was augmented with "and non-MPLS networks".  I don't
> really see a problem with it, as it emphasizes that two encapsulation
> mechanisms are provided.
>
> Eric
>
>

-- 
*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: Jeff Tantsura <[email-masked]>
Date: Mon, 08 May 2017 14:47:09 -0700

yes/support 

Cheers,

Jeff

From: BIER <[email-masked]> on behalf of Greg Shepherd <[email-masked]>
Reply-To: <[email-masked]>
Date: Friday, May 5, 2017 at 15:58
To: "[email-masked]" <[email-masked]>
Subject: [Bier] WGLC: draft-ietf-bier-mpls-encapsulation-06

Thank you,

Chairs

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

---

From: Xuxiaohu <[email-masked]>
Date: Tue, 9 May 2017 02:42:11 +0000

> was added, the title was augmented with "and non-MPLS networks".
> I don't really see a problem with it, as it emphasizes that two encapsulation
> mechanisms are provided.

Hi all,

I really don't think it's worthwhile to have two indirection approaches with little significant differences. IMHO, the only difference between the two approaches is whether the first 20-bit (i.e., the indirection key) is deeded as an MPLS label or not. Is that so important in nature?

Best regards,
Xiaohu

---

From: Eric C Rosen <[email-masked]>
Date: Tue, 9 May 2017 10:42:43 -0400

On 5/8/2017 11:44 AM, Stewart Bryant wrote:
> The document seems to be about how you operate BIER in an MPLS network, 

Please avoid the word "operate".  We don't want to give the 
Operations&Maintenance ADs any opportunity to insist that the document 
is not complete without a "how to" guide for operators ;-)

> and so I would have expected tunnelling over MPLS to be in scope. 

The topic of the draft is how to form a BIER encapsulation that can be 
used in an MPLS network, and how to form a BIER encapsulation that can 
be used in a non-MPLS network.  Admitedly, there is some discussion 
(sections 2.1.3 and 2.2.3) of further encapsulating the BIER packets in 
tunnels, but not a comprehensive survey of all the issues that might 
arise when tunneling.

Suppose P1 and P2 are packets, and E(Px) is the result of encapsulating 
Px in order to send it through a particular tunnel.  I think it is true 
in general that if P1 and P2 have the same entropy, then it is desirable 
for E(P1) and E(P2) to also have the same entropy.   This isn't 
mentioned because it isn't specific to either BIER or to MPLS, it's a 
general principle of tunneling.  But I could add something like the 
above sentences to sections 2.1.3 and 2.2.3, as well as to section 6.9 
of the architecture draft.  Note that that text deliberately avoids 
RFC2119 language.

I don't want to get into any detail about how to set the entropy in the 
tunnel encapsulation headers; that's clearly out of scope. There is no 
need for a discussion of when it is and is not appropriate to use the 
entropy label, how one knows whether the entropy label will be 
understood properly, how one knows whether the entropy label will make 
the stack too long, whether the FAT PW mechanism is appropriate, whether 
hardware can always preserve the entropy properly when putting on a 
tunnel encapsulation header, what the best entropy mechanism is for 
MPLSoUDP encapsulations, etc., etc., etc.

Someone could write an entire draft on the entropy issues that arise 
when tunneling, but I don't think this needs to be dealt with in the 
BIER docs.

(BTW, I'm sure you've noticed that the entropy field in the BIER header 
is 20 bits long, and hence could be copied into an entropy label.  
Perhaps it's worth mentioning tht explicitly, as long as RFC2119 
language is not used.)

---

From: <[email-masked]>
Date: Tue, 9 May 2017 15:23:06 +0000

Support

From: BIER [mailto:[email-masked]] On Behalf Of Greg Shepherd
Sent: Friday, May 05, 2017 6:58 PM
To: [email-masked]
Subject: [Bier] WGLC: draft-ietf-bier-mpls-encapsulation-06

This email starts a two week timer for feedback on the draft:
https://datatracker.ietf.org/doc/draft-ietf-bier-mpls-encapsulation/<https://urldefense.proofpoint.com/v2/url?u=https-3A__datatracker.ietf.org_doc_draft-2Dietf-2Dbier-2Dmpls-2Dencapsulation_&d=DwMFaQ&c=4ZIZThykDLcoWk-GVjSLmy8-1Cr1I4FWIvbLFebwKgY&r=JA6g2ZDvIPLQHZqHQByKQq-jvOcxu4cQskARppQFqZc&m=_BjA7Lb009LxRhxakfOvdmj90qFhy_HmCjkYA21PuUY&s=JexoDj-54-pp1IuEtP04h2g6VF3NSSLQgCBeoUjmVvY&e=>

Thank you,
Chairs