Subject: [bess] I-D Action: draft-ietf-bess-mvpn-expl-track-07.txt

From: [email-masked]
Date: Tue, 20 Feb 2018 10:53:39 -0800

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the BGP Enabled ServiceS WG of the IETF.

        Title           : Explicit Tracking with Wild Card Routes in Multicast VPN
        Authors         : Andrew Dolganow
                          Jayant Kotalwar
                          Eric C. Rosen
                          Zhaohui Zhang
	Filename        : draft-ietf-bess-mvpn-expl-track-07.txt
	Pages           : 17
	Date            : 2018-02-20

Abstract:
   The MVPN specifications provide procedures to allow a multicast
   ingress node to invoke "explicit tracking" for a multicast flow or
   set of flows, thus learning the egress nodes for that flow or set of
   flows.  However, the specifications are not completely clear about
   how the explicit tracking procedures work in certain scenarios.  This
   document provides the necessary clarifications.  It also specifies a
   new, optimized explicit tracking procedure.  This new procedure
   allows an ingress node, by sending a single message, to request
   explicit tracking of each of a set of flows, where the set of flows
   is specified using a wildcard mechanism.  This document updates RFCs
   6514, 6625, and 7524.

The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-bess-mvpn-expl-track/

There are also htmlized versions available at:
https://tools.ietf.org/html/draft-ietf-bess-mvpn-expl-track-07
https://datatracker.ietf.org/doc/html/draft-ietf-bess-mvpn-expl-track-07

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-bess-mvpn-expl-track-07

Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

---

From: Eric C Rosen <[email-masked]>
Date: Tue, 20 Feb 2018 13:58:04 -0500

The -07 rev of draft-ietf-bess-mvpn-expl-track has the following changes 
from the -06 version:

1. The draft now says that it updates RFCs 6514 and 7524 as well as RFC 
6625.  I think this is now necessary because the draft modifies the 
ingress node processing of received Leaf A-D routes that carry a PTA 
with the LIR-pF flag set.  I'm not sure what the objective criteria are 
supposed to be for "updates",  but it makes sense that anyone trying to 
implement RFC 6514 or 7524 read this document as well.

2. There are a number of textual changes and clarifications in response 
to comments by Stephane Litkowski.

3. The boilerplate is updated to be in accord with RFC 8174.

4. There is now a warning that the LIR-pF flag should not be set unless 
it is known a priori that all nodes support it.

5. It is now REQUIRED that the LIR flag be set whenever the LIR-pF flag 
is set in the PTA carried by an S-PMSI A-D route.

6. The peculiar idea of modifying the RD of a Leaf A-D route originated 
in response to the LIR-pF flag has been eliminated. (Mea culpa.)

7. A Leaf A-D route originated in response to the LIR-pF flag is now 
REQUIRED to carry a PTA with the LIR-pF flag set.

8. Text has been added specifying when such a PTA should specify "no 
tunnel info" and when it should specify a tunnel type.

9. Text has been added to deal with the case where a wildcard S-PMSI A-D 
route has (a) LIR-pF set in its PTA, and (b) also specifies a tunnel 
type of Ingress Replication. The new text allows a Leaf A-D route sent 
in response to the LIR-pF bit to carry a PTA specifying an MPLS label.

10. Text has been added to say that the specifications for how to use 
new "tunnel types" with MVPN must specify procedures for originating 
Leaf A-D routes in response to S-PMSI A-D routes whose PTAs specify the 
given tunnel type and have the LIR-pF flag set.  An informational 
reference to the bier-mvpn draft has been added as an example.

11. A section has been added discussing how an ingress node responds to 
a Leaf A-D route that carries a PTA with the LIR-pF bit set.

I hope those who are interested will review the diffs and send feedback 
to the list.

---

From: <[email-masked]>
Date: Thu, 22 Feb 2018 08:10:25 +0000

Hi Eric,

Thanks a lot for the update.
Couple of more comments:

Section 2:
I still have some concern about these two sentences:
1)"This flag SHOULD NOT be set
   unless it is known that all the PEs that are to receive the route
   carrying the PTA support the flag."
2)"By setting LIR as well as
   LIR-pF, one forces a response to be sent by an egress node that does
   not support LIR-pF."

[SLI] As per 1), the situation described in 2) should not happen
Do we agree that this should not happen ?
I think we can make the text more clear about the implications of setting the LIR-pf in a partial deployment scenario.
We can add a text like after 1):
"Setting the LIR-pF in a network where only a subset of PEs supports it prevents the ingress PE to have a complete view of the receiving PEs."

We may also modify 2) as follows:
OLD
By setting LIR as well as
   LIR-pF, one forces a response to be sent by an egress node that does
   not support LIR-pF.  It is possible to tell from that response that
   the egress node does not support LIR-pF.  This may be an aid to
   troubleshooting.
NEW
By setting LIR as well as
   LIR-pF, one forces a response to be sent by an egress node that does
   not support LIR-pF.  It is possible to tell from that response that
   the egress node does not support LIR-pF.  As the support of LIR-pF is recommended on all PEs, this situation should not happen.
  However, in case of deployment error, this may be an aid to troubleshooting.

