Subject: [bess] WGLC: draft-ietf-bier-mvpn-05

From: Greg Shepherd <[email-masked]>
Date: Wed, 14 Jun 2017 15:01:18 -0700

BIER, BESS, PIM

At BIER 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-mvpn

WGLC to run in parallel in both BIER, BESS, and PIM WGs due to the scope of
the work.

Thanks,
Greg
(BIER Chairs)

---

From: Stig Venaas <[email-masked]>
Date: Mon, 19 Jun 2017 14:47:50 -0700

Hi

I think this draft is mostly ready. I just have a couple of comments.

In section 1:
   This revision of the document does not specify the procedures
   necessary to support MVPN customers that are using BIDIR-PIM.  Those
   procedures will be added in a future revision.

Remove this text?

Section 2.1.  MPLS Label

Should one use different labels to distinguish address families in the same VRF?

The PTA must be present in Leaf A-D routes so one can know the BIER
prefix of the router joining. It might be obvious, but I think it is
worth pointing it out. It is specified for IR (in RFC 7988 section
4.1.1 it says: "Leaf A-D route MUST also contain a PTA"...

Stig

On Wed, Jun 14, 2017 at 3:01 PM, Greg Shepherd <[email-masked]> wrote:
> BIER, BESS, PIM
>
> At BIER 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
> _______________________________________________
> BESS mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/bess
>

---

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

Stig, thanks for your comments.+

>     procedures will be added in a future revision.

We'll probably just change this to something like "Procedures to support 
MVPN customers that are using BIDIR-PIM are outside the scope of this 
document".

> Should one use different labels to distinguish address families in the same VRF?

Nice catch.  The customer's address family is identified by the AFI of 
the MCAST-VPN routes.  There should be a requirement that a given router 
MUST NOT originate two x-PMSI A-D routes with different AFIs but with 
the same upstream-assigned label in their respective PTAs.

> 4.1.1 it says: "Leaf A-D route MUST also contain a PTA"...

For IR, the PTA is needed because each egress PE needs to advertise a 
downstream-assigned label.

For BIER, I was thinking that the BFR-Prefix of the egress PE should 
appear in the "originating router's IP address" field of the Leaf A-D 
NLRI.  However, it is probably better to allow the "originating router's 
IP address" to be different than the BFR-Prefix, and in that case to use 
the Leaf A-D route's PTA to specify the BFR-Prefix.

---

From: "Mahesh Sivakumar (masivaku)" <[email-masked]>
Date: Wed, 21 Jun 2017 17:08:39 +0000

Hi Eric,

>> the Leaf A-D route's PTA to specify the BFR-Prefix.

I was thinking along the same lines so that we have the flexibility on the
Ingress BFR to use either the originating router or the BFR prefix while
tracking.
But do you envision a real use case at the ingress BFIR for using the BFR prefix
in the PTA given that the BFIR can use the originating router IP address to
match the appropriate S-PMSI A-D route.
Accordingly, should we make the BIER-pfx in the PTA optional?

Thanks
Mahesh

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

---

From: "Swadesh Agrawal (swaagraw)" <[email-masked]>
Date: Wed, 21 Jun 2017 18:22:36 +0000

It can be achieved by having ipv6 explicit NULL in data path. We may not need different label to identify AFI.

Regards
Swadesh

On 6/21/17, 8:39 AM, "BESS on behalf of Eric C Rosen" <[email-masked] on behalf of [email-masked]> wrote:

---

From: Eric C Rosen <[email-masked]>
Date: Wed, 21 Jun 2017 15:52:35 -0400

> It can be achieved by having ipv6 explicit NULL in data path. We may not need different label to identify AFI.

We could have a rule saying that if MVPN payload packet is an IPv6 
packet, then v6 explicit null must be pushed before the 
upstream-assigned label is pushed.

But hen someone would claim that we're favoring v4 over v6, and the rule 
should be that if the MVPN payload is a v4 packet, v4 explicit null must 
be pushed before the upstream-assigned label is pushed.

If we don't have one rule or the other, we risk multi-vendor interop 
problems.

People will disagree about which rule is best, so someone will claim 
that we need a configuration item to say which payload type is the 
default and which requires explicit null.

Then someone would say that we need to add to the signaling an 
indication of which payload type is the default and which requires 
explicit null.

Then someone would say that the root cause of the problem is the lack of 
a protocol type field in MPLS, and we should fix the root cause instead 
of using explicit null.

So although your observation is absolutely correct, I think it's simpler 
if we just use different upstream-assigned labels for the different AFIs.

---

From: "Swadesh Agrawal (swaagraw)" <[email-masked]>
Date: Wed, 21 Jun 2017 20:15:14 +0000

Rosen MLDP MVPN(vpnid) and many other profiles have same tunnel for v4 and v6. I think it’s pretty standard to send ipv6 traffic with ipv6 explicit NULL.
It was never required to be explicitly mention in RFC. 
Mandating to have different upstream assign label does not look correct. Should mention both option and leave it to implementation. 

Regards
Swadesh

On 6/21/17, 12:52 PM, "Eric C Rosen" <[email-masked]> wrote:

---

From: "Swadesh Agrawal (swaagraw)" <[email-masked]>
Date: Wed, 21 Jun 2017 20:18:44 +0000

We won’t need signaling. It will depend on ingress PE. If ingress PE does not send ipv6 explicit NULL, it should announce different upstream assigned label for afi.
Egress PE should work in both scenario without any signaling of what ingress PE has implemented.

Regards
Swadesh 

On 6/21/17, 1:15 PM, "BESS on behalf of Swadesh Agrawal (swaagraw)" <[email-masked] on behalf of [email-masked]> wrote:

    Regards
    Swadesh

---

From: Eric C Rosen <[email-masked]>
Date: Wed, 21 Jun 2017 16:22:30 -0400

On reflection, I think it's best if there is no requirement for a PE's 
BFR-Prefix to appear in the NLRI of any of the MVPN routes, no 
requirement for it to appear in the VRF Route Import EC, no requirement 
for it to appear in any next hop field, no requirement for it to appear 
in the Inter-Area P2MP Next Hop EC, etc.  That is, no requirement for it 
to be anything other than a BFR-Prefix.

So if the PTA of an x-PMSI A-D route specifies tunnel type "BIER", I 
think the simplest thing is to require that the BFR-Prefix be specified 
in the PTA.

Similarly, the simplest way to ensure that the ingress PE knows the 
BFR-Prefix of an egress PE is to have the egress PE include a PTA in the 
Leaf A-D route, and require to PTA to specify "tunnel type" BIER, MPLS 
Label 0 (ignored), and the BFR-Prefix of the Leaf.  Which I think was 
Stig's original suggestion.

---

From: Eric C Rosen <[email-masked]>
Date: Wed, 21 Jun 2017 16:51:34 -0400

On 6/21/2017 4:15 PM, Swadesh Agrawal (swaagraw) wrote:
> I think it’s pretty standard to send ipv6 traffic with ipv6 explicit NULL.

I wouldn't make that assumption.  Especially not in MPLS backbones built 
on an IPv6 infrastructure.

> It was never required to be explicitly mention in RFC.

The fact that this was never made explicit in any RFC has been the cause 
of numerous interoperability problems.  Many of these have been hammered 
down over the past twenty years, but new issues of this sort still 
arise, especially in new applications where label stacks are signaled in 
new and different ways.

> Egress PE should work in both scenario without any signaling of what ingress PE has implemented.

I think it would be good for the egress PE to know in advance whether or 
not it is expected to infer the payload type from the upstream-assigned 
label (assuming that that label appears at the bottom of the stack).