Re: [bess] Benjamin Kaduk's Discuss on draft-ietf-bess-mvpn-expl-track-13: (with DISCUSS and COMMENT)

[Eric Rosen]

On 11/29/2018 5:05 PM, Benjamin Kaduk wrote:
> The updates in the -13 include new Updates headers for RFCs 7582 and 7900,
> which may or may not call for additional IESG eyes on the changes.  Just from
> looking at the diff, it's not entirely clear to me what about those documents 
> is
> being updated.

In Alvaro's comments, he explicitly asked me to put 7582 and 7900 in the 
"Updates" header.

His reasoning was based on the the following text (which is unchanged 
from the previous version) from Section 3:

    The rules for finding a "match for reception" in [RFC6625] are hereby
    modified as follows:

   When applying the rules of Section 3.2.1 or 3.2.2 of [RFC6625], it
   is REQUIRED to ignore any S-PMSI A-D route that has no PTA, or
   whose PTA specifies "no tunnel information present".

    There are other RFCs that update [RFC6625] and that modify the rules
    for finding a "match for reception".  See, e.g., [RFC7582] and
    [RFC7900].  When applying those modified rules, it is REQUIRED to
    ignore any S-PMSI A-D route that has no PTA, or whose PTA specifies
    "no tunnel information present".

Alvaro's comment was:

"This text is also Updating rfc7582 and rfc7900 (and others?) that Updated
rfc6625.  This document should then be marked to Update those other RFCs
explicitly."

This comment seems reasonable to me, but if you two would like to fight 
it out, just let me know the resolution ;-)
___
BESS mailing list
BESS@ietf.org
https://www.ietf.org/mailman/listinfo/bess

Re: [bess] Mirja Kühlewind's Discuss on draft-ietf-bess-mvpn-expl-track-12: (with DISCUSS and COMMENT)

[Eric Rosen]

Mirja,

I believe draft-ietf-bess-mvpn-expl-track-13 addresses your issues. I 
have expanded the Security Considerations section per your suggestions, 
which IMO are all very reasonable.

Please let me know whether this is satisfactory.

Thanks.

Eric

On 11/26/2018 9:03 AM, Mirja Kuehlewind (IETF) wrote:
> Hi Eric,
>
> thanks for your detailed reply. Please see below.
>
>> Am 15.11.2018 um 19:07 schrieb Eric Rosen :
>>
>> On 10/24/2018 8:28 AM, Mirja Kühlewind wrote:
>>> -
>>> DISCUSS:
>>> --
>>>
>>> In section 9 (security considerations):
>>> Thanks for discussing network load here! However, I find this sentence a bit
>>> unsatisfactory:
>>> „The specification of counter-measures for this problem is outside the 
>>> scope
>>> of this document.“
>>> Isn’t there any easy way to make some more recommendations for counter 
>>> measures
>>> that could be discussed here? E.g. implement some rate limiting or 
>>> filtering.
>>> Or only accept LIR-PF request from preconfigured hosts (given that LIR-PF
>>> support must anyway be pre-configured)? I’m not an expert on this topic and
>>> therefore don’t know if any of such recommendations make sense, however, I
>>> would quickly like to discuss if it is potentially possible to say more than
>>> what’s current said. Thanks!
>> These particular suggestions don't really work in this context.
>>
>> - The set of Provider Edge routers (PEs) that attach to a given VPN is
>> always auto-discovered, never pre-configured.  That's an important part
>> of the L3VPN value proposition.   There are already mechanisms in place
>> to ensure that the S-PMSI A-D route gets sent only to the proper set of
>> egress PEs.  Also, a properly functioning egress PE will only respond
>> with a Leaf A-D route if it has already auto-discovered the ingress PE.
>> (You might want to question the security of the L3VPN mechanisms, but
>> that would certainly be outside the scope of this document .)
>>
>> - Rate limiting the generation of Leaf A-D routes wouldn't work, because
>> the problem is not that one PE generates too many, but that too many PEs
>> may generate them.  Rate limiting the processing of received Leaf A-D
>> routes is also problematic.  In normal operation, you might correctly
>> get a whole bunch of them in quick succession, and if you don't process
>> them in a timely manner, the customers will see a high multicast "join
>> latency".
>>
>> In the particular sort of attack mentioned in the Security
>> Considerations section, an ingress PE originates an S-PMSI A-D route
>> with LIR-pF clear, but somehow the bit gets set before the route is
>> received by the egress PEs.   As Alvaro has suggested, if an attacker
>> can modify the control messages, quite a bit of havoc can result, and
>> the particular attack under discussion is just one of many that can
>> occur if the control plane is not secure.  I can certainly put in a
>> reference to RFCS 6192 and 7454 (as Alvaro suggests), if you think that
>> is helpful.  Properly protecting the control plane should prevent this
>> kind of attack.
> Okay, then I would simply suggest to say this ("Properly protecting the 
> control plane should prevent this kind of attack“) instead of just calling it 
> out of scope.
>
>> In the event such an attack occurs, mitigating it is unfortunately not
>> very straightforward.  The ingress node can take note of the fact that
>> it is getting Leaf A-D routes with LIR-pF set, in response to an S-PMSI
>> A-D route with LIR-pF clear.  Withdrawing the S-PMSI A-D route could put
>> a stop to the attack.  However, there are a few problems with this:
>>
>> - Under normal operation, there are some race conditions that may cause
>> the ingress node to think it is being attacked, when in fact it is not.
>>
>> - If some egress nodes have a bug that causes them to set LIR-pF when it
>> should be clear, withdrawing the S-PMSI A-D route will stop the flow of
>> multicast data traffic to all the egress nodes, causing an unnecessary
>> customer-visible disruption.
>>
>> - The same situation that caused the S-PMSI A-D route to be originated
>> in the first place will still exist after the S-PMSI A-D route is
>> withdrawn, so the route will just be re-originated.
>>
>> In other words, any action that would ameliorate the effects of this
>> sort of att