Section 5.2:
"The encoding of these Leaf A-D routes is similar to the encoding of
   the Leaf A-D routes described in section 6.2.2 of [RFC7524], which
   were designed for the support of "global table multicast".  However,
   that document sets the RD to either 0 or -1; following the procedures
   of this document, the RD will never be 0 or -1.  Therefore Leaf A-D
   routes constructed according to the procedures of this section can
   always be distinguished from the Leaf A-D routes constructed
   according to the procedures of section 6.2.2 of [RFC7524].  Also,
   Leaf A-D routes constructed according to the procedures of this
   section are VPN-specific routes, and will always carry an IP-address-
   specific Route Target, as specified in [RFC6514]."

[SLI] I'm wondering if this text is still required as we do not modify the RD compared to RFC6514.

Brgds,

-----Original Message-----
From: BESS [mailto:[email-masked]] On Behalf Of Eric C Rosen
Sent: Tuesday, February 20, 2018 19:58
To: [email-masked]
Subject: Re: [bess] I-D Action: draft-ietf-bess-mvpn-expl-track-07.txt

The -07 rev of draft-ietf-bess-mvpn-expl-track has the following changes from the -06 version:

1. The draft now says that it updates RFCs 6514 and 7524 as well as RFC 6625.  I think this is now necessary because the draft modifies the ingress node processing of received Leaf A-D routes that carry a PTA with the LIR-pF flag set.  I'm not sure what the objective criteria are supposed to be for "updates",  but it makes sense that anyone trying to implement RFC 6514 or 7524 read this document as well.

2. There are a number of textual changes and clarifications in response to comments by Stephane Litkowski.

4. There is now a warning that the LIR-pF flag should not be set unless it is known a priori that all nodes support it.

5. It is now REQUIRED that the LIR flag be set whenever the LIR-pF flag is set in the PTA carried by an S-PMSI A-D route.

6. The peculiar idea of modifying the RD of a Leaf A-D route originated in response to the LIR-pF flag has been eliminated. (Mea culpa.)

7. A Leaf A-D route originated in response to the LIR-pF flag is now REQUIRED to carry a PTA with the LIR-pF flag set.

8. Text has been added specifying when such a PTA should specify "no tunnel info" and when it should specify a tunnel type.

9. Text has been added to deal with the case where a wildcard S-PMSI A-D route has (a) LIR-pF set in its PTA, and (b) also specifies a tunnel type of Ingress Replication. The new text allows a Leaf A-D route sent in response to the LIR-pF bit to carry a PTA specifying an MPLS label.

10. Text has been added to say that the specifications for how to use new "tunnel types" with MVPN must specify procedures for originating Leaf A-D routes in response to S-PMSI A-D routes whose PTAs specify the given tunnel type and have the LIR-pF flag set.  An informational reference to the bier-mvpn draft has been added as an example.

11. A section has been added discussing how an ingress node responds to a Leaf A-D route that carries a PTA with the LIR-pF bit set.

I hope those who are interested will review the diffs and send feedback to the list.

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

_________________________________________________________________________________________________________________________

Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.

This message and its attachments may contain confidential or privileged information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.
Thank you.

---

From: Eric C Rosen <[email-masked]>
Date: Mon, 26 Feb 2018 15:40:04 -0500

> Thanks a lot for the update.

And thank you for your continued attention to the details.  I have 
posted -08.  Responses in-line.

>    However, in case of deployment error, this may be an aid to troubleshooting.

[Eric] In revision -08, I have reworked this text to indicate what will 
happen in the case of deployment errors, and how such errors can be 
detected.  However, I wouldn't necessarily guarantee that there are no 
corner cases in which a deployment error might go undetected.

> [SLI] I'm wondering if this text is still required as we do not modify the RD compared to RFC6514.

[Eric] There are two situations in which an ingress node might receive a 
Leaf A-D route whose route key field is not identical to the NLRI of a 
current x-PMSI A-D route originated by the ingress node.  One situation 
is specified in RFC 7524.  The other is specified in the explicit 
tracking draft.  I think it is useful to point out that the ingress node 
can distinguish between these two cases when it receives such a Leaf A-D 
route.

---

From: <[email-masked]>
Date: Tue, 27 Feb 2018 14:52:54 +0000

Hi Eric,

I'm fine with the version 8.
Thanks a lot for the changes.

Speaking as WG chair,

Due to the substantial changes in the document, I will initiate a new short WGLC for this document soon.

Brgds,

-----Original Message-----
From: Eric C Rosen [mailto:[email-masked]] 
Sent: Monday, February 26, 2018 21:40
To: LITKOWSKI Stephane OBS/OINIS; [email-masked]
Subject: Re: [bess] I-D Action: draft-ietf-bess-mvpn-expl-track-07.txt

> Thanks a lot for the update.

And thank you for your continued attention to the details.  I have posted -08.  Responses in-line.

>    However, in case of deployment error, this may be an aid to troubleshooting.

[Eric] In revision -08, I have reworked this text to indicate what will happen in the case of deployment errors, and how such errors can be detected.  However, I wouldn't necessarily guarantee that there are no corner cases in which a deployment error might go undetected.

> [SLI] I'm wondering if this text is still required as we do not modify the RD compared to RFC6514.

[Eric] There are two situations in which an ingress node might receive a Leaf A-D route whose route key field is not identical to the NLRI of a current x-PMSI A-D route originated by the ingress node.  One situation is specified in RFC 7524.  The other is specified in the explicit tracking draft.  I think it is useful to point out that the ingress node can distinguish between these two cases when it receives such a Leaf A-D route.