Subject: [bess] Comments on draft-dolganow-l3vpn-mvpn-expl-track-00

From: Eric C Rosen <[email-masked]>
Date: Fri, 7 Nov 2014 11:52:56 -0500

I have a few comments on draft-dolganow-l3vpn-mvpn-expl-track-00.txt.

The draft points out a few issues with regard to the use of a PMSI Tunnel
attribute (PTA) whose "tunnel type" is set to "no tunnel information". 

The first issue is the following.

RFC6625 gives a detailed set of procedures for figuring out which S-PMSI A-D
route specifies the P-tunnel to be used for sending or receiving a
particular multicast C-flow.  However, RFC6625 neglects to point out that if
the PTA of particular S-PMSI A-D route specifies "no tunnel information",
then the that S-PMSI A-D route should be ignored when those procedures are
applied.

The draft is correct to point this out, though I'm not sure any implementer
would actually try to send or receive packets on a P-tunnel whose type is
"no tunnel information".  This particular issue might be better addressed
through an erratum to RFC6625.

But a couple of more difficult issues are raised as well.

I think the original intention of using "no tunnel information" is that it
would be used with (C-S,C-G) S-PMSI A-D routes.  Thus there is no clear
statement in any of the RFCs about how to use it with an S-PMSI A-D route
that has one or more wildcards in its NLRI.

It's clear that a egress node, say PE1, interested in (C-S,C-G), needs to
send a Leaf A-D route in response to a "no tunnel info" S-PMSI A-D route
with (C-S, C-G) in its NLRI, as long as the S-PMSI A-D route is originated
by the ingress node that PE1 has selected for (C-S,C-G).

What's not clear is what to do in the following case:

- PE1 is an egress node interested in (C-S,C-G)

- PE1 has chosen PE2 as the ingress node for (C-S,C-G)

- PE1 has installed a (C-S,C-G) S-PMSI A-D route from PE2, where the route
  specifies a tunnel to join

- PE1 has installed an S-PMSI A-D route from PE2 with a "less specific" NLRI
  (e.g., (C-*,C-G) or (C-S,C-*) or (C-*,C-*)), and that specifies "no tunnel
  information" with LIR set.

Does PE1 have to respond to PE2's less specific S-PMSI A-D route with a Leaf
A-D route in this case?  The RFCs don't really say.  I can imagine several
possible answers:

- yes

- no

- it depends on whether the more specific route had LIR set

- it depends on whether the less specific route covers more than one more
  specific route

- it depends on something else

The desired behavior when mixing "no tunnel information" with wildcards was
not thought out when RFC6625 was written.

Another issue has to do with the way the P-tunnel segmentation procedures
are applied to an S-PMSI A-D route whose PTA specifies "no tunnel
information."

The draft doesn't actually mention P-tunnel segmentation, but it does
distinguish between "intra-AS" and "inter-AS" procedures.  It leaves
inter-AS "for further study", so I surmise that the authors think there are
some issues when S-PMSI A-D routes with "no tunnel information" have to
travel inter-AS.  I surmise further that the issues have to do with the
application of the P-tunnel segmentation procedures to S-PMSI A-D routes
with "no tunnel information".

This surmise could be wrong, because (a) segmentation doesn't have to be
applied at inter-AS boundaries, and (b) segmentation can be applied within
within a single AS (see "seamless multicast").  But I think there are some
issues having to do with processing these routes at "segmentation
boundaries", whether or not those boundaries are also AS boundaries.

Generally, when a P-tunnel is segmented, the segments do not all have to be
the same tunnel type.  However, we could decide that when segmenting a "no
tunnel information" P-tunnel, the segments should all be "no tunnel
information" segments, with each segment having LIR set.

(Yes, I know it doesn't make literal sense to talk of segmenting a "no
tunnel information" tunnel, this is just shorthand for applying the P-tunnel
segmentation procedures to S-PMSI A-D routes whose PTAs specify "no tunnel
information".)

Or we could decide that whether a "no tunnel information" PTA should pass
through a segmentation boundary is a matter of policy.

But note that when the ingress PE and egress PEs are separated by
segmenation boundaries, there are no procedures that allow the ingress PE to
track the egress PEs.  The procedures are really designed only to enable the
ingress node of a "segmentation domain" to track the egress nodes of that
domain.  That is all that is needed if the purpose of explicit tracking is
to enable the ingress node to add egress nodes to a particular P-tunnel
segment.

If it is desired to enable PE-PE explicit tracking across segmentation
domains, new procedures would be needed.

I would like to know if the authors think that I have correctly captured the
issues.  Also, if new procedures need to be developed, we should discuss
some use cases, to make sure that any new procedures are really solving the
problems posed by the use cases.

---

From: "Dolganow, Andrew (Andrew)" <[email-masked]>
Date: Fri, 7 Nov 2014 22:54:24 +0000

Eric,

Thank you for your comments. Please see inline

>through an erratum to RFC6625.

You are correct; although a tunnel may not be found by some
implementation.  We can decide in due time what is better a separate draft
or erratum.
>that has one or more wildcards in its NLRI.

This may have been the original intenion; however, I believe that there is
enough to make wildcard tracking work, and since there is(are)
implementation for that it would be good if other implementations were
interoperable.
>- it depends on something else

To us, the receiver responds to explicit tracking only if it would use the
route with a tunnel to receive data. Per draft (section 4.2):

"We say a PE is to receive traffic for the explicitly tracked wildcard
stream, if at least one (C-S, C-G) C-flow matchesthe S-PMSI A-D route
encoding the explicitly tracked stream using procedures of section 3.2 of
[MVPN-WC].²

So for the case you outlined, if (C-S,C-G) is the only group, here would
be no response (as wildcard matching procedures would match to S-PMSI A-D
route for the (C-S,C-G) and not wildcard.

>not thought out when RFC6625 was written.

Agree, hence our draft.

The above though made me think that we should add explicit procedure we
may to account for withdraw of more specific (A-D) routes that would
require response to wildcard tracking. And equivalent reverse case.

>
>Another issue
>has to do with the way the P-tunnel segmentation procedures

We left Inter-AS use case as future study because we have no immediate use
case for that. We can discuss at the meeting whether we think we want to
handle this or not. As you notice below, inter-AS requires a bit more
thinking to make sure everything works as expected.
>domains, new procedures would be needed.

Agree.
>problems posed by the use cases.

Absolutely,

Andrew
>
>
>
>
>_______________________________________________
>BESS mailing list
>[email-masked]
>https://www.ietf.org/mailman/listinfo/bess