Re: [bess] Suresh Krishnan's Discuss on draft-ietf-bess-mvpn-expl-track-12: (with DISCUSS)

[Eric Rosen]

Suresh,

I believe draft-ietf-bess-mvpn-expl-track-13 addresses your issues. 
Please let me know.

Eric

On 10/25/2018 9:14 AM, Suresh Krishnan wrote:
> Hi Martin,
>
>
>> On Oct 25, 2018, at 4:31 AM, Vigoureux, Martin (Nokia - FR/Paris-Saclay) 
>>  wrote:
>>
>> Hello Suresh,
>>
>> thank you for your review.
>> This NLRI is in fact defined in 6514 and the determination of the length
>> of the IP address field is clarified in 6515, section 2 item 3.
> That makes more sense but this is not clear from the draft at all. The only 
> prelude to the format says
>
> "The "route key" field of the NLRI will have the following format:”
>
> with no further explanations that this format is simply repeated from 
> RFC6514(I am guessing it is the S-PMSI A-D Route defined in Section 4.3). 
> Additionally, the draft does not even have a reference to RFC6515. I think it 
> would be really good to put some pointers into this draft. Suggest something 
> like this
>
> OLD:
>
> The "route key" field of the NLRI will have
> the following format:
>
> NEW:
>
> The "route key" field of the NLRI uses
> the following format as defined in Section 4.3 of [RFC6514]:
>
>
> OLD:
>
> o  The "ingress PE" address is taken from the "originating router"
>field of the NLRI of the S-PMSI A-D route that is the match for
>tracking.
>
> NEW:
>
> o  The "ingress PE" address is taken from the "originating router"
>field of the NLRI of the S-PMSI A-D route that is the match for
>tracking. The length of the Ingress PE's IP address is computed
>using the procedure described in Section 2 Item 3 of [RFC6515]
>
> Thanks
> Suresh
>

___
BESS mailing list
BESS@ietf.org
https://www.ietf.org/mailman/listinfo/bess

Re: [bess] Benjamin Kaduk's Discuss on draft-ietf-bess-mvpn-expl-track-12: (with DISCUSS and COMMENT)

[Eric Rosen]

Benjamin,

