Thanks for clarification. We are good . will work with Matthew about write up ☺
Mankamana From: "Jeffrey (Zhaohui) Zhang" <zzhang=40juniper....@dmarc.ietf.org> Date: Monday, April 13, 2020 at 1:04 PM To: "Acee Lindem (acee)" <a...@cisco.com>, "Mankamana Mishra (mankamis)" <manka...@cisco.com>, "draft-ietf-bess-mvpn-msdp-sa-interoperat...@ietf.org" <draft-ietf-bess-mvpn-msdp-sa-interoperat...@ietf.org> Cc: "Bocci, Matthew (Nokia - GB)" <matthew.bo...@nokia.com>, "bess@ietf.org" <bess@ietf.org> Subject: RE: [bess] Shepherd review comment draft-ietf-bess-mvpn-msdp-sa-interoperation-04 Hi Acee, Thanks for clarifying that. Hi Mankamana, Please see zzh> below. From: Acee Lindem (acee) <a...@cisco.com> Sent: Sunday, April 12, 2020 7:53 AM To: Mankamana Mishra (mankamis) <mankamis=40cisco....@dmarc.ietf.org>; draft-ietf-bess-mvpn-msdp-sa-interoperat...@ietf.org Cc: Bocci, Matthew (Nokia - GB) <matthew.bo...@nokia.com>; bess@ietf.org Subject: Re: [bess] Shepherd review comment draft-ietf-bess-mvpn-msdp-sa-interoperation-04 [External Email. Be cautious of content] Hi Mankamana, From: BESS <bess-boun...@ietf.org<mailto:bess-boun...@ietf.org>> on behalf of "Mankamana Mishra (mankamis)" <mankamis=40cisco....@dmarc.ietf.org<mailto:mankamis=40cisco....@dmarc.ietf.org>> Date: Saturday, April 11, 2020 at 4:41 PM To: "draft-ietf-bess-mvpn-msdp-sa-interoperat...@ietf.org<mailto:draft-ietf-bess-mvpn-msdp-sa-interoperat...@ietf.org>" <draft-ietf-bess-mvpn-msdp-sa-interoperat...@ietf.org<mailto:draft-ietf-bess-mvpn-msdp-sa-interoperat...@ietf.org>> Cc: "Bocci, Matthew (Nokia - GB)" <matthew.bo...@nokia.com<mailto:matthew.bo...@nokia.com>>, "bess@ietf.org<mailto:bess@ietf.org>" <bess@ietf.org<mailto:bess@ietf.org>> Subject: [bess] Shepherd review comment draft-ietf-bess-mvpn-msdp-sa-interoperation-04 Authors, As part of BESS Shepherd review process, went over document. Its in good shape to move forward. But I have some comments . · Abstract : I think new directive is not to have any RFC reference in Abstract, so you can remove reference of RFC 6514 from abstract As long as the referring text isn’t in the form of an IETF reference, i.e., [RFCXXXX], it is fine. In fact, this type of statement is required in a document that updates an RFC. Thanks, Acee · Terminology : Since it uses many terms from RFC 7761 (PIM), 6513 and 5614 . it may be good to state that familiarity with terms used in these RFC would be useful. · Introduction : o In introduction I see it talks about PE1 , PE2. But there Is no picture / topology in document . it may be useful to have one sample topology created . o Introduction does mention one statement about Extranet, but rest of the document does not have any mention of it. Do you want to add small paragraph which talks about what is expected in case of extranet ? Zzh> Nothing specific to extranet. It’s just that policies for extranet can control how BGP MVPN SA routes are advertised/imported (independent of this interoperation procedure), and then imported MVPN SA routes can be turned into MSDP SA routes (independent of extranet). · Section 3: Statement from this section “In that case, if the selected best MVPN SA route does not have the "MVPN SA RP-address EC" but another route for the same (C-S, C-G) does, then the best route with the EC SHOULD be chosen.” Does it not make sense to make it as MUST ? Zzh> Making it MUST will require changes to BGP route selection procedures; besides, an incoming MVPN SA routes may not carry that EC and the receiving PE needs to handle that anyway, so I think SHOULD is appropriate here. Zzh> Thanks! Zzh> Jeffrey Mankamana
_______________________________________________ BESS mailing list BESS@ietf.org https://www.ietf.org/mailman/listinfo/bess
