|
Hi Qin, Thank you so much for the review and comments. I have posted -06 revision. Jeffrey From: Qin Wu <bill.wu@xxxxxxxxxx>
[External Email. Be cautious of content] Jeffrey, thanks for your clarification. I am clear now. Would it be great to add some clarifications text as an overview somewhere which will add a lot of clarity. Thanks! 发件人：
Jeffrey (Zhaohui) Zhang<zzhang@xxxxxxxxxxx> 收件人：
Qin Wu<bill.wu@xxxxxxxxxx>;Lenny Giuliano<lenny@xxxxxxxxxxx>;ops-dir<ops-dir@xxxxxxxx> 抄送：
bess<bess@xxxxxxxx>;draft-ietf-bess-mvpn-msdp-sa-interoperation.all<draft-ietf-bess-mvpn-msdp-sa-interoperation.all@xxxxxxxx>;last-call<last-call@xxxxxxxx> 主题：
RE: Opsdir last call review of draft-ietf-bess-mvpn-msdp-sa-interoperation-05 时间：
2021-04-30 23:04:49 Hi Qin, Before the mechanism in this document is introduced, a PE may need to have MSDP sessions of both of the following:
#1 is clearly stated in RFC6514. #2 is mentioned in this document: … PE2 would need to have an MSDP session with PE1 (that advertised the MVPN SA messages) to learn the sources via MSDP SA messages, for it to advertise the MSDP SA to its local peers. With the mechanism (i.e., a PE advertises MSDP SA messages based on received MVPN SA routes) in this document, #2 is no longer needed. Jeffrey From: Qin Wu <bill.wu@xxxxxxxxxx>
[External Email. Be cautious of content] 发件人:
Jeffrey (Zhaohui) Zhang [mailto:zzhang@xxxxxxxxxxx]
Hi Qin, I assume there is one question in your latest email, marked with [Qin3], about the following paragraph: The MVPN PEs that act as customer RPs or have one or more MSDP sessions in a VPN (or the global table in case of GTM) are treated as an MSDP mesh group for that VPN (or the global table). In the rest of the document, it is referred to as the PE mesh group. It MUST NOT include other MSDP speakers … Let's restart from a clean slate. It reads the following: The MVPN PEs … are treated as an MSDP mesh group … It MUST NOT Include other MSDP speakers … Basically the mesh group only includes certain MVPN PEs and not other MSDP speakers. The PEs that are included in the mesh group are those that "act as customer RPs or have
one ore more MSDP sessions". I thought the text is clear? [Qin]: Sorry to go into loop discussion, When you say MVPN PEs have one or more MSDP sessions
in a VPN, I am wondering, with whom MVPN PE have one or more MSDP session?
non-PE MSDP speakers ? This is not clear to me. Do we really need to have such MSDP session? [Qin]: it seems PEs can have one or more MSDP session with other PEs, but based on your previous clarification, you said: “ 1. Highlight the assumption difference between mechanism proposed in RFC6514 and one proposed in this draft, e.g., in this draft, it doesn't require MSDP session to be established between PEs while RFC6514 allows this, that is why we
applied different policy on different network elements. Zzh3> The introduction section does clearly state the following: If a PE does advertise MSDP SA messages based on received MVPN SA routes, the VPN-specific MSDP sessions are no longer needed. ” Are you saying VPN-specific MSDP session between PEs are not needed? Or sometimes need while sometimes not needed? Thanks. Jeffrey -----Original Message----- [External Email. Be cautious of content] Section 3 When we say MVPN Pes that have one or more MSDP session in a VPN, does this statement contradict with “VPN-specific MSDP sessions are not required among the PEs”? zzh> The MSDP session that the PEs have are with other non-PE MSDP speakers but not among themselves, so it does not contradict with that quoted text. [Qin]:Without your clarification, I feel MVPN PEs will only establish MSDP session with other PEs in a VPN, rather than non-PE MSDP speakers? Can you add text to make this
clear? Zzh2> Section 1 does say the following: ... One or more of the PEs, say PE1, either act as a C-RP and learn of (C-S,C-G) via PIM Register messages, or have MSDP sessions with some MSDP peers and <==== learn (C-S,C-G) via MSDP SA messages... [Qin2]: without your clarification or familiar with the context of RFC6514, I will believe MSDP can be either PE2 or non PE elements. [RFC6514] only specifies that a PE receiving the MVPN SA routes, say PE2, will advertise (C-S,C-G) C-multicast routes if it has corresponding (C-*,C-G) state learnt from its CE. PE2 may also have MSDP sessions with other C-RPs at its site, <==== [Qin2]: In the VPN membership context, I will assume C-RPs can be PE1, but of course I am wrong. Zzh2> MVPN PEs establishing MSDP sessions with other non-PE devices is a common practice in RFC6514, so we should not need to call it again. [Qin2]: I think having some text to clarify MSDP peers or C-RPS as MSDP speakers is non-PE elements will have no harm, e.g., OLD TEXT: " The MVPN PEs that act as customer RPs or have one or more MSDP sessions in a VPN (or the global table in case of GTM) are treated as an MSDP mesh group for that VPN (or the global table). In the rest of the document, it is referred to as the PE mesh group. It MUST NOT include other MSDP speakers, and is integrated into the rest of MSDP infrastructure for the VPN (or the global table) following normal MSDP rules and practices. " NEW TEXT: " The MVPN PEs that act as customer RPs or have one or more MSDP sessions with non-PE elements in a VPN (or the global table in case of GTM) are treated as an MSDP mesh group for that VPN (or the global table). In the rest of the document, it is referred to as the PE mesh group. It only have one PE and MUST NOT include other PEs as MSDP speakers, and is integrated into the rest of MSDP infrastructure for the VPN (or the global table) following normal MSDP rules and practices. " Zzh3> Unfortunately the new text is not correct
😊 Zzh3> This document is about a PE treating incoming MVPN SA routes as MSDP SA messages (which triggers outgoing MSDP SA messages to MSDP peers). Therefore, the PEs originating
the MVPN SA routes and PEs originating outgoing MSDP SA messages as a result are considered in the same MSDP mesh group (as if they were running MSDP among themselves). That mesh group, referred to as PE mesh group, includes all PEs that "act as customer RPs
or have one or more MSDP sessions in a VPN". Zzh3> A PE may have multiple MSDP sessions and mesh groups. Zzh3> This document does assume "familiarity with MVPN and MSDP protocols and procedures", and adding more clarifications will pull in more and more concepts/procedures like
a chain reaction, so I'd rather avoid that. Zzh3> Thanks. Zzh3> Jeffrey [Qin3]: I think the confusing issue comes from " It MUST NOT include other MSDP speakers " and " have one or more MSDP sessions in a VPN ", my question are what are other MSDP speaker?, with whom PE have one or more session in a VPN? based on your previous clarification above, i.e., " Zzh said: " zzh> The MSDP session that the PEs have are with other non-PE MSDP speakers but not among themselves " Now you said: " Zzh3> A PE may have multiple MSDP sessions and mesh groups with other PEs Zzh3>That mesh group, referred to as PE mesh group, includes all PEs that "act as customer RPs or have one or more MSDP sessions in a VPN". " So Which one statement is correct? Are you sure MSDP session between PEs are needed or required in this document? Juniper Business Use Only Juniper Business Use Only
Juniper Business Use Only |
-- last-call mailing list last-call@xxxxxxxx https://www.ietf.org/mailman/listinfo/last-call