I believe draft-ietf-bess-mvpn-expl-track-13 addresses your issues.

Please let me know whether this is the case.

And thank you for doing such a careful review.

Eric


On 10/22/2018 9:41 PM, Benjamin Kaduk wrote:
> Benjamin Kaduk has entered the following ballot position for
> draft-ietf-bess-mvpn-expl-track-12: Discuss
>
> When responding, please keep the subject line intact and reply to all
> email addresses included in the To and CC lines. (Feel free to cut this
> introductory paragraph, however.)
>
>
> Please refer to 
> https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_iesg_statement_discuss-2Dcriteria.html=DwICaQ=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI=-DXB84eU9m4cIlq2OOcCJCQQAwJXQQswyu3F0kG0VNo=_As6D3lr-KYW2BdIKLvT4bjw3HDCFWJBsOFYObf1E_0=UWa2_MZELEQCZBxgLuEXDrhFGiFhDaSLecKezEgQJSk=
> for more information about IESG DISCUSS and COMMENT positions.
>
>
> The document, along with other ballot positions, can be found here:
> https://urldefense.proofpoint.com/v2/url?u=https-3A__datatracker.ietf.org_doc_draft-2Dietf-2Dbess-2Dmvpn-2Dexpl-2Dtrack_=DwICaQ=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI=-DXB84eU9m4cIlq2OOcCJCQQAwJXQQswyu3F0kG0VNo=_As6D3lr-KYW2BdIKLvT4bjw3HDCFWJBsOFYObf1E_0=Zs4cZ41OK1XktcOKuVjcsMkGQmpuzOc9fWuTjx1HQZY=
>
>
>
> --
> DISCUSS:
> --
>
> This document places normative requirements on new tunnel types but does
> not indicate this in a way that someone specifying a new tunnel type would
> be forced to see.  This occurs both in Section 5.2:
>
> o  When additional tunnel types are defined, the specification for
>how MVPN is to use those tunnel types must also specify how to
>construct the PTA of a Leaf A-D route that is originated in
>response to the LIR-pF flag.  As an example, see [BIER-MVPN].
>
> and in Section 6:
>
> If L's PTA specifies a tunnel type not mentioned above, the
> specification for how MVPN uses that tunnel type must specify the
> actions that N is to take upon receiving L.  As an example, see
> [BIER-MVPN].
>
> I think the best way to do this would be to have IANA Considerations
> updating the registration procedure for
> P-Multicast Service Interface (PMSI) Tunnel Type codepoints to note that
> new registrations must include this information.  It might also suffice to
> call out the existence of these requirements in the portion of the
> Introduction that discusses how this document Updates RFC 6514 (though, per
> the COMMENT section, this portion of the Introduction doesn't exist in a
> good form yet).
>
> Thank you for providing the BIER example, though -- it is helpful to see
> how the requirement plays out in practice!
>
>
> --
> COMMENT:
> --
>
> Section 1
>
> This document clarifies the procedures for originating and receiving
> S-PMSI A-D routes and Leaf A-D routes.  This document also adds new
> procedures to allow more efficient explicit tracking.  The procedures
> being clarified and/or extended are discussed in multiple places in
> the documents being updated.
>
> This is in effect saying to the reader, "you must read the updated
> document(s) in their entirety and decide for yourself whether a procedure
> being updated is described", which is perhaps not the most friendly thing
> to be doing.
>
> Section 2
>
> If the LIR-pF flag is set in the PTA of an S-PMSI A-D route, the LIR
> flag of that PTA MUST also be set.
>
> What do I do if I receive a PTA in violation of the MUST?
>
> Note that support for the LIR-pF flag is OPTIONAL.  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.  How this is known is
> outside the scope of this document.
>
> Maybe remind us what a PE that doesn't support this flag will do if it
> happens to receive a PTA with it set?  (I see discussion below of the state
> at the ingress node in this case, but not an explicit confirmation of what
> egress nodes do.)  It would also be nice to give non-normative examples of
> how a sender might know that receivers support the flag.
>
> Section 3
>
> The rules for finding a "match for reception" in [RFC6625] are hereby
> modified as follows:
>
> Maybe give a section reference too?  (Especially since 6625 does not use
> the abbreviated version we define here, and instead writes "Finding the
> Match for Data Reception".)
>
>For a given C-flow ((C-S,C-G) or (C-*,C-G)) the "match for
>tracking" is chosen as follows.  Ignore any S-PMSI A-D route that
>has no PTA.  Also ignore any S-PMSI A-D route whose PTA specifies
>"no tunnel information present", but does not have either LIR or
>

Re: [bess] Benjamin Kaduk's Discuss on draft-ietf-bess-mvpn-expl-track-12: (with DISCUSS and COMMENT)

[Eric Rosen]

On 10/22/2018 9:41 PM, Benjamin Kaduk wrote:
> --
> DISCUSS:
> --
>
> This document places normative requirements on new tunnel types but does
> not indicate this in a way that someone specifying a new tunnel type would
> be forced to see.  This occurs both in Section 5.2:
>
> o  When additional tunnel types are defined, the specification for
>how MVPN is to use those tunnel types must also specify how to
>construct the PTA of a Leaf A-D route that is originated in
>response to the LIR-pF flag.  As an example, see [BIER-MVPN].
>
> and in Section 6:
>
> If L's PTA specifies a tunnel type not mentioned above, the
> specification for how MVPN uses that tunnel type must specify the
> actions that N is to take upon receiving L.  As an example, see
> [BIER-MVPN].
>
> I think the best way to do this would be to have IANA Considerations
> updating the registration procedure for
> P-Multicast Service Interface (PMSI) Tunnel Type codepoints to note that
> new registrations must include this information.  It might also suffice to
> call out the existence of these requirements in the portion of the
> Introduction that discusses how this document Updates RFC 6514 (though, per
> the COMMENT section, this portion of the Introduction doesn't exist in a
> good form yet).
>
> Thank you for providing the BIER example, though -- it is helpful to see
> how the requirement plays out in practice!

Well, let me make a counter-proposal :-)

