Re: [Last-Call] Opsdir last call review of draft-ietf-bess-mvpn-msdp-sa-interoperation-05

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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?
 
Thanks.
Jeffrey
 
-----Original Message-----
From: Qin Wu <bill.wu@xxxxxxxxxx>
Sent: Friday, April 30, 2021 9:43 AM
To: Jeffrey (Zhaohui) Zhang <zzhang@xxxxxxxxxxx>; Lenny Giuliano <lenny@xxxxxxxxxxx>; ops-dir@xxxxxxxx
Cc: bess@xxxxxxxx; draft-ietf-bess-mvpn-msdp-sa-interoperation.all@xxxxxxxx; last-call@xxxxxxxx
Subject: RE: Opsdir last call review of draft-ietf-bess-mvpn-msdp-sa-interoperation-05
 
[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
-- 
last-call mailing list
last-call@xxxxxxxx
https://www.ietf.org/mailman/listinfo/last-call

[Index of Archives]     [IETF Annoucements]     [IETF]     [IP Storage]     [Yosemite News]     [Linux SCTP]     [Linux Newbies]     [Mhonarc]     [Fedora Users]

  Powered by Linux