Re: [bess] Suresh Krishnan's No Objection on draft-ietf-bess-bgp-vpls-control-flags-07: (with COMMENT)
> On Apr 19, 2019, at 10:09 PM, Ravi Singh wrote: > > Hi Suresh > I've incorporated your suggestions. > Good catch with the PE#. Thanks Ravi. Regards Suresh ___ BESS mailing list BESS@ietf.org https://www.ietf.org/mailman/listinfo/bess
Re: [bess] Suresh Krishnan's No Objection on draft-ietf-bess-evpn-vpls-seamless-integ-05: (with COMMENT)
Hi Ali, The suggested changes look good to me. Thanks Suresh > On Jan 22, 2019, at 4:20 AM, Ali Sajassi (sajassi) wrote: > > Suresh, > Thanks for your review and your comments. Please refer to my replies below > marked with "AS>". > > On 1/9/19, 8:03 PM, "Suresh Krishnan" wrote: > >Suresh Krishnan has entered the following ballot position for >draft-ietf-bess-evpn-vpls-seamless-integ-05: No Objection > >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://www.ietf.org/iesg/statement/discuss-criteria.html >for more information about IESG DISCUSS and COMMENT positions. > > >The document, along with other ballot positions, can be found here: >https://datatracker.ietf.org/doc/draft-ietf-bess-evpn-vpls-seamless-integ/ > > > >-- >COMMENT: >-- > >* Section 3.3 MAC Mobility > >The handling of MAC mobility between the EVPN and VPLS PEs seems a bit, > for a >lack of a better term, "not seamless" to me. While only using EVPN a MAC > that >has moved will get propagated out without *initiating* any sort of BUM > traffic >itself as described Section 15 of RFC7432. If I understand this document >correctly, if a MAC moves onto a segment with a VPLS PE, traffic towards it >will be blackholed until it initiates BUM traffic which is not the case > when >the MAC moves between EVPN PEs. Did I get this right? If so, I think this >limitation needs to be highlighted a bit more prominently. > > AS> Section 3.3 describes two MAC move scenarios: move from EVPN PE to VPLS > PE (1st para) and move from VPLS PE to EVPN PE (2nd para). In the first > scenario, it says that if the moved MAC address doesn't initiate any BUM > traffic (it only initiates known unicast traffic), then there can be > black-holing for both EVPN and VPLS PEs. However, for the 2nd scenario, the > black-holing can happen only for VPLS PEs. To clarify this point further, I > added a sentence to each of the paragraph. > 1st para: Such black-holing happens for traffic destined to the moved C-MAC > from both EVPN and VPLS PEs. > 2nd para: Such black-holing happens for traffic destined to the moved C-MAC > for only VPLS PEs but not for EVPN PEs. > > Cheers, > Ali > > ___ BESS mailing list BESS@ietf.org https://www.ietf.org/mailman/listinfo/bess
[bess] Suresh Krishnan's No Objection on draft-ietf-bess-evpn-df-election-framework-07: (with COMMENT)
Suresh Krishnan has entered the following ballot position for draft-ietf-bess-evpn-df-election-framework-07: No Objection 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://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-bess-evpn-df-election-framework/ -- COMMENT: -- Given the drawbacks this document mentions regarding the default DF election algorithm defined in RFC7432, I also think it would be better for this document to update RFC7432 so that implementers are aware that there are better alternatives out there. * Section 3.2: Who actually advertises Type 0 in the DF Alg field given that the legacy RFC7432 implementations do not use this extended community at all? ___ BESS mailing list BESS@ietf.org https://www.ietf.org/mailman/listinfo/bess
[bess] Suresh Krishnan's No Objection on draft-ietf-bess-evpn-vpls-seamless-integ-05: (with COMMENT)
Suresh Krishnan has entered the following ballot position for draft-ietf-bess-evpn-vpls-seamless-integ-05: No Objection 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://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-bess-evpn-vpls-seamless-integ/ -- COMMENT: -- * Section 3.3 MAC Mobility The handling of MAC mobility between the EVPN and VPLS PEs seems a bit, for a lack of a better term, "not seamless" to me. While only using EVPN a MAC that has moved will get propagated out without *initiating* any sort of BUM traffic itself as described Section 15 of RFC7432. If I understand this document correctly, if a MAC moves onto a segment with a VPLS PE, traffic towards it will be blackholed until it initiates BUM traffic which is not the case when the MAC moves between EVPN PEs. Did I get this right? If so, I think this limitation needs to be highlighted a bit more prominently. ___ BESS mailing list BESS@ietf.org https://www.ietf.org/mailman/listinfo/bess
Re: [bess] Suresh Krishnan's Discuss on draft-ietf-bess-mvpn-expl-track-12: (with DISCUSS)
Hi Eric, Yes. It does. I have cleared. Regards Suresh > On Nov 28, 2018, at 11:35 AM, Eric Rosen wrote: > > 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
[bess] Suresh Krishnan's No Objection on draft-ietf-bess-mvpn-expl-track-13: (with COMMENT)
Suresh Krishnan has entered the following ballot position for draft-ietf-bess-mvpn-expl-track-13: No Objection 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://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-bess-mvpn-expl-track/ -- COMMENT: -- Thanks for addressing my DISCUSS ___ BESS mailing list BESS@ietf.org https://www.ietf.org/mailman/listinfo/bess
Re: [bess] Suresh Krishnan's Discuss on draft-ietf-bess-mvpn-expl-track-12: (with DISCUSS)
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
[bess] Suresh Krishnan's Discuss on draft-ietf-bess-mvpn-expl-track-12: (with DISCUSS)
Suresh Krishnan 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://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-bess-mvpn-expl-track/ -- DISCUSS: -- * Section 5.2. In the NLRI format it is not clear what the length of the "Ingress PE's IP address" field is supposed to be. i.e. what address families does it support and how do we determine what sort of address follows since there is no length field in front. ___ BESS mailing list BESS@ietf.org https://www.ietf.org/mailman/listinfo/bess