In section 2, I'd like to add the following text:

Use of the LIR-pF flag in a PTA whose tunnel type is not one of the
    types listed in Section 5 of [RFC6514] is outside the scope of this
    document.  Presumably, if an additional tunnel type is used, there
    will be a specification for how that tunnel type is used in MVPN.  If
    it is desired to use that tunnel type along with the LIR-pF flag,
    that specification will have to specify the rules for using the LIR-
    pF flag with that tunnel type.  As an example, see [BIER-MVPN].  In
    the absence of such a specification, the LIR-pF flag SHOULD NOT be
    set in a PTA that specifies that tunnel type, and its value SHOULD be
    ignored.

And for section 5.2:

o  If the tunnel type of the PTA attached to the match for tracking/
   reception is any other tunnel type, the rules for constructing the
   PTA of a Leaf A-D route that is originated in response to the
   LIR-pF flag are outside the scope of this document. Presumably
   there will be a specification for how that tunnel type is used in
   MVPN.  If it is desired to use that tunnel type along with the
   LIR-pF flag, that specification will have to specify the rules for
   constructing the PTA.  As an example, see [BIER-MVPN].  In the
   absence of such a specification, the LIR-pF flag in a PTA
   specifying that tunnel type SHOULD be ignored.

(The context will make it clear that "any other tunnel type" is "any 
tunnel type not mentioned in Section 5 of RFC 6514".)

And for section 6:

If L's PTA specifies a tunnel type not mentioned above, presumably
    there is a specification for how MVPN uses that tunnel type.  If the
    LIR-pF flag is to be used with that tunnel type, that specification
    must specify the actions that N is to take upon receiving L.  As an
    example, see [BIER-MVPN].  In the absence of such a specification,
    the LIR-pF flag SHOULD BE ignored.


(The context will make it clear that "a tunnel type not mentioned above" 
is "any tunnel type not mentioned in Section 5 of RFC 6514".)

I think that these passages address your issue.  If someone wants to use 
a new tunnel type with MVPN and they don't care about the LIR-pF flag, 
then they don't have to do anything, and the flag will be ignored.  If 
they do care about LIR-pF, then they'll look at this document and see 
just what they need to specify.

What do you think?

>
>
> --
> COMMENT:
> --
>
> Section 1
>
> This document clarifies the procedures for originating and receiving
> S-PMSI A-D routes and Leaf A-D routes.  This document also adds new
> procedures to allow more efficient explicit tracking.  The procedures
> being clarified and/or extended are discussed in multiple places in
> the documents being updated.
>
> This is in effect saying to the reader, "you must read the updated
> document(s) in their entirety and decide for yourself whether a procedure
> being updated is described", which is perhaps not the most friendly thing
> to be doing.

Your point is well-taken, but unfortunately RFC 6514 is not organized in 
a manner  that makes it really feasible to point out each place that 
might be relevant.  If I tried to find 

Re: [bess] Mirja Kühlewind's Discuss on draft-ietf-bess-mvpn-expl-track-12: (with DISCUSS and COMMENT)

[Eric Rosen]

On 10/24/2018 8:28 AM, Mirja Kühlewind wrote:
> -
> DISCUSS:
> --
>
> In section 9 (security considerations):
> Thanks for discussing network load here! However, I find this sentence a bit
> unsatisfactory:
> „The specification of counter-measures for this problem is outside the 
> scope
> of this document.“
> Isn’t there any easy way to make some more recommendations for counter 
> measures
> that could be discussed here? E.g. implement some rate limiting or filtering.
> Or only accept LIR-PF request from preconfigured hosts (given that LIR-PF
> support must anyway be pre-configured)? I’m not an expert on this topic and
> therefore don’t know if any of such recommendations make sense, however, I
> would quickly like to discuss if it is potentially possible to say more than
> what’s current said. Thanks!

These particular suggestions don't really work in this context.

- The set of Provider Edge routers (PEs) that attach to a given VPN is 
always auto-discovered, never pre-configured.  That's an important part 
of the L3VPN value proposition.   There are already mechanisms in place 
to ensure that the S-PMSI A-D route gets sent only to the proper set of 
egress PEs.  Also, a properly functioning egress PE will only respond 
with a Leaf A-D route if it has already auto-discovered the ingress PE.  
(You might want to question the security of the L3VPN mechanisms, but 
that would certainly be outside the scope of this document .)

- Rate limiting the generation of Leaf A-D routes wouldn't work, because 
the problem is not that one PE generates too many, but that too many PEs 
may generate them.  Rate limiting the processing of received Leaf A-D 
routes is also problematic.  In normal operation, you might correctly 
get a whole bunch of them in quick succession, and if you don't process 
them in a timely manner, the customers will see a high multicast "join 
latency".

In the particular sort of attack mentioned in the Security 
Considerations section, an ingress PE originates an S-PMSI A-D route 
with LIR-pF clear, but somehow the bit gets set before the route is 
received by the egress PEs.   As Alvaro has suggested, if an attacker 
can modify the control messages, quite a bit of havoc can result, and 
the particular attack under discussion is just one of many that can 
occur if the control plane is not secure.  I can certainly put in a 
reference to RFCS 6192 and 7454 (as Alvaro suggests), if you think that 
is helpful.  Properly protecting the control plane should prevent this 
kind of attack.

In the event such an attack occurs, mitigating it is unfortunately not 
very straightforward.  The ingress node can take note of the fact that 
it is getting Leaf A-D routes with LIR-pF set, in response to an S-PMSI 
A-D route with LIR-pF clear.  Withdrawing the S-PMSI A-D route could put 
a stop to the attack.  However, there are a few problems with this:

- Under normal operation, there are some race conditions that may cause 
the ingress node to think it is being attacked, when in fact it is not.

- If some egress nodes have a bug that causes them to set LIR-pF when it 
should be clear, withdrawing the S-PMSI A-D route will stop the flow of 
multicast data traffic to all the egress nodes, causing an unnecessary 
customer-visible disruption.

- The same situation that caused the S-PMSI A-D route to be originated 
in the first place will still exist after the S-PMSI A-D route is 
withdrawn, so the route will just be re-originated.

In other words, any action that would ameliorate the effects of this 
sort of attack would have a negative effect during normal operation.  
Therefore it is really better to rely on security mechanisms that 
protect the control plane generally, rather than having a mechanism that 
is focused on this one particular type of attack.

We could say that if an ingress PE receives a Leaf A-D route with LIR-pF 
set, and that route is a response to an S-PMSI A-D route that did not 
have LIR-pF set, the event MUST be logged.  This would generate some 
noise in the log during normal operation, but could provide at least a 
hint that an attack is occurring.

What do you think?

> --
> COMMENT:
> --
>
> Some other minor comments:
>   1) section 2: „Use of this flag in the PTA carried by other route types is 
> outside
> the scope of this document.  Use of this flag in the PTA carried by
> an S-PMSI A-D routes whose NLRI does not contain a wildcard is
> outside the scope of this document.“
> Maybe you also want to say something like „The flag SHOULD be ignored in 
> these cases.“..?

Agreed.

>
>   2) section 3
> s/The result (if any) is the match for tracking“/The result (if any) is the 
> “match for tracking“/
> 

Re: [bess] WG adoption poll for draft-zzhang-bess-mvpn-evpn-aggregation-label-01

[Eric Rosen]

I am not aware of any relevant undisclosed IPR.


On 10/30/2018 4:22 AM, 
stephane.litkow...@orange.com wrote:
Hi WG,

This email begins a two-week poll for BESS working group adoption 
draft-zzhang-bess-mvpn-evpn-aggregation-label-01 [1]

Please review the draft and post any comments to the BESS working group list, 
stating whether or not you support adoption.

We are also polling for knowledge of any undisclosed IPR that applies to this 
Document, to ensure that IPR has been disclosed in compliance with IETF IPR 
rules (see RFCs 3979, 4879, 3669 and 5378 for more details).
If you are listed as an author or a contributor of this document, please 
respond to this email and indicate whether or not you are aware of any relevant 
undisclosed IPR, copying the BESS mailing list. The document won't progress 
without answers from all the authors and contributors.

If you are not listed as an author or a contributor, then please explicitly 
respond only if you are aware of any IPR that has not yet been disclosed in 
conformance with IETF rules.

The poll for working group adoption closes on Tue 13th November.

Regards,
Stéphane and Matthew

[1] 
https://datatracker.ietf.org/doc/draft-zzhang-bess-mvpn-evpn-aggregation-label/





[Orange 
logo]

Stephane Litkowski
Network Architect
Orange/SCE/EQUANT/OINIS/NET
Orange Expert Future Networks
phone: +33 2 23 06 49 83 

  NEW !
mobile: +33 6 71 63 27 50 

  NEW !
stephane.litkow...@orange.com


_

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.




___
BESS mailing list
BESS@ietf.org
https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_bess=DwICAg=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI=-DXB84eU9m4cIlq2OOcCJCQQAwJXQQswyu3F0kG0VNo=ytiaqUZqDqVgLr4WYWfN-GUmT_N5YOih6vg--vecWf8=QdjXp8jY3XDIzmAQ7Lf2qITBSk1pjHi1sUPFi3CKWqg=


___
BESS mailing list
BESS@ietf.org
https://www.ietf.org/mailman/listinfo/bess

Re: [bess] I-D Action: draft-ietf-bess-mvpn-expl-track-12.txt

[Eric Rosen]

Yes, IANA has acknowledged this.  But it won't appear in the registry 
until the draft is ready for publication as an RFC.

On 10/15/2018 11:53 PM, Xiejingrong wrote:
> BESS WG:
>
> Had the IANA ack'ed the request of adding the value 2 (Name LIR-PF) ?
>
> I have not seen it in 
> https://urldefense.proofpoint.com/v2/url?u=https-3A__www.iana.org_assignments_bgp-2Dparameters_bgp-2Dparameters.xhtml-23pmsi-2Dtunnel-2Dattributes=DwICAg=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI=-DXB84eU9m4cIlq2OOcCJCQQAwJXQQswyu3F0kG0VNo=-lXQr57gjaAzIOLwbMkK7R9-pM63sLMIM4FA1yr70zc=SLspw81-g1YnerSbyR4wVksLFbTE0tg5RiaFqroktpE=
>
> Thanks.
> Jingrong
>
> -Original Message-
> From: BESS [mailto:bess-boun...@ietf.org] On Behalf Of 
> internet-dra...@ietf.org
> Sent: Wednesday, October 10, 2018 12:53 AM
> To: i-d-annou...@ietf.org
> Cc: bess@ietf.org
> Subject: [bess] I-D Action: draft-ietf-bess-mvpn-expl-track-12.txt
>
>
> 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-12.txt
>   Pages   : 18
>   Date: 2018-10-09
>
> 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://urldefense.proofpoint.com/v2/url?u=https-3A__datatracker.ietf.org_doc_draft-2Dietf-2Dbess-2Dmvpn-2Dexpl-2Dtrack_=DwICAg=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI=-DXB84eU9m4cIlq2OOcCJCQQAwJXQQswyu3F0kG0VNo=-lXQr57gjaAzIOLwbMkK7R9-pM63sLMIM4FA1yr70zc=IbfNIjAs_IGX1-zHjQkho0Beih9ye-K5dJadYTD3KPc=
>
> There are also htmlized versions available at:
> https://urldefense.proofpoint.com/v2/url?u=https-3A__tools.ietf.org_html_draft-2Dietf-2Dbess-2Dmvpn-2Dexpl-2Dtrack-2D12=DwICAg=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI=-DXB84eU9m4cIlq2OOcCJCQQAwJXQQswyu3F0kG0VNo=-lXQr57gjaAzIOLwbMkK7R9-pM63sLMIM4FA1yr70zc=pvX7bR0yD-Ps5xQp5Chx9znYPBsvN1OPcOqdHykWbtk=
> https://urldefense.proofpoint.com/v2/url?u=https-3A__datatracker.ietf.org_doc_html_draft-2Dietf-2Dbess-2Dmvpn-2Dexpl-2Dtrack-2D12=DwICAg=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI=-DXB84eU9m4cIlq2OOcCJCQQAwJXQQswyu3F0kG0VNo=-lXQr57gjaAzIOLwbMkK7R9-pM63sLMIM4FA1yr70zc=uEZq-1orypvLdV0mt38qRc6XnZUYPoeQlPGa7AboW6M=
>
> A diff from the previous version is available at:
> https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_rfcdiff-3Furl2-3Ddraft-2Dietf-2Dbess-2Dmvpn-2Dexpl-2Dtrack-2D12=DwICAg=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI=-DXB84eU9m4cIlq2OOcCJCQQAwJXQQswyu3F0kG0VNo=-lXQr57gjaAzIOLwbMkK7R9-pM63sLMIM4FA1yr70zc=5ARY4wCXV5wFMvi_B6cxOAwwbK10uQtiIEyLo1fyGoI=
>
>
> 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:
> https://urldefense.proofpoint.com/v2/url?u=ftp-3A__ftp.ietf.org_internet-2Ddrafts_=DwICAg=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI=-DXB84eU9m4cIlq2OOcCJCQQAwJXQQswyu3F0kG0VNo=-lXQr57gjaAzIOLwbMkK7R9-pM63sLMIM4FA1yr70zc=BD9UsKgQrN-hZxM4pV_hN0RYLbvP1_yHwv07FPpSHcQ=
>
> ___
> BESS mailing list
> BESS@ietf.org
> https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_bess=DwICAg=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI=-DXB84eU9m4cIlq2OOcCJCQQAwJXQQswyu3F0kG0VNo=-lXQr57gjaAzIOLwbMkK7R9-pM63sLMIM4FA1yr70zc=x2nsWkJvMS2mofrLcPRDRW8tGPbjWHWTEZrHyhzzy-M=
>
> ___
> BESS mailing list
> BESS@ietf.org
> https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_bess=DwICAg=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI=-DXB84eU9m4cIlq2OOcCJCQQAwJXQQswyu3F0kG0VNo=-lXQr57gjaAzIOLwbMkK7R9-pM63sLMIM4FA1yr70zc=x2nsWkJvMS2mofrLcPRDRW8tGPbjWHWTEZrHyhzzy-M=

___
BESS mailing list
BESS@ietf.org
https://www.ietf.org/mailman/listinfo/bess

Re: [bess] Genart last call review of draft-ietf-bess-mvpn-expl-track-10

[Eric Rosen]

> Minor issues:
> -
>
> As I understand it, if a network only partially supports the new
> (LIR-pF) flag, it doesn't work properly. So we find at the end of
> section 2:
>
> ...the ingress node can conclude
> that the egress node originating that Leaf A-D route does not support
> the LIR-pF flag.
>
> The software at the ingress node SHOULD detect this, and should have
> a way of alerting the operator that the deployment is not properly
> configured.
>
> I don't see why this is only a SHOULD, and I don't see why the operator
> alert is not a MUST too. Surely the operator always needs to be alerted?

Good point, I have changed this to:

    The software at the ingress node MUST detect this, and MUST have a 
way of alerting the operator that the deployment is not properly configured.

> I agree with the point raised in the Routing Area review
> (be explicit about the updated sections of RFC 6514, 6625,
> and 7524).

The clarifications and extensions may affect the procedures for 
originating and receiving/processing S-PMSI A-D routes and Leaf A-D 
routes.  These procedures are discussed in many different places in the 
updated drafts.  I don't believe there is any value in having the 
authors of mvpn-expl-track go through those drafts to try to make a list 
of all the places where S-PMSI A-D routes and/or Leaf A-D routes are 
discussed.  If we attempted to do so, we'd surely miss a few places and 
thereby introduce bugs into the spec.  The information currently in the 
document is sufficient to enable anyone who understands the updated 
references to figure out what needs to be done.

___
BESS mailing list
BESS@ietf.org
https://www.ietf.org/mailman/listinfo/bess

Re: [bess] Introducing a one-implementation requirement before WG last calls

[Eric Rosen]

My opinion is unchanged; there is no need to impose any implementation 
requirement, nor is there any need to add more process hurdles that 
further slow down the progress of a document towards publication.  
Certainly there is no need to gather details about implementations, 
vendor releases, etc.  The process is already slow enough and has enough 
useless overhead.


If folks object to the progression of a document, they are already free 
to make those objections during last call.




On 12/14/2015 4:28 AM, Martin Vigoureux wrote:

WG,

we have reviewed the different comments posted on the list in response 
to our initial proposal.
After thinking further about that, we'd like to propose the following 
as a way forward:


At the same time we issue a Working Group Last Call we would ask for 
knowledge of existing implementations, and the more details provided 
at that time, the better.
In the situation where an implementation would exist we would proceed 
with submission to IESG.
In the opposite situation (no implementation exists), we would 
systematically ask the WG for reasoned opinions regarding whether we 
should nevertheless proceed with submission to IESG.
We will gauge consensus on that aspect. In case consensus is in favour 
of proceeding with submission to IESG we will do so. In the opposite 
case, we will put the document in a "Waiting for implementation" state 
until information on an existing implementation is brought to our 
knowledge or of the WG.


Please share your views on that.

Thank you

M


Le 24/11/2015 10:03, Thomas Morin a écrit :

Hello everyone,

Following the positive feedback received during BESS meeting in Yokohama
about introducing a one-implementation requirement in BESS, we propose
to do the following for future WG last calls:

As a prerequisite before doing a working group last call on a document,
the chairs will ask the working group for known implementations of the
specifications; a relatively detailed level of information will be
required (e.g. "release x.y of solution z shipping date d", "all
features implemented", "partial implementation only", etc.) and everyone
will be invited to reply (not only co-authors of the specifications);
the chairs will then do the working group last call if satisfying
information was provided on at least one implementation.

We are open for comments on this proposal until December 7th.

Martin & Thomas

___
BESS mailing list
BESS@ietf.org
https://www.ietf.org/mailman/listinfo/bess




___
BESS mailing list
BESS@ietf.org
https://www.ietf.org/mailman/listinfo/bess


___
BESS mailing list
BESS@ietf.org
https://www.ietf.org/mailman/listinfo/bess