Re: [bess] DF election text in RFC7432/7432bis and draft-ietf-bess-evpn-fast-df-recovery

[Jeffrey (Zhaohui) Zhang]

Hi Luc,

Thanks for your response and consideration.
Please see zzh> below.



Juniper Business Use Only
From: Luc André Burdet 
Sent: Friday, April 26, 2024 3:42 PM
To: Jeffrey (Zhaohui) Zhang ; 'BESS' 
Subject: Re: DF election text in RFC7432/7432bis and 
draft-ietf-bess-evpn-fast-df-recovery

[External Email. Be cautious of content]

Hi Jeffrey,

#3 is the one that should be updated, only the recovering PE starts a timer.

   3.  When the timer expires, each PE builds an ordered list of the IP
   addresses of all the PE nodes connected to the Ethernet segment
   (including itself), in increasing numeric value. ...
to:
   3.  Each PE builds an ordered list of the IP
   addresses of all the PE nodes connected to the Ethernet segment
   (including itself), in increasing numeric value. ...

The correction is really just to remove that statement re: timer expiry.  All 
the Peers build the list, only recovering timer has a “3s window to receive 
routes” which is meant to prevent the rapid-reshuffle when recovering PE gets 
1,2,3... peer routes in succession.
With this change, the text is aligned with the RFC8584 FSM. In a nutshell: 
failures on the DF are resolved as fast as possible. Recoveries of the former 
DF depend on the timer.

Zzh> Yes, this does align with the RFC8584. The previous “upon timer expiry” 
was adding confusion (even though it’s better for everyone to wait for the 
timer – then the only issue is with the transmission delay – propagation and 
scheduling in various parts of the machinery).
Zzh> I don’t understand the “In a nutshell: failures on the DF are resolved as 
fast as possible” part though – there is no DF failure here – we’re talking 
about a new ES route is originated, not that a previously valid ES route is 
lost.

I don’t think the “timer should be the same on all PEs in ES” statement is 
harmful? It’s just good practice and that ‘should’ is not normative.

Zzh> It’s not harmful, just really no use. That statement together with the 
“upon timer expiry” wording, really leads to one to believe that all PEs do the 
election at roughly the same time (barring the transmission delay). Now that 
we’re making it clear that is not the case, we might as well remove the 
unnecessary “timer should be the same on all PEs in ES” statement.

For Fast-DF-Recovery, it is not the CALC that is delayed, it is the 
application.  The calculation itself continues to be same as RFC7432/bis.  Only 
applying the result to HW is delayed on “other PEs”, which the (updated) FSM 
reflects.
Section 2.2 of the fast-df recovery draft is correct the way it is described: 
it refers to delaying the transition from DF_CALC to DF_DONE, which is not to 
be confused with the initial/discovery timer which is a locally configured 
timer. The delay between DF_CALC and DF_DONE is driven by the received SCT in 
the ES route not a local config.

Zzh> My previous reasoning: while this could be viewed as an implementation 
detail, it is implementation-wise easier and specification-wise cleaner to 
delay the DF_CALC itself. Every PE starts a timer that expires at the same 
absolute time, though the timer duration is different – depending on when a PE 
receives the new ES route with the SCT.

Zzh> Then I realize that the “skew” is probably what leads to the current text, 
and that makes sense. However, upon further reading of the “skew” text, I think 
the following inconsistencies need to be corrected.
Zzh> On an existing PE, the skew depends on the DF role (which could be 
different for different VLANs on the same ES) according to Section 3:


   In fact, PE1 should carve slightly before PE2 (skew) to maintain the

   preference of minimal loss over duplicate traffic.  The previously

   inserted PE2 that is recovering performs both transitions DF to NDF

   and NDF to DF per VLANs at the timer's expiry.  Since the goal is to

   prevent duplicates, the original PE1, which received the SCT will

   apply:



   *  DF to NDF transition at t=SCT minus skew, where both PEs are NDF

  for 'skew' amount of time



   *  NDF to DF transition at t=SCT

Zzh> However, the following text in section 2 does not talk about DF role at 
all. If one follows the following paragraph, then even the existing PEs would 
better go through the DF_WAIT state (my previous reasoning). This paragraph 
should be clarified with the DF role implications.

   Upon receipt of that new BGP Extended Community, partner PEs can
   determine the service carving time of the newly insterted PE.  The
   notion of skew is introduced to eliminate any potential duplicate
   traffic or loops.  The receiving partner PEs add a skew (default =
   -10ms) to the Service Carving Time to enforce this.  The previously
   inserted PE(s) must carve first, followed shortly (skew) by the newly
   insterted PE.

Zzh> In addition, in the section 2 text, the “previously inserted PEs” seem to 
refer to the existing/partner PEs while th

[bess] DF election text in RFC7432/7432bis and draft-ietf-bess-evpn-fast-df-recovery

[Jeffrey (Zhaohui) Zhang]

Hi,

I discussed this offline with a few people before. I want to bring it up here 
to make sure that consistent text is used 7432bis and relevant drafts.

https://datatracker.ietf.org/doc/html/draft-ietf-bess-rfc7432bis-08#name-designated-forwarder-electi
 says:

   1.  When a PE discovers the ESI of the attached Ethernet segment, it
   advertises an Ethernet Segment route with the associated
   ES-Import extended community.

   2.  The PE then starts a timer (default value = 3 seconds) to allow
   the reception of Ethernet Segment routes from other PE nodes
   connected to the same Ethernet segment.  This timer value should
   be the same across all PEs connected to the same Ethernet
   segment.

   3.  When the timer expires, each PE builds an ordered list of the IP
   addresses of all the PE nodes connected to the Ethernet segment
   (including itself), in increasing numeric value. ...

#2 says "the PE" (the new PE coming up on that ES) starts a timer. It does not 
mention if other PEs start a timer or not.
#3 says "when the timer expires, each PE ..."

Based on this existing text, #2 should be updated to "each PE then starts a 
timer". However, RFC8584's FSM makes it clear that existing PEs don't wait. 
Therefore, #3 should be updated. In addition, if it is only the new PE that 
starts the timer, then "This timer value should be the same across all PEs 
connected to the same Ethernet segment" in #2 is no longer needed.

I also wonder if in the 
https://datatracker.ietf.org/doc/html/draft-ietf-bess-evpn-fast-df-recovery#name-updates-to-rfc8584
 we should transition from DF_DONE to DF_WAIT instead of DF_CALC. Of course, 
the existing/peering PE's wait time is different from the new PE - the wait 
time is determined based on the received absolute SCT. This way, we have 
consistent behavior for the new and existing PEs.

Thanks.
Jeffrey



Juniper Business Use Only

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

Re: [bess] WG Adoption and IPR Poll for draft-sr-bess-evpn-dpath-04

[Jeffrey (Zhaohui) Zhang]

Hi,

We have received enough support for the adoption of this draft.
Authors, please submit WG -00 revision and adjust the front-page authors as 
discussed.

Thanks.
BESS chairs


Juniper Business Use Only
-Original Message-
From: Idr  On Behalf Of Jeffrey (Zhaohui) Zhang
Sent: Wednesday, March 6, 2024 1:32 PM
To: 'BESS' ; draft-sr-bess-evpn-dp...@ietf.org
Cc: idr@ietf. org ; 'bess-cha...@ietf.org' 
Subject: [Idr] WG Adoption and IPR Poll for draft-sr-bess-evpn-dpath-04

[External Email. Be cautious of content]


Hi,

This email begins a two-week WG adoption and IPR poll for 
draft-sr-bess-evpn-dpath-04 
(https://urldefense.com/v3/__https://datatracker.ietf.org/doc/draft-sr-bess-evpn-dpath/__;!!NEt6yMaO-gk!FM3dErCUE7LVeA4bJ2PAtLAmpdIH-zKHVKwBetKk2md1AOFsYHl9Il3XSX0aPfaUC4p1durJg1WtOLyXFvZiHPmZfnKcUBii$
 ).

Please review the draft and post any comments to the BESS working group list. 
The IDR list is copied in this call because of the Domain Path Attribute 
(D-PATH) introduced in draft-ietf-bess-evpn-ipvpn-interworking.

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 will not progress 
without answers from all the authors and contributors.

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

This poll for adoption closes on 20th March 2024.

Thanks.


BESS chairs

Juniper Business Use Only

___
Idr mailing list
i...@ietf.org
https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/idr__;!!NEt6yMaO-gk!FM3dErCUE7LVeA4bJ2PAtLAmpdIH-zKHVKwBetKk2md1AOFsYHl9Il3XSX0aPfaUC4p1durJg1WtOLyXFvZiHPmZfpooTiu7$

Juniper Business Use Only

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

Re: [bess] John Scudder's No Objection on draft-ietf-bess-evpn-irb-mcast-11: (with COMMENT)

[Jeffrey (Zhaohui) Zhang]

Hi John,

The duplication itself is a problem - a receiver should not receive duplicates.

However, a source should not send the same packet to two BDs. That's what the 
paragraph is supposing:

... (This does assume that source S does not
send the same (S,G) datagram on two different BDs ...)

Thanks.
Jeffrey


Juniper Business Use Only
-Original Message-
From: John Scudder 
Sent: Thursday, March 7, 2024 11:07 AM
To: Jeffrey (Zhaohui) Zhang 
Cc: The IESG ; draft-ietf-bess-evpn-irb-mc...@ietf.org; 
bess-cha...@ietf.org; bess@ietf.org; manka...@cisco.com
Subject: Re: John Scudder's No Objection on draft-ietf-bess-evpn-irb-mcast-11: 
(with COMMENT)

On Mar 7, 2024, at 9:47 AM, Jeffrey (Zhaohui) Zhang  wrote:
>
> zzh> If the source host is also connected to another BD3 that is attached to 
> PE2 and it is sending to both BD2 and BD3, then both copies will be switched 
> to PE1 via the SBD

So the only consequence is suboptimality because of duplicated packets? That 
seems fine. Thanks.

—John

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

Re: [bess] John Scudder's No Objection on draft-ietf-bess-evpn-irb-mcast-11: (with COMMENT)

[Jeffrey (Zhaohui) Zhang]

Hi John,

Thank you for your review and comments. A new revision will be posted after the 
pre-IETF119 quiescence period.

Please see zzh> below.

-Original Message-
From: John Scudder via Datatracker 
Sent: Wednesday, March 6, 2024 8:08 PM
To: The IESG 
Cc: draft-ietf-bess-evpn-irb-mc...@ietf.org; bess-cha...@ietf.org; 
bess@ietf.org; manka...@cisco.com; manka...@cisco.com
Subject: John Scudder's No Objection on draft-ietf-bess-evpn-irb-mcast-11: 
(with COMMENT)

[External Email. Be cautious of content]


John Scudder has entered the following ballot position for
draft-ietf-bess-evpn-irb-mcast-11: 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://urldefense.com/v3/__https://www.ietf.org/about/groups/iesg/statements/handling-ballot-positions/__;!!NEt6yMaO-gk!A78Ta3ONdPXEoLQIN_Gt40k6a96liTui1TPt4pd7phW8_rrv8UPDH6pB3ufNR90lr3bDTnxSm3NQbOQ$
for more information about how to handle DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://urldefense.com/v3/__https://datatracker.ietf.org/doc/draft-ietf-bess-evpn-irb-mcast/__;!!NEt6yMaO-gk!A78Ta3ONdPXEoLQIN_Gt40k6a96liTui1TPt4pd7phW8_rrv8UPDH6pB3ufNR90lr3bDTnxSbovfttY$



--
COMMENT:
--

Thanks for this document. Although dense and slow going, I appreciated the 
thoroughness and precision and have confidence that the dedicated reader who 
makes it all the way through will be able to implement this specification. I 
have some minor comments below that I hope might be of use.

- I continue to find the profligate use of acronyms and initialisms that 
characterizes so many bess documents to be an unnecessary, not to say 
gratuitous, impediment to readability, but so it goes. (If the authors are open 
to what might be an extensive revision to address this, I'm willing to dig in 
and provide more detailed feedback. But I don't expect it, at this late stage, 
especially since as noted above, I do think the document is usable, my 
complaint notwithstanding. If I'm mistaken, let me know and we can work on it.)

Zzh> Let me work with you separately on addressing this problem going forward 
in general.

- I agree with Éric Vyncke that there are several places where the text could 
easily be elucidated with the use of a diagram. Essentially, any of the many 
(very welcome!) examples seems like an easy candidate, one instance being 
“Suppose a given Tenant Domain contains three BDs (BD1, BD2, BD3) and two PEs 
(PE1, PE2). PE1 attaches to BD1 and BD2, while PE2 attaches to BD2 and BD3.”

Zzh> I added the following for the example you give:

SBDSBD
   /  \
  /\
 +---+  +---+
 |PE1+--+PE2|
 +---+  +---+
  | \   / |
 BD1 BD2  BD2 BD3

Zzh> I had to change the format of this email from plain text and use Courier 
New font. Hopefully it comes out aligned.

- I'm sure the RFCEd will flag this, but consider replacing the pronoun "he" in 
Section 1.3 with something not gender-specific.

Zzh> I changed it to “it”. I suppose we can use “it” for a “tenant” because 
we’re talking about an organization not a person.

- In Section 1.5.2 you mention an “attachment AC”, which expands as "attachment 
attachment circuit". Probably drop "attachment" or (better still in my view, 
see my first bullet) spell out "attachment circuit".

Zzh> I spelled it out.

- In Section 2.5 you have “This does assume that source S does not send the 
same (S,G) datagram on two different BDs, and that the Tenant Domain does not 
contain two or more sources with the same IP address S. The use of multicast 
sources that have IP "anycast" addresses is outside the scope of this 
document?” I tried to puzzle out what the consequence would be if that 
situation arose, but failed. Can you comment?

Zzh> Let me quote the context below.

   If all the sources and receivers for a given (*,G) are in the Tenant
   Domain, inter-subnet "Any Source Multicast" traffic will be properly
   routed without requiring any Rendezvous Points, shared trees, or
   other complex aspects of multicast routing infrastructure.   Suppose,
   for example, that:

   *  PE1 has a local receiver, on BD1, for (*,G)

   *  PE2 has a local source, on BD2, for (*,G).

   PE1 will originate an SMET(*,G) route for the SBD, and PE2 will
   receive that route, even if PE2 is not attached to BD1.  PE2 will
   thus know to forward (S,G) traffic to PE1.  PE1 does not need to do
   any "source discovery".  (This does 

Re: [bess] Robert Wilton's No Objection on draft-ietf-bess-evpn-irb-mcast-11: (with COMMENT)

[Jeffrey (Zhaohui) Zhang]

Thanks, Rob.
I have changed that. A new revision with some other minor changes will be 
posted after the pre-IETF119 quiescence period.

Jeffrey


Juniper Business Use Only
-Original Message-
From: Robert Wilton via Datatracker 
Sent: Thursday, March 7, 2024 6:34 AM
To: The IESG 
Cc: draft-ietf-bess-evpn-irb-mc...@ietf.org; bess-cha...@ietf.org; 
bess@ietf.org; manka...@cisco.com; manka...@cisco.com
Subject: Robert Wilton's No Objection on draft-ietf-bess-evpn-irb-mcast-11: 
(with COMMENT)

[External Email. Be cautious of content]


Robert Wilton has entered the following ballot position for
draft-ietf-bess-evpn-irb-mcast-11: 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://urldefense.com/v3/__https://www.ietf.org/about/groups/iesg/statements/handling-ballot-positions/__;!!NEt6yMaO-gk!AHYVKqdnIFS8Z1fiig5zR8V9MFgDfNSMs7auANZ0yhJzJbWFww-Ah7AiKw21r9pa9foq6LyB4t8Q1nI$
for more information about how to handle DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://urldefense.com/v3/__https://datatracker.ietf.org/doc/draft-ietf-bess-evpn-irb-mcast/__;!!NEt6yMaO-gk!AHYVKqdnIFS8Z1fiig5zR8V9MFgDfNSMs7auANZ0yhJzJbWFww-Ah7AiKw21r9pa9foq6LyBcyvcBqs$



--
COMMENT:
--

Hi,

One minor comment to check:

(1) p 10, sec 1.3.  Need for EVPN-aware Multicast Procedures

   However, that technique does not provide optimal routing for
   multicast.  In conventional multicast routing, for a given multicast
   flow, there is only one multicast router on each BD that is permitted
   to send traffic of that flow to the BD.  If that BD has receivers for
   a given flow, but the source of the flow is not on that BD, then the
   flow must pass through that multicast router.  This leads to the
   "hair-pinning" problem described (for unicast) in Appendix A.
   For example, consider an (S,G) flow that is sourced by a TS S and
   needs to be received by TSes R1 and R2.  Suppose S is on a segment of
   BD1, R1 is on a segment of BD2, but both are attached to PE1.
   Suppose also that the tenant has a multicast router, attached to a
   segment of BD1 and to a segment of BD2.  However, the segments to
   which that router is attached are both attached to PE2.  Then the
   flow from S to R would have to follow the path:
   S-->PE1-->PE2-->Tenant Multicast Router-->PE2-->PE1-->R1.  Obviously,
   the path S-->PE1-->R would be preferred.

S to R => S to R1, and PE1-->R to PE1-->R1?

Regards,
Rob



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

[bess] WG Adoption and IPR Poll for draft-sr-bess-evpn-dpath-04

[Jeffrey (Zhaohui) Zhang]

Hi,

This email begins a two-week WG adoption and IPR poll for 
draft-sr-bess-evpn-dpath-04 
(https://datatracker.ietf.org/doc/draft-sr-bess-evpn-dpath/).

Please review the draft and post any comments to the BESS working group list. 
The IDR list is copied in this call because of the Domain Path Attribute 
(D-PATH) introduced in draft-ietf-bess-evpn-ipvpn-interworking.

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 will not progress 
without answers from all the authors and contributors.

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

This poll for adoption closes on 20th March 2024.

Thanks.


BESS chairs

Juniper Business Use Only

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

Re: [bess] Roman Danyliw's No Objection on draft-ietf-bess-evpn-irb-mcast-11: (with COMMENT)

[Jeffrey (Zhaohui) Zhang]

Hi Roman,

Thanks for your review and comments.
I will make some changes and post after the pre-IETF119 quiescence period is 
over.

Please see zzh> below for some clarifications.


Juniper Business Use Only
-Original Message-
From: Roman Danyliw via Datatracker 
Sent: Tuesday, March 5, 2024 8:40 PM
To: The IESG 
Cc: draft-ietf-bess-evpn-irb-mc...@ietf.org; bess-cha...@ietf.org; 
bess@ietf.org; manka...@cisco.com; manka...@cisco.com
Subject: Roman Danyliw's No Objection on draft-ietf-bess-evpn-irb-mcast-11: 
(with COMMENT)

[External Email. Be cautious of content]


Roman Danyliw has entered the following ballot position for
draft-ietf-bess-evpn-irb-mcast-11: 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://urldefense.com/v3/__https://www.ietf.org/about/groups/iesg/statements/handling-ballot-positions/__;!!NEt6yMaO-gk!ClajButEf7Y6yic83YRtyz3RrbPLLYNFPnyfi0Da7BFSRs66fzxgissKV741K6byCGd4XHeSEPiWhlI$
for more information about how to handle DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://urldefense.com/v3/__https://datatracker.ietf.org/doc/draft-ietf-bess-evpn-irb-mcast/__;!!NEt6yMaO-gk!ClajButEf7Y6yic83YRtyz3RrbPLLYNFPnyfi0Da7BFSRs66fzxgissKV741K6byCGd4XHeSsCr3BIY$



--
COMMENT:
--

Thank you to Tiru Reddy for his SECDIR review.  I saw not response to his 
feedback.  I have similar feedback.

Zzh> Oops. We did work with Tiru (copied) and posted the -09 revision to 
address his comments, but we forgot to reply to the original email thread after 
that.

** Section 9
   This document uses protocols and procedures defined in the normative
   references, and inherits the security considerations of those
   references.

-- Please explicitly name the relevant references.

Zzh> Sure.

-- Do the Security Considerations of [I-D.ietf-bier-evpn] apply?

Zzh> I guess. I will also add P2MP tunnel references for the inheritance of 
security considerations.

** Section 9
   Incorrect addition, removal, or modification of those
   flags and/or ECs will cause the procedures defined herein to
   malfunction, in which case loss or diversion of data traffic is
   possible.  Implementations should provide tools to easily debug
   configuration mistakes that cause the signaling of incorrect
   information.

Is this manipulation of flags something done as by an attacker or an 
unintentional insider misconfiguring a system?  Are there any mitigations for 
this manipulation of flags?

Zzh> It'd be unintentional insider misconfiguration or software bugs. The 
mitigation is basically improving software quality and "provide tools to easily 
debug configuration mistakes that cause the signaling of incorrect information".

** Section 8.  Typo.  Wrong registry name.

   IANA is requested to assign new flags in the "Multicast Flags
   Extended Community Flags" registry.

Zzh> Thanks. Fixed.
Zzh> Jeffrey

The formal name of the registry is “Multicast Flags Extended Community” (no
“Flags”) per
https://urldefense.com/v3/__https://www.iana.org/assignments/bgp-extended-communities/bgp-extended-communities.xhtml*multicast-flags__;Iw!!NEt6yMaO-gk!ClajButEf7Y6yic83YRtyz3RrbPLLYNFPnyfi0Da7BFSRs66fzxgissKV741K6byCGd4XHeSHors4cw$



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

Re: [bess] Erik Kline's No Objection on draft-ietf-bess-evpn-irb-mcast-11: (with COMMENT)

[Jeffrey (Zhaohui) Zhang]

Hi Erik,

Thanks for your review and comments.
I've fixed two nits in the .xml source - it will be posted when the pre-IETF119 
quiescence period is over.
One clarifying point below with the zzh> prefix.


Juniper Business Use Only
-Original Message-
From: Erik Kline via Datatracker 
Sent: Tuesday, March 5, 2024 11:24 PM
To: The IESG 
Cc: draft-ietf-bess-evpn-irb-mc...@ietf.org; bess-cha...@ietf.org; 
bess@ietf.org; manka...@cisco.com; manka...@cisco.com
Subject: Erik Kline's No Objection on draft-ietf-bess-evpn-irb-mcast-11: (with 
COMMENT)

[External Email. Be cautious of content]


Erik Kline has entered the following ballot position for
draft-ietf-bess-evpn-irb-mcast-11: 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://urldefense.com/v3/__https://www.ietf.org/about/groups/iesg/statements/handling-ballot-positions/__;!!NEt6yMaO-gk!CO7zCp6IWnMHFgB7DRMhN0bEPtACq62ALzQc4RYvT-trbgrXey5CEDqRaeBiIzWb56wNVMlxMCY67kc$
for more information about how to handle DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://urldefense.com/v3/__https://datatracker.ietf.org/doc/draft-ietf-bess-evpn-irb-mcast/__;!!NEt6yMaO-gk!CO7zCp6IWnMHFgB7DRMhN0bEPtACq62ALzQc4RYvT-trbgrXey5CEDqRaeBiIzWb56wNVMlxVDWBsjc$



--
COMMENT:
--

# Internet AD comments for draft-ietf-bess-evpn-irb-mcast-11 CC @ekline

* comment syntax:
  - 
https://urldefense.com/v3/__https://github.com/mnot/ietf-comments/blob/main/format.md__;!!NEt6yMaO-gk!CO7zCp6IWnMHFgB7DRMhN0bEPtACq62ALzQc4RYvT-trbgrXey5CEDqRaeBiIzWb56wNVMlxaWOynKw$

* "Handling Ballot Positions":
  - 
https://urldefense.com/v3/__https://ietf.org/about/groups/iesg/statements/handling-ballot-positions/__;!!NEt6yMaO-gk!CO7zCp6IWnMHFgB7DRMhN0bEPtACq62ALzQc4RYvT-trbgrXey5CEDqRaeBiIzWb56wNVMlxxtN2VQw$

## Comments

* Very clearly written, I thought, thank you.

## Nits

### S1.1

* "address of addresses"
  "address or addresses", I suspect

### S1.3

* Consider "he" -> "they"

Zzh> It is about "a particular tenant", so "he" should be fine?

  For instance, if a particular tenant has n BDs among
  which he wants to send IP multicast traffic ...

zzh> Thanks!
Zzh> Jeffrey

### Appendix A.

* "intreface" -> "interface"



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

Re: [bess] Éric Vyncke's No Objection on draft-ietf-bess-evpn-irb-mcast-10: (with COMMENT)

[Jeffrey (Zhaohui) Zhang]

Hi Eric,

Thanks for your review and comments. I posted -11 that addresses most of your 
comments: 
https://author-tools.ietf.org/iddiff?url1=draft-ietf-bess-evpn-irb-mcast-10=draft-ietf-bess-evpn-irb-mcast-11=--html.

Please see zzh> below for some clarfications.


Juniper Business Use Only
-Original Message-
From: Éric Vyncke via Datatracker 
Sent: Monday, March 4, 2024 5:20 AM
To: The IESG 
Cc: draft-ietf-bess-evpn-irb-mc...@ietf.org; bess-cha...@ietf.org; 
bess@ietf.org; manka...@cisco.com; manka...@cisco.com; br...@innovationslab.net
Subject: Éric Vyncke's No Objection on draft-ietf-bess-evpn-irb-mcast-10: (with 
COMMENT)

[External Email. Be cautious of content]


Éric Vyncke has entered the following ballot position for
draft-ietf-bess-evpn-irb-mcast-10: 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://urldefense.com/v3/__https://www.ietf.org/about/groups/iesg/statements/handling-ballot-positions/__;!!NEt6yMaO-gk!DhD7utIBY1vYH8I6IZ-ox9QnO5417w-hM2_79mAuuG1tuAnmpU8_FHmV8LwOOSBhg3VEPCoRCEMrYgs$
for more information about how to handle DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://urldefense.com/v3/__https://datatracker.ietf.org/doc/draft-ietf-bess-evpn-irb-mcast/__;!!NEt6yMaO-gk!DhD7utIBY1vYH8I6IZ-ox9QnO5417w-hM2_79mAuuG1tuAnmpU8_FHmV8LwOOSBhg3VEPCoRkpiq_7Y$



--
COMMENT:
--


# Éric Vyncke, INT AD, comments for draft-ietf-bess-evpn-irb-mcast-10

Thank you for the work put into this document.

Please find below some non-blocking COMMENT points (but replies would be 
appreciated even if only for my own education), and some nits.

Special thanks to Mankamana Mishra for the shepherd's detailed write-up 
including the WG consensus *and* the justification of the intended status. The 
use of the old template was a trip to the past ;-) (but this is OK).

Other thanks to Brian Haberman, the Internet directorate reviewer (at my 
request), please consider this int-dir review:
https://urldefense.com/v3/__https://datatracker.ietf.org/doc/review-ietf-bess-evpn-irb-mcast-09-intdir-telechat-haberman-2024-02-22/__;!!NEt6yMaO-gk!DhD7utIBY1vYH8I6IZ-ox9QnO5417w-hM2_79mAuuG1tuAnmpU8_FHmV8LwOOSBhg3VEPCoRknVNCiM$
(and I have read Jeffrey's replies, thanks)

I hope that this review helps to improve the document,

Zzh> It definitely helps!

Regards,

-éric

# COMMENTS (non-blocking)

## Author count

Just a minor comment, there are 6 authors while the limit is usually 5. Not a 
big deal at all for me, and it is justified in the shepherd's write-up.

## Readability

In several sections, a network diagram would help the reader.

Zzh> I had added one diagram per Brian's comment. If you can point me to more 
sections, I can try to add more.

This I-D solves a hard-problem, and it is not an easy read. I sincerely hope 
that the existing implementations (per shepherd's write-up) are interoperable 
and follow this specification.

Zzh> There was an interop testing done just last week as part of EANTC.

## Section 1.1

The abstract mentions MPLS and IP as backbone while this section is only about 
IP. Which one is correct ?

Zzh> I changed to "IP or MPLS backbone". The emphasis is that the backbone is 
L3 (not L2).

Please move the BCP 14 template outside of `background`

Zzh> Done.

## Section 1.1.1

Is having TS1 and TS2 on the same BD enough to ensure that mcast traffic is 
received ? Should the layer-2 infrastructure also be aware of the mcast traffic 
(i.e., MLD snooping)? After all, the "B" in "BD" is only for broadcast.

Zzh> Yes. By default, multicast traffic is treated as broadcast and flooded 
everywhere. With snooping, the flooding is turned into selective forwarding 
(only to where it needs to go).

Would the infinite loop also happen with plain broadcast frames ?

Zzh> Yes. I think "This is particularly important for multicast" is to compare 
to unicast, not to broadcast.

## Section 1.1.2

`The TTL field of the IP datagram` let's rather use "hop limit" in 2024.

Zzh> I was planning to do a whole change of TTL to "hop limit" but it does not 
read well in some places. Given that TTL is a well know term, I'd like to stay 
with it.

## Section 1.1.3

The readers would probably welcome some explanations of why PIM/MLD is not 
enough in the case of inter-subnet mcast traffic. Or a promise that the 
explanations are deferred to section 1.2. Or the leading text moved to section 
1.2.

Zzh> IGMP/MLD is only used for hosts on a subnet to signal to routers that they 
need to receive certain multicast traffic. Inter-subnet multicast traffic 
requires PIM. I'll see if I could add some text somewhere.

## Section 1.3

Which header is it in `header checksum is 

Re: [bess] Intdir telechat review of draft-ietf-bess-evpn-irb-mcast-09

[Jeffrey (Zhaohui) Zhang]

Hi Brian,

Thank you for reviewing the diff and my response below. I've updated it further 
and posted the -10 revision: 
https://author-tools.ietf.org/iddiff?url2=draft-ietf-bess-evpn-irb-mcast-10

Jeffrey


Juniper Business Use Only
-Original Message-
From: Jeffrey (Zhaohui) Zhang
Sent: Saturday, February 24, 2024 9:24 PM
To: Brian Haberman ; int-...@ietf.org
Cc: bess@ietf.org; draft-ietf-bess-evpn-irb-mcast@ietf.org; 
last-c...@ietf.org
Subject: RE: Intdir telechat review of draft-ietf-bess-evpn-irb-mcast-09

Hi Brian,

Thank you for your review and comments.

I will post a revision. For now, please see zzh> below.

-Original Message-
From: Brian Haberman via Datatracker 
Sent: Thursday, February 22, 2024 12:27 PM
To: int-...@ietf.org
Cc: bess@ietf.org; draft-ietf-bess-evpn-irb-mcast@ietf.org; 
last-c...@ietf.org
Subject: Intdir telechat review of draft-ietf-bess-evpn-irb-mcast-09

[External Email. Be cautious of content]


Reviewer: Brian Haberman
Review result: Ready with Issues

I am an assigned INT directorate reviewer for draft-ietf-bess-evpn-irb-mcast.
These comments were written primarily for the benefit of the Internet Area 
Directors. Document editors and shepherd(s) should treat these comments just 
like they would treat comments from any other IETF contributors and resolve 
them along with any other Last Call comments that have been received. For more 
details on the INT Directorate, see 
https://urldefense.com/v3/__https://datatracker.ietf.org/group/intdir/about/__;!!NEt6yMaO-gk!Bx0bNC3eOL4kGtr34kvBCeiPvJn5p5ANXiHZr-ZJa_wfCj3KVIZ4QsqlBZpRhP64_-HXi10psON49uU$
<https://urldefense.com/v3/__https://datatracker.ietf.org/group/intdir/about/__;!!NEt6yMaO-gk!Bx0bNC3eOL4kGtr34kvBCeiPvJn5p5ANXiHZr-ZJa_wfCj3KVIZ4QsqlBZpRhP64_-HXi10psON49uU$
 >.

I have a number of comments/questions/suggestions about this draft. Happy to be 
pointed to other documents where these topics are addressed, but they stood out 
to me in this document.

1. Section 1.2 - The (S,G) flow example would benefit greatly from a diagram.
It is difficult to follow the explanation without some visualization of the 
connectivity.

Zzh> I will add a diagram.

2. Section 1.3 - I see very little traceability or justification for the 
requirements. For example, what is the genesis of the fourth requirement for 
not using multicast routing when you have multiple broadcast domains?

Zzh> Are you referring to the following?

   *  If a Tenant Domain contains several BDs, it MUST be possible for a
  multicast flow (even when the multicast group address is an "any
  source multicast" (ASM) address), to have sources in one of those
  BDs and receivers in one or more of the other BDs, without
  requiring the presence of any system performing PIM Rendezvous
  Point (RP) functions [RFC7761].  Multicast throughout a Tenant
  Domain must not require the tenant systems to be aware of any
  underlying multicast infrastructure.

Zzh> It does not say "not using multicast routing". It only says RPs must not 
be required. One may argue this is not a justified requirement, but the 
solution in this document does have the nice property that RP is not needed at 
all. I removed the last sentence, because it is true even in the traditional 
multicast routing outside the context of EVPN.

3. Section 1.4 - I am failing to see the distinction in the definitions of
"(S,G) Multicast Frame" and "(S,G) Multicast Packet". I suspect the definition 
of the former should be for an ethernet frame carrying an IP multicast packet.

Zzh> Correct.

4. Section 1.5.1 - At this point in time, why does the specification mandate
IGMPv2/MLDv1 rather than IGMPv3/MLDv2? Those specifications support ASM as well 
as SSM.

Zzh> Are you referring to that the following paragraph only references 2236 and 
2710? That's an oversight. We now reference 3376 (which obsoletes 2236), 2710,  
and 3810.

   In this section, and in the remainder of this document, we assume the
   reader is familiar with the procedures of IGMP/MLD (see [RFC2236] and
   [RFC2710]), by which hosts announce their interest in receiving
   particular multicast flows.

5. It appears that this specification is assuming that all multicast addresses 
that fall outside of the designated SSM range should be treated as ASM.
However, multicast routers can apply SSM handling procedures to any multicast 
group if it has been configured to do so. Will OISM also require a 
configuration option to designate which address ranges are SSM vs ASM?

Zzh> It does not need to distinguish between SSM and ASM (besides that one uses 
(s,g) while the other uses (*,g) states triggered by (s,g) or (*,g) joins), and 
there is no need for an RP even for ASM.

6. Section 4.1 - It is unclear if the forwarding being described is using 
ethernet frame information or IP header information. I am assuming the former, 
but clarity would

Re: [bess] Intdir telechat review of draft-ietf-bess-evpn-irb-mcast-09

[Jeffrey (Zhaohui) Zhang]

Hi Brian,

Thank you for your review and comments.

I will post a revision. For now, please see zzh> below.


Juniper Business Use Only
-Original Message-
From: Brian Haberman via Datatracker 
Sent: Thursday, February 22, 2024 12:27 PM
To: int-...@ietf.org
Cc: bess@ietf.org; draft-ietf-bess-evpn-irb-mcast@ietf.org; 
last-c...@ietf.org
Subject: Intdir telechat review of draft-ietf-bess-evpn-irb-mcast-09

[External Email. Be cautious of content]


Reviewer: Brian Haberman
Review result: Ready with Issues

I am an assigned INT directorate reviewer for draft-ietf-bess-evpn-irb-mcast.
These comments were written primarily for the benefit of the Internet Area 
Directors. Document editors and shepherd(s) should treat these comments just 
like they would treat comments from any other IETF contributors and resolve 
them along with any other Last Call comments that have been received. For more 
details on the INT Directorate, see 
https://urldefense.com/v3/__https://datatracker.ietf.org/group/intdir/about/__;!!NEt6yMaO-gk!Bx0bNC3eOL4kGtr34kvBCeiPvJn5p5ANXiHZr-ZJa_wfCj3KVIZ4QsqlBZpRhP64_-HXi10psON49uU$
.

I have a number of comments/questions/suggestions about this draft. Happy to be 
pointed to other documents where these topics are addressed, but they stood out 
to me in this document.

1. Section 1.2 - The (S,G) flow example would benefit greatly from a diagram.
It is difficult to follow the explanation without some visualization of the 
connectivity.

Zzh> I will add a diagram.

2. Section 1.3 - I see very little traceability or justification for the 
requirements. For example, what is the genesis of the fourth requirement for 
not using multicast routing when you have multiple broadcast domains?

Zzh> Are you referring to the following?

   *  If a Tenant Domain contains several BDs, it MUST be possible for a
  multicast flow (even when the multicast group address is an "any
  source multicast" (ASM) address), to have sources in one of those
  BDs and receivers in one or more of the other BDs, without
  requiring the presence of any system performing PIM Rendezvous
  Point (RP) functions [RFC7761].  Multicast throughout a Tenant
  Domain must not require the tenant systems to be aware of any
  underlying multicast infrastructure.

Zzh> It does not say "not using multicast routing". It only says RPs must not 
be required. One may argue this is not a justified requirement, but the 
solution in this document does have the nice property that RP is not needed at 
all. I removed the last sentence, because it is true even in the traditional 
multicast routing outside the context of EVPN.

3. Section 1.4 - I am failing to see the distinction in the definitions of
"(S,G) Multicast Frame" and "(S,G) Multicast Packet". I suspect the definition 
of the former should be for an ethernet frame carrying an IP multicast packet.

Zzh> Correct.

4. Section 1.5.1 - At this point in time, why does the specification mandate
IGMPv2/MLDv1 rather than IGMPv3/MLDv2? Those specifications support ASM as well 
as SSM.

Zzh> Are you referring to that the following paragraph only references 2236 and 
2710? That's an oversight. We now reference 3376 (which obsoletes 2236), 2710,  
and 3810.

   In this section, and in the remainder of this document, we assume the
   reader is familiar with the procedures of IGMP/MLD (see [RFC2236] and
   [RFC2710]), by which hosts announce their interest in receiving
   particular multicast flows.

5. It appears that this specification is assuming that all multicast addresses 
that fall outside of the designated SSM range should be treated as ASM.
However, multicast routers can apply SSM handling procedures to any multicast 
group if it has been configured to do so. Will OISM also require a 
configuration option to designate which address ranges are SSM vs ASM?

Zzh> It does not need to distinguish between SSM and ASM (besides that one uses 
(s,g) while the other uses (*,g) states triggered by (s,g) or (*,g) joins), and 
there is no need for an RP even for ASM.

6. Section 4.1 - It is unclear if the forwarding being described is using 
ethernet frame information or IP header information. I am assuming the former, 
but clarity would be good given the overloaded use of the "(S,G)" nomenclature.

Zzh> It is actually the IP header information. "Layer 3 multicast state" refers 
to what we're used to for multicast routing. "layer 2 multicast state" refers 
to the multicast state in BDs built by IGMP/MLD snooping or the OISM procedures 
in this document, but it is still (S,G)/(*,G) based. I understand that "layer 2 
multicast state" may be misleading - I will add some clarifying text.

7. Section 4.1.1 - It is unclear if the snooping being described here is based 
on RFC 9251 or RFC 4541. Assuming the 

[bess] ECMP, equal/unequal Load-Balancing, and https://datatracker.ietf.org/doc/html/draft-ietf-bess-evpn-unequal-lb-21

[Jeffrey (Zhaohui) Zhang]

Hi Neeraj,

ECMP is mentioned many times in the draft. It seems to be used somewhat 
inconsistently.

My understanding is that ECMP, spelled as Equal Cost Multi-Path, is about the 
underlay paths to egress MHES PEs. If an ingress PE does not have equal cost 
paths to those PEs, then load-balancing will not be used at all by default - 
the closest PE is always used. This is to optimize the traffic delivery in the 
core network.

Of course, one may choose to do load-balancing even w/o ECMP, for better 
utilization of MHES ACs.

The above is regardless of whether equal or non-equal distribution of load to 
different PEs is used or not.

I suppose the document is mainly about equal or unequal (weighted) 
load-balancing, which can be applied regardless of whether ECMP exists or not 
(depending on the operator's choice).

If my understanding is correct, the document should minimize the use of ECMP 
term. Perhaps just mention it once or twice - either that ECMP is the 
prerequisite, or load-balancing (equal or unequal) can be used whether ECMP 
exists or not.

Some examples of inconsistent uses:

   Once consistency of 'Value-Units' is validated, ingress PE SHOULD use
   the 'Value-Weight' received from each egress PE to compute a relative
   (normalized) weight for each egress PE, per ES, and then use this
   relative weight to compute a weighted path-list to be used for load
   balancing, as opposed to using an ECMP path-list for load balancing
   across the egress PE paths.  Egress PE Weight and resulting weighted
   path-list computation at ingress PEs is a local matter.

The above paragraph says, "a weighted path-list ... as opposed to an ECMP 
path-list". It implies that ECMP refers to "equal" load balancing.

   While incorporating link bandwidth into the DF election process
   provides optimal BUM traffic distribution across the ES links, it
   also implies that DF elections are re-adjusted on link failures or
   bandwidth changes.  If the operator does not wish to have this level
   of churn in their DF election, then they should not advertise the BW
   capability.  Not advertising BW capability may result in less than
   optimal BUM traffic distribution while still retaining the ability to
   allow an ingress PE to do weighted ECMP for its unicast traffic to a
   set of egress PEs.

The "weighted ECMP" above implies ECMP is about the ECMP in the underlay.

   In an EVPN IRB (Integrated Routing and Bridging) overlay network as
   described in [RFC9135], with a CE multi-homed via a EVPN all-active
   multi-homing, bridged and routed traffic from ingress PEs can be
   equally load balanced (ECMPed) across the multi-homing egress PEs:

   *  ECMP Load-balancing for bridged unicast traffic is enabled via
  aliasing and mass-withdraw procedures detailed in [RFC7432].

   *  ECMP Load-balancing for routed unicast traffic is enabled via
  existing L3 ECMP mechanisms.

The above seems to refer to equal load-balancing.

Jeffrey

Juniper Business Use Only

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

Re: [bess] Comments about https://datatracker.ietf.org/doc/html/draft-duan-bess-simplified-mvpn-for-bier-and-ir-00

[Jeffrey (Zhaohui) Zhang]

Hi Siyu,

Let me list some high-level summary of BGP-MVPN protocol mechanisms before 
going into response to your comments.

BGP-MVPN has 7 route types:

- Type 1: To announce non-segmented inclusive tunnels
- Type 2: To announce segmented inter-as tunnels and for per-AS aggregation
- Type 3: To announce binding of flows to selective tunnels
- Type 4: For egress PEs to tell ingress PEs they're leaves of the selective 
tunnels in response to type 2/3. Needed for RSVP P2MP, IR/BIER
- Type 5: For source discovery, assert and (s,g,rpt) prune in case of shared 
tree across the provider network
- Type 6/7: For (*,g) or (s,g) joins

To compare against Rosen/PIM-MVPN:

- Type-1 route is comparable to the static configuration of per-VPN group for 
the default MDT
- Type-2 route is irrelevant because there is no concept of per-AS aggregation 
and inter-AS segmentation
- Type-3 route is comparable to the data MDT route
- Type-4 is for explicit tracking, and not needed for PIM/mLDP provider tunnels
- Type-5 is for the control plane based assert procedure and (s,g,rpt) prune
- Type 6/7 is comparable for PIM (*,g)/(s,g) joins but w/o the explicit 
tracking functionality

Please see zzh> below.


Juniper Business Use Only
-Original Message-
From: Chensiyu (Susie)
Sent: Thursday, November 30, 2023 10:23 PM
To: Jeffrey (Zhaohui) Zhang ; 'BESS'
Cc: duanfanghong
Subject: RE: Comments about 
https://datatracker.ietf.org/doc/html/draft-duan-bess-simplified-mvpn-for-bier-and-ir-00

[External Email. Be cautious of content]


Hi Jeffrey,

Your summary about our method is great. I've also read your draft about 
explicit tracking. Explicit tracking is realized by our new procedure, but it's 
not the only goal we'd like to achieve.

Zzh> Explicit tracking is an important aspect in both drafts - separate 
type-6/7 and type-4 routes are merged. In draft-zzhang, it is into the existing 
type-6/7 routes and in draft-duan it is into a new route. The question is, 
which way do we want to go for explicit tracking.

Our goal is to provide the simplest MVPN signaling interaction when the tunnel 
type is BIER or IR. Previous 8 routes are simplified to 2 routes.

Zzh> The draft talks about the following:

 3.1.  Simplification of Type 1 to Type 4 NLRI . . . . . . . . .   4
 3.2.  Simplification of Type 6 to Type 7 NLRI . . . . . . . . .   5

Zzh> About "simplification of Type 1 to Type 4", I don't think your proposal 
handles segmentation and per-AS aggregation, so it is only about 
"simplification of Type 1/3/4". Specifically, the Type 1/3 functionality is 
folded into the UMH routes while the Type 4 functionality is folded into your 
new route type (a merge of Type 6/7 and Type 4). My previous email pointed out 
the issue with using UMH routes, and in draft-zzhang, the Type 3 functionality 
is folded into type 1 in case of BIER/IR (but still allow to use Type 3 when 
more granularity is needed, e.g., different flows may use different BIER 
sub-domains) and the Type 4 functionality (explicit tracking) is folded into 
Type 6/7 itself.
Zzh> My argument is that the solution in draft-zzhang is better.

Zzh> Now about "Simplification of Type 6 to Type 7 NLRI" - it's basically the 
explicit tracking plus (s,g,rpt) prune. We talked about explicit tracking 
already.

We don't aim at all existing tunnels and would like to construct a PIM-like 
procedure which consists of RPF route and J/P/SG-RPT route exchanging. The 
J/P/SG-RPT route can either be a new route or a modified one based on the 
existing C-multicast route. The new route will carry (S,G,RPT) information 
which weren't carried by the old C-multicast routes in RFC6514. These routes 
and exchanging procedures are designed based on BGP because BGP is widely 
deployed.

Zzh> draft-zzhang covers many different use cases with different solutions. In 
case of BIER/IR tunnel, it extends Type-6/7 routes with explicit tracking and 
removes the need for type-3 route. With that, it achieves the same goals you 
listed above except the (s,g,rpt) prune.
Zzh> When BGP-MVPN was designed, a deliberate decision was made to use type-5 
routes for (s,g,rpt) prune instead of using explicit (s,g,rpt) prune 
flag/route. I can't articulate the detailed reasons, but we don't have to rush 
to a change.

Therefore, we think that our draft actually focus on different scenario and 
problems and we'd like to continue our work on our draft. We are also working 
on solution for tunnel segmentation scenario and it will be updated in later 
version.

Zzh> As explained above, I don't agree that your draft focus on different 
scenarios and problems. You can say that you use different solutions for the 
same problem (for which there are already proposed solutions w/o using new 
route types), and the WG can debate and decide which way to go.

Zzh> Jeffrey

Best wishes,
Siyu
-Original Message-
From: Jeffrey (Zhaohui) Zhang [mailto:zzhang=40juni

[bess] Questions/comments on https://datatracker.ietf.org/doc/html/draft-ietf-bess-evpn-ac-aware-bundling-04

[Jeffrey (Zhaohui) Zhang]

Hi,

I have the following questions/comments.

The use case seem to be:

> to have multiple subnets using a single broadcast domain - only one broadcast 
> domain and one IRB for "N" subnets compare to the "N" broadcast domain and 
> "N" IRB interface to manage.
> to have multiple subnets from same ES on multihoming All-Active mode

What exactly is a broadcast domain? From the following RFC7432 text:

> VLAN-Based Service Interface: With this service interface, an EVPN instance 
> consists of only a single broadcast domain (e.g., a single VLAN).
> VLAN Bundle Service Interface: With this service interface, an EVPN instance 
> corresponds to multiple broadcast domains (e.g., multiple VLANs)
> VLAN-Aware Bundle Service Interface: With this service interface, an EVPN 
> instance consists of multiple broadcast domains (e.g., multiple VLANs) with 
> each VLAN having its own bridge table

It seems that a broadcast domain is equivalent to a vlan. If that is the case, 
I have two confusions:

- How are multiple subnets in a single broadcast domain (i.e. a single vlan) 
differentiated? Why does the draft say the following where multiple VLANs are 
used?

> For example, lets take the case from Figure 1 where PE1 learns MAC of H1 on 
> VLAN 1 (subnet S1).
> In Figure 1, BD-1 has multiple subnets where each subnet is distinguished by 
> VLAN 1, 2,3 and 4.

- Since a VLAN bundle in RFC7432 has *multiple* broadcast domains, why does the 
draft say the following?

> From the definition, it seems like VLAN Bundle Service Interface does provide 
> flexibility to support multiple subnets within *a single* broadcast domain.

Or is it that the requirement is not about "a single broadcast domain", but "a 
single IRB"? If so, we should remove all text about broadcast domain.

https://datatracker.ietf.org/doc/html/draft-ietf-bess-evpn-vpws-fxc-08 says:

   [RFC8214] describes a solution to deliver P2P services using BGP
   constructs defined in [RFC7432].  It delivers this P2P service
   between a pair of Attachment Circuits (ACs), where an AC can
   designate on a PE, a port, a VLAN on a port, or a group of VLANs on a
   port.

It seems that:

- Each pair of AC in vpws-fxc is given a normalized VID as the AC ID.
- In this draft, each VLAN across the MHES is given an ACID and signaled in the 
attachment circuit ID Extended Community (ACID EC)

I am confused as to why this draft applies only to MHES. Let's say there is no 
MH and the CE is only homed to PE1, but both PE1 and PE2 host subnet S1. When 
PE2 gets a packet destined to H1 and it is to be routed down PE2's IRB (and 
then switched to PE1 - asymmetric mode), what VLAN ID should PE2 use? I suppose 
what is needed is a mapping between vlan and subnet - something to be 
configured locally. But once that is done, the MHES problem is also solved, 
right? And the vlan/subnet mapping is comparable to the ACID configuration.

In the case of syncing IGMP/MLD state across MHES PEs, we just need to attach 
the VLAN info to the routes.

Finally, even if we want to go with the solution in the draft, I don't think we 
should call this the 4th service interface. It is just about how to do single 
IRB on the vlan bundle service interface. Adding the 4th service interface just 
adds confusion.

Thanks.

Jeffrey

Juniper Business Use Only

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

Re: [bess] [RTG-DIR] Rtgdir early review of draft-ietf-bess-bgp-multicast-05

[Jeffrey (Zhaohui) Zhang]

Hi Ben,

Sorry for not replying sooner. I thought I had addressed your comments, but I 
just submitted the -07 revision that did it.

Thanks a lot for your review and comments!
Jeffrey


Juniper Business Use Only
-Original Message-
From: rtg-dir  On Behalf Of Ben Niven-Jenkins via 
Datatracker
Sent: Friday, November 10, 2023 4:22 PM
To: rtg-...@ietf.org
Cc: bess@ietf.org; draft-ietf-bess-bgp-multicast@ietf.org
Subject: [RTG-DIR] Rtgdir early review of draft-ietf-bess-bgp-multicast-05

[External Email. Be cautious of content]


Reviewer: Ben Niven-Jenkins
Review result: Has Nits

Hello

I have been selected to do a routing directorate “early” review of this draft.
https://urldefense.com/v3/__https://datatracker.ietf.org/doc/draft-ietf-bess-bgp-multicast/__;!!NEt6yMaO-gk!Ab2b0dOJX9VHnzuNRC9o0Oz8oysWKP25V5pcXuG5xIczUGhjSKTqaFw9BujKzroDP9pIlwItUkBSE7w$

The routing directorate will, on request from the working group chair, perform 
an “early” review of a draft before it is submitted for publication to the 
IESG. The early review can be performed at any time during the draft’s lifetime 
as a working group document. The purpose of the early review depends on the 
stage that the document has reached.

For more information about the Routing Directorate, please see 
https://urldefense.com/v3/__https://wiki.ietf.org/en/group/rtg/RtgDir__;!!NEt6yMaO-gk!Ab2b0dOJX9VHnzuNRC9o0Oz8oysWKP25V5pcXuG5xIczUGhjSKTqaFw9BujKzroDP9pIlwItHZSqjyQ$

Document: draft-ietf-bess-bgp-multicast-05.txt
Reviewer: Ben Niven-Jenkins
Review Date: 10 November 2023
Intended Status: Standards Track

Summary: This document is basically ready for publication, but has nits that 
should be considered prior to being submitted to the IESG.

Comments: The document is well written and easy to read and understand.

Nits:

Section 1.2.4 - “For unlabeled (x,g) unidirectional trees, the upstream peer 
MAY prefer LAN interfaces to send traffic, since multiple downstream peers may 
be reached simultaneously, or it may make a decision based on local policy, 
e.g., for load balancing purpose.”

I do not understand why the first MAY is capitalised. Is this a mistake and it 
should be in lowercase like the other instances of may in that sentence?

Section 1.2.5 - “PIM and BGP MUST not be used simultaneously between two 
neighbors for multicast purpose, and routers connected to the same LAN MUST be 
transitioned during the same maintenance window.”

I think the “MUST not” should be “MUST NOT”?

Thanks
Ben



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

Re: [bess] Genart early review of draft-ietf-bess-bgp-multicast-05

[Jeffrey (Zhaohui) Zhang]

Hi Joel,

We had offline exchanges and I just posted the -06 revision that addressed all 
your comments: 
https://datatracker.ietf.org/doc/draft-ietf-bess-bgp-multicast/06/.

Thanks again for your thorough review and lots of comments - a great help in 
improving the document quality.

Jeffrey


Juniper Business Use Only
-Original Message-
From: Jeffrey (Zhaohui) Zhang
Sent: Monday, October 23, 2023 4:23 PM
To: Joel Halpern ; gen-...@ietf.org
Cc: bess@ietf.org; draft-ietf-bess-bgp-multicast@ietf.org
Subject: RE: Genart early review of draft-ietf-bess-bgp-multicast-05

Hi Joel,

Thanks for your review and comments.
I will address them and come back.

Jeffrey

-Original Message-
From: Joel Halpern via Datatracker 
Sent: Monday, October 23, 2023 3:00 PM
To: gen-...@ietf.org
Cc: bess@ietf.org; draft-ietf-bess-bgp-multicast@ietf.org
Subject: Genart early review of draft-ietf-bess-bgp-multicast-05

[External Email. Be cautious of content]


Reviewer: Joel Halpern
Review result: Not Ready

This is a requested genart early review of

draft-ietf-bess-bgp-multicast-05

Prepared on 23-Oct-2023

Summary: This draft is not ready, having a number of issues that need to be 
addressed.

I presume this draft will be socialized with the PIM and IDR working groups 
before completion (or maybe it already has been?)

Major:
While I appreciate the effort to give an overview of the operation before
providing the specification, the actual text is almost impossible to
follow.   At a guess, the authors have a coherent view of what happens, and
have then written down each "interesting" piece.   This does not give the
reader clarity. As a first step, before giving the overview, all the
terminology needs to be defined.  Including such things as the fact that
MCAST-TREE NLRI is a general holder, within which there are a number of
different NLRI (which is finally explained in section 2, after the reader
is thoroughly confused.)  All terms and abbreviations should be defined or,
when they are from other documents, expanded with a citation so the reader
knows where to look for the term.  (I did figure out what FHR and LHR were,
but the draft did not help me do so.) Secondly, the extensive use of
construction of the form ~this use of construct A is just like the use in
document B except...~ is very confusing.  The reader is left without a
coherent description of how this protocol works, exactly which pieces from
the other document must be followed, and exactly how the changes are to be
applied. Third, if the intention of the introductory material is to provide
a perspective on, but not duplicative specification of, the material in
section 2.2, then each overview should have forward references explaining
where the detailed procedures can be found.  If material in the overview is
intended to be the normative specification of the operation (as for example
when and which rotue communities are to be used, and apparently all of
section 1.2.1.1) then normative language is needed.  It is quite hard to
exgtract from these sections the required procedures.

I also note that ID-Nits ha a lot of complaints.  I will not repeat them,
but they need to be dealt with. (For example, the addresses used in various
examples are not example addresses.  They should be.)

Scaling needs to be better addressed.  While I understand the use of RT
constraints helps the avoidance of overloading the leaves of the tree, it
appears that any network using route reflectors is likely to have state
about every sender of every multicast group in every rotue reflector.  It
may be that this is acceptable.  But it should be called out explicitly.

Section 2.2.1 sates that source advertisement will be triggered only by sources 
sending multicast traffic.  And will expire based on time.  Except that the 
network has no idea what the suitable time interval is for a given multicast 
group.  Some groups will have long inter-packet intervals, while some will be 
short and some will be quite variable.  Also, some groups will have the 
property that the senders will know who they are before sending, and receivers 
may even want to join before the senders are active.  If the working group 
wishes to exclude such use cases, then the document should be explicit about 
what use cases it is covering.

Moderate:
Additional explanation is needed in section 1.2.1.2.  This section describes 
how to set up a shared tree for an ANY-Source Multicast Group.  Unlike the 
earlier discussion of advertising sources with a route target community to 
restrict distribution, this section explicitly says that the sources sending to 
the ASM Group are advertised in BGP without the restricting community.  I 
presume there is some other assumed aspect that restrits the information so it 
is only received by the Rendezvous points for the shared tree. 

Re: [bess] WG Adoption and IPR poll for draft-sajassi-bess-evpn-ip-aliasing-09

[Jeffrey (Zhaohui) Zhang]

Hi,

We have got sufficient support from WG members of a variety of organizations. 
The draft is now accepted as a WG document.

Authors - please submit a WG -00 revision.

The adoption call was expected to close on Monday, 11/27 (we already had 
sufficient support by then). The delay was to collect all the required IPR 
declarations - thanks to Mankamana's effort on that.

Jeffrey


Juniper Business Use Only
-Original Message-
From: Jeffrey (Zhaohui) Zhang
Sent: Monday, November 13, 2023 6:51 AM
To: 'BESS' 
Cc: 'bess-cha...@ietf.org' ; 
draft-sajassi-bess-evpn-ip-alias...@ietf.org
Subject: WG Adoption and IPR poll for draft-sajassi-bess-evpn-ip-aliasing-09

Hi,

This email begins a two-week WG adoption and IPR poll for 
draft-sajassi-bess-evpn-ip-aliasing-09 
(https://datatracker.ietf.org/doc/html/draft-sajassi-bess-evpn-ip-aliasing-09).

Please review the draft and post any comments to the BESS working group list.

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 will not progress 
without answers from all the authors and contributors.

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

This poll for adoption closes on Monday, 27th of November, 2023.

Thanks.
Jeffrey

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

[bess] WG Adoption and IPR poll for draft-sajassi-bess-evpn-ip-aliasing-09

[Jeffrey (Zhaohui) Zhang]

Hi,

This email begins a two-week WG adoption and IPR poll for 
draft-sajassi-bess-evpn-ip-aliasing-09 
(https://datatracker.ietf.org/doc/html/draft-sajassi-bess-evpn-ip-aliasing-09).

Please review the draft and post any comments to the BESS working group list.

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 will not progress 
without answers from all the authors and contributors.

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

This poll for adoption closes on Monday, 27th of November, 2023.

Thanks.
Jeffrey

Juniper Business Use Only

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

Re: [bess] Comments about https://datatracker.ietf.org/doc/html/draft-duan-bess-simplified-mvpn-for-bier-and-ir-00

[Jeffrey (Zhaohui) Zhang]

Actually, we don't need the extended community even in the case of tunnel 
segmentation, because the C-multicast route used for explicit tracking purposes 
should not be sent to the UMH but to the local upstream segmentation point (and 
the next hop of the route would not change so it can be used to identify the 
leaf PE).

Additionally, if the UMH route is used to advertise the PTA info, then the 
segmentation points need to update that info, which is not desired since 
they're just unicast routes not MVPN routes. The existing x-PMSI route 
procedures work very well with tunnel segmentation.


Juniper Business Use Only
-Original Message-
From: Jeffrey (Zhaohui) Zhang
Sent: Friday, November 10, 2023 2:30 PM
To: Chensiyu (Susie) ; 'BESS' 

Subject: Comments about 
https://datatracker.ietf.org/doc/html/draft-duan-bess-simplified-mvpn-for-bier-and-ir-00

Hi Siyu,

To follow up my comments in the BESS session, it is indeed good to optimize 
provider tunnel procedures based on PMSI/Leaf AD route in the case of IR/BIER, 
but there are alternatives.

Essentially, draft-duan replaces the PMSI/Leaf AD routes with the following:

- Announce the PTA info in the UMH routes instead of PMSI routes
- Use a new route type, which is a variant of C-Multicast route instead Leaf 
route, for leaf tracking purposes

For leaf tracking purposes, an alternative is also proposed in 
https://datatracker.ietf.org/doc/html/draft-zzhang-bess-mvpn-evpn-cmcast-enhancements-01#section-1.2.1.

   Notice that the (C-*,C-G-BIDIR) C-Multicast routes from different PEs
   all have their own RDs so Route Reflectors (RRs) will reflect every
   one of them, and they already serve explicit tracking purpose (the
   BGP Next Hop identifies the originator of the route in non-
   segmentation case) - there is no need to use Leaf A-D routes
   triggered by the LIR bit in S-PMSI A-D routes.  In case of RSVP-TE
   P2MP tunnel, the S-PMSI A-D routes are still needed to announce the
   tunnel but the LIR bit does not need to be set.  In case of IR/BIER,
   there is no need for S-PMSI A-D routes at all.

Although that is in the context of the MVPN-RPL Method of C-BIDIR support, the 
same idea can be used in general: instead of using the UMH's RD, each leaf PE 
just uses its own RD. While in RFC6514 the UMH's RD is used, that is for 
exactly the opposite purpose - the RRs only need to re-advertise a single 
C-Multicast route to the UMH while here we want each C-Multicast route to reach 
the UMH for leaf tracking purposes.

This method does not need a new route type - just use the leaf PE's own RD and 
attach an extended community to identify the leaf PE (the extended community is 
only needed in case of tunnel segmentation).

To announce the PTA, we don't need to attach the PTA (info) to the UMH routes 
(which could be a lot). A single I-PMSI or (*,*) S-PMSI can be used, or 
additional S-PMSI routes can also be used when more granularity is needed 
(e.g., some flows use some sub-domains while some other flows use some other 
subdomains).

Thanks.
Jeffrey

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

[bess] Comments about https://datatracker.ietf.org/doc/html/draft-duan-bess-simplified-mvpn-for-bier-and-ir-00

[Jeffrey (Zhaohui) Zhang]

Hi Siyu,

To follow up my comments in the BESS session, it is indeed good to optimize 
provider tunnel procedures based on PMSI/Leaf AD route in the case of IR/BIER, 
but there are alternatives.

Essentially, draft-duan replaces the PMSI/Leaf AD routes with the following:

- Announce the PTA info in the UMH routes instead of PMSI routes
- Use a new route type, which is a variant of C-Multicast route instead Leaf 
route, for leaf tracking purposes

For leaf tracking purposes, an alternative is also proposed in 
https://datatracker.ietf.org/doc/html/draft-zzhang-bess-mvpn-evpn-cmcast-enhancements-01#section-1.2.1.

   Notice that the (C-*,C-G-BIDIR) C-Multicast routes from different PEs
   all have their own RDs so Route Reflectors (RRs) will reflect every
   one of them, and they already serve explicit tracking purpose (the
   BGP Next Hop identifies the originator of the route in non-
   segmentation case) - there is no need to use Leaf A-D routes
   triggered by the LIR bit in S-PMSI A-D routes.  In case of RSVP-TE
   P2MP tunnel, the S-PMSI A-D routes are still needed to announce the
   tunnel but the LIR bit does not need to be set.  In case of IR/BIER,
   there is no need for S-PMSI A-D routes at all.

Although that is in the context of the MVPN-RPL Method of C-BIDIR support, the 
same idea can be used in general: instead of using the UMH's RD, each leaf PE 
just uses its own RD. While in RFC6514 the UMH's RD is used, that is for 
exactly the opposite purpose - the RRs only need to re-advertise a single 
C-Multicast route to the UMH while here we want each C-Multicast route to reach 
the UMH for leaf tracking purposes.

This method does not need a new route type - just use the leaf PE's own RD and 
attach an extended community to identify the leaf PE (the extended community is 
only needed in case of tunnel segmentation).

To announce the PTA, we don't need to attach the PTA (info) to the UMH routes 
(which could be a lot). A single I-PMSI or (*,*) S-PMSI can be used, or 
additional S-PMSI routes can also be used when more granularity is needed 
(e.g., some flows use some sub-domains while some other flows use some other 
subdomains).

Thanks.
Jeffrey

Juniper Business Use Only

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

Re: [bess] Genart early review of draft-ietf-bess-bgp-multicast-controller-11

[Jeffrey (Zhaohui) Zhang]

Hi Meral,

Thanks for your review and comments.
I have fixed the issues in my source .xml. I will soon post the revision along 
with other potential changes.

Jeffrey


Juniper Business Use Only
-Original Message-
From: Meral Shirazipour via Datatracker 
Sent: Tuesday, November 7, 2023 2:32 AM
To: gen-...@ietf.org
Cc: bess@ietf.org; draft-ietf-bess-bgp-multicast-controller@ietf.org
Subject: Genart early review of draft-ietf-bess-bgp-multicast-controller-11

[External Email. Be cautious of content]


Reviewer: Meral Shirazipour
Review result: Ready with Nits

I am the assigned Gen-ART reviewer for this draft. The General Area Review Team
(Gen-ART) reviews all IETF documents being processed by the IESG for the IETF 
Chair.  Please treat these comments just like any other last call comments.

For more information, please see the FAQ at

.

Document: draft-ietf-bess-bgp-multicast-controller-11

Reviewer: Meral Shirazipour
Review Date: 2023-11-06
IETF LC End Date: 2023-11-10
IESG Telechat date: NA

Summary: This draft is almost ready to be published as Standard RFC, no other 
comments than those on the list.

Major issues:

Minor issues:

Nits/editorial comments:

-[Page 21], Section 4.2, "recevied on"-->"received on" (twice)

-[Page 21], Section 4.3, "an Extented"-->"an Extended"



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

Re: [bess] Questions on draft-sajassi-bess-evpn-ip-aliasing-07

[Jeffrey (Zhaohui) Zhang]

Hi Jorge,

Thanks for the revision. I will start the adoption process.

A couple of further questions below. I snipped text for clarity.

---
4.1.2.  IP A-D per ES route and SRv6 Transport

   When an SRv6 transport is used, each IP A-D per ES route MUST carry
   an SRv6 L3 Service TLV within the BGP Prefix-SID attribute [RFC9252].
   The Service SID MUST be of value 0.  The SRv6 Endpoint Behavior
   SHOULD be one of these End.DT46, End.DT4, End.DT6, End.DX4, or
   End.DX6.

What is the purpose of the above?
[Jorge] A-D per ES routes carry a BGP encapsulation extended community in case 
of VXLAN, MPLS, etc, and an SRv6 Service TLV in case of SRv6, as also described 
in draft-trr-bess-bgp-srv6-args.

Zhz> It's good to clarify that (like what you did for 4.1.3).

---

4.3.  Handling Silent Host MAC/IP route for IP Aliasing
   ...
   Thus to avoid blackholing, when PE2 detects loss of reachability to
   PE1, it should trigger ARP/ND requests for all remote IP prefixes
   received from PE1 across all affected IP-VRFs.  This will force host
   H1 to reply to the solicited ARP/ND messages from PE2 and refresh
   both MAC and IP for the corresponding host in its tables.

This section talks about the silent host MAC/IP route. I suppose there is no 
similar mechanism for Section 4.2 if a single routing session from the CE to 
one of the PEs?
[Jorge] 4.2 talks about the synchronization of the ip routes on the PEs 
attached to the same ES, and 4.3 about the synch of the ARP/ND entries on the 
PEs. Unless a use case is explicitly mentioned, the sections from 2. on are 
relevant to all use cases - 1.1, 1.2 and 1.3. I added a sentence at the end of 
section 2.

Zzh> What I meant was, if the routes that PE1 learns are from a single routing 
session (like BGP) vs. ARP/ND, then PE2 can't learn them proactively even after 
it detects PE1's failure. Is that correct?
Zzh> Is "refresh both MAC and IP for the corresponding host in its tables" for 
PE2? The way the text reads, it's H1.

Zzh> Additionally, I noticed the following right after the above quoted text:

   Even in core failure scenario on PE1, PE1 must withdraw all its local
   layer-2 connectivity, as Layer-2 traffic should not be received by
   PE1.

Zzh> I struggled with "withdraw all its local layer-2 connectivity". I finally 
think you probably mean "bring down all its local layer-2 connectivity". Is 
that right?

--
For the following normalization rule:

  ... If the
  ingress PE learns a prefix P via a non-reserved ESI RT-5 route
  with a weight (for which IP A-D per ES routes also signal a
  weight) and a zero ESI RT-5 that includes a weight, the ingress PE
  will consider all the PEs attached to the ES as a single PE when
  normalizing weights.

  As an example, consider PE1 and PE2 are attached to ES-1 and PE1
  advertises an RT-5 for prefix P with ESI-1 (and EVPN Link
  Bandwidth of 1).  Consider PE3 advertises an RT-5 for P with ESI=0
  and EVPN Link Bandwidth of 2.  If PE1 and PE2 advertise an EVPN
  Link Bandwidth of 1 and 2, respectively, in the IP A-D per ES
  routes for ES-1, an ingress PE4 SHOULD assign a normalized weight
  of 1 to ES-1 and a normalized weight of 2 to PE3.

What is the rationale for normalizing the weight of ES-1 to 1?
[Jorge] the ES represents a single CE, and the weight of the RT-5 with ESI=1 
influences the number of flows for that CE. So if the remote PE gets two RT-5s: 
RT-5 (weight=1) and RT-5 (weight=2) it should apply the weights based on those 
RT-5s.

Zzh> I still don't get the rational. PE1/PE2/PE3 advertise link bandwidth 1/2/2 
respectively, yet we normalize ES-1 to weight 1?
Zzh> Thanks.
Zzh> Jeffrey

Thanks.
Jeffrey



Juniper Business Use Only
___
BESS mailing list
BESS@ietf.org
https://www.ietf.org/mailman/listinfo/bess

Re: [bess] Shepherd review of draft-ietf-bess-evpn-mh-split-horizon-05

[Jeffrey (Zhaohui) Zhang]

Hi Jorge,

Thanks for the revision.
Please see zzh> below for two comments.



Juniper Business Use Only
From: Jorge Rabadan (Nokia) 
Sent: Monday, October 23, 2023 10:33 AM
To: Jeffrey (Zhaohui) Zhang ; Kiran Nagaraj (Nokia) 
; Wen Lin ; 'Ali Sajassi (sajassi)' 

Cc: 'BESS' 
Subject: Re: Shepherd review of draft-ietf-bess-evpn-mh-split-horizon-05

[External Email. Be cautious of content]

Hi Jeffrey,

Thanks very much for the review. Version 6 is published addressing your 
comments.

Please see in-line.

Thanks!
Jorge



Juniper Business Use Only
From: Jeffrey (Zhaohui) Zhang mailto:zzh...@juniper.net>>
Date: Wednesday, September 27, 2023 at 5:34 PM
To: Jorge Rabadan (Nokia) 
mailto:jorge.raba...@nokia.com>>, Kiran Nagaraj 
(Nokia) mailto:kiran.naga...@nokia.com>>, Wen Lin 
mailto:w...@juniper.net>>, 'Ali Sajassi (sajassi)' 
mailto:saja...@cisco.com>>
Cc: 'BESS' mailto:bess@ietf.org>>
Subject: Shepherd review of draft-ietf-bess-evpn-mh-split-horizon-05

CAUTION: This is an external email. Please be very careful when clicking links 
or opening attachments. See the URL nok.it/ext for additional information.



Hi,

I have the following comments/suggestions/questions:

Idnits reported:

  -- The draft header indicates that this document updates RFC8365, but the
 abstract doesn't seem to mention this, which it should.
[Jorge] good point. Added.


Would this update 7432 as well?
[Jorge] since 7432bis obsoletes 7432 and refers to this document, it is 
probably ok not to say it updates 7432... but I don't have a strong opinion. It 
may depend on how fast 7432bis progresses as well?

Zzh> 7432bis WGLC has not happened yet, so I believe this one will go before 
7432bis and should update 7432.


  == Outdated reference: A later version (-06) exists of
 draft-ietf-bess-evpn-geneve-05

I normally don't reference a specific revision of a document, unless the 
revision number matters. If you remove the revision in the reference, you'll 
not need to worry about updating it again.
[Jorge] sure, done.


Given that this is ahead of rfc7432bis, the "EVPN ESI Multihoming Attributes" 
registry creation for the 1-octet Flags field in the ESI Label Extended 
Community should be moved to this draft.
[Jorge] As long as this document it is really ahead of 7432bis, sure. We added 
it to the IANA section, and we can always remove it if 7432bis goes out before 
this one.

Zzh> I should have noticed it earlier, but now I think the name "EVPN ESI 
Multihoming Attributes" is a bit confusing. I think it's better called "EVPN 
ESI Label Extended Community Flags" registry. In addition, all existing bits 
should also be documented in the registry-creation request.
Zzh> Thanks!
Zzh> Jeffrey


"MPLS-based IP Tunnel" does not seem to be accurate to me. It should be 
"IP-based MPLS Tunnel". Related to that, the three tunnel types can be renamed 
to:

- IP-based MPLS Tunnel
- (SR-)MPLS Tunnel
- IP Tunnel

I don't think we need "group" in terms like "group MPLS-based IP" - it can 
simply be "IP-based MPLS".
[Jorge] ok, changed


There a few references like the following:

   [RFC9012] BGP Encapsulation extended community

I believe the reference should be put after the relevant text:

   BGP Encapsulation extended community [RFC9012]
[Jorge] ok, fixed.



Thanks.
Jeffrey

Juniper Business Use Only
___
BESS mailing list
BESS@ietf.org
https://www.ietf.org/mailman/listinfo/bess

Re: [bess] Genart early review of draft-ietf-bess-bgp-multicast-05

[Jeffrey (Zhaohui) Zhang]

Hi Joel,

Thanks for your review and comments.
I will address them and come back.

Jeffrey


Juniper Business Use Only
-Original Message-
From: Joel Halpern via Datatracker 
Sent: Monday, October 23, 2023 3:00 PM
To: gen-...@ietf.org
Cc: bess@ietf.org; draft-ietf-bess-bgp-multicast@ietf.org
Subject: Genart early review of draft-ietf-bess-bgp-multicast-05

[External Email. Be cautious of content]


Reviewer: Joel Halpern
Review result: Not Ready

This is a requested genart early review of

draft-ietf-bess-bgp-multicast-05

Prepared on 23-Oct-2023

Summary: This draft is not ready, having a number of issues that need to be 
addressed.

I presume this draft will be socialized with the PIM and IDR working groups 
before completion (or maybe it already has been?)

Major:
While I appreciate the effort to give an overview of the operation before
providing the specification, the actual text is almost impossible to
follow.   At a guess, the authors have a coherent view of what happens, and
have then written down each "interesting" piece.   This does not give the
reader clarity. As a first step, before giving the overview, all the
terminology needs to be defined.  Including such things as the fact that
MCAST-TREE NLRI is a general holder, within which there are a number of
different NLRI (which is finally explained in section 2, after the reader
is thoroughly confused.)  All terms and abbreviations should be defined or,
when they are from other documents, expanded with a citation so the reader
knows where to look for the term.  (I did figure out what FHR and LHR were,
but the draft did not help me do so.) Secondly, the extensive use of
construction of the form ~this use of construct A is just like the use in
document B except...~ is very confusing.  The reader is left without a
coherent description of how this protocol works, exactly which pieces from
the other document must be followed, and exactly how the changes are to be
applied. Third, if the intention of the introductory material is to provide
a perspective on, but not duplicative specification of, the material in
section 2.2, then each overview should have forward references explaining
where the detailed procedures can be found.  If material in the overview is
intended to be the normative specification of the operation (as for example
when and which rotue communities are to be used, and apparently all of
section 1.2.1.1) then normative language is needed.  It is quite hard to
exgtract from these sections the required procedures.

I also note that ID-Nits ha a lot of complaints.  I will not repeat them,
but they need to be dealt with. (For example, the addresses used in various
examples are not example addresses.  They should be.)

Scaling needs to be better addressed.  While I understand the use of RT
constraints helps the avoidance of overloading the leaves of the tree, it
appears that any network using route reflectors is likely to have state
about every sender of every multicast group in every rotue reflector.  It
may be that this is acceptable.  But it should be called out explicitly.

Section 2.2.1 sates that source advertisement will be triggered only by sources 
sending multicast traffic.  And will expire based on time.  Except that the 
network has no idea what the suitable time interval is for a given multicast 
group.  Some groups will have long inter-packet intervals, while some will be 
short and some will be quite variable.  Also, some groups will have the 
property that the senders will know who they are before sending, and receivers 
may even want to join before the senders are active.  If the working group 
wishes to exclude such use cases, then the document should be explicit about 
what use cases it is covering.

Moderate:
Additional explanation is needed in section 1.2.1.2.  This section describes 
how to set up a shared tree for an ANY-Source Multicast Group.  Unlike the 
earlier discussion of advertising sources with a route target community to 
restrict distribution, this section explicitly says that the sources sending to 
the ASM Group are advertised in BGP without the restricting community.  I 
presume there is some other assumed aspect that restrits the information so it 
is only received by the Rendezvous points for the shared tree.  But I can not 
see how this is achieved.  Please add explanation of why this approach does not 
flood the whole domain with information it does not want or need.

The last paragraph (short) of section 1.2.1.2 gives a vague description of 
certain cases.  Presuming it is described in more detail later, a forward 
reference would be extremely helpful.

Section 1.2.1.3 has very confusing use of ingress and egress PE.  I would have 
assumed ingress and egress were in terms of the direction of traffic flow (from 
traffic sources to interested receivers).  But the usage 

Re: [bess] Éric Vyncke's No Objection on draft-ietf-bess-mvpn-evpn-aggregation-label-13: (with COMMENT)

[Jeffrey (Zhaohui) Zhang]

Hi Eric,

Thanks for your additional comments.
Please see zzh> below.


Juniper Business Use Only
-Original Message-
From: Éric Vyncke via Datatracker 
Sent: Wednesday, October 4, 2023 4:54 AM
To: The IESG 
Cc: draft-ietf-bess-mvpn-evpn-aggregation-la...@ietf.org; bess-cha...@ietf.org; 
bess@ietf.org; slitkows.i...@gmail.com; slitkows.i...@gmail.com
Subject: Éric Vyncke's No Objection on 
draft-ietf-bess-mvpn-evpn-aggregation-label-13: (with COMMENT)

[External Email. Be cautious of content]


Éric Vyncke has entered the following ballot position for
draft-ietf-bess-mvpn-evpn-aggregation-label-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://urldefense.com/v3/__https://www.ietf.org/about/groups/iesg/statements/handling-ballot-positions/__;!!NEt6yMaO-gk!FEgMbJglM32kNpUq8oHsJACNotxG8OsVTbawC8CSmY6LxXGvbXL5dg2IGipM1_A9Gt7HJwasAU7uYvU$
for more information about how to handle DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://urldefense.com/v3/__https://datatracker.ietf.org/doc/draft-ietf-bess-mvpn-evpn-aggregation-label/__;!!NEt6yMaO-gk!FEgMbJglM32kNpUq8oHsJACNotxG8OsVTbawC8CSmY6LxXGvbXL5dg2IGipM1_A9Gt7HJwasNmJJFr4$



--
COMMENT:
--

Thanks to Zhaohui Zhang and Stéphane Litkowski for addressing my previous 
DISCUSS points (even if they were 'discuss discuss', i.e., just to have a 
discussion). I have now cleared my previous DISCUSS ballot.

# COMMENTS

## Abstract

Should the abstract qualify the VPN with layer-3 (for MVPN) and layer-2 (for
EVPN) ?

Zzh> In this document, VPN refers to IP VPN. L2 VPN is specifically EVPN.
Zzh> I can change VPN to IP VPN in the abstract, and then in the first section 
clarify that VPN specifically refers to IP VPN.
Zzh> Is that ok?

## Section 1

Should "SR" also be expanded ? Should RFC 8660 be a reference ?

Zzh> Changed and added.

## Section 2

`to transmit multicast traffic or BUM traffic` is somehow redundant as BUM 
includes multicast.

Zzh> Changed to "to transmit VPN multicast  traffic or EVPN BUM traffic".

## Section 2.1

`At the present time` what about "In 2023, " ?

Zzh> Changed to "So far, ".

## Section 3.1

Please expand "EC" at first use (even if it can be guessed on the previous 
sentence).

Zzh> Fixed.

Why this section use `to be defined by IANA`, while section 5 lists the 
IANA-assigned values ?

Zzh> Fixed.

## Section 3.2

This I-D uses 'outside the scope of this document' twice. I am curious: is 
there any work in BESS WG for this ?

Zzh> No at this time 
Zzh> Coordinated label assignment is like IP address assignment.
Zzh> Ensuring all PEs supporting the procedures is like an operator making sure 
that all its PEs are running a certain software release.

# NITS

zzh> All fixed. To be posted.
Zzh> Thanks!
Zzh> Jeffrey

## Section 1

s/Terminologies/Terminology/

s/Broadcast, Unknown *U*nicast, or Multicast (traffic)/Broadcast, Unknown 
*u*nicast, or Multicast (packet)/

s/sub set/subset/



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

Re: [bess] John Scudder's Discuss on draft-ietf-bess-mvpn-evpn-aggregation-label-12: (with DISCUSS and COMMENT)

[Jeffrey (Zhaohui) Zhang]

Hi John,

All are good suggestions. I will update the draft accordingly.

Thanks!
Jeffrey


Juniper Business Use Only
-Original Message-
From: John Scudder 
Sent: Wednesday, October 4, 2023 9:18 AM
To: Jeffrey (Zhaohui) Zhang 
Cc: The IESG ; 
draft-ietf-bess-mvpn-evpn-aggregation-la...@ietf.org; bess-cha...@ietf.org; 
bess@ietf.org; slitkows.i...@gmail.com; idr-cha...@ietf.org
Subject: Re: John Scudder's Discuss on 
draft-ietf-bess-mvpn-evpn-aggregation-label-12: (with DISCUSS and COMMENT)

Hi Jeffrey,

Thanks for the quick turnaround. The update looks good, I’ll clear my discuss. 
I have a couple new comments/questions regarding the “Context-Specific Label 
Space ID Type” registry.

- Is there any existing group of registries you could suggest IANA organize the 
new registry under? At first glance, it appears as though it might fit in the 
“Border Gateway Protocol (BGP) Extended Communities” group, there are a bunch 
of other (sub)type registries there. If you agree that’s the place for it, add 
that suggestion in the IANA section.

- Probably add another line to the table, indicating values 1-255 are 
unassigned. Unless you want to reserve value 255, sometimes people like to do 
that, for various reasons. It doesn’t really seem necessary in this case, but 
on the other hand, it may come under the heading of “can’t hurt, might help“. 
In that case, it would be two new lines: “1-254, unassigned; 255, reserved”.

Thanks,

—John

> On Oct 3, 2023, at 9:13 PM, Jeffrey (Zhaohui) Zhang  
> wrote:
>
> Hi John,
>
> Thanks for your review and for catching those issues.
> I posted -13 revision that addresses them (and some comments from others).
> https://author-tools.ietf.org/iddiff?url1=draft-ietf-bess-mvpn-evpn-aggregation-label-12=draft-ietf-bess-mvpn-evpn-aggregation-label-13=--html
>
> Please see zzh> below for two clarifications.
>
>
> Juniper Business Use Only
> -Original Message-
> From: John Scudder via Datatracker 
> Sent: Tuesday, October 3, 2023 6:06 PM
> To: The IESG 
> Cc: draft-ietf-bess-mvpn-evpn-aggregation-la...@ietf.org; 
> bess-cha...@ietf.org; bess@ietf.org; slitkows.i...@gmail.com; 
> slitkows.i...@gmail.com; idr-cha...@ietf.org
> Subject: John Scudder's Discuss on 
> draft-ietf-bess-mvpn-evpn-aggregation-label-12: (with DISCUSS and COMMENT)
>
> [External Email. Be cautious of content]
>
>
> John Scudder has entered the following ballot position for
> draft-ietf-bess-mvpn-evpn-aggregation-label-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.com/v3/__https://www.ietf.org/about/groups/iesg/statements/handling-ballot-positions/__;!!NEt6yMaO-gk!DCMEQpDxLLxMiP1UHgTMTxAPXUhT-KT3_3rIVmJ9CNiiUKgKhsCBWmSR2xjtPxyphO6-wP9ysPLbofw$
> for more information about how to handle DISCUSS and COMMENT positions.
>
>
> The document, along with other ballot positions, can be found here:
> https://urldefense.com/v3/__https://datatracker.ietf.org/doc/draft-ietf-bess-mvpn-evpn-aggregation-label/__;!!NEt6yMaO-gk!DCMEQpDxLLxMiP1UHgTMTxAPXUhT-KT3_3rIVmJ9CNiiUKgKhsCBWmSR2xjtPxyphO6-wP9y8nKQlYI$
>
>
>
> --
> DISCUSS:
> --
>
> # John Scudder, RTG AD, comments for
> draft-ietf-bess-mvpn-evpn-aggregation-label-12 CC @jgscudder
>
> Thanks for this spec. I have one serious concern (but I think it will be easy 
> to take care of) and a few comments and nits.
>
> (Sorry for the iteration on this ballot, I missed one of my pages of notes in 
> my haste to get this sent off.)
>
> ## DISCUSS
>
> ### Section 3.2, ignoring routes considered harmful
>
> Zzh> You're right. Thanks for the detailed explanation. I changed both to 
> "treat-as-withdraw".
>
> There are two places toward the end of this subsection where you specify that 
> a route must be ignored. The first is:
>
> "A PE MUST ignore a received route with both the DCB-flag and the Context 
> Label Space ID EC attached, treating as if it was not received."
>
> The second is:
>
> "If a PE originates two x-PMSI/IMET routes with the same tunnel, it MUST 
> ensure one of the following" ... "Otherwise, a receiving PE MUST ignore the 
> routes."
>
> Literally ignoring routes is one of the classic Bad Ideas in BGP. There can 
> be exceptions, if the conditions for ignoring the routes are carefully chosen 
> so that correctness (or something like it) is preserved, but as a general 
> matter, ignoring routes is a one-way ticket to persistent traffic loss

Re: [bess] John Scudder's Discuss on draft-ietf-bess-mvpn-evpn-aggregation-label-12: (with DISCUSS and COMMENT)

[Jeffrey (Zhaohui) Zhang]

Hi John,

Thanks for your review and for catching those issues.
I posted -13 revision that addresses them (and some comments from others).
https://author-tools.ietf.org/iddiff?url1=draft-ietf-bess-mvpn-evpn-aggregation-label-12=draft-ietf-bess-mvpn-evpn-aggregation-label-13=--html

Please see zzh> below for two clarifications.


Juniper Business Use Only
-Original Message-
From: John Scudder via Datatracker 
Sent: Tuesday, October 3, 2023 6:06 PM
To: The IESG 
Cc: draft-ietf-bess-mvpn-evpn-aggregation-la...@ietf.org; bess-cha...@ietf.org; 
bess@ietf.org; slitkows.i...@gmail.com; slitkows.i...@gmail.com; 
idr-cha...@ietf.org
Subject: John Scudder's Discuss on 
draft-ietf-bess-mvpn-evpn-aggregation-label-12: (with DISCUSS and COMMENT)

[External Email. Be cautious of content]


John Scudder has entered the following ballot position for
draft-ietf-bess-mvpn-evpn-aggregation-label-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.com/v3/__https://www.ietf.org/about/groups/iesg/statements/handling-ballot-positions/__;!!NEt6yMaO-gk!DCMEQpDxLLxMiP1UHgTMTxAPXUhT-KT3_3rIVmJ9CNiiUKgKhsCBWmSR2xjtPxyphO6-wP9ysPLbofw$
for more information about how to handle DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://urldefense.com/v3/__https://datatracker.ietf.org/doc/draft-ietf-bess-mvpn-evpn-aggregation-label/__;!!NEt6yMaO-gk!DCMEQpDxLLxMiP1UHgTMTxAPXUhT-KT3_3rIVmJ9CNiiUKgKhsCBWmSR2xjtPxyphO6-wP9y8nKQlYI$



--
DISCUSS:
--

# John Scudder, RTG AD, comments for
draft-ietf-bess-mvpn-evpn-aggregation-label-12 CC @jgscudder

Thanks for this spec. I have one serious concern (but I think it will be easy 
to take care of) and a few comments and nits.

(Sorry for the iteration on this ballot, I missed one of my pages of notes in 
my haste to get this sent off.)

## DISCUSS

### Section 3.2, ignoring routes considered harmful

Zzh> You're right. Thanks for the detailed explanation. I changed both to 
"treat-as-withdraw".

There are two places toward the end of this subsection where you specify that a 
route must be ignored. The first is:

"A PE MUST ignore a received route with both the DCB-flag and the Context Label 
Space ID EC attached, treating as if it was not received."

The second is:

"If a PE originates two x-PMSI/IMET routes with the same tunnel, it MUST ensure 
one of the following" ... "Otherwise, a receiving PE MUST ignore the routes."

Literally ignoring routes is one of the classic Bad Ideas in BGP. There can be 
exceptions, if the conditions for ignoring the routes are carefully chosen so 
that correctness (or something like it) is preserved, but as a general matter, 
ignoring routes is a one-way ticket to persistent traffic loss or worse. It's 
for this reason that RFC 7606 specifies treat-as-withdraw for many error 
conditions. I'll illustrate the general problem with an example that uses 
simple IPv4 unicast routes:

- Suppose we receive 10/8, with nexthop 1.1.1.1, choose it as best, and install 
it in the FIB. - Now suppose the router that advertised it to us sends a 
replacement, an advertisement for 10/8, nexthop 2.2.2.2, including path 
attribute P that we decide is malformed. We ignore the route as our error 
handling strategy. - We are left in a state where we still have 10/8 via
1.1.1.1 selected and installed, because we ignored the replacement, "treating 
it as if was not received". This is an incorrect state. I can easily show you 
scenarios where it leads to traffic loss, persistent loops, etc. - The correct 
behavior in this scenario would be to remove the 10/8 route received in the 
first step; RFC 7606 calls this "treat-as-withdraw".

It might be that something special about MVPN/EVPN routes means this isn't an 
issue for the two cases I've quoted, but you haven't made this clear in the 
document. I think at minimum, some analysis is needed to show that the strategy 
is OK. On the other hand if what you meant by "ignore" is something closer to 
the "treat-as-withdraw" strategy, I think the language has to be made more 
specific and leave less to the creativity and imagination of the implementor.

Let's have a discussion about which it is, and see where to go from there.

Edited to add: I sent this as a followup to my original ballot, with cc
idr-chairs: "I suspect my DISCUSS would have been caught if there had been 
review from IDR. Searching for the draft name in the IDR mailing list archive 
doesn’t surface any traffic about it, so I’m guessing this didn’t occur."


--
COMMENT:
--

## 

Re: [bess] Lars Eggert's No Objection on draft-ietf-bess-mvpn-evpn-aggregation-label-12: (with COMMENT)

[Jeffrey (Zhaohui) Zhang]

Hi Lars,

Thanks for your review.

I have fixed the issues below (I will submit a revision when I finish 
addressing some comments from others), but have two clarifications - please see 
zzh> below.


Juniper Business Use Only
-Original Message-
From: Lars Eggert via Datatracker 
Sent: Tuesday, October 3, 2023 2:50 AM
To: The IESG 
Cc: draft-ietf-bess-mvpn-evpn-aggregation-la...@ietf.org; bess-cha...@ietf.org; 
bess@ietf.org; slitkows.i...@gmail.com; slitkows.i...@gmail.com
Subject: Lars Eggert's No Objection on 
draft-ietf-bess-mvpn-evpn-aggregation-label-12: (with COMMENT)

[External Email. Be cautious of content]


Lars Eggert has entered the following ballot position for
draft-ietf-bess-mvpn-evpn-aggregation-label-12: 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://urldefense.com/v3/__https://www.ietf.org/about/groups/iesg/statements/handling-ballot-positions/__;!!NEt6yMaO-gk!EupXuCkh2mnHJtnCzM5Y-b7mTyMdfqM0_c75sREZPUhZ5xrIFAXijD3WOxPvCkra7F1NlAkXlmOokW8$
for more information about how to handle DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://urldefense.com/v3/__https://datatracker.ietf.org/doc/draft-ietf-bess-mvpn-evpn-aggregation-label/__;!!NEt6yMaO-gk!EupXuCkh2mnHJtnCzM5Y-b7mTyMdfqM0_c75sREZPUhZ5xrIFAXijD3WOxPvCkra7F1NlAkX9SFzLZk$



--
COMMENT:
--

# GEN AD review of draft-ietf-bess-mvpn-evpn-aggregation-label-12

CC @larseggert

Thanks to Russ Housley for the General Area Review Team (Gen-ART) review 
(https://urldefense.com/v3/__https://mailarchive.ietf.org/arch/msg/gen-art/3fAtK3w0wRrSeNCGgzBnr86jTRU__;!!NEt6yMaO-gk!EupXuCkh2mnHJtnCzM5Y-b7mTyMdfqM0_c75sREZPUhZ5xrIFAXijD3WOxPvCkra7F1NlAkX96rP7Ns$
 ).

## Nits

All comments below are about very minor potential issues that you may choose to 
address in some way - or ignore - as you see fit. Some were flagged by 
automated tools (via 
https://urldefense.com/v3/__https://github.com/larseggert/ietf-reviewtool__;!!NEt6yMaO-gk!EupXuCkh2mnHJtnCzM5Y-b7mTyMdfqM0_c75sREZPUhZ5xrIFAXijD3WOxPvCkra7F1NlAkX0YAcIcU$
 ), so there will likely be some false positives. There is no need to let me 
know what you did with these suggestions.

### Grammar/style

 Section 1, paragraph 14
```
onal label spaces is to be used to lookup the label, hence those label space
   ^^ ``` The word "lookup" is a noun. The 
verb is spelled with a white space.

 Section 1, paragraph 16
```
referred to as upstream-assigned. Otherwise it is downstream-assigned. An ups
  ^ ``` A comma may be missing after 
the conjunctive/linking adverb "Otherwise".

 Section 2.1, paragraph 5
```
VPN 1, and so forth. Now only 1000 label instead of 1,000,000 labels are nee
   ^ ``` Possible agreement error. The noun 
"label" seems to be countable.

 Section 2.2.1, paragraph 2
```
hen tunnel segmentation is applied to a S-PMSI, certain nodes are "segmentati
  ^
```
Use "an" instead of "a" if the following word starts with a vowel sound, e.g.
"an article", "an hour".

 Section 2.2.2.1, paragraph 1
```
 tunnel T2 and Flow-2 by tunnel T3. Then when the segmentation point receives
 ``` Consider adding a comma here.

 Section 2.2.2.1, paragraph 3
```
 labels for segmented S-PMSI independently from its assigned label block tha
 ^^ ``` The usual collocation for 
"independently" is "of", not "from". Did you mean "independently of"?

Zzh> That "from" goes with the earlier "allocate" not "independently": 
"allocate labels ... from its assigned label block". I changed it to 
"independently allocate labels from ...".

 Section 2.2.2.2, paragraph 1
```
-PMSIs for the same VPN/BD to share the a VPN/BD-identifying label that leads
^ ``` Two determiners in a row. Choose 
either "the" or "a".

 Section 3.2, paragraph 5
```
nel encapsulation of data packets arriving on the tunnel. * They MUST all hav
  ^^^ ``` The usual preposition after 
"arriving" is "at", not "on". Did you mean "arriving at"?

Zzh> I changed it to "via". I feel that "at the tunnel" is a little inaccurate 
(it's really coming out of the tunnel).
Zzh> Thanks!
Zzh> Jeffrey

## Notes

This review is in the ["IETF Comments" Markdown format][ICMF], You can use the 
[`ietf-comments` tool][ICT] to automatically convert this review into 
individual GitHub issues. Review generated by the [`ietf-reviewtool`][IRT].

[ICMF]: 

Re: [bess] Erik Kline's No Objection on draft-ietf-bess-mvpn-evpn-aggregation-label-11: (with COMMENT)

[Jeffrey (Zhaohui) Zhang]

Hi Erik,

Thanks for your thorough review.
I have submitted the -12 revision that addresses your comments and fixes the 
reference error pointed out by Eric Vyncke.

Jeffrey


Juniper Business Use Only
-Original Message-
From: Erik Kline via Datatracker 
Sent: Monday, September 25, 2023 1:51 AM
To: The IESG 
Cc: draft-ietf-bess-mvpn-evpn-aggregation-la...@ietf.org; bess-cha...@ietf.org; 
bess@ietf.org; slitkows.i...@gmail.com; slitkows.i...@gmail.com
Subject: Erik Kline's No Objection on 
draft-ietf-bess-mvpn-evpn-aggregation-label-11: (with COMMENT)

[External Email. Be cautious of content]


Erik Kline has entered the following ballot position for
draft-ietf-bess-mvpn-evpn-aggregation-label-11: 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://urldefense.com/v3/__https://www.ietf.org/about/groups/iesg/statements/handling-ballot-positions/__;!!NEt6yMaO-gk!Alukip4OH8CHrYQG0OVIeDKiGhefA8qHdGgmpgaIoecTJaJw8KvvXcbu--afWgcl7XLHT-R2_WGJR-0$
for more information about how to handle DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://urldefense.com/v3/__https://datatracker.ietf.org/doc/draft-ietf-bess-mvpn-evpn-aggregation-label/__;!!NEt6yMaO-gk!Alukip4OH8CHrYQG0OVIeDKiGhefA8qHdGgmpgaIoecTJaJw8KvvXcbu--afWgcl7XLHT-R2ssRoo3E$



--
COMMENT:
--

# Internet AD comments for draft-ietf-bess-mvpn-evpn-aggregation-label-11
CC @ekline

* comment syntax:
  - 
https://urldefense.com/v3/__https://github.com/mnot/ietf-comments/blob/main/format.md__;!!NEt6yMaO-gk!Alukip4OH8CHrYQG0OVIeDKiGhefA8qHdGgmpgaIoecTJaJw8KvvXcbu--afWgcl7XLHT-R2D4oiH7A$

* "Handling Ballot Positions":
  - 
https://urldefense.com/v3/__https://ietf.org/about/groups/iesg/statements/handling-ballot-positions/__;!!NEt6yMaO-gk!Alukip4OH8CHrYQG0OVIeDKiGhefA8qHdGgmpgaIoecTJaJw8KvvXcbu--afWgcl7XLHT-R27YdZiAg$

## Nits

### S2.1

* The first paragraph does not read like a normal part of the text flow.
  Maybe just some parentheses around it might help.

### S2.2.2.1

* "from those a few" -> "from those few"?

### S3.2

* s/mpls/MPLS/



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

Re: [bess] Éric Vyncke's Discuss on draft-ietf-bess-mvpn-evpn-aggregation-label-11: (with DISCUSS and COMMENT)

[Jeffrey (Zhaohui) Zhang]

Hi Eric,

Thanks for your thorough review.
I have submitted the -12 revision that fixes the reference error (and addresses 
comments from Erik Kline).

Jeffrey


Juniper Business Use Only
-Original Message-
From: Éric Vyncke via Datatracker 
Sent: Friday, September 29, 2023 6:30 AM
To: The IESG 
Cc: draft-ietf-bess-mvpn-evpn-aggregation-la...@ietf.org; bess-cha...@ietf.org; 
bess@ietf.org; slitkows.i...@gmail.com; slitkows.i...@gmail.com
Subject: Éric Vyncke's Discuss on 
draft-ietf-bess-mvpn-evpn-aggregation-label-11: (with DISCUSS and COMMENT)

[External Email. Be cautious of content]


Éric Vyncke has entered the following ballot position for
draft-ietf-bess-mvpn-evpn-aggregation-label-11: 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.com/v3/__https://www.ietf.org/about/groups/iesg/statements/handling-ballot-positions/__;!!NEt6yMaO-gk!DjXuL1noCSa5WhUuS_bagMtl618K7y88Y_-qasDkUDNDfZ35V5l7ZaLNrjHA44aocSkdXbcTESUiVoY$
for more information about how to handle DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://urldefense.com/v3/__https://datatracker.ietf.org/doc/draft-ietf-bess-mvpn-evpn-aggregation-label/__;!!NEt6yMaO-gk!DjXuL1noCSa5WhUuS_bagMtl618K7y88Y_-qasDkUDNDfZ35V5l7ZaLNrjHA44aocSkdXbcT1sqDXoM$



--
DISCUSS:
--

# Éric Vyncke, INT AD, comments for
draft-ietf-bess-mvpn-evpn-aggregation-label-11

Thank you for the work put into this document.

Please find below two blocking DISCUSS points (easy to address), some 
non-blocking COMMENT points (but replies would be appreciated even if only for 
my own education), and some nits.

Special thanks to Stéphane Litkowski for the shepherd's detailed write-up 
including the WG consensus ***but it lacks*** the justification of the intended 
status.

I hope that this review helps to improve the document,

Regards,

-éric

# DISCUSS

As noted in 
https://urldefense.com/v3/__https://www.ietf.org/blog/handling-iesg-ballot-positions/__;!!NEt6yMaO-gk!DjXuL1noCSa5WhUuS_bagMtl618K7y88Y_-qasDkUDNDfZ35V5l7ZaLNrjHA44aocSkdXbcTXkvFe6c$
 , a DISCUSS ballot is a request to have a discussion on the following topics:

## Shepherd write-up

The shepherd write-up includes `Martin Vigoureux is the responsible AD`.

The shepherd write-up includes `There is one IPR`, while data tracker has 2 IPR 
declarations. At least, the auto-generated IETF Last Call correctly listed the 
two IPR declarations.

The above parts are obviously outdated and MUST be updated.

This is not really a DISCUSS criteria, so I will change my ballot after the 
IESG formal telechat or after an update of the shepherd write-up (the earlier).

## Wrong reference to RFC5531

As indicated by idnits, there is a reference to RFC 5531 (it should probably be 
RFC 5331)


--
COMMENT:
--


# COMMENTS

## Abstract

Should the abstract qualify the VPN with layer-3 (for MVPN) and layer-2 (for
EVPN) ?

## Section 1

Should "SR" also be expanded ? Should RFC 8660 be a reference ?

## Section 2

`to transmit multicast traffic or BUM traffic` is somehow redundant as BUM 
includes multicast.

## Section 2.1

`At the present time` what about "In 2023, " ?

## Section 3.1

Please expand "EC" at first use (even if it can be guessed on the previous 
sentence).

Why this section use `to be defined by IANA`, while section 5 lists the 
IANA-assigned values ?

## Section 3.2

This I-D uses 'outside the scope of this document' twice. I am curious: is 
there any work in BESS WG for this ?

# NITS

## Section 1

s/Terminologies/Terminology/

s/Broadcast, Unknown *U*nicast, or Multicast (traffic)/Broadcast, Unknown 
*u*nicast, or Multicast (packet)/

s/sub set/subset/



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

[bess] Shepherd review of draft-ietf-bess-evpn-mh-split-horizon-05

[Jeffrey (Zhaohui) Zhang]

Hi,

I have the following comments/suggestions/questions:

Idnits reported:

  -- The draft header indicates that this document updates RFC8365, but the
 abstract doesn't seem to mention this, which it should.

Would this update 7432 as well?

  == Outdated reference: A later version (-06) exists of
 draft-ietf-bess-evpn-geneve-05

I normally don't reference a specific revision of a document, unless the 
revision number matters. If you remove the revision in the reference, you'll 
not need to worry about updating it again.

Given that this is ahead of rfc7432bis, the "EVPN ESI Multihoming Attributes" 
registry creation for the 1-octet Flags field in the ESI Label Extended 
Community should be moved to this draft.

"MPLS-based IP Tunnel" does not seem to be accurate to me. It should be 
"IP-based MPLS Tunnel". Related to that, the three tunnel types can be renamed 
to:

- IP-based MPLS Tunnel
- (SR-)MPLS Tunnel
- IP Tunnel

I don't think we need "group" in terms like "group MPLS-based IP" - it can 
simply be "IP-based MPLS".

There a few references like the following:

   [RFC9012] BGP Encapsulation extended community

I believe the reference should be put after the relevant text:

   BGP Encapsulation extended community [RFC9012]


Thanks.
Jeffrey

Juniper Business Use Only
___
BESS mailing list
BESS@ietf.org
https://www.ietf.org/mailman/listinfo/bess

[bess] Questions on draft-sajassi-bess-evpn-ip-aliasing-07

[Jeffrey (Zhaohui) Zhang]

Hi,

To prepare for the adoption call, I read the draft and have some questions and 
nit comments. If a point has been discussed before, a link to the email archive 
is appreciated.

   ... If H1 is
   locally learned only at one of the multi-homing PEs, PE1 or PE2, due
   to LAG hashing, PE3 will not be able to build an IP ECMP list for the
   H1 host route.

Perhaps remove the red text so that it is clear that "due to LAG hashing" is 
for "H1 is locally learned only ..." rather than for "PE3 will not be able to 
...".

For the following three subsections:

1.1.  Ethernet Segments for Host Routes in Symmetric IRB
   ...
   With Asymmetric IRB [RFC9135], ...

1.2.  Inter-subnet Forwarding for Prefix Routes in the Interface-less
  IP-VRF-to-IP-VRF Model

   In the Interface-less IP-VRF-to-IP-VRF model described in [RFC9136]
   ...

1.3.  Ethernet Segments for Prefix routes in IP-VRF-to-IP-VRF use-cases

   This document also enables fast convergence and aliasing/backup path
   to be used even when the ESI is used exclusively as an L3 construct,
   in an Interface-less IP-VRF-to-IP-VRF scenario [RFC9136].

Do we need to discuss the asymmetric model? It seems to be irrelevant.
Both 1.2 and 1.3 mention "Interface-less IP-VRF-to-IP-VRF scenario" in RFC9136 
though they are about different scenarios. Perhaps the section titles could be 
more accurate - in fact, they could be more consistent with the a/b/c use cases 
preceding 1.1. The following is a suggestion:

  1.1. MAC/IP routes with symmetric IRB
  1.2. IP Prefix routes with interface-less model
  1.3. IP Prefix routes with ESI being a pure L3 construct

In 1.3.1:

   In these use-cases, sometimes the CE supports a single BGP session to
   one of the PEs (through which it advertises a number of IP Prefixes
   seating behind itself) and yet, it is desired that remote PEs can
   build an IP ECMP list or backup IP list including all the PEs multi-
   homed to the same CE.

I initially wondered with how PE2 would know to forward traffic to the CE since 
it does not learn the routes from the CE, until it came to me that PE1 will 
re-advertise type-5 routes to every PE. I also see it is explicitly mentioned 
in 4.2. It would be good to briefly mention it in 1.3.1 as well.

It's also worth pointing out that both PE1 and PE2 can multi-path via each 
other.

1.3.2 does not seem to be a different use case from 1.3.1. It can be viewed as 
a special case of 1.3.1 - PEC's attachment to the ES is down. Perhaps fold 
1.3.2 into 1.3.1 as a special case?

For the following:

4.1.2.  IP A-D per ES route and SRv6 Transport

   When an SRv6 transport is used, each IP A-D per ES route MUST carry
   an SRv6 L3 Service TLV within the BGP Prefix-SID attribute [RFC9252].
   The Service SID MUST be of value 0.  The SRv6 Endpoint Behavior
   SHOULD be one of these End.DT46, End.DT4, End.DT6, End.DX4, or
   End.DX6.

What is the purpose of the above?

4.1.3.  IP A-D per ES route and ESI Label Extended Community

   Each IP A-D per ES route MUST be sent with the ESI Label extended
   community [I-D.ietf-bess-rfc7432bis].  The ESI Label field of the
   extended community SHOULD be set to zero when sending and MUST be
   ignored on reception.

I assume the purpose is to advertise flags - like whether it is all-active or 
single-active. Good to point that out.

4.3.  Handling Silent Host MAC/IP route for IP Aliasing
   ...
   Thus to avoid blackholing, when PE2 detects loss of reachability to
   PE1, it should trigger ARP/ND requests for all remote IP prefixes
   received from PE1 across all affected IP-VRFs.  This will force host
   H1 to reply to the solicited ARP/ND messages from PE2 and refresh
   both MAC and IP for the corresponding host in its tables.

This section talks about the silent host MAC/IP route. I suppose there is no 
similar mechanism for Section 4.2 if a single routing session from the CE to 
one of the PEs?

For the following:

  5.  Determining Reachability to Unicast IP Addresses

Perhaps change "IP Addresses" to "IP Destinations"?

For the following sections:

5.2.  Remote Learning

   The procedures for remote learning do not change from [RFC7432] or
   [RFC9136].

5.3.  Constructing the EVPN IP Routes

   The procedures for constructing MAC/IP Address or IP Prefix
   Advertisements do not change from [RFC7432] or [RFC9136].

5.3.1.  Route Resolution

5.3.1 is about Route Resolution on a receiving PE, while 5.3 is about 
constructing the routes on an originating PE. Seems that 5.3.1 should be moved 
out of 5.3.

What is the definition of "remote learning"? Both on a remote PE (e.g. PE3) and 
on a multi-homed PE (e.g., PE2 learning from PE1)? Both need to follow the 
updated route resolution procedures, so "The procedures for remote learning do 
not change from [RFC7432] or [RFC9136]"  does not seem right.

What's the difference between sections 7 and 8?

7.  Load Balancing of Unicast Packets

   The procedures for load balancing of Unicast Packets 

Re: [bess] Secdir last call review of draft-ietf-bess-mvpn-evpn-aggregation-label-10

[Jeffrey (Zhaohui) Zhang]

Hi Robert,

Thanks for your review and for working with me offline on the security 
considerations.

I have posted the -11 revision, which addresses your comments and comments from 
others.

https://author-tools.ietf.org/iddiff?url1=draft-ietf-bess-mvpn-evpn-aggregation-label-10=draft-ietf-bess-mvpn-evpn-aggregation-label-11=--html

Please let me know if you have any other comments.

Thanks!
Jeffrey


Juniper Business Use Only
-Original Message-
From: Robert Sparks via Datatracker 
Sent: Tuesday, July 11, 2023 12:05 PM
To: sec...@ietf.org
Cc: bess@ietf.org; draft-ietf-bess-mvpn-evpn-aggregation-label@ietf.org; 
last-c...@ietf.org
Subject: Secdir last call review of 
draft-ietf-bess-mvpn-evpn-aggregation-label-10

[External Email. Be cautious of content]


Reviewer: Robert Sparks
Review result: Has Nits

I have reviewed this document as part of the security directorate's ongoing 
effort to review all IETF documents being processed by the IESG. These comments 
were written primarily for the benefit of the security area directors. Document 
editors and WG chairs should treat these comments just like any other review 
comments.

This document is mostly ready for publication as a Proposed Standard RFC, but 
has nits (one bordering on an issue) to address before publication.

This document requires quite a bit of background provided outside of the 
document to make it meaningful. There is some effort to point to where 
essential concepts are defined, but a few more might be appropriate. It reads 
reasonably well, but I have provided some editorial comments at the end.

Nit bordering on issue:

The Security Considerations need more consideration. The essence of what's 
provided so far is "Nothing new to consider here, see RFC 5331, RFC 6514, RFC 
7432, and RFC 8402 for the things you should really think about before using 
the procedures defined in this document".

It's not clear how what the security consideration section in 5331 applies to 
these procedures - some discussion of what's important from that, and the other 
referenced docs, to _this_ document would be helpful. The primary concern seems 
to be entirely about the safe handling of, and consequences of 
(mis)-provisioning of, labels. Is there not a concise discussion in the 
literature around these labels to point to?

Structural nit:

The last paragraph and four bullets at the end of section 3.2 appears to be a 
set of pre-condition requirement (something that can only be violated by
mis-configuration) rather than something to test for at runtime. Consider 
stating this earlier and as a requirement on configuration of the system. Or, 
if I'm incorrect, say what to do should a receiving PE encounter this 
configuration.

Editorial nits:

Consider more explicit instruction where you require PEs to program things. I 
think "place an entry in" or similar would be clearer.

There is something that looks like normative text in the Terminology definition 
of SRGB (last sentence). Consider moving it into the body of the document, 
pointing to where it's specified (if specified elsewhere), or removing it.

At "This document simply specifies" (in 2.1) - what does "simply" mean here?
Please see if you can avoid the term.

Consider rewriting the first sentence of 3.2 more directly (think about 
translation into other languages). Something like "The procedures here MAY be 
used when...". The "need not...unless" construction is difficult.

At the last sentence of section 2.2 (before 2.2.1), consider how this will read 
in a decade. Avoid "today's networks" and simplify "more and more".

Please break the single sentence paragraph at the end of page 12 (starting 
"When a PE receives an x-PMSI/IMEI") into several simpler sentences.

Consider reworking the first part of "A PE MUST NOT both carry the DCB 
flag...". The route is carrying the flag, not the PE.



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

Re: [bess] Genart last call review of draft-ietf-bess-mvpn-evpn-aggregation-label-10

[Jeffrey (Zhaohui) Zhang]

Hi Russ,

I have posted the -11 revision, which addresses your comments and comments from 
others.

https://author-tools.ietf.org/iddiff?url1=draft-ietf-bess-mvpn-evpn-aggregation-label-10=draft-ietf-bess-mvpn-evpn-aggregation-label-11=--html

Please let me know if you have any other comments.

Thanks!
Jeffrey


Juniper Business Use Only
-Original Message-
From: Jeffrey (Zhaohui) Zhang
Sent: Tuesday, July 11, 2023 10:43 PM
To: Russ Housley ; gen-...@ietf.org
Cc: bess@ietf.org; draft-ietf-bess-mvpn-evpn-aggregation-label@ietf.org; 
last-c...@ietf.org
Subject: RE: Genart last call review of 
draft-ietf-bess-mvpn-evpn-aggregation-label-10

Hi Russ,

Thanks for your review and comments.
Please see zzh> below.

-Original Message-
From: Russ Housley via Datatracker 
Sent: Friday, June 30, 2023 11:34 AM
To: gen-...@ietf.org
Cc: bess@ietf.org; draft-ietf-bess-mvpn-evpn-aggregation-label@ietf.org; 
last-c...@ietf.org
Subject: Genart last call review of 
draft-ietf-bess-mvpn-evpn-aggregation-label-10

[External Email. Be cautious of content]


Reviewer: Russ Housley
Review result: Almost Ready

I am the assigned Gen-ART reviewer for this draft. The General Area Review Team 
(Gen-ART) reviews all IETF documents being processed by the IESG for the IETF 
Chair.  Please treat these comments just like any other last call comments.

For more information, please see the FAQ at 
<https://urldefense.com/v3/__http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq__;!!NEt6yMaO-gk!Bn70GYYpMVzCajcXY6lg0iBcKkTYHdlqiTryvf4m2OjdKMVqmA7FDSbsFpOYzSz92OgNRiv14HmwByA$
 >.

Document: draft-ietf-bess-mvpn-evpn-aggregation-label-10
Reviewer: Russ Housley
Review Date: 2023-06-30
IETF LC End Date: 2023-07-12
IESG Telechat date: unknown


Summary: Almost Ready


Major Concerns: None.


Minor Concerns:

Section 2.2: Please provide more discussion of "central authority".  I do not 
think that a Internet-wide authority is required to meet this requirement.  I 
think that the authority needs to be recognized throughout a provider network.

Zzh> Correct. I changed the first to "central entity in the provider network", 
and the rest to "central entity".
Zzh> I fixed the following nits as well - will post the revision after the 
quiescence period is over.

Zzh> Jeffrey

Nits:

Section 1: please avoid splitting "I/S-PMSI" across multiple lines.

Section 2: s/ingress PE's default label space/default label space/

Section 2: s/packet's ingress PE/ingress PE of the packet/

Section 2.2.2.1: s/Route-2 respectively/Route-2, respectively/

Section 3.2: s/PTA's Label field/label field of the PTA/

Section 3.2: s/source PE's label space/label space of the source PE/

Section 4: s/third party's label space/label space of a third party/ (2 places)

Section 4: please spell out "LFIBs"; this term is not in the definitions.


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

Re: [bess] Opsdir last call review of draft-ietf-bess-mvpn-evpn-aggregation-label-10

[Jeffrey (Zhaohui) Zhang]

Hi Menachem,

I have posted the -11 revision, which addresses your comments and comments from 
others.

https://author-tools.ietf.org/iddiff?url1=draft-ietf-bess-mvpn-evpn-aggregation-label-10=draft-ietf-bess-mvpn-evpn-aggregation-label-11=--html

Please let me know if you have any other comments.

Thanks!
Jeffrey


Juniper Business Use Only
-Original Message-
From: Jeffrey (Zhaohui) Zhang
Sent: Tuesday, July 11, 2023 11:25 PM
To: Menachem Dodge ; ops-...@ietf.org
Cc: bess@ietf.org; draft-ietf-bess-mvpn-evpn-aggregation-label@ietf.org; 
last-c...@ietf.org
Subject: RE: Opsdir last call review of 
draft-ietf-bess-mvpn-evpn-aggregation-label-10

Hi Menachem,

Thanks for your review and comments.
Please see zzh> below.

-Original Message-
From: Menachem Dodge via Datatracker 
Sent: Sunday, July 2, 2023 4:58 AM
To: ops-...@ietf.org
Cc: bess@ietf.org; draft-ietf-bess-mvpn-evpn-aggregation-label@ietf.org; 
last-c...@ietf.org
Subject: Opsdir last call review of 
draft-ietf-bess-mvpn-evpn-aggregation-label-10

[External Email. Be cautious of content]


Reviewer: Menachem Dodge
Review result: Has Nits

Hello,
I have reviewed this document as part of the Operational directorate's ongoing 
effort to review all IETF documents being processed by the IESG.  These 
comments were written with the intent of improving the operational aspects of 
the IETF drafts. Comments that are not addressed in last call may be included 
in AD reviews during the IESG review.  Document editors and WG chairs should 
treat these comments just like any other last call comments.

The document is well written.

Summary:
For MVPN and EVPN networks where P2MP or MP2MP tunnels are used to carry 
traffic, the ingress routers allocate an upstream label for each VPN or for 
each BD. This can lead to the egress routers needing to keep track of large 
numbers of labels that can be greatly reduced if the association between a 
label and a VPN or BD is made by provisioning, so that all ingress routers 
assign the same label to a particular VPN or BD.

The document is for the standards track.

Nits

1. Section 2.2, 5th paragraph - missing word:
OLD --> However, that is not necessary as the labels used by PEs for the 
purposes defined in this document will only rise to the top of the label stack 
when traffic arrives the PEs. SUGGEST --> However, that is not necessary as the 
labels used by PEs for the purposes defined in this document will only rise to 
the top of the label stack when traffic arrives at the PEs.

Zzh> Fixed.

 2. Section 2.2, Last Paragraph - sentence not clear:
OLD --> Allocating a label from the DCB or from those a few context-specific 
label spaces and communicating them to all PEs is not different from allocating 
VNIs, and is feasible in today's networks since controllers are used more and 
more widely SUGGEST --> Allocating a label from the DCB or from a 
context-specific label space and communicating them to all PEs is not different 
from allocating VNIs, and is feasible in today's networks since controllers are 
used more and more widely

Zzh> Fixed.

3. Section 2.2.3, first sentence:
OLD --> In summary, labels can be allocated and advertised the following ways:
SUGGEST --> In summary, labels can be allocated and advertised in the following
ways:

zzh> Fixed.

4. Section 2.2.3, point 3 - sentence is unclear.
"A central authority assigns disjoint label blocks from those a few 
context-specific label spaces to each PE, and allocate labels from the DCB to 
identify the context-specific label spaces."

Zzh> What it tries to say is:
Zzh> a) a central entity breaks a few label spaces into disjoint blocks
Zzh> and assign those blocks to PEs
Zzh> b) it also allocates some labels from the DCB, one for each of
Zzh> those label spaces I tweaked the entire paragraph slightly and it now 
reads:

   3.  A central entity assigns disjoint label blocks from a few
   context-specific label spaces to each PE, and allocates labels
   from the DCB to identify those context-specific label spaces.  A
   PE independently allocates a label for a segmented S-PMSI from
   its assigned label block, and advertises the label along with the
   context-identifying label.

Zzh> Please let me know if this works. I will post the revision after the 
quiescence period is over.
Zzh> Thanks.
Zzh> Jeffrey

Thank you kindly.

Best Regards,
Menachem Dodge


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

Re: [bess] Comments on the VPN Inter-AS Option BC draft

[Jeffrey (Zhaohui) Zhang]

Hi Sasha, Jorge,

Thanks for the comments. Please see zzh> below.



Juniper Business Use Only
From: Alexander Vainshtein 
Sent: Tuesday, August 1, 2023 5:42 PM
To: Jorge Rabadan (Nokia) 
Cc: bess@ietf.org; Nitsan Dolev ; 
draft-zzhang-bess-vpn-option-bc.auth...@ietf.org
Subject: RE: Comments on the VPN Inter-AS Option BC draft

[External Email. Be cautious of content]

Jorge,
I think that a more detailed definition of the TEA-based solution for inter-AS 
Option BC and EVPN is required.

Zzh> For the TEA based solution, I had thought the method was described well 
enough (except the normative encoding format). It also includes the interop 
between the nodes that are incapable of handling the new "composite tunnel" 
(more below). Apparently, we need to elaborate it more.
Zzh> Indeed the draft was written more focused on IP VPN (RFC 4364) and in that 
case the double-label based approach is better in that many PEs may already be 
able to support it. In case of EVPN, as Jorge commented on the mic, TED based 
approach is needed.

According to RFC 9136, Encapsulation Extended Community can be attached to EVPN 
Ip Prefix routes in some cases.
And Section 4.1 of RFC 
9012
 says that the semantics of this extended community are the same as could be 
encoded in the "barebones Tunnel TLV".

Zzh> RFC9012 states:

   Section 6 of [RFC8365] talks about the use of the Encapsulation
   Extended Community to allow Network Virtualization Edge (NVE) devices
   to signal their supported encapsulations.  We note that with the
   introduction of this specification, the Tunnel Encapsulation
   attribute can also be used for this purpose.  For purposes where RFC
   8365 talks about "advertising supported encapsulations" (for example,
   in the second paragraph of Section 6), encapsulations advertised
   using the Tunnel Encapsulation attribute should be considered equally
   with those advertised using the Encapsulation Extended Community.

Are there valid scenarios in which Encapsulation Extended Community has to be 
attached to the EVPN IP Prefix route for the reasons defined in RFC 9136 the 
same route undergoes inter-AS Option BC handling based on the TEA, and, if yes, 
how these two usages can be clearly differentiated?

Zzh> For Option-BC, the new "composite tunnel" needs to be used to convey the 
semantics that the label in the tunnel is used for label switching the traffic.
Zzh> More below.

Regards, and lots of thanks in advance,
Sasha

From: Jorge Rabadan (Nokia) 
mailto:jorge.raba...@nokia.com>>
Sent: Monday, July 31, 2023 6:32 PM
To: Alexander Vainshtein 
mailto:alexander.vainsht...@rbbn.com>>; 
draft-zzhang-bess-vpn-option-bc.auth...@ietf.org
Cc: bess@ietf.org; Nitsan Dolev 
mailto:nitsan.do...@rbbn.com>>
Subject: [EXTERNAL] Re: Comments on the VPN Inter-AS Option BC draft

Hi everyone,

I mostly agree with Sasha's points.
For completeness I'd like to add that, as I said on the mike, I believe a 
solution based on the TEA would be better (than based on multi-label NLRI). 
Reasons are:

-   RFC8277 was only defined for SAFIs 1 and 128, never for EVPN

Zzh> On the mic I think I mentioned "protocols could be extended" - I thought 
you were saying about TEA for EVPN use. Now I see you were referring to the 
multi-label encoding. I agree with you.


-   EVPN route type 2 uses multiple labels in the NLRI already, so it would be 
simpler to use TEA.

Zzh> I agree that for EVPN we need to use TEA.
Zzh> More below for Sasha's comments.

Thanks.
Jorge

From: BESS mailto:bess-boun...@ietf.org>> on behalf of 
Alexander Vainshtein 
mailto:alexander.vainsht...@rbbn.com>>
Date: Sunday, July 30, 2023 at 12:33 AM
To: 
draft-zzhang-bess-vpn-option-bc.auth...@ietf.org
 
mailto:draft-zzhang-bess-vpn-option-bc.auth...@ietf.org>>
Cc: bess@ietf.org mailto:bess@ietf.org>>, 
Nitsan Dolev mailto:nitsan.do...@rbbn.com>>
Subject: [bess] Comments on the VPN Inter-AS Option BC draft

CAUTION: This is an external email. Please be very careful when clicking links 
or opening attachments. See the URL nok.it/ext for additional information.


Hi,
A few comments on the VPN Inter-AS Option BC 
draft
 that has been presented at the BESS WG session in SF last Thursday.

I think that the draft presents an elegant and much needed solution for real 
problem.
I fully agree with the statement in the 

Re: [bess] IETF 117 BESS - IPv6 Only PE Design & IPv4 Only PE Design ALL SAFI Supported

[Jeffrey (Zhaohui) Zhang]

I support the merge.



Juniper Business Use Only
From: BESS  On Behalf Of Gyan Mishra
Sent: Thursday, July 27, 2023 5:32 PM
To: BESS ; bess-cha...@ietf.org; Dongjie (Jimmy) 

Subject: [bess] IETF 117 BESS - IPv6 Only PE Design & IPv4 Only PE Design ALL 
SAFI Supported

[External Email. Be cautious of content]

Dear BESS WG,

From my presentation today discussion on "merging" of drafts I  would like to 
poll the BESS WG on merging of the two drafts labeled #1 & #2 below into the WG 
document labeled #3 below:
Please respond  to this email.

Some history:
IPv6 Only PE design / ALL SAFI:
draft-ietf-bess-ipv6-only-pe-design-04 (BCP) (Original BCP testing draft with 
Cisco, Juniper, Nokia, Arista, Huawei) (WG document)
IPv6 Only PE design single IPv6 peer - testing SAFI 1,128,129
draft-mishra-bess-ipv6-only-pe-design-all-safi-04 (Standards Track) (New Draft) 
- Extended Standards Track to support ALL IPv4 SAFI

IPv4 Only PE design / ALL SAFI:
The below drafts were two separate drafts but I have combined into single draft 
since they both were not WG documents
draft-mishra-bess-ipv4-only-pe-design-02 -(BCP) (POC testing draft with Cisco, 
Juniper, Nokia, Arista, Huawei)
IPv4 Only PE design single IPv4 peer - testing SAFI 1,128,129
draft-mishra-bess-ipv4-only-pe-design-all-safi-05 (Standards track) (New Draft) 
- Extended Standards Track to support ALL IPv4 SAFI (Both v4 drafts have been 
combined into this Draft early this year)
(Introduces new IPv4 next hop encoding IANA capability codepoint 
standardization following RFC 8950 IPv4 next hop and not legacy IPv4 mapped 
IPv6 address next hop ::::1.1.1.1)
(Today there is a mix of IPv4 next hop and IPv4 mapped IPv6 next hop across all 
vendors and within same vendor platform -afi/safi matrix to be added to merged 
draft)

Combine these two drafts --> So now we are left with  these 2 new drafts that 
extend to support ALL SAFI

#1 draft-mishra-bess-ipv6-only-pe-design-all-safi-03 (Standards Track)
#2 draft-mishra-bess-ipv4-only-pe-design-all-safi-04 (Standard Track)

Into WG document below:

#3 draft-ietf-bess-ipv6-only-pe-design-04 (BCP)

And make the new combined draft "Standards Track" as it will have the 
operational process and procedure update for the alternative dual stacking 
method for all SAFI
as well as New IANA capability code point for IPv4 next hop encoding similar to 
RFC 8950.

NEW DRAFT NAME:

 draft-ietf-bess-v4-v6-pe-all-safi (Standards Track)

Why combine?

  *   Both IPv4 Only PE Design & IPv6 Only PE design are identical concepts of 
single IPv4 peer or single IPv6 peer carrying SAFI 1,128.129 for both v4 & v6 
prefixes being POC tested - can now be done in parallel
  *   Extensibility of both the IPv4 Only PE Design & IPv6 Only PE design 
extends to the same set of ALL IPv4 / IPv6 SAFI's
  *   Saves both WG time on progressing 3 separate drafts
  *   Single draft that has the entire v4 / v6 design & architecture in one 
spot versus being broken out into separate drafts added complexity

Thank you


[http://ss7.vzw.com/is/image/VerizonWireless/vz-logo-email]

Gyan Mishra

Network Solutions Architect

Email gyan.s.mis...@verizon.com

M 301 502-1347

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

Re: [bess] Opsdir last call review of draft-ietf-bess-mvpn-evpn-aggregation-label-10

[Jeffrey (Zhaohui) Zhang]

Hi Menachem,

Thanks for your review and comments.
Please see zzh> below.


Juniper Business Use Only
-Original Message-
From: Menachem Dodge via Datatracker 
Sent: Sunday, July 2, 2023 4:58 AM
To: ops-...@ietf.org
Cc: bess@ietf.org; draft-ietf-bess-mvpn-evpn-aggregation-label@ietf.org; 
last-c...@ietf.org
Subject: Opsdir last call review of 
draft-ietf-bess-mvpn-evpn-aggregation-label-10

[External Email. Be cautious of content]


Reviewer: Menachem Dodge
Review result: Has Nits

Hello,
I have reviewed this document as part of the Operational directorate's ongoing 
effort to review all IETF documents being processed by the IESG.  These 
comments were written with the intent of improving the operational aspects of 
the IETF drafts. Comments that are not addressed in last call may be included 
in AD reviews during the IESG review.  Document editors and WG chairs should 
treat these comments just like any other last call comments.

The document is well written.

Summary:
For MVPN and EVPN networks where P2MP or MP2MP tunnels are used to carry 
traffic, the ingress routers allocate an upstream label for each VPN or for 
each BD. This can lead to the egress routers needing to keep track of large 
numbers of labels that can be greatly reduced if the association between a 
label and a VPN or BD is made by provisioning, so that all ingress routers 
assign the same label to a particular VPN or BD.

The document is for the standards track.

Nits

1. Section 2.2, 5th paragraph - missing word:
OLD --> However, that is not necessary as the labels used by PEs for the 
purposes defined in this document will only rise to the top of the label stack 
when traffic arrives the PEs. SUGGEST --> However, that is not necessary as the 
labels used by PEs for the purposes defined in this document will only rise to 
the top of the label stack when traffic arrives at the PEs.

Zzh> Fixed.

 2. Section 2.2, Last Paragraph - sentence not clear:
OLD --> Allocating a label from the DCB or from those a few context-specific 
label spaces and communicating them to all PEs is not different from allocating 
VNIs, and is feasible in today's networks since controllers are used more and 
more widely SUGGEST --> Allocating a label from the DCB or from a 
context-specific label space and communicating them to all PEs is not different 
from allocating VNIs, and is feasible in today's networks since controllers are 
used more and more widely

Zzh> Fixed.

3. Section 2.2.3, first sentence:
OLD --> In summary, labels can be allocated and advertised the following ways:
SUGGEST --> In summary, labels can be allocated and advertised in the following
ways:

zzh> Fixed.

4. Section 2.2.3, point 3 - sentence is unclear.
"A central authority assigns disjoint label blocks from those a few 
context-specific label spaces to each PE, and allocate labels from the DCB to 
identify the context-specific label spaces."

Zzh> What it tries to say is:
Zzh> a) a central entity breaks a few label spaces into disjoint blocks and 
assign those blocks to PEs
Zzh> b) it also allocates some labels from the DCB, one for each of those label 
spaces
Zzh> I tweaked the entire paragraph slightly and it now reads:

   3.  A central entity assigns disjoint label blocks from a few
   context-specific label spaces to each PE, and allocates labels
   from the DCB to identify those context-specific label spaces.  A
   PE independently allocates a label for a segmented S-PMSI from
   its assigned label block, and advertises the label along with the
   context-identifying label.

Zzh> Please let me know if this works. I will post the revision after the 
quiescence period is over.
Zzh> Thanks.
Zzh> Jeffrey

Thank you kindly.

Best Regards,
Menachem Dodge


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

Re: [bess] Genart last call review of draft-ietf-bess-mvpn-evpn-aggregation-label-10

[Jeffrey (Zhaohui) Zhang]

Hi Russ,

Thanks for your review and comments.
Please see zzh> below.


Juniper Business Use Only
-Original Message-
From: Russ Housley via Datatracker 
Sent: Friday, June 30, 2023 11:34 AM
To: gen-...@ietf.org
Cc: bess@ietf.org; draft-ietf-bess-mvpn-evpn-aggregation-label@ietf.org; 
last-c...@ietf.org
Subject: Genart last call review of 
draft-ietf-bess-mvpn-evpn-aggregation-label-10

[External Email. Be cautious of content]


Reviewer: Russ Housley
Review result: Almost Ready

I am the assigned Gen-ART reviewer for this draft. The General Area Review Team 
(Gen-ART) reviews all IETF documents being processed by the IESG for the IETF 
Chair.  Please treat these comments just like any other last call comments.

For more information, please see the FAQ at 
.

Document: draft-ietf-bess-mvpn-evpn-aggregation-label-10
Reviewer: Russ Housley
Review Date: 2023-06-30
IETF LC End Date: 2023-07-12
IESG Telechat date: unknown


Summary: Almost Ready


Major Concerns: None.


Minor Concerns:

Section 2.2: Please provide more discussion of "central authority".  I do not 
think that a Internet-wide authority is required to meet this requirement.  I 
think that the authority needs to be recognized throughout a provider network.

Zzh> Correct. I changed the first to "central entity in the provider network", 
and the rest to "central entity".
Zzh> I fixed the following nits as well - will post the revision after the 
quiescence period is over.

Zzh> Jeffrey

Nits:

Section 1: please avoid splitting "I/S-PMSI" across multiple lines.

Section 2: s/ingress PE's default label space/default label space/

Section 2: s/packet's ingress PE/ingress PE of the packet/

Section 2.2.2.1: s/Route-2 respectively/Route-2, respectively/

Section 3.2: s/PTA's Label field/label field of the PTA/

Section 3.2: s/source PE's label space/label space of the source PE/

Section 4: s/third party's label space/label space of a third party/ (2 places)

Section 4: please spell out "LFIBs"; this term is not in the definitions.


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

Re: [bess] Discussion on draft-rabadan-bess-evpn-inter-domain-opt-b and draft-ietf-bess-evpn-virtual-hub.

[Jeffrey (Zhaohui) Zhang]

Hi Yubao,

Please see zzh> below.

From: BESS  On Behalf Of wang.yub...@zte.com.cn
Sent: Thursday, May 11, 2023 3:32 AM
To: draft-rabadan-bess-evpn-inter-domain-op...@ietf.org; 
draft-ietf-bess-evpn-virtual-...@ietf.org; jorge.raba...@nokia.com
Cc: bess@ietf.org
Subject: [bess] Discussion on draft-rabadan-bess-evpn-inter-domain-opt-b and 
draft-ietf-bess-evpn-virtual-hub.

[External Email. Be cautious of content]




Hi authors,



I noticed that draft-rabadan-bess-evpn-inter-domain-opt-b tries to summarize 
the impact of the Inter-Domain Option-B connectivity in the EVPN procedures.

And I noticed that, when there is an inter-domain option-b node between virtual 
hub nodes and virtual spoke nodes, how should the PED label attribute ( section 
7.1 of draft-ietf-bess-evpn-virtual-hub ) be rewritten has not been clearly 
defined yet.



" ...  ... Notice that an "upstream-assigned" label used by a V-hub to send

   traffic with on a P2MP tunnel to identify the source V-spoke is the

   same "downstream-assigned" label used by the V-hub to receive traffic

   on the IR tunnel from the V-spoke. "

zzh> It is the same label allocated by the V-hub to identify the source 
V-spoke. When IR is used to receive traffic from the source V-spoke, it is 
downstream/receiver-allocated (from the sending V-spoke point of view); when 
P2MP is used to relay traffic from the source V-spoke to others, it is 
upstream/sender-allocated (from the receiving PE point of view). But it is the 
same label allocated by the V-hub. From the V-hub point of view, it is from the 
regular (down-stream allocation) label space.

As described in section 7.1 of draft-ietf-bess-evpn-virutal-hub, the PED label 
is both  "upstream-assigned" and "downstream-assigned". In such case, when an 
inter-domain option-b nodes decides to rewrite the PED labels, how can it find 
a common label value which is unused both in the "upstream-assigned" label 
space and "downstream-assigned" label space?

Zzh> As explained above, it is from the same label space of the allocator.

Zzh> The questions below are a bit complicated; we can continue if the above 
explanation does not resolve them.

Zzh> Thanks.

Zzh> Jeffrey

PE1--ABR-PE2

When the ABR propagate EVPN routes to PE3, should the PED labels from PE2 be 
rewritten in the same "upstream-assigned" label space as the PED labels from 
PE1?

Especially when there are multiple types of EVPN services over P2MP LSP between 
PE1 and PE2. e.g. only half of these services of is EVPN VH/VS over P2MP LSP, 
the other half of these services is normal EVPN VPLS over P2MP LSP. The ABR 
above is the common inter-domain option-b node of both the two halves of these 
services.Should the EVPN labels of those normal EVPN VPLS over P2MP LSP 
services also be allocated in the same "upstream-assigned" label space as the 
PED labels?

If there is also a normal L3VPN/EVPN over MP2P/P2P LSP service between PE1 and 
PE2, from the viewpoint of ABR node, should the EVPN label of such normal 
L3VPN/EVPN service also be allocated in the same "downstream-assigned" label 
space as the PED labels? Will the label rewritting procedures for these normal 
L3VPN/EVPN over MP2P/P2P services be affected by the PED label rewritting 
procedures?



Will this use case be considered by any of these two drafts?



Thanks,

Yubao










Juniper Business Use Only
___
BESS mailing list
BESS@ietf.org
https://www.ietf.org/mailman/listinfo/bess

Re: [bess] New Version Notification for draft-wang-bess-mvpn-upstream-df-selection-03.txt

[Jeffrey (Zhaohui) Zhang]

Hi Siyu,

For the following:

-
#6.
   ... According to the negotiation community, a distinct
   C-Multicast route for (C-S, C-G) is sent to each multi-homed root PE.
   Leaf PE installs all P-Tunnels rooted from the multi-homed PEs into
   the anycast RPF tunnel checklist of the corresponding multicast
   traffic (C-S, C-G).

> Suggestion : This means, if there are four ingress PEs for the same flow,  
> all of them will receive the C-multicast route. With the RFC9026 procedure, 
> only two of them will, and the selection can still be based on (s,g).
In summary, I don't see sufficient advantages of developing another solution 
now that RFC9026 have been implemented and deployed.

>> Reply: In RFC9026, there can be one standby PE or multiple standby PEs.
a) Multiple standby PEs in Section 3.1.6.2:
 'If the site that contains C-S is connected to two or more PEs, a 
downstream PE will select one as its Primary Upstream PE, while others are 
considered to be Standby Upstream PEs'.
b) One standby PE in Section 4:
 'In the case where more than two PEs are connected to the C-S site, 
selection of the Standby PE can be performed using one of the methods of 
selecting a UMH.'
In our draft, we will modify relevant descriptions so that only one PE will be 
selected as Standby PE. C-multicast route will only be sent to the selected 
Standby PE.
The advantage of our approach over RFC9026 has been mentioned in #3.
-

My understanding is from the following text:

  If a leaf PE decides to send C-Multicast routes to upstream PEs for a
  given (C-S, C-G), it follows the procedure described in [RFC6514]
  excepting that the RPF route of the c-root has an IDF negotiation
--->community.  According to the negotiation community, a distinct
--->C-Multicast route for (C-S, C-G) is sent to each multi-homed root PE.
   ...

   b.  To perform IDF election for each C-G of a specific multicast
   source C-S, each PE also builds an ordered list of the IP
   addresses of all the multi-homed PE nodes at first.  The
   difference between this option and above is that the election of
   IDF occurs not upon receiving all UMH routes of the other multi-
>homed PEs of the specfied C-S but upon receiving the C-multicast
>join of the corresponding C-G.  Assuming an ordered list of N
   elements, the PE with ordinal i is the IDF for a C-G when (C-G
   mod N) = i.  The PE with ordinal j is the Standby IDF when j is
   (C-G mod (N-1)).  The calculation of standby IDF uses the ordered
   IP addresses list without considering the existance of the
   elected IDF element.

To perform (S,G) based selection, all root PEs must receive the C-mcast routes 
first.

Thanks.
Jeffrey


Juniper Business Use Only

-Original Message-
From: Chensiyu (Susie)  
Sent: Monday, February 13, 2023 7:11 AM
To: Jeffrey (Zhaohui) Zhang ; bess@ietf.org
Cc: duanfanghong 
Subject: RE:RE: New Version Notification for 
draft-wang-bess-mvpn-upstream-df-selection-03.txt

[External Email. Be cautious of content]


Hi, Jeffrey
Thank you very much for your feedback on our draft. We will update a new 
version of the draft later based on our discussions. Our replies to all 
suggestions are as follow.
-
#1.
   For the "hot root standby"
   mechanism, all the ingress PEs, regardless of the primary or standby
   role, forward (C-S,C-G) flow to other PEs through a P-tunnel, forcing
   the egress PEs to discard all but one, which will cause the steady
   traffic redundancy throughout the backbone network.  In the scenarios
   of enterprise networks crossing provider networks, the waste of
   bandwidth is a crucial issue causing the increasement of the OpEx of
   enterprise networks, and the "warm root standby" mechanism is
   expected to be a better solution.
> Suggestion : The mentioning of Hot Root Standby (HRS) should be removed.
It is specifically designed for scenarios where it is critical for egress PEs 
to receive but discard duplicates and BW consumption is not a concern. Where BW 
is a concern, the Warm Root Standby
(WRS) can be used.
This draft should only compare to WRS.

>> Reply : We will modify the first para

Re: [bess] New Version Notification for draft-wang-bess-mvpn-upstream-df-selection-03.txt

[Jeffrey (Zhaohui) Zhang]

Hi Siyu,

Please see comments below.

   For the "hot root standby"
   mechanism, all the ingress PEs, regardless of the primary or standby
   role, forward (C-S,C-G) flow to other PEs through a P-tunnel, forcing
   the egress PEs to discard all but one, which will cause the steady
   traffic redundancy throughout the backbone network.  In the scenarios
   of enterprise networks crossing provider networks, the waste of
   bandwidth is a crucial issue causing the increasement of the OpEx of
   enterprise networks, and the "warm root standby" mechanism is
   expected to be a better solution.

The mentioning of Hot Root Standby (HRS) should be removed.
It is specifically designed for scenarios where it is critical for
egress PEs to receive but discard duplicates and BW consumption
is not a concern. Where BW is a concern, the Warm Root Standby
(WRS) can be used.

This draft should only compare to WRS.

   However, there are some problems
   when deploying the "warm root standby" mechanism described in
   [RFC9026].

   a.  Upon the failure of primary ingress PE, the standby ingress PE
   needs to send PIM join hop by hop toward multicast source for
   each multicast flow and the time when the standby ingress PE
   switches to the primary role may be inconsistent with the time
   when the leaf PE determines to accept multicast traffic sent by
   the standby root, causing which the failover time can hardly
   reach the same level of "hot root standby" mechanism.

This point should be removed because it describes Cold Root Standby.
With WRS in RFC9026, traffic already arrives on both PEs.

   b.  There is no endogenous mechanism for standby ingress PEs to
   discover and detect the failure of primary ingress PEs, resulting
   in the uncertainty in deployment and implementation.

What's the problem of relying on egress PEs detecting the failure of primary PE?

   c.  In [RFC9026], the standby ingress PE is determined by using
   "Standby PE Community" carried in the C-Multicast routes.  The
   premise of this mechanism is that all leaf PEs choose the same
   primary and standby ingress PEs, which may not be meeted due to
   transient unicast routing inconsistencies, the inconsistencies of
   P-Tunnel status determined by each leaf PE or lack of support of
   the Standby PE community on leaf PE, causing that the "warm root
   standby" mechanism is not stable and returns to "hot root
   standby" mode because the standby ingress PE also sends multicast
   traffic to backbone when the condition is not satisfied.

The potential inconsistent choice among egress PEs is likely because that
the tunnel branches may be up to some egress PEs while down to others.
That is actually a good reason for different choices - we don't want some egress
PEs to not be able to receive from the primary PE. Besides, MVPN handles that
situation well (remember that each egress PE can choose its ingress PE -
see the "Another procedure ..." paragraph in 
https://www.rfc-editor.org/rfc/rfc6513.html#section-5.1.3).

If it desired to avoid that, the tunnel status consideration can be skipped
and you'll get consistency that your draft wants, but both are at the cost of
some egress PE may not be able to receive traffic.

   d.  The primary and standby role is fixed for each multicast flow,
   resulting in that ingress PEs cannot perform load balancing for
   multicast traffic.  Only two ingress PEs are selected for all
   multicast stream from a specific multicast source, causing that
   the "warm root standby" mechanism cannot be used in the scenarios
   of client nework multihoming to more than two ingress PEs.

I don't think that is true. The same Single Forward Selection rules in RFC6513,
which can do load balancing (see 5.1.3 of RFC6513) among different
(C-S,C-G) flows, can be used to
choose both primary and secondary UMH (the secondary one can be
chosen the same way after excluding the primary one). If RFC9026
is not clear about that, it can be clarified.

anycast RPF checking mechanism in dataplane

The word "anycast" is misleading. You should say that traffic from any of the 
ingress PEs can be accepted.

   ... According to the negotiation community, a distinct
   C-Multicast route for (C-S, C-G) is sent to each multi-homed root PE.
   Leaf PE installs all P-Tunnels rooted from the multi-homed PEs into
   the anycast RPF tunnel checklist of the corresponding multicast
   traffic (C-S, C-G).

This means, if there are four ingress PEs for the same flow,
 all of them will receive the C-multicast route. With the RFC9026 procedure,
only two of them will, and the selection can still be based on (s,g).

In summary, I don't see sufficient advantages of developing another solution
now that RFC9026 have been implemented and deployed.

   For the scenarios of the same RD, this document introduces a new type
   of UMH route to be sent in MVPN SAFI, of which 

Re: [bess] Rtgdir last call review of draft-ietf-bess-mvpn-evpn-aggregation-label-08

[Jeffrey (Zhaohui) Zhang]

Hi Tony,

Thanks for your thorough review and comments. I have posted the -09 version 
that I believe/hope have address your comments/concerns.
https://datatracker.ietf.org/doc/html/draft-ietf-bess-mvpn-evpn-aggregation-label-09

Please see zzh> below for some details.


Juniper Business Use Only

-Original Message-
From: Tony Przygienda via Datatracker  
Sent: Tuesday, November 1, 2022 4:02 PM
To: rtg-...@ietf.org
Cc: bess@ietf.org; draft-ietf-bess-mvpn-evpn-aggregation-label@ietf.org; 
last-c...@ietf.org
Subject: Rtgdir last call review of 
draft-ietf-bess-mvpn-evpn-aggregation-label-08

[External Email. Be cautious of content]


Reviewer: Tony Przygienda
Review result: Has Issues

As first, technically sound except point 18. Rest of the commentes provided are 
all for easier readability/clarity for a reader that may not be super 
instrinsically familiar with the world of overlay multicast tunnels underlying 
VPN technologies first. I am quite versant in it but even then, the complexity 
of the field made me stumble on some assertions given without explanation.
Then, good amount of omitted words etc necessary to read as coherent English 
sentences. Ultimately, some of the transitions in terms of causality chains do 
not connect and can leave the reader stranded which I'm pointing out in 
specific comments.

Numbered:

1.  document only distincts between p2mp and mp2mp rather than using the PMSI 
terminology with inclusisve/selective [RFC6513]. the S/I is not relevant but it 
would help readability if that would be explained. Especially since the S/I 
starts to be introduced in 2.2.2.1 suddenly.

Zzh> The difference between P2MP and MP2MP is actually not important and not 
the focus of the document. The document starts with P2MP because it is more 
common; it does talk about MP2MP's applicability with some specifics afterwards.

Zzh> Use of per-VPN/BD/ES DCB labels does not work for tunnel segmentation, and 
entire section 2.2.2 is about how we mitigate that. Section 2.2.2.1 explains 
the need for per-PMSI labels using selective tunnels example, and section 
2.2.2.2 extends it to inclusive tunnels.
Zzh> For an average reader, selective/inclusive tunnels are easier to 
understand than S/I-PMSI terms so the sections are based on "tunnels" instead 
of PMSIs, but now I have added additional glossaries and text to tie the two 
together.

2. Terminology
-- provide references for BD/BUM/PMSI/IMET/PTA in terms of RFCs defining them 
properly. Currently the section is just acronym expansion really.
-- provide definition of "aggregate tunnel" in the terminology section rather 
than later in the document for consistency
-- add definitons for "context space", "upstream assigned label" and "ESI 
Label" here as well rather than later in the document. This may lead to more 
conscise and readable introduction section
-- add definition for DCB
-- add def for SRGB with according SRGB

--- I suggest to add upstream assigned (and downstream) labels to definitions 
as well since it's so central to the document. Acronym expansion + RFC ref is 
fine AFAIS but at least the reader can peddle back and know in one shot where 
all the stuff comes from or read things upfront to have an inkling. The 
drip-drip technique uesed in the document is ok'ish since it makes an illusion 
of gradual introduction into the solution space on first read but makes it hard 
to find things later, have in one easy shot a quick recall "what was that all 
about". IME good glossary goes a very long way when attempting a 2nd read or 
trying to do a fast page-in later.
-- given 2.2.2.1 I suggest to add PMSI + S/I + PTA defintions + IMET + RBR. And 
maybe minimum definition (or where to find the terminology precisely) for the 
whole (C-*,C-*) machinery involved in context lookups you pull out in 2.2.2.3

Zzh> I added more terms.
Zzh> I assume most people now just read the electronic copy instead of paper 
copy, so the drip-drip technique should not only work well for gradual 
introduction but also not make it hard to find things later? 

3. "but each PE would
   know not to allocate labels from that block for other purposes" is difficult
   to read. Rewrite from negative.

Zzh> I removed it entirely. Sometimes less is more 

4. "1000 is for VPN 0, 1001 for VPN 1 ...". Write it clearer, maybe "label 1000 
maps to VPN 0, 1001 to VPN1 and so forth"

Zzh> Fixed as suggested.

5. "
network.  (Though if tunnel
   segmentation [RFC6514] is used, each segmentation region could have
   its own DCB.  This will be explained in more detail later.)". This separate
   sentence in () is funny, make is a composite sentence or part of previous
   sentence in ()

zzh> I removed it. It's more accurate w/o it.

6. "
However, that is not necessarily as the labels used by PEs
   for the purposes defined in this document will only rise to the top
   of the label stack when traffic arrives the PEs.
"
does not parse as English. this is not necessarily _true_ ? arrives 

Re: [bess] Routing Directorate Last Call Review for draft-ietf-bess-evpn-irb-mcast-07.txt

[Jeffrey (Zhaohui) Zhang]

Hi Acee,

Thanks a lot for your thorough review and comments. I have posted -08 revision 
to address most of your comments: 
https://www.ietf.org/rfcdiff?url2=draft-ietf-bess-evpn-irb-mcast-08.txt.

Please see zzh> below.



Juniper Business Use Only
From: Acee Lindem (acee) 
Sent: Tuesday, November 15, 2022 1:49 PM
To: draft-ietf-bess-evpn-irb-mc...@ietf.org; Routing ADs 
Cc: Routing Directorate ; bess@ietf.org
Subject: Routing Directorate Last Call Review for 
draft-ietf-bess-evpn-irb-mcast-07.txt

[External Email. Be cautious of content]

Hello,

I have been selected as the Routing Directorate reviewer for this draft.
The Routing Directorate seeks to review all routing or routing-related
drafts as they pass through IETF last call and IESG review, and
sometimes on special request. The purpose of the review is to provide
assistance to the Routing ADs. For more information about the Routing
Directorate, please see ​

  http://trac.tools.ietf.org/area/rtg/trac/wiki/RtgDir

Although these comments are primarily for the use of the Routing ADs,
it would be helpful if you could consider them along with any other
IETF Early Review/Last Call  comments that you receive, and strive to
resolve them through discussion or by updating the draft.

Document: draft-ietf-bess-evpn-irb-mcast-07.txt
Reviewer: Acee Lindem
Review Date: Nov 15th, 2022
IETF LC End Date: Nov 7, 2022
Intended Status: Standards Track

Summary: I have some minor concerns about this document that I think should be 
resolved before publication.

Comments:

The draft is readable per se but the subject matter, Optimized Inter-Subnet 
Multicast,
is quite complex. The draft covers the mechanisms and procedures for multicast
advertisement and forwarding between tenant-BDs. Additionally, a single line in 
the
abstract includes procedures to accommodate multicast traffic external to the 
tenant
domain results in very dense specification of various interworking with other 
multicast
domains. These interworking scenarios build on the OISM gateway functionality 
specified
early in the document. The cascaded complexity probably explains the number of 
directorate
members who declined the review request. Given the complexity, this is a 
document that
could really benefit from implementation experience.

Major Issues: None

Minor Issues:

   1. The concept of multicast packets and, in some cases, advertisements being 
sent
  "Up" or "Down" the IRB interface seemed confusing to me. I'd of thought 
the IRB
  interfaces would be described in terms of transmission or reception by 
the IRB
  L3 Routing instance. In any case, the usage must be described in the 
terminology
 section is not intuitive even though one can reverse engineer what is 
meant.

Zzh> An IRB interface connects a bridge domain (L2) to an IP routing instance 
(L3). Therefore, we use the up/down to indicate if traffic is up towards the L3 
or down towards L2. I’ve added the following paragraph in section “1.1.2.  
Inter-BD (Inter-Subnet) IP Traffic” where IRB interface was firs mentioned in 
the document:

   In this document, when traffic is 
routed out of an IRB interface,
   we say it is sent down the IRB 
interface to the BD that the IRB is
   for. In the other direction, traffic 
is sent up the IRB interface
   from the BD to the L3 routing 
instance.


   2. The Section 6 interworking scenarios could benefit from some ASCII art for
   visual reference of the various gateway and domain scenarios.

Zzh> I have added the following figure:



 src1   rcvr1
 |  |
 R1   RPR2

   PIM/MVPN
domain
+---+  +---+
   -|GW1|--|GW2|
+---+  +---+
 | \ \/ / |
 |  \ \  / /  |
   BD1 BD2 SBDSBD BD2 BD1

  EVPN Domain

   SBDSBD
  /  \
 /\
+---+  +---+
|PE1|  |PE2|
+---+  +---+
 | \   / |
BD1 BD2  BD2 BD1
 |   ||  |
src2 rcvr2  src3 rcvr3

   3. Since this is Last Call review, it seems references to topics that may be
  covered in future revisions of the draft should be removed.

Zzh> I fixed two such topics to say “may be 

[bess] IP-VPN without IP/UDP header transportation

[Jeffrey (Zhaohui) Zhang]

[changing subject]

Hi,

After filling in the signaling procedures for 
draft-zzhang-pals-pw-for-ip-udp-payload, we feel that BESS is a better home for 
the draft, so we rehomed it to BESS: 
https://datatracker.ietf.org/doc/draft-zzhang-bess-ipvpn-payload-only/.

Of course, it still benefits discussions in PALS/MPLS WG.

Thanks.
Jeffrey



Juniper Business Use Only
From: Jeffrey (Zhaohui) Zhang
Sent: Wednesday, June 22, 2022 4:30 PM
To: Christian Schmutzer (cschmutz) ; 
mpls-chairs ; p...@ietf.org; bess@ietf.org; SPRING WG 

Cc: 'ke...@arrcus.com' 
Subject: RE: [bess] [Pals] [EXTERNAL] Re: [spring] Martini Pseudowires and SR

Regarding feature gaps, I’d like to point to 
https://datatracker.ietf.org/doc/html/draft-zzhang-pals-pw-for-ip-udp-payload-01
 for a new kind of PW.
I had not got to socialize it in PALS/MPLS WG and will fill in the signaling 
details in the next revision (yes, EVPN-VPWS type of signaling is what I am 
thinking of).
Looks like this is a good email thread to tag on for my topic.

Appreciate your comments.

Thanks.
Jeffrey



Juniper Business Use Only
From: BESS mailto:bess-boun...@ietf.org>> On Behalf Of 
Christian Schmutzer (cschmutz)
Sent: Saturday, June 4, 2022 1:35 AM
To: mpls-chairs mailto:mpls-cha...@ietf.org>>; 
p...@ietf.org<mailto:p...@ietf.org>; bess@ietf.org<mailto:bess@ietf.org>; 
SPRING WG mailto:spr...@ietf.org>>
Subject: Re: [bess] [Pals] [EXTERNAL] Re: [spring] Martini Pseudowires and SR

[External Email. Be cautious of content]



On 01.06.2022, at 09:42, Christian Schmutzer (cschmutz) 
mailto:cschm...@cisco.com>> wrote:

Hi,

After the initial hype for PWE3 in the early 2000s we have seen renewed 
interest in circuit emulation (TDM PWE3) in 2015 as there was (and still is) a 
lot of PDH and SONET/SDH infrastructure out there that operators can’t get rid 
of fast enough while those products go end of life.

We have invested in a modern, complete (SATOP, CESOP and CEP) and high-density 
MPLS/PWE3 implementation and several operators and utilities have deployed our 
solution (based on T-LDP PWE3).

Having said that, many operators raised the question on “why not EVPN-VPWS 
instead of T-LDP?” as they were already looking at EVPN-VPWS for ethernet 
services. As we see continued interest in our circuit emulation offering and 
this EVPN-VPWS question is continuously coming up I believe there is merit in 
addressing TDM pseudowire setup via EVPN-VPWS.

Also more recently we got requests to carry high speed “pipes” such as 10GE, 
100GE, OC192/STM64 and various FibreChannel variants in a transparent manner 
which lead to our PLE data plane proposal documented in 
https://datatracker.ietf.org/doc/html/draft-schmutzer-bess-ple<https://urldefense.com/v3/__https:/datatracker.ietf.org/doc/html/draft-schmutzer-bess-ple__;!!NEt6yMaO-gk!DlYfLfhLreAoyF1YRUnoLvSQMd3DO8AOA4GFDdsQmL4gqY9Q3BySRnQHgGTXedeK_UEpQvd1hOyKvv0AF1V4NR_7RvgObuTe$>.

For PLE (being new) we looked at EVPN-VPWS to start with (instead of T-LDP) and 
also already started a proposal via 
https://datatracker.ietf.org/doc/html/draft-schmutzer-bess-ple-vpws-signalling<https://urldefense.com/v3/__https:/datatracker.ietf.org/doc/html/draft-schmutzer-bess-ple-vpws-signalling__;!!NEt6yMaO-gk!DlYfLfhLreAoyF1YRUnoLvSQMd3DO8AOA4GFDdsQmL4gqY9Q3BySRnQHgGTXedeK_UEpQvd1hOyKvv0AF1V4NR_7Rn59D532$>.
 The proposal is not re-inventing the wheel, rather aligning with the concepts 
defined in T-LDP. We would appreciate community review and input.

I think draft-schmutzer-bess-ple-vpws-signalling can address the “TDM’ish” 
features while another document or updates to RFC8214 could address the other 
(more generic gaps) to RFC8077 and other T-LDP RFCs.

Regards
Christian

On 31.05.2022, at 18:52, Ketan Talaulikar 
mailto:ketant.i...@gmail.com>> wrote:

+ 1 to Sasha and Jorge

The feature gaps to be addressed in BGP EVPN VPWS should be based on operators' 
feedback so we add only those that are relevant.

Thanks,
Ketan


On Tue, May 31, 2022 at 4:59 PM Alexander Vainshtein 
mailto:alexander.vainsht...@rbbn.com>> wrote:
Jorge and all,
Here is a (admittedly incomplete) list of things that, AFAIK, today are not 
supported with EVPN VPWS:

  1.  All the non-Ethernet PW types (28 such types can be found in the IANA 
registry<https://urldefense.com/v3/__https:/www.iana.org/assignments/pwe3-parameters/pwe3-parameters.xhtml*pwe3-parameters-2__;Iw!!NEt6yMaO-gk!DlYfLfhLreAoyF1YRUnoLvSQMd3DO8AOA4GFDdsQmL4gqY9Q3BySRnQHgGTXedeK_UEpQvd1hOyKvv0AF1V4NR_7Rqbfe_ps$>)

 *   Not sure if all these types are relevant for the industry today
 *   AFAIK, TDM and SONET over packet are still widely deployed

  1.  Differentiation between Raw and Tagged Ethernet PW types (not sure it is 
needed, but still)
  2.  All Interface Attributes listed in the IANA registry with the following 
exclusions:

 *   Interface MTU  (EVPN VPWS supports a standard way to ignore it which 
IMHO is one grea

Re: [bess] [Pals] [EXTERNAL] Re: [spring] Martini Pseudowires and SR

[Jeffrey (Zhaohui) Zhang]

Regarding feature gaps, I’d like to point to 
https://datatracker.ietf.org/doc/html/draft-zzhang-pals-pw-for-ip-udp-payload-01
 for a new kind of PW.
I had not got to socialize it in PALS/MPLS WG and will fill in the signaling 
details in the next revision (yes, EVPN-VPWS type of signaling is what I am 
thinking of).
Looks like this is a good email thread to tag on for my topic.

Appreciate your comments.

Thanks.
Jeffrey



Juniper Business Use Only
From: BESS  On Behalf Of Christian Schmutzer (cschmutz)
Sent: Saturday, June 4, 2022 1:35 AM
To: mpls-chairs ; p...@ietf.org; bess@ietf.org; SPRING WG 

Subject: Re: [bess] [Pals] [EXTERNAL] Re: [spring] Martini Pseudowires and SR

[External Email. Be cautious of content]



On 01.06.2022, at 09:42, Christian Schmutzer (cschmutz) 
mailto:cschm...@cisco.com>> wrote:

Hi,

After the initial hype for PWE3 in the early 2000s we have seen renewed 
interest in circuit emulation (TDM PWE3) in 2015 as there was (and still is) a 
lot of PDH and SONET/SDH infrastructure out there that operators can’t get rid 
of fast enough while those products go end of life.

We have invested in a modern, complete (SATOP, CESOP and CEP) and high-density 
MPLS/PWE3 implementation and several operators and utilities have deployed our 
solution (based on T-LDP PWE3).

Having said that, many operators raised the question on “why not EVPN-VPWS 
instead of T-LDP?” as they were already looking at EVPN-VPWS for ethernet 
services. As we see continued interest in our circuit emulation offering and 
this EVPN-VPWS question is continuously coming up I believe there is merit in 
addressing TDM pseudowire setup via EVPN-VPWS.

Also more recently we got requests to carry high speed “pipes” such as 10GE, 
100GE, OC192/STM64 and various FibreChannel variants in a transparent manner 
which lead to our PLE data plane proposal documented in 
https://datatracker.ietf.org/doc/html/draft-schmutzer-bess-ple.

For PLE (being new) we looked at EVPN-VPWS to start with (instead of T-LDP) and 
also already started a proposal via 
https://datatracker.ietf.org/doc/html/draft-schmutzer-bess-ple-vpws-signalling.
 The proposal is not re-inventing the wheel, rather aligning with the concepts 
defined in T-LDP. We would appreciate community review and input.

I think draft-schmutzer-bess-ple-vpws-signalling can address the “TDM’ish” 
features while another document or updates to RFC8214 could address the other 
(more generic gaps) to RFC8077 and other T-LDP RFCs.

Regards
Christian

On 31.05.2022, at 18:52, Ketan Talaulikar 
mailto:ketant.i...@gmail.com>> wrote:

+ 1 to Sasha and Jorge

The feature gaps to be addressed in BGP EVPN VPWS should be based on operators' 
feedback so we add only those that are relevant.

Thanks,
Ketan


On Tue, May 31, 2022 at 4:59 PM Alexander Vainshtein 
mailto:alexander.vainsht...@rbbn.com>> wrote:
Jorge and all,
Here is a (admittedly incomplete) list of things that, AFAIK, today are not 
supported with EVPN VPWS:

  1.  All the non-Ethernet PW types (28 such types can be found in the IANA 
registry)

 *   Not sure if all these types are relevant for the industry today
 *   AFAIK, TDM and SONET over packet are still widely deployed

  1.  Differentiation between Raw and Tagged Ethernet PW types (not sure it is 
needed, but still)
  2.  All Interface Attributes listed in the IANA registry with the following 
exclusions:

 *   Interface MTU  (EVPN VPWS supports a standard way to ignore it which 
IMHO is one great advantage over LDP-based signaling)
 *   Flow Label (support is defined in 7432bis)

  1.  Full-blown PW status signaling
  2.  FCS retention – not sure it is used these days
  3.  PW fragmentation and reassembly - not sure it is used these days.

Regards,
Sasha

Office: +972-39266302
Cell:  +972-549266302
Email:   alexander.vainsht...@rbbn.com

From: Rabadan, Jorge (Nokia - US/Sunnyvale) 
mailto:jorge.raba...@nokia.com>>
Sent: Monday, May 30, 2022 1:02 PM
To: Alexander Vainshtein 
mailto:alexander.vainsht...@rbbn.com>>; Stewart 
Bryant mailto:stewart.bry...@gmail.com>>; Andrew 
Alston - IETF 
mailto:40liquid.t...@dmarc.ietf.org>>;
 mpls-chairs mailto:mpls-cha...@ietf.org>>
Cc: SPRING WG mailto:spr...@ietf.org>>; 
p...@ietf.org; 

Re: [bess] A new draft for MVPN in IPv6-only network.

[Jeffrey (Zhaohui) Zhang]

Fanghong,

Please see zzh4> below.



Juniper Business Use Only
From: duanfanghong 
Sent: Saturday, June 18, 2022 5:06 AM
To: Jeffrey (Zhaohui) Zhang ; bess@ietf.org
Subject: RE: [bess] A new draft for MVPN in IPv6-only network.

[External Email. Be cautious of content]

Hi Jeffrey,

Please see Dfh4> below.

Thanks.
Fanghong


From: Jeffrey (Zhaohui) Zhang [mailto:zzhang=40juniper@dmarc.ietf.org]
Sent: Saturday, June 18, 2022 6:36 AM
To: duanfanghong mailto:duanfangh...@huawei.com>>; 
bess@ietf.org<mailto:bess@ietf.org>
Subject: RE: [bess] A new draft for MVPN in IPv6-only network.

HI Fanghong,

Let me pull up the points up here at the top.


Dfh3>  I think you were making a mistake, RT-constrain is an extra procedure 
and cannot run without obsoleting the propagating-along-reverse-path-of-I-PMSI 
procedure. So, I think the solution you considered is with too many limitation, 
only applicable in some specific cases with distinct RDs of   tuple 
and with obsoleting the propagating-along-reverse-path-of-I-PMSI procedure in 
regular MVPN, and may leave the complication/limitation to deployment.

Regardless of whether RDs are different or not, the solution in 
draft-zzhang-bess-mvpn-evpn-cmcast-enhancements  (draft-zzhang) works for 
“non-segmented provider tunnel in IPv6-only network”.
Dfh4>  I don’t think so. If two ingress PEs are with a same RD, Leaf PEs are 
difficult to perform SFS even if [ADD-PTAH] is enabled on RRs as described in 
RFC7716, resulting in which two Leaf PEs selecting different ingress PE send 
C-multicast routes carrying different RT extended community (The global 
administrator fields are with different originator IP addresses of 
corresponding ingress PE) but with a same NLRI key because you set the “Source 
AS” filed to 0 in that document, causing that only one route is selected on RRs 
/ ASBRs and the other one cannot be targeted to the corresponding ingress PE.
Dfh4>  If the RDs are different, your solution is less optimal as you described 
in that document if RT-constrain is not available.

Zzh4> As you said, “Dfh3> So, This is the reason why I consider two ingress PE 
with a same RD is a different scenarios”.
Zzh4> This is a summary of all issues that have been talked about:

1.  SFS when same RD (zero or not) are used. This is before C-multicast 
route is generated

2.  Distinguishing C-multicast routes intended for different ingress PEs 
when same RD is used (e.g. for live-live protection)

3.  Propagate C-multicast route when non-segmented tunnels are used for IPv6
Zzh4> Your draft has solutions for #2 and #3 but I don’t see you have a 
solution for #1 (my draft does not address #1 either, though I have some ideas 
for it).
Zzh4> Whether it is GTM (RFC7716) or real VPN, when you have same RDs on 
some/all PEs, #1 and #2 exist regardless of IPv6, intra/inter-as or whether 
propagating-along-reverse-path-of-I-PMSI is used or not. Even in your draft, 
solutions for #2 and #3 are different and for different problems.
Zzh4> The root-cause of the #3 “non-segmented tunnel in ipv6” issue that the 
source AS field is not large enough to carry the IPv6 address of the ingress 
PE. Using the Ingress PE’s IP address in a RT attached to the route is a 
solution with its drawbacks (I’ll talk about the drawbacks separately since we 
now need to clear out some tangled issues). It alone does not address #1 or #2. 
My “using rt-constrain” solution also only address the same problem of “source 
as field not large enough to carry IPv6 address”. When I said “Regardless of 
whether RDs are different or not, the solution in 
draft-zzhang-bess-mvpn-evpn-cmcast-enhancements  (draft-zzhang) works” is only 
for issue #3.
Zzh4> Your solution for #2 will not work for segmented tunnel case if I 
understand it correctly, because the ASBRs needed to use the source as field so 
you can’t put the generated distinguishing number there.

RT-constrain is a well-deployed feature. The 
propagating-along-reverse-path-of-I-PMSI procedures does not need to be 
“obsoleted” (or a better way to say is that existing code will work with 
RT-constrain for “non-segmented tunnels in IPv6 provider network”).
Simply put, non-segmented tunnels in IPv6 provider network” works once you use 
RT-constrain. No new code is needed.
Dfh4>  I don’t think so. The code of C-multicast propagating control in ASBRs 
must also be modified to do not check the existence of Intra-AS AD if “Source 
AS” filed is zero according to your solution, otherwise the procedure of your 
solution cannot run even if RT-constrain is available, because RT-constrain is 
an extra procedure and before it takes part the routes must complete 
corresponding processing of MVPN process in which your zero “Source AS” 
C-multicast routes are processed as invalid routes in regular MVPN because no 
corresponding Intra-AS AD is found.
Zzh4> I would say that rt-constrain procedures are the more basic/gene

Re: [bess] A new draft for MVPN in IPv6-only network.

[Jeffrey (Zhaohui) Zhang]

HI Fanghong,

Let me pull up the points up here at the top.


Dfh3>  I think you were making a mistake, RT-constrain is an extra procedure 
and cannot run without obsoleting the propagating-along-reverse-path-of-I-PMSI 
procedure. So, I think the solution you considered is with too many limitation, 
only applicable in some specific cases with distinct RDs of   tuple 
and with obsoleting the propagating-along-reverse-path-of-I-PMSI procedure in 
regular MVPN, and may leave the complication/limitation to deployment.

Regardless of whether RDs are different or not, the solution in 
draft-zzhang-bess-mvpn-evpn-cmcast-enhancements  (draft-zzhang) works for 
“non-segmented provider tunnel in IPv6-only network”.

RT-constrain is a well-deployed feature. The 
propagating-along-reverse-path-of-I-PMSI procedures does not need to be 
“obsoleted” (or a better way to say is that existing code will work with 
RT-constrain for “non-segmented tunnels in IPv6 provider network”).

Simply put, non-segmented tunnels in IPv6 provider network” works once you use 
RT-constrain. No new code is needed.


Dfh3> So, This is the reason why I consider two ingress PE with a same RD is a 
different scenarios, especially in some real deployment cases, same RD may be 
needed and important… Our solution is aiming at those cases and helps providing 
a reliable Single Forward Selection.

Indeed, the RD discussion is for a different issue that is not IPv6 specific. I 
had acknowledged that very early in this email thread.
However, the following solution in your draft does *not* provide “a reliable 
Single Forward Selection”:

   3.  If the Originating Router's IP Address field of the found Intra-
   AS I-PMSI A-D route is an IPv6 address and the root PE and leaf
   PE are in the different ASs, a four bytes distinct value MUST be
   assigned by leaf PE for each root PE, the Root Distinguisher
   field in C-Multicast NLRI is filled with this value and a
   distinct C-multicast route will be send to individual upstream
   root PE.

The only way to provide “a reliable Single Forward Selection” is for the UMH 
routes to carry distinct RDs.
I assume that the above is intended to address the following:


   In [RFC7716<https://datatracker.ietf.org/doc/html/rfc7716>], zero RD is 
introduced in BGP MVPN NLRIs to enable

   Global Table Multicast service in provider's networks.  In IPv6

   infrastructure networks, Leaf PEs cannot send two distinct

   C-multicast route to two individual upstream root PEs for selctive

   forwarding, because the RD of the two roots is the same.

However, it has the following issues:


1.   The problem you wanted to address is not specific to IPv6 or Inter-AS 
or tunnel segmentation, yet the proposal above is IPv6 specific.

2.   The above solution, even after made IPv6-agnostic, does not work for 
inter-AS segmentation if we still depend on 
propagating-along-the-reverse-path-of-I-PMSI.

3.   Just that each egress PE generates distinct values for different 
ingress PEs is not enough. Say egress PE3 generate 100/200 for ingress PE1/2 
respectively, but egress PE4 generates 200/300 for ingress PE1/2 respectively, 
then PE3’s c-multicast route for PE2 and PE4’s c-multicast route for PE1 would 
get mixed up.

While the third issue can be easily solved, once the distinct value is 
generated, it does not need to go into the “source-as” field. It can simply be 
put into the RD field. The RD field is really just an opaque field when 
propagating-along-the-reverse-path-of-I-PMSI is not used.

When consider all the factors, here are my observations:


a.   We could really move away from 
propagating-along-the-reverse-path-of-I-PMSI and just rely on rt-constrain. 
That will work for “non-segmented tunnels in IPv6” as well.

b.   Regardless whether propagating-along-the-reverse-path-of-I-PMSI is 
used, it is best to tie the RD to the ingress PEs if you need to target 
redundant c-multicast routes to different ingress PEs. There are ways to do 
that even for GTM.

Thanks.
Jeffrey



Juniper Business Use Only
From: duanfanghong 
Sent: Thursday, June 16, 2022 8:50 AM
To: Jeffrey (Zhaohui) Zhang ; bess@ietf.org
Subject: RE: [bess] A new draft for MVPN in IPv6-only network.

[External Email. Be cautious of content]

Hi Jeffrey,

Please see Dfh3> below.

Thanks.
Fanghong

From: Jeffrey (Zhaohui) Zhang [mailto:zzhang=40juniper@dmarc.ietf.org]
Sent: Thursday, June 16, 2022 10:17 AM
To: duanfanghong mailto:duanfangh...@huawei.com>>; 
bess@ietf.org<mailto:bess@ietf.org>
Cc: Xiejingrong (Jingrong) 
mailto:xiejingr...@huawei.com>>; Gengxuesong (Geng 
Xuesong) mailto:gengxues...@huawei.com>>; Wangheng 
(MCAST, P) mailto:wanghen...@huawei.com>>
Subject: RE: [bess] A new draft for MVPN in IPv6-only network.

Hi Fanghong,

Please see zzh3> below.



Juniper Business Use Only
From: duanfanghong 
mailto:duanfanghong=40huawei@dmarc.ietf.org>&

Re: [bess] A new draft for MVPN in IPv6-only network.

[Jeffrey (Zhaohui) Zhang]

Hi Fanghong,

Please see zzh3> below.



Juniper Business Use Only
From: duanfanghong 
Sent: Wednesday, June 15, 2022 3:36 AM
To: Jeffrey (Zhaohui) Zhang ; bess@ietf.org
Cc: Xiejingrong (Jingrong) ; Gengxuesong (Geng Xuesong) 
; Wangheng (MCAST, P) 
Subject: RE: [bess] A new draft for MVPN in IPv6-only network.

[External Email. Be cautious of content]

Hi Jeffrey,

Please see Dfh2> below.

Thanks.
Fanghong

From: Jeffrey (Zhaohui) Zhang [mailto:zzhang=40juniper@dmarc.ietf.org]
Sent: Wednesday, June 15, 2022 11:41 AM
To: duanfanghong mailto:duanfangh...@huawei.com>>; 
bess@ietf.org<mailto:bess@ietf.org>
Cc: Xiejingrong (Jingrong) 
mailto:xiejingr...@huawei.com>>; Gengxuesong (Geng 
Xuesong) mailto:gengxues...@huawei.com>>; Wangheng 
(MCAST, P) mailto:wanghen...@huawei.com>>
Subject: RE: [bess] A new draft for MVPN in IPv6-only network.

Hi Fanghong,

Please see zzh2> below.



Juniper Business Use Only
From: duanfanghong 
mailto:duanfanghong=40huawei@dmarc.ietf.org>>
Sent: Sunday, June 5, 2022 10:55 PM
To: Jeffrey (Zhaohui) Zhang mailto:zzh...@juniper.net>>; 
bess@ietf.org<mailto:bess@ietf.org>
Cc: Xiejingrong (Jingrong) 
mailto:xiejingr...@huawei.com>>; Gengxuesong (Geng 
Xuesong) mailto:gengxues...@huawei.com>>; Wangheng 
(MCAST, P) mailto:wanghen...@huawei.com>>
Subject: RE: [bess] A new draft for MVPN in IPv6-only network.

[External Email. Be cautious of content]

Hi Jeffrey,

Please see Dfh> below.

Thanks.
Fanghong

From: Jeffrey (Zhaohui) Zhang [mailto:zzhang=40juniper@dmarc.ietf.org]
Sent: Friday, June 3, 2022 4:06 AM
To: duanfanghong mailto:duanfangh...@huawei.com>>; 
bess@ietf.org<mailto:bess@ietf.org>
Cc: Xiejingrong (Jingrong) 
mailto:xiejingr...@huawei.com>>; Gengxuesong (Geng 
Xuesong) mailto:gengxues...@huawei.com>>; Wangheng 
(MCAST, P) mailto:wanghen...@huawei.com>>
Subject: RE: [bess] A new draft for MVPN in IPv6-only network.

Hi Fanghong,

Please see zzh> below.



Juniper Business Use Only
From: duanfanghong 
mailto:duanfanghong=40huawei@dmarc.ietf.org>>
Sent: Thursday, June 2, 2022 6:50 AM
To: Jeffrey (Zhaohui) Zhang mailto:zzh...@juniper.net>>; 
bess@ietf.org<mailto:bess@ietf.org>
Cc: Xiejingrong (Jingrong) 
mailto:xiejingr...@huawei.com>>; Gengxuesong (Geng 
Xuesong) mailto:gengxues...@huawei.com>>; Wangheng 
(MCAST, P) mailto:wanghen...@huawei.com>>
Subject: RE: [bess] A new draft for MVPN in IPv6-only network.

[External Email. Be cautious of content]

Hi Jeffrey,

In the draft I published, we focus on the problems and solutions of MVPN in 
IPv6-only infrastructure and dual-stack infrastructure. Although the 
"source-as" field length problem overlaps with the one mentioned in your draft, 
I think it does not prevent moving our draft forward.

1．In our draft, we introduce a solution to do precise control of 
C-multicast routes propagation between ASBRs, not a less optimal one (In your 
draft, it is mentioned that the solution for this problem is less optimal) than 
regular solution in RFC6514.

Zzh> It mentioned “less optimal” only in the context of not using RT Constrain 
(RFC 4684). If RFC 4684 procedure is used, then there is no issue at all.
Dfh> Yes, if RT Constrain (RFC 4684) is used, both solutions can reach the same 
level of propagation control.
Zzh> The procedure of propagating C-multicast routes in the reverse path of 
I-PMSI routes is complicated. We can get away with not using it at all.
Dfh> In some real deployment, operators may not select RT Constrain as a 
mandatory option. In that case, a precise control is needed.


2．To configure distinct RDs for each ingress PEs, it is not applicable for 
some real deployment scenario because of some provision reason. It does exist 
this problem even in IPv4 infrastructure and become more critical in IPv6 
infrastructure because of above "source-as" field length problem.

Our solution does not try to solve all the problems of ADD-PATH, but it is 
effective for most scenarios when the ingress PEs carries the same RD.



Zzh> Is it that 0:0 RD issue is independent of IPv6 and “source-as” field 
length issue, and the latter already has a (better, simpler and more general) 
solution?

Dfh> The issue for 0:0 RD or two ingress PE with a same RD is not a specific 
problem for IPv6 infrastructure, it seems more crucial than IPv4 together with 
the issue  of “source-as” field length. I’m writing a better solution (without 
enabling ADD-PATH on RRs or carrying different RDs in UMH routes) to update 
another draft 
“https://www.ietf.org/archive/id/draft-wang-bess-mvpn-upstream-df-selection-00.txt<https://urldefense.com/v3/__https:/www.ietf.org/archive/id/draft-wang-bess-mvpn-upstream-df-selection-00.txt__;!!NEt6yMaO-gk!E0cAwbF2FJZ4JBNFtUmdWW8losqIPKA6JoEjREF7yrPtn6CnEcKs788GchHxAQy4znjVDKqH3VvwxKqP5WBFjAsTT6ZM7LJg$&

Re: [bess] A new draft for MVPN in IPv6-only network.

[Jeffrey (Zhaohui) Zhang]

Hi Fanghong,

Please see zzh2> below.



Juniper Business Use Only
From: duanfanghong 
Sent: Sunday, June 5, 2022 10:55 PM
To: Jeffrey (Zhaohui) Zhang ; bess@ietf.org
Cc: Xiejingrong (Jingrong) ; Gengxuesong (Geng Xuesong) 
; Wangheng (MCAST, P) 
Subject: RE: [bess] A new draft for MVPN in IPv6-only network.

[External Email. Be cautious of content]

Hi Jeffrey,

Please see Dfh> below.

Thanks.
Fanghong

From: Jeffrey (Zhaohui) Zhang [mailto:zzhang=40juniper@dmarc.ietf.org]
Sent: Friday, June 3, 2022 4:06 AM
To: duanfanghong mailto:duanfangh...@huawei.com>>; 
bess@ietf.org<mailto:bess@ietf.org>
Cc: Xiejingrong (Jingrong) 
mailto:xiejingr...@huawei.com>>; Gengxuesong (Geng 
Xuesong) mailto:gengxues...@huawei.com>>; Wangheng 
(MCAST, P) mailto:wanghen...@huawei.com>>
Subject: RE: [bess] A new draft for MVPN in IPv6-only network.

Hi Fanghong,

Please see zzh> below.



Juniper Business Use Only
From: duanfanghong 
mailto:duanfanghong=40huawei@dmarc.ietf.org>>
Sent: Thursday, June 2, 2022 6:50 AM
To: Jeffrey (Zhaohui) Zhang mailto:zzh...@juniper.net>>; 
bess@ietf.org<mailto:bess@ietf.org>
Cc: Xiejingrong (Jingrong) 
mailto:xiejingr...@huawei.com>>; Gengxuesong (Geng 
Xuesong) mailto:gengxues...@huawei.com>>; Wangheng 
(MCAST, P) mailto:wanghen...@huawei.com>>
Subject: RE: [bess] A new draft for MVPN in IPv6-only network.

[External Email. Be cautious of content]

Hi Jeffrey,

In the draft I published, we focus on the problems and solutions of MVPN in 
IPv6-only infrastructure and dual-stack infrastructure. Although the 
"source-as" field length problem overlaps with the one mentioned in your draft, 
I think it does not prevent moving our draft forward.

1．  In our draft, we introduce a solution to do precise control of C-multicast 
routes propagation between ASBRs, not a less optimal one (In your draft, it is 
mentioned that the solution for this problem is less optimal) than regular 
solution in RFC6514.

Zzh> It mentioned “less optimal” only in the context of not using RT Constrain 
(RFC 4684). If RFC 4684 procedure is used, then there is no issue at all.
Dfh> Yes, if RT Constrain (RFC 4684) is used, both solutions can reach the same 
level of propagation control.
Zzh> The procedure of propagating C-multicast routes in the reverse path of 
I-PMSI routes is complicated. We can get away with not using it at all.
Dfh> In some real deployment, operators may not select RT Constrain as a 
mandatory option. In that case, a precise control is needed.


2．  To configure distinct RDs for each ingress PEs, it is not applicable for 
some real deployment scenario because of some provision reason. It does exist 
this problem even in IPv4 infrastructure and become more critical in IPv6 
infrastructure because of above "source-as" field length problem.

Our solution does not try to solve all the problems of ADD-PATH, but it is 
effective for most scenarios when the ingress PEs carries the same RD.



Zzh> Is it that 0:0 RD issue is independent of IPv6 and “source-as” field 
length issue, and the latter already has a (better, simpler and more general) 
solution?

Dfh> The issue for 0:0 RD or two ingress PE with a same RD is not a specific 
problem for IPv6 infrastructure, it seems more crucial than IPv4 together with 
the issue  of “source-as” field length. I’m writing a better solution (without 
enabling ADD-PATH on RRs or carrying different RDs in UMH routes) to update 
another draft 
“https://www.ietf.org/archive/id/draft-wang-bess-mvpn-upstream-df-selection-00.txt”,
 which a new version will be published before IETF 114.

zzh> BTW, I think you missed mentioning that now the C-multicast routes need 
carry an “IPv6 VRF Route Import Extended Community” that is copied from the UMH 
route, in addition to RTs (one of which matches but is not the same as the 
“IPv6 VRF Route Import Extended Community”).

Dfh> I think only one “IPv6 VRF Route Import Extended Community” is needed. In 
our solution, Leaf PEs sent distinct C-multicast routes for each ingress PE, 
each C-multicast route carried a “IPv6 VRF Route Import Extended Community” 
copied from the UMH route sent by the corresponding ingress PE. This procedure 
is using what described in RFC 6515 & RFC 6514, so we did not emphasize it.

Zzh2> C-multicast routes don’t just copy “VRF Route Import Extended Community” 
from the UH route. It uses that to construct a RT Extended Community - the two 
are different.

Zzh2> More importantly, there is just no advantage of using the 
flawed/complicated procedure (of following reverse path of I-PMSI or (*,*) 
S-PMSI route), when the RT-constrain based propagation works well (and that 
should be widely deployed).


3.In addition, we also mentioned the IPv4 to IPv6 migration problems, and 
listed some suggestions to control the explosion of MVPN route’s PATHs.

Zzh> Is this an information/BCP ki

Re: [bess] A new draft for MVPN in IPv6-only network.

[Jeffrey (Zhaohui) Zhang]

Hi Fanghong,

Please see zzh> below.



Juniper Business Use Only
From: duanfanghong 
Sent: Thursday, June 2, 2022 6:50 AM
To: Jeffrey (Zhaohui) Zhang ; bess@ietf.org
Cc: Xiejingrong (Jingrong) ; Gengxuesong (Geng Xuesong) 
; Wangheng (MCAST, P) 
Subject: RE: [bess] A new draft for MVPN in IPv6-only network.

[External Email. Be cautious of content]

Hi Jeffrey,

In the draft I published, we focus on the problems and solutions of MVPN in 
IPv6-only infrastructure and dual-stack infrastructure. Although the 
"source-as" field length problem overlaps with the one mentioned in your draft, 
I think it does not prevent moving our draft forward.

1．In our draft, we introduce a solution to do precise control of 
C-multicast routes propagation between ASBRs, not a less optimal one (In your 
draft, it is mentioned that the solution for this problem is less optimal) than 
regular solution in RFC6514.

Zzh> It mentioned “less optimal” only in the context of not using RT Constrain 
(RFC 4684). If RFC 4684 procedure is used, then there is no issue at all.
Zzh> The procedure of propagating C-multicast routes in the reverse path of 
I-PMSI routes is complicated. We can get away with not using it at all.


2．To configure distinct RDs for each ingress PEs, it is not applicable for 
some real deployment scenario because of some provision reason. It does exist 
this problem even in IPv4 infrastructure and become more critical in IPv6 
infrastructure because of above "source-as" field length problem.

Our solution does not try to solve all the problems of ADD-PATH, but it is 
effective for most scenarios when the ingress PEs carries the same RD.



Zzh> Is it that 0:0 RD issue is independent of IPv6 and “source-as” field 
length issue, and the latter already has a (better, simpler and more general) 
solution?

zzh> BTW, I think you missed mentioning that now the C-multicast routes need 
carry an “IPv6 VRF Route Import Extended Community” that is copied from the UMH 
route, in addition to RTs (one of which matches but is not the same as the 
“IPv6 VRF Route Import Extended Community”).


3.In addition, we also mentioned the IPv4 to IPv6 migration problems, and 
listed some suggestions to control the explosion of MVPN route’s PATHs.

Zzh> Is this an information/BCP kind of document?
Zzh> BTW, is it ok to for a RR to just reflect routes received on v4 sessions 
to other v4 sessions, and reflect routes received on v6 sessions to other v6 
sessions?
Zzh> Jeffrey

Thanks.
Fanghong.
From: Jeffrey (Zhaohui) Zhang [mailto:zzhang=40juniper@dmarc.ietf.org]
Sent: Tuesday, May 31, 2022 11:57 PM
To: duanfanghong mailto:duanfangh...@huawei.com>>; 
bess@ietf.org<mailto:bess@ietf.org>
Cc: Xiejingrong (Jingrong) 
mailto:xiejingr...@huawei.com>>; Gengxuesong (Geng 
Xuesong) mailto:gengxues...@huawei.com>>; Wangheng 
(MCAST, P) mailto:wanghen...@huawei.com>>
Subject: RE: [bess] A new draft for MVPN in IPv6-only network.

Hi Fanghong,

My understanding of the main problem that is pointed out in your draft is that 
the “source-as” field cannot hold an IPv6 address that is required for 
non-segmented tunnels in case of IPv6 infrastructure.
The draft I referred to also pointed out that problem, and gave a solution 
(that also has other benefits) that obsoletes the requirement of encoding that 
IPv6 address.

That’s why I think the (main) problem in your draft is already (better) 
addressed.

Upon further reading of your draft, I realized you also talked about another 
problem:


   In 
[RFC7716<https://urldefense.com/v3/__https:/datatracker.ietf.org/doc/html/rfc7716__;!!NEt6yMaO-gk!CRxUJ5O7pnF1DFfZilrqRplvWUQ4cTP-OWfCGpmEJ_Ra41xbWykb_9Wk5Ccw98vCC_KCVJqqZea37vSGBHoG1qLOkPgHB1MG$>],
 zero RD is introduced in BGP MVPN NLRIs to enable

   Global Table Multicast service in provider's networks.  In IPv6

   infrastructure networks, Leaf PEs cannot send two distinct

   C-multicast route to two individual upstream root PEs for selctive

   forwarding, because the RD of the two roots is the same.

That does not seem to be specific to IP6 though - we have the same problem with 
IPv4, and that’s why RFC 7716 has “2.3.4.  Why SFS Does Not Apply to GTM”.
The simple solution to that problem is not using SFS, and if it is desired to 
target c-multicast routes to different upstream PEs (e.g. for live-live 
redundance), we could enhance the 7716 procedures to allow non-zero RDs even 
for GTM. That does not need to change the c-mcast format (as RD is supposed to 
be treated as opaque info).

You mentioned problem with ADD-PATH. Not sure if why ADD-PATH came into the 
picture at all. RFC 7716 mentioned ADD-PATH but it is meant to say that even 
ADD-PATH would not solve the SFS problem.

Thanks.
Jeffrey



Juniper Business Use Only
From: duanfanghong 
mailto:duanfanghong=40huawei@dmarc.ietf.org>>
Sent: Monday, May 30, 2022 2:32 AM
To: Jeffrey (Zhaohui) Z

Re: [bess] WGLC, IPR and implementation poll for draft-ietf-bess-evpn-redundant-mcast-source

[Jeffrey (Zhaohui) Zhang]

Hi,

I recently became aware of a related IPR that Juniper's Legal team is preparing 
for disclosure.
It should be filed soon.

Thanks.
Jeffrey



Juniper Business Use Only
From: slitkows.i...@gmail.com 
Sent: Wednesday, May 18, 2022 3:23 AM
To: draft-ietf-bess-evpn-redundant-mcast-sou...@ietf.org; bess@ietf.org
Cc: bess-cha...@ietf.org
Subject: WGLC, IPR and implementation poll for 
draft-ietf-bess-evpn-redundant-mcast-source

[External Email. Be cautious of content]


Hello WG,







This email starts a two weeks Working Group Last Call on 
draft-ietf-bess-evpn-redundant-mcast-source

 [1].







This poll runs until * the 1th of June *.







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. The Document won't progress without answers from

all the Authors and Contributors.



There is currently no IPR disclosed.







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.







We are also polling for any existing implementation as per [2].







Thank you,



Stephane & Matthew







[1]

https://datatracker.ietf.org/doc/draft-ietf-bess-evpn-redundant-mcast-source/



[2]



https://mailarchive.ietf.org/arch/msg/bess/cG3X1tTqb_vPC4rg56SEdkjqDpw

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

Re: [bess] A new draft for MVPN in IPv6-only network.

[Jeffrey (Zhaohui) Zhang]

Hi Fanghong,

My understanding of the main problem that is pointed out in your draft is that 
the "source-as" field cannot hold an IPv6 address that is required for 
non-segmented tunnels in case of IPv6 infrastructure.
The draft I referred to also pointed out that problem, and gave a solution 
(that also has other benefits) that obsoletes the requirement of encoding that 
IPv6 address.

That's why I think the (main) problem in your draft is already (better) 
addressed.

Upon further reading of your draft, I realized you also talked about another 
problem:


   In [RFC7716<https://datatracker.ietf.org/doc/html/rfc7716>], zero RD is 
introduced in BGP MVPN NLRIs to enable

   Global Table Multicast service in provider's networks.  In IPv6

   infrastructure networks, Leaf PEs cannot send two distinct

   C-multicast route to two individual upstream root PEs for selctive

   forwarding, because the RD of the two roots is the same.

That does not seem to be specific to IP6 though - we have the same problem with 
IPv4, and that's why RFC 7716 has "2.3.4.  Why SFS Does Not Apply to GTM".
The simple solution to that problem is not using SFS, and if it is desired to 
target c-multicast routes to different upstream PEs (e.g. for live-live 
redundance), we could enhance the 7716 procedures to allow non-zero RDs even 
for GTM. That does not need to change the c-mcast format (as RD is supposed to 
be treated as opaque info).

You mentioned problem with ADD-PATH. Not sure if why ADD-PATH came into the 
picture at all. RFC 7716 mentioned ADD-PATH but it is meant to say that even 
ADD-PATH would not solve the SFS problem.

Thanks.
Jeffrey



Juniper Business Use Only
From: duanfanghong 
Sent: Monday, May 30, 2022 2:32 AM
To: Jeffrey (Zhaohui) Zhang ; bess@ietf.org
Cc: Xiejingrong (Jingrong) ; Gengxuesong (Geng Xuesong) 
; Wangheng (MCAST, P) 
Subject: RE: [bess] A new draft for MVPN in IPv6-only network.

[External Email. Be cautious of content]

Hi Jeffrey,

I have read your draft carefully, as you mentioned in this draft, it is a less 
optimal solution for PE to PE C-Multicast signaling.

In the draft I just published, we describe IPv6-only infrastructure and 
dual-stack infrastructure issues and solutions for regular option B scenario in 
RFC 6514. So, both the scenario and solution are different from the one you 
published.

Thanks.
Fanghong.

From: Jeffrey (Zhaohui) Zhang [mailto:zzhang=40juniper@dmarc.ietf.org]
Sent: Thursday, May 26, 2022 10:23 PM
To: duanfanghong mailto:duanfangh...@huawei.com>>; 
bess@ietf.org<mailto:bess@ietf.org>
Cc: Xiejingrong (Jingrong) 
mailto:xiejingr...@huawei.com>>; Gengxuesong (Geng 
Xuesong) mailto:gengxues...@huawei.com>>; Wangheng 
(MCAST, P) mailto:wanghen...@huawei.com>>
Subject: RE: [bess] A new draft for MVPN in IPv6-only network.

Hi Fanghong,

It seems that 
https://datatracker.ietf.org/doc/html/draft-zzhang-bess-mvpn-evpn-cmcast-enhancements-01#section-1.3<https://urldefense.com/v3/__https:/datatracker.ietf.org/doc/html/draft-zzhang-bess-mvpn-evpn-cmcast-enhancements-01*section-1.3__;Iw!!NEt6yMaO-gk!An361zOjmlWoNMSf73DSUaS8_rgACyWhpJqXDXIsOskU1Mu_2aAJvWLQcqzYMgIYjZ0i9ZWt3JEeKLEWNckNoq6_VOuxU5Iz$>
 talked about the problems and a more general solution.

That draft also has other enhancements considerations. It has stalled but looks 
like we should get it going.

Thanks.
Jeffrey



Juniper Business Use Only
From: BESS mailto:bess-boun...@ietf.org>> On Behalf Of 
duanfanghong
Sent: Tuesday, May 24, 2022 8:24 AM
To: bess@ietf.org<mailto:bess@ietf.org>
Cc: Xiejingrong (Jingrong) 
mailto:xiejingr...@huawei.com>>; Gengxuesong (Geng 
Xuesong) mailto:gengxues...@huawei.com>>; Wangheng 
(MCAST, P) mailto:wanghen...@huawei.com>>
Subject: [bess] A new draft for MVPN in IPv6-only network.

[External Email. Be cautious of content]

Hi All,

  MVPN(RFC 6513/RFC 6514/RFC 6515) faces some problems in IPv6-only networks, 
especially in the non-segmented inter-AS scenario and IPv4 to IPv6 migration 
scenario.
  We have published a new draft 
https://datatracker.ietf.org/doc/draft-duan-bess-mvpn-ipv6-infras/<https://urldefense.com/v3/__https:/datatracker.ietf.org/doc/draft-duan-bess-mvpn-ipv6-infras/__;!!NEt6yMaO-gk!An361zOjmlWoNMSf73DSUaS8_rgACyWhpJqXDXIsOskU1Mu_2aAJvWLQcqzYMgIYjZ0i9ZWt3JEeKLEWNckNoq6_VHqmJjHC$>,
 aiming to solve these problems.

  Please provide your valuable comments and help evolving it further.

  Thanks.

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

Re: [bess] A new draft for MVPN in IPv6-only network.

[Jeffrey (Zhaohui) Zhang]

Hi Fanghong,

It seems that 
https://datatracker.ietf.org/doc/html/draft-zzhang-bess-mvpn-evpn-cmcast-enhancements-01#section-1.3
 talked about the problems and a more general solution.

That draft also has other enhancements considerations. It has stalled but looks 
like we should get it going.

Thanks.
Jeffrey



Juniper Business Use Only
From: BESS  On Behalf Of duanfanghong
Sent: Tuesday, May 24, 2022 8:24 AM
To: bess@ietf.org
Cc: Xiejingrong (Jingrong) ; Gengxuesong (Geng Xuesong) 
; Wangheng (MCAST, P) 
Subject: [bess] A new draft for MVPN in IPv6-only network.

[External Email. Be cautious of content]

Hi All,

  MVPN(RFC 6513/RFC 6514/RFC 6515) faces some problems in IPv6-only networks, 
especially in the non-segmented inter-AS scenario and IPv4 to IPv6 migration 
scenario.
  We have published a new draft 
https://datatracker.ietf.org/doc/draft-duan-bess-mvpn-ipv6-infras/, aiming to 
solve these problems.

  Please provide your valuable comments and help evolving it further.

  Thanks.

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

Re: [bess] [Idr] draft-hb-idr-sr-p2mp-policy (3/10 to 3/24/2022) - Adoption call

[Jeffrey (Zhaohui) Zhang]

Hi Gyan,

Gyan2> What is the advantage of using TEA encoding as opposed to existing PTA 
RFC 6513 & RFC 6514 MVPN signaling?

This is about using procedures in draft-ietf-bess-bgp-multicast-controller to 
set up (s,g) forwarding state in a VRF, as an alternative to BGP-MVPN.

As described in 
https://datatracker.ietf.org/doc/html/draft-ietf-bess-bgp-multicast-controller-09#section-2,
 instead of ingress/egress PE figuring out the (s,g) state based on BGP-MVPN 
signaling and PIM signaling (for local OIFs to CEs), they simply take 
instructions from a control on what tunnel branches and which local OIFs to use 
– as if an operator is configuring them statically. This allows the PEs to be 
very dumb and simple.

From that point of view, there is no difference between “underlay” and 
“overlay” and the TEA is perfect to encode that information – each “tunnel” in 
the TEA is a replication branch.

That section does have the following that makes use of the PTA (attached to 
MCAST-TREE NLRIs for programing VRF (s,g) forwarding state):

   The Replication State route may also have a PMSI Tunnel Attribute
   (PTA) attached to specify the provider tunnel while the TEA specifies
   the local PE-CE interfaces where traffic need to be sent out.  This
   not only allows provider tunnel without a binding SID (e.g., in a
   non-SR network) to be specified without explicitly listing its
   replication branches, but also allows the service controller for MVPN
   overlay state to be independent of provider tunnel setup (which could
   be from a different transport controller or even without a
   controller).

Jeffrey



Juniper Business Use Only
From: Gyan Mishra 
Sent: Thursday, April 28, 2022 12:19 AM
To: Jeffrey (Zhaohui) Zhang 
Cc: BESS ; Bidgoli, Hooman (Nokia - CA/Ottawa) 
; Susan Hares ; i...@ietf.org; 
p...@ietf.org
Subject: Re: [bess] [Idr] draft-hb-idr-sr-p2mp-policy (3/10 to 3/24/2022) - 
Adoption call

[External Email. Be cautious of content]


Hi Jeffrey

Please see Gyan2>

On Tue, Apr 12, 2022 at 11:02 AM Jeffrey (Zhaohui) Zhang 
mailto:zzh...@juniper.net>> wrote:
Hi Gyan,

Please see zzh2> below.



Juniper Business Use Only
From: Gyan Mishra mailto:hayabusa...@gmail.com>>
Sent: Friday, April 8, 2022 8:48 PM
To: Jeffrey (Zhaohui) Zhang mailto:zzh...@juniper.net>>
Cc: BESS mailto:bess@ietf.org>>; Bidgoli, Hooman (Nokia - 
CA/Ottawa) mailto:hooman.bidg...@nokia.com>>; Susan 
Hares mailto:sha...@ndzh.com>>; 
i...@ietf.org<mailto:i...@ietf.org>; p...@ietf.org<mailto:p...@ietf.org>
Subject: Re: [bess] [Idr] draft-hb-idr-sr-p2mp-policy (3/10 to 3/24/2022) - 
Adoption call

[External Email. Be cautious of content]


Hi Jeffrey

Please see Gyan>


On Tue, Apr 5, 2022 at 7:38 PM Jeffrey (Zhaohui) Zhang 
mailto:zzh...@juniper.net>> wrote:
Hi Gyan,

Please see zzh> below for my view.



Juniper Business Use Only
From: Gyan Mishra mailto:hayabusa...@gmail.com>>
Sent: Tuesday, March 29, 2022 10:31 AM
To: Jeffrey (Zhaohui) Zhang mailto:zzh...@juniper.net>>
Cc: BESS mailto:bess@ietf.org>>; Bidgoli, Hooman (Nokia - 
CA/Ottawa) mailto:hooman.bidg...@nokia.com>>; Susan 
Hares mailto:sha...@ndzh.com>>; 
i...@ietf.org<mailto:i...@ietf.org>; p...@ietf.org<mailto:p...@ietf.org>
Subject: Re: [bess] [Idr] draft-hb-idr-sr-p2mp-policy (3/10 to 3/24/2022) - 
Adoption call

[External Email. Be cautious of content]


Dear authors

Can you describe in more detail the relationship and interaction between the 
two SR P2MP variants below:

Defines new SAFI for SR P2MP variant
https://datatracker.ietf.org/doc/html/draft-hb-idr-sr-p2mp-policy-04<https://urldefense.com/v3/__https:/datatracker.ietf.org/doc/html/draft-hb-idr-sr-p2mp-policy-04__;!!NEt6yMaO-gk!RNg1gSHc7bgU2dou9enCSiVF-PXIWQ2Wk4mTxBBHjYxjFPb_mdHB9D5C3jKh83Sr$>

zzh> draft-ietf-bess-bgp-multicast-controller (referred to as draft-bess) 
defines a SAFI and different route types of that SAFI to setup replication 
state on IP/mLDP/SR-P2MP tree nodes. One of the route types is for SR-P2MP 
purposes.
Zzh2> Correction – the MCAST-TREE SAFI is defined in 
draft-ietf-bess-bgp-multicast.

   Gyan> Ack
Zzh> draft-hb-idr-sr-p2mp-policy (draft in this adoption call, referred to as 
draft-hb) defines a different SAFI and route types for the same SR-P2MP 
purposes.
 Gyan> The adoption call draft is aligned with SR-TE policy as P2MP extension 
for simplicity for operators which I agree makes sense.
Does this draft utilize all the drafts below Tree sid / Replication sid and SR 
P2MP MVPN procedures for auto discovery etc.

Zzh> Both drafts are for realizing the two tree-sid drafts mentioned below; 
both can be used for draft-ietf-bess-mvpn-evpn-sr-p2mp.
 Gyan> Ack
Zzh> As I mentioned before, both draft-bess and draft-hb have its own 
considerations. The biggest difference is how the replication information is 
encoded in the Tunnel Encapsulation Attribute

Re: [bess] [Idr] draft-hb-idr-sr-p2mp-policy (3/10 to 3/24/2022) - Adoption call

[Jeffrey (Zhaohui) Zhang]

Hi Gyan,

Please see zzh2> below.



Juniper Business Use Only
From: Gyan Mishra 
Sent: Friday, April 8, 2022 8:48 PM
To: Jeffrey (Zhaohui) Zhang 
Cc: BESS ; Bidgoli, Hooman (Nokia - CA/Ottawa) 
; Susan Hares ; i...@ietf.org; 
p...@ietf.org
Subject: Re: [bess] [Idr] draft-hb-idr-sr-p2mp-policy (3/10 to 3/24/2022) - 
Adoption call

[External Email. Be cautious of content]


Hi Jeffrey

Please see Gyan>


On Tue, Apr 5, 2022 at 7:38 PM Jeffrey (Zhaohui) Zhang 
mailto:zzh...@juniper.net>> wrote:
Hi Gyan,

Please see zzh> below for my view.



Juniper Business Use Only
From: Gyan Mishra mailto:hayabusa...@gmail.com>>
Sent: Tuesday, March 29, 2022 10:31 AM
To: Jeffrey (Zhaohui) Zhang mailto:zzh...@juniper.net>>
Cc: BESS mailto:bess@ietf.org>>; Bidgoli, Hooman (Nokia - 
CA/Ottawa) mailto:hooman.bidg...@nokia.com>>; Susan 
Hares mailto:sha...@ndzh.com>>; 
i...@ietf.org<mailto:i...@ietf.org>; p...@ietf.org<mailto:p...@ietf.org>
Subject: Re: [bess] [Idr] draft-hb-idr-sr-p2mp-policy (3/10 to 3/24/2022) - 
Adoption call

[External Email. Be cautious of content]


Dear authors

Can you describe in more detail the relationship and interaction between the 
two SR P2MP variants below:

Defines new SAFI for SR P2MP variant
https://datatracker.ietf.org/doc/html/draft-hb-idr-sr-p2mp-policy-04<https://urldefense.com/v3/__https:/datatracker.ietf.org/doc/html/draft-hb-idr-sr-p2mp-policy-04__;!!NEt6yMaO-gk!RNg1gSHc7bgU2dou9enCSiVF-PXIWQ2Wk4mTxBBHjYxjFPb_mdHB9D5C3jKh83Sr$>

zzh> draft-ietf-bess-bgp-multicast-controller (referred to as draft-bess) 
defines a SAFI and different route types of that SAFI to setup replication 
state on IP/mLDP/SR-P2MP tree nodes. One of the route types is for SR-P2MP 
purposes.
Zzh2> Correction – the MCAST-TREE SAFI is defined in 
draft-ietf-bess-bgp-multicast.

   Gyan> Ack
Zzh> draft-hb-idr-sr-p2mp-policy (draft in this adoption call, referred to as 
draft-hb) defines a different SAFI and route types for the same SR-P2MP 
purposes.
 Gyan> The adoption call draft is aligned with SR-TE policy as P2MP extension 
for simplicity for operators which I agree makes sense.
Does this draft utilize all the drafts below Tree sid / Replication sid and SR 
P2MP MVPN procedures for auto discovery etc.

Zzh> Both drafts are for realizing the two tree-sid drafts mentioned below; 
both can be used for draft-ietf-bess-mvpn-evpn-sr-p2mp.
 Gyan> Ack
Zzh> As I mentioned before, both draft-bess and draft-hb have its own 
considerations. The biggest difference is how the replication information is 
encoded in the Tunnel Encapsulation Attribute (TEA).

Gyan> Ack
Zzh> I can understand that the IDR/PIM/BESS WGs may decide to accept both ways 
of encoding replication information in the TEA, but I believe we should share 
SAFI and route types between the two drafts – only the TEA would be different.

Gyan> Both the BESS and IDR adoption draft are vastly different solutions that 
have very different goals I don’t see any reason or need to have similarities 
as far as TEA or SAFI encodings or usage.  The BGP controller draft has a very 
wide scope, but also is more of an alternative approach as it introduces new 
extensibility idea of utilizing TEA and wide communities encoding to make the 
solution RFC 6513 and 6514 MVPN signaling independent.  That is a drastic 
change for scalability for operations traditional use of multicast X-PMSI 
P-Tree  leveraging the separation of control plane from forwarding plane with 
RR using traditional MVPN procedures.  As the ideas from the BESS draft as it 
builds on the BGP Multicast draft is to eliminate soft state tree building 
protocols and with the move towards hard state, thus the signaling paradigm 
change from traditional MVPM procedures to alternate TEA and wide community 
encoding.  Am I reading that correctly as the goals of the BESS draft?

Zzh2> Not really 

The BESS document also mentions that the solution can be used for underlay and 
overlay trees as replacement for MVPN signaling.  For underlay trees are you 
referring to GTM?  I have many more questions about the BESS draft and will ask 
in a new thread.

Zzh2> draft-ietf-bess-bgp-multicast-controller was initially intended to build 
traditional IP multicast trees (w/o any VPN specifics) and mLDP tunnels 
(started in September 2017) with calculation on and signaling from controllers. 
SR-P2MP was added in -03 (July 2020) because the generic mechanism for IP/mLDP 
trees can be used for SR-P2MP as well. These can all be considered as underlay.
Zzh2> Overlay support – as an MVPN replacement – was added in -06 (February 
2021), but the concept is *not different* from underlay at all – we’re just 
setting up (s, g) IP multicast state in VRFs, with downstream nodes including 
remote VRFs connected by some sort of tunnels. That is not different from 
setting up state in global table at all.
Zzh2> Thanks.
Zzh2> Jeffrey

Re: [bess] qquestion om draft-mpmz-bess-mup-saf at the bess meeting at IETF 113

[Jeffrey (Zhaohui) Zhang]

Linda,

In the central PSA UPF model, the gNB-UPF N3 interface is over an IP network 
that is typically implemented as a VPN (referred to as N3VPN). It has PEs close 
to gNBs and UPFs. What this draft does is moving the central PSA UPF 
functionality to the MUP GWs (which are N3VPN PEs close to the gNBs).

This is similar to the vanilla/traditional but distributed PSA UPFs that use 
vanilla N4 signaling, though the difference is that it is based on routers and 
BGP signaling. It's another way of doing distributed UPF. It may be desired by 
some operators/vendors, and it is transparent to 3GPP architecture and 
signaling (as far as SMF/gNBs are concerned, they are still interacting with a 
centralized PSA UPF even though it is realized by a collection of ).

Jeffrey



Juniper Business Use Only
From: Linda Dunbar 
Sent: Thursday, April 7, 2022 2:26 PM
To: Keyur Patel ; Jeffrey (Zhaohui) Zhang 
; Loa Andersson ; 
draft-mpmz-bess-mup-s...@ietf.org; wim.henderi...@alcatel-lucent.com
Cc: BESS 
Subject: RE: qquestion om draft-mpmz-bess-mup-saf at the bess meeting at IETF 
113

[External Email. Be cautious of content]

Jeffery and Keyur,

5G has distributed UPFs, UPFs can collocate with gNB. Therefore, there might 
not be a router between gNB and UPFs.

All the traffic out of UPFs (on N6 interfaces) are carried by IP networks.

So what does MUP do?

Linda

From: Keyur Patel mailto:ke...@arrcus.com>>
Sent: Tuesday, April 5, 2022 1:45 PM
To: Linda Dunbar 
mailto:linda.dun...@futurewei.com>>; Jeffrey 
(Zhaohui) Zhang mailto:zzh...@juniper.net>>; Loa Andersson 
mailto:l...@pi.nu>>; 
draft-mpmz-bess-mup-s...@ietf.org<mailto:draft-mpmz-bess-mup-s...@ietf.org>; 
wim.henderi...@alcatel-lucent.com<mailto:wim.henderi...@alcatel-lucent.com>
Cc: BESS mailto:bess@ietf.org>>
Subject: Re: qquestion om draft-mpmz-bess-mup-saf at the bess meeting at IETF 
113

Hi Linda,

To be clear - We are not replacing the UPF. The UPF still remains in the 
network. We are also not changing anything that is defined in 3GPP architecture.

Best Regards,
Keyur

From: BESS mailto:bess-boun...@ietf.org>> on behalf of 
Linda Dunbar mailto:linda.dun...@futurewei.com>>
Date: Tuesday, April 5, 2022 at 9:24 AM
To: Jeffrey (Zhaohui) Zhang mailto:zzh...@juniper.net>>, 
Loa Andersson mailto:l...@pi.nu>>, 
draft-mpmz-bess-mup-s...@ietf.org<mailto:draft-mpmz-bess-mup-s...@ietf.org> 
mailto:draft-mpmz-bess-mup-s...@ietf.org>>, 
wim.henderi...@alcatel-lucent.com<mailto:wim.henderi...@alcatel-lucent.com> 
mailto:wim.henderi...@alcatel-lucent.com>>
Cc: BESS mailto:bess@ietf.org>>
Subject: Re: [bess] qquestion om draft-mpmz-bess-mup-saf at the bess meeting at 
IETF 113
Jeffrey,

You are talking about changing the 3GPP architecture: replacing UPF by MUP and 
MUP GW, enabling BGP signaling, etc. have you discussed this architecture at 
3GPP S2 group?

Linda

-Original Message-
From: Jeffrey (Zhaohui) Zhang mailto:zzh...@juniper.net>>
Sent: Monday, April 4, 2022 6:47 PM
To: Linda Dunbar 
mailto:linda.dun...@futurewei.com>>; Loa Andersson 
mailto:l...@pi.nu>>; 
draft-mpmz-bess-mup-s...@ietf.org<mailto:draft-mpmz-bess-mup-s...@ietf.org>; 
wim.henderi...@alcatel-lucent.com<mailto:wim.henderi...@alcatel-lucent.com>
Cc: BESS mailto:bess@ietf.org>>
Subject: RE: qquestion om draft-mpmz-bess-mup-saf at the bess meeting at IETF 
113

Hi Linda, Loa,

Consider a traditional 5G deployment with all necessary NFs, including a 
central UPF. SMF signals to the UPF on N4 interface. AMF signals to gNBs on N2 
interface. The N3 transport (between gNBs and the UPF) is via an IPVPN over a 
transport infrastructure. There are PEs next to the gNBs and the UPF. The PEs 
are not 3GPP functions.

Now replace that UPF with the following: MUP controller, a group of MUP GWs and 
a MUP PE. The MUP GWs are just the previous PEs next to the gNBs. The MUP PE is 
just the previous PE next to the replaced UPF. The UPF is no longer needed, but 
from SMF and gNB's point of view it is still there.

With this replacement, there is no N2/N4 change. gNBs still send GTP packets to 
the old UPF address; it's just that the GTP packets will be intercepted by the 
GWs as if the UPF address is a local one. They still receive GTP packets as if 
being sent from the previous UPF.

The BGP signaling translates N4 signaling to BGP messages. The N4 signaling 
could include the UE addresses that are managed by the SMF; it could also be 
that the previous central UPF was managing the UE addresses itself. In either 
case, the MUP controller will signal the UE addresses (as host routes) to the 
MUP GWs - whether assigned by the SMF or assigned by the MUP controller (if the 
addresses were managed by the UPF before).

Jeffrey


Juniper Business Use Only

-Original Message-
From: Linda Dunbar 
mailto:linda.dun...@futurewei.com>>
Sent: Monday, April 4, 2022 12:47 PM
To

Re: [bess] [Idr] draft-hb-idr-sr-p2mp-policy (3/10 to 3/24/2022) - Adoption call

[Jeffrey (Zhaohui) Zhang]

Hi Sue,

I replied to Gyan's email last night and I just noticed that it crossed with 
this email.

I have posted draft-ietf-bess-bgp-multicast-controller-08.

Thanks!
Jeffrey



Juniper Business Use Only
From: Susan Hares 
Sent: Tuesday, April 5, 2022 7:10 PM
To: Jeffrey (Zhaohui) Zhang ; i...@ietf.org
Cc: 'BESS' ; p...@ietf.org
Subject: RE: [Idr] draft-hb-idr-sr-p2mp-policy (3/10 to 3/24/2022) - Adoption 
call

[External Email. Be cautious of content]

Jeffrey:

The assumptions in the following email:
https://mailarchive.ietf.org/arch/msg/idr/KObeSgKPu3HRbd0ZN7L7fWq_Eto/<https://urldefense.com/v3/__https:/mailarchive.ietf.org/arch/msg/idr/KObeSgKPu3HRbd0ZN7L7fWq_Eto/__;!!NEt6yMaO-gk!TXoR3wZyAFd_Sg2L6d_XgKBqhfuPh_uIvuy64pVKhGW97Gud1X-42EXyHo2-JRLO$>

are based on past assumptions.  The  BESS, IDR, and PIM WG Chairs
have agreed to a joint WG adoptions to gain input from these 3 WGs
into cohesive solutions.   Therefore, let's focus on the technologies in this 
adoption.

Please repost your draft:
https://datatracker.ietf.org/doc/draft-ietf-bess-bgp-multicast-controller/<https://urldefense.com/v3/__https:/datatracker.ietf.org/doc/draft-ietf-bess-bgp-multicast-controller/__;!!NEt6yMaO-gk!TXoR3wZyAFd_Sg2L6d_XgKBqhfuPh_uIvuy64pVKhGW97Gud1X-42EXyHuAZdTyY$>

I have extended the WG adoption call so that you can repost this draft.
Please repost on 4/5 or 4/6.  Without a repost of your draft,
I will close the WG adoption call.

My next posts will focus on the technical based on the following
assertions you made in

You indicated in
https://mailarchive.ietf.org/arch/msg/idr/8k4Pkcg0aqIwPFbSULXepsaHDSw/<https://urldefense.com/v3/__https:/mailarchive.ietf.org/arch/msg/idr/8k4Pkcg0aqIwPFbSULXepsaHDSw/__;!!NEt6yMaO-gk!TXoR3wZyAFd_Sg2L6d_XgKBqhfuPh_uIvuy64pVKhGW97Gud1X-42EXyHurmAs0M$>

"When it comes to SR-P2MP state downloading, there are three aspects involved 
here:


  1.  NLRI to encode policy information
  2.  NLRI to encode  identification
  3.  Tunnel Encapsulation Attribute (TEA) that encodes actual replication 
branches

The draft-ietf-bess-(even when used for SR-P2MP) is aligned with other
non-SR multicast trees (IP/mLDP) for a unified approach,
while draft-hb is aligned to unicast BGP SR policy."

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

Re: [bess] [Idr] draft-hb-idr-sr-p2mp-policy (3/10 to 3/24/2022) - Adoption call

[Jeffrey (Zhaohui) Zhang]

Hi Gyan,

Please see zzh> below for my view.



Juniper Business Use Only
From: Gyan Mishra 
Sent: Tuesday, March 29, 2022 10:31 AM
To: Jeffrey (Zhaohui) Zhang 
Cc: BESS ; Bidgoli, Hooman (Nokia - CA/Ottawa) 
; Susan Hares ; i...@ietf.org; 
p...@ietf.org
Subject: Re: [bess] [Idr] draft-hb-idr-sr-p2mp-policy (3/10 to 3/24/2022) - 
Adoption call

[External Email. Be cautious of content]


Dear authors

Can you describe in more detail the relationship and interaction between the 
two SR P2MP variants below:

Defines new SAFI for SR P2MP variant
https://datatracker.ietf.org/doc/html/draft-hb-idr-sr-p2mp-policy-04<https://urldefense.com/v3/__https:/datatracker.ietf.org/doc/html/draft-hb-idr-sr-p2mp-policy-04__;!!NEt6yMaO-gk!RNg1gSHc7bgU2dou9enCSiVF-PXIWQ2Wk4mTxBBHjYxjFPb_mdHB9D5C3jKh83Sr$>

zzh> draft-ietf-bess-bgp-multicast-controller (referred to as draft-bess) 
defines a SAFI and different route types of that SAFI to setup replication 
state on IP/mLDP/SR-P2MP tree nodes. One of the route types is for SR-P2MP 
purposes.
Zzh> draft-hb-idr-sr-p2mp-policy (draft in this adoption call, referred to as 
draft-hb) defines a different SAFI and route types for the same SR-P2MP 
purposes.

Does this draft utilize all the drafts below Tree sid / Replication sid and SR 
P2MP MVPN procedures for auto discovery etc.

Zzh> Both drafts are for realizing the two tree-sid drafts mentioned below; 
both can be used for draft-ietf-bess-mvpn-evpn-sr-p2mp.

Zzh> As I mentioned before, both draft-bess and draft-hb have its own 
considerations. The biggest difference is how the replication information is 
encoded in the Tunnel Encapsulation Attribute (TEA).
Zzh> I can understand that the IDR/PIM/BESS WGs may decide to accept both ways 
of encoding replication information in the TEA, but I believe we should share 
SAFI and route types between the two drafts - only the TEA would be different.
Zzh> Jeffrey

Defines Tree SID stitching of replication SID SR policy P2MP variant
https://datatracker.ietf.org/doc/html/draft-voyer-pim-sr-p2mp-policy-00<https://urldefense.com/v3/__https:/datatracker.ietf.org/doc/html/draft-voyer-pim-sr-p2mp-policy-00__;!!NEt6yMaO-gk!RNg1gSHc7bgU2dou9enCSiVF-PXIWQ2Wk4mTxBBHjYxjFPb_mdHB9D5C3gdi0hAB$>

Replication SID
https://datatracker.ietf.org/doc/html/draft-ietf-spring-sr-replication-segment<https://urldefense.com/v3/__https:/datatracker.ietf.org/doc/html/draft-ietf-spring-sr-replication-segment__;!!NEt6yMaO-gk!RNg1gSHc7bgU2dou9enCSiVF-PXIWQ2Wk4mTxBBHjYxjFPb_mdHB9D5C3smIMNzh$>

Defines new SR P2MP PTA using MVPN procedures
https://datatracker.ietf.org/doc/html/draft-ietf-bess-mvpn-evpn-sr-p2mp<https://urldefense.com/v3/__https:/datatracker.ietf.org/doc/html/draft-ietf-bess-mvpn-evpn-sr-p2mp__;!!NEt6yMaO-gk!RNg1gSHc7bgU2dou9enCSiVF-PXIWQ2Wk4mTxBBHjYxjFPb_mdHB9D5C3g-W3jH0$>


Kind Regards

Gyan


On Mon, Mar 28, 2022 at 3:39 PM Jeffrey (Zhaohui) Zhang 
mailto:40juniper@dmarc.ietf.org>> 
wrote:
Hi,

When it comes to SR-P2MP state downloading, there are three aspects involved 
here:


  1.  NLRI to encode policy information
  2.  NLRI to encode  identification
  3.  Tunnel Encapsulation Attribute (TEA) that encodes actual replication 
branches

The major difference between the two ways is on #3. Indeed, we could not reach 
consensus - there are two ways of encoding the TEA and each has its own 
considerations. The draft-ietf-bess way (even when used for SR-P2MP) is aligned 
with other non-SR multicast trees (IP/mLDP) for a unified approach, while 
draft-hb is aligned to unicast BGP SR policy.

I want to initiate a discussion and I can understand that WGs may eventually 
choose to allow both ways for #3. Even so, I think we should strive for 
consistent approach at least for #1 and #2 (and for that I am not saying that 
draft-ietf-bess way must be used). For example, use the same SAFI and route 
types for both ways, but use different TEA encoding methods.

Thanks.

Jeffrey



Juniper Business Use Only
From: Bidgoli, Hooman (Nokia - CA/Ottawa) 
mailto:hooman.bidg...@nokia.com>>
Sent: Friday, March 25, 2022 11:34 AM
To: Jeffrey (Zhaohui) Zhang mailto:zzh...@juniper.net>>; 
Susan Hares mailto:sha...@ndzh.com>>; 
i...@ietf.org<mailto:i...@ietf.org>
Cc: 'p...@ietf.org<mailto:p...@ietf.org>' 
mailto:p...@ietf.org>>; 'BESS' 
mailto:bess@ietf.org>>
Subject: RE: [Idr] draft-hb-idr-sr-p2mp-policy (3/10 to 3/24/2022) - Adoption 
call

[External Email. Be cautious of content]

Hi All

Zzh> I do think BGP signaling for SR P2MP is appropriate. We just need to 
discuss the two ways and figure out how to proceed. The authors have discussed 
before though we have not reached consensus.

HB> yes there was discussion and there was no consensus to merge the 2 drafts 
as their approach is widely different. The authors of this draft have kept the 
implementation very close to unicast BGP SR Policy for the segment list, which 
sim

Re: [bess] qquestion om draft-mpmz-bess-mup-saf at the bess meeting at IETF 113

[Jeffrey (Zhaohui) Zhang]

Hi Linda, Loa,

Consider a traditional 5G deployment with all necessary NFs, including a 
central UPF. SMF signals to the UPF on N4 interface. AMF signals to gNBs on N2 
interface. The N3 transport (between gNBs and the UPF) is via an IPVPN over a 
transport infrastructure. There are PEs next to the gNBs and the UPF. The PEs 
are not 3GPP functions. 

Now replace that UPF with the following: MUP controller, a group of MUP GWs and 
a MUP PE. The MUP GWs are just the previous PEs next to the gNBs. The MUP PE is 
just the previous PE next to the replaced UPF. The UPF is no longer needed, but 
from SMF and gNB's point of view it is still there.

With this replacement, there is no N2/N4 change. gNBs still send GTP packets to 
the old UPF address; it's just that the GTP packets will be intercepted by the 
GWs as if the UPF address is a local one. They still receive GTP packets as if 
being sent from the previous UPF.

The BGP signaling translates N4 signaling to BGP messages. The N4 signaling 
could include the UE addresses that are managed by the SMF; it could also be 
that the previous central UPF was managing the UE addresses itself. In either 
case, the MUP controller will signal the UE addresses (as host routes) to the 
MUP GWs - whether assigned by the SMF or assigned by the MUP controller (if the 
addresses were managed by the UPF before).

Jeffrey


Juniper Business Use Only

-Original Message-
From: Linda Dunbar  
Sent: Monday, April 4, 2022 12:47 PM
To: Loa Andersson ; draft-mpmz-bess-mup-s...@ietf.org; 
wim.henderi...@alcatel-lucent.com
Cc: BESS 
Subject: RE: qquestion om draft-mpmz-bess-mup-saf at the bess meeting at IETF 
113

[External Email. Be cautious of content]


Thanks to Loa for reminding me of the questions.

Actually my question is more fundamental. The 3GPP Mobility Management Function 
manages the IP address assignments to UEs. Traffic from UEs are tunneled by GTP 
tunnel between the eNB and UPF. Many UPF has NAT, so the IP network might not 
see the UE's actual IP addresses.

Question 1: is draft-mpmz-bess-mup-safi managing the IP address from UPF? Or 
the actual UEs' IP addresses?
Question 2: If it is the IP addresses from the UPF, many flows from different 
UEs are aggregated to one IP. What the BGP extension for Mobile User Plan do?


Thank you very much.
Linda

-Original Message-
From: Loa Andersson 
Sent: Sunday, April 3, 2022 12:58 AM
To: draft-mpmz-bess-mup-s...@ietf.org; Linda Dunbar 
; wim.henderi...@alcatel-lucent.com
Cc: BESS 
Subject: qquestion om draft-mpmz-bess-mup-saf at the bess meeting at IETF 113

Authors,

When the draft-mpmz-bess-mup-safi were presented at IETF 113, Linda asked a 
question. The audio was bad, but I think Linda asked "VPN 3GPP and and VPN6, 
uses totally different address, how are they inter-worked?" I could not hear 
your answer, can you please repeat here?

Wim asked about the relationship to 3GPP. I think your answer was that since 
you are not changing anything in the 3GPP specifications there is no problem. 
That might be correct, but I think it would be prudent to let 3GPP know what we 
are doing.

/Loa


--
Loa Anderssonemail: l...@pi.nu
Senior MPLS Expert  loa.pi...@gmail.com
Bronze Dragon Consulting phone: +46 739 81 21 64
___
BESS mailing list
BESS@ietf.org
https://www.ietf.org/mailman/listinfo/bess

Re: [bess] [Idr] draft-hb-idr-sr-p2mp-policy (3/10 to 3/24/2022) - Adoption call

[Jeffrey (Zhaohui) Zhang]

Hi,

When it comes to SR-P2MP state downloading, there are three aspects involved 
here:


  1.  NLRI to encode policy information
  2.  NLRI to encode  identification
  3.  Tunnel Encapsulation Attribute (TEA) that encodes actual replication 
branches

The major difference between the two ways is on #3. Indeed, we could not reach 
consensus - there are two ways of encoding the TEA and each has its own 
considerations. The draft-ietf-bess way (even when used for SR-P2MP) is aligned 
with other non-SR multicast trees (IP/mLDP) for a unified approach, while 
draft-hb is aligned to unicast BGP SR policy.

I want to initiate a discussion and I can understand that WGs may eventually 
choose to allow both ways for #3. Even so, I think we should strive for 
consistent approach at least for #1 and #2 (and for that I am not saying that 
draft-ietf-bess way must be used). For example, use the same SAFI and route 
types for both ways, but use different TEA encoding methods.

Thanks.

Jeffrey



Juniper Business Use Only
From: Bidgoli, Hooman (Nokia - CA/Ottawa) 
Sent: Friday, March 25, 2022 11:34 AM
To: Jeffrey (Zhaohui) Zhang ; Susan Hares 
; i...@ietf.org
Cc: 'p...@ietf.org' ; 'BESS' 
Subject: RE: [Idr] draft-hb-idr-sr-p2mp-policy (3/10 to 3/24/2022) - Adoption 
call

[External Email. Be cautious of content]

Hi All

Zzh> I do think BGP signaling for SR P2MP is appropriate. We just need to 
discuss the two ways and figure out how to proceed. The authors have discussed 
before though we have not reached consensus.

HB> yes there was discussion and there was no consensus to merge the 2 drafts 
as their approach is widely different. The authors of this draft have kept the 
implementation very close to unicast BGP SR Policy for the segment list, which 
simplifies the implementation and deployment of the technology. As you said 
there seems to be two way to download this policy and the segment list and we 
can work on both.
Given the solid support I don't see why the adoption of this draft should  be 
delayed because of these arguments.

Thanks
Hooman

From: pim mailto:pim-boun...@ietf.org>> On Behalf Of 
Jeffrey (Zhaohui) Zhang
Sent: Friday, March 25, 2022 10:47 AM
To: Susan Hares mailto:sha...@ndzh.com>>; 
i...@ietf.org<mailto:i...@ietf.org>
Cc: 'p...@ietf.org' mailto:p...@ietf.org>>; 'BESS' 
mailto:bess@ietf.org>>
Subject: Re: [pim] [Idr] draft-hb-idr-sr-p2mp-policy (3/10 to 3/24/2022) - 
Adoption call

[+ BESS, PIM]

Hi,

I realized that in a hurry I did not respond to the specific questions below. 
Please see zzh> next to the questions.

Looks like that there are some comments on BESS/PIM list and I will go through 
those to see if I have any addition/follow-up on those.



Juniper Business Use Only
From: Idr mailto:idr-boun...@ietf.org>> On Behalf Of 
Jeffrey (Zhaohui) Zhang
Sent: Friday, March 25, 2022 6:30 AM
To: Susan Hares mailto:sha...@ndzh.com>>; 
i...@ietf.org<mailto:i...@ietf.org>
Subject: Re: [Idr] draft-hb-idr-sr-p2mp-policy (3/10 to 3/24/2022) - Adoption 
call

[External Email. Be cautious of content]

I am sorry for responding late. I somehow missed this.

I think we should discuss the relationship with 
daft-ietf-bess-bgp-multicast-controller further before adopting this.

Thanks.
Jeffrey



Juniper Business Use Only
From: Idr mailto:idr-boun...@ietf.org>> On Behalf Of 
Susan Hares
Sent: Thursday, March 10, 2022 10:28 AM
To: i...@ietf.org<mailto:i...@ietf.org>
Subject: Re: [Idr] draft-hb-idr-sr-p2mp-policy (3/10 to 3/24/2022) - Adoption 
call

[External Email. Be cautious of content]

IDR WG:

If you just wish to respond to the IDR list,
you may respond to this email on the adoption call.

Cheers, Sue

From: Idr [mailto:idr-boun...@ietf.org] On Behalf Of Susan Hares
Sent: Thursday, March 10, 2022 9:55 AM
To: i...@ietf.org<mailto:i...@ietf.org>; p...@ietf.org<mailto:p...@ietf.org>; 
bess@ietf.org<mailto:bess@ietf.org>
Subject: [Idr] draft-hb-idr-sr-p2mp-policy (3/10 to 3/24/2022)

This begins a 2 week WG adoption call for:
draft-hb-idr-sr-p2mp-policy from (3/10 to 3/24/2022)

You can obtain the draft at:
https://datatracker.ietf.org/doc/draft-hb-idr-sr-p2mp-policy/<https://urldefense.com/v3/__https:/datatracker.ietf.org/doc/draft-hb-idr-sr-p2mp-policy/__;!!NEt6yMaO-gk!TfiPI1NfecN3db3pj6WZ8paxUr4s6OvmVZ91mapddPFeCkFZJodxFk8aTGCpYg34$>

In your comments for this call please consider:

Zzh> I want to point out that 
https://datatracker.ietf.org/doc/draft-ietf-bess-bgp-multicast-controller/<https://urldefense.com/v3/__https:/datatracker.ietf.org/doc/draft-ietf-bess-bgp-multicast-controller/__;!!NEt6yMaO-gk!S33KKHGKJVywLaE5hTpBZvb2Og_8GrdduTTT-6xmknLUl8Yylk7RNo3lGazDpUZk$>
 is another way to do the same. I also explained in 
https://mailarchive.ietf.org/arch/msg/idr/KObeSgKPu3HRbd0ZN7L7fWq_Eto/<https://urldefense.com/v3/__https:/mailarchive.ietf.org/arch/msg/idr/KObeSgKPu3HRbd0ZN7L7fWq_Eto/__;!!NEt6y

Re: [bess] [Idr] draft-hb-idr-sr-p2mp-policy (3/10 to 3/24/2022) - Adoption call

[Jeffrey (Zhaohui) Zhang]

[+ BESS, PIM]

Hi,

I realized that in a hurry I did not respond to the specific questions below. 
Please see zzh> next to the questions.

Looks like that there are some comments on BESS/PIM list and I will go through 
those to see if I have any addition/follow-up on those.



Juniper Business Use Only
From: Idr  On Behalf Of Jeffrey (Zhaohui) Zhang
Sent: Friday, March 25, 2022 6:30 AM
To: Susan Hares ; i...@ietf.org
Subject: Re: [Idr] draft-hb-idr-sr-p2mp-policy (3/10 to 3/24/2022) - Adoption 
call

[External Email. Be cautious of content]

I am sorry for responding late. I somehow missed this.

I think we should discuss the relationship with 
daft-ietf-bess-bgp-multicast-controller further before adopting this.

Thanks.
Jeffrey



Juniper Business Use Only
From: Idr mailto:idr-boun...@ietf.org>> On Behalf Of 
Susan Hares
Sent: Thursday, March 10, 2022 10:28 AM
To: i...@ietf.org<mailto:i...@ietf.org>
Subject: Re: [Idr] draft-hb-idr-sr-p2mp-policy (3/10 to 3/24/2022) - Adoption 
call

[External Email. Be cautious of content]

IDR WG:

If you just wish to respond to the IDR list,
you may respond to this email on the adoption call.

Cheers, Sue

From: Idr [mailto:idr-boun...@ietf.org] On Behalf Of Susan Hares
Sent: Thursday, March 10, 2022 9:55 AM
To: i...@ietf.org<mailto:i...@ietf.org>; p...@ietf.org<mailto:p...@ietf.org>; 
bess@ietf.org<mailto:bess@ietf.org>
Subject: [Idr] draft-hb-idr-sr-p2mp-policy (3/10 to 3/24/2022)

This begins a 2 week WG adoption call for:
draft-hb-idr-sr-p2mp-policy from (3/10 to 3/24/2022)

You can obtain the draft at:
https://datatracker.ietf.org/doc/draft-hb-idr-sr-p2mp-policy/<https://urldefense.com/v3/__https:/datatracker.ietf.org/doc/draft-hb-idr-sr-p2mp-policy/__;!!NEt6yMaO-gk!TfiPI1NfecN3db3pj6WZ8paxUr4s6OvmVZ91mapddPFeCkFZJodxFk8aTGCpYg34$>

In your comments for this call please consider:

Zzh> I want to point out that 
https://datatracker.ietf.org/doc/draft-ietf-bess-bgp-multicast-controller/ is 
another way to do the same. I also explained in 
https://mailarchive.ietf.org/arch/msg/idr/KObeSgKPu3HRbd0ZN7L7fWq_Eto/ why it 
was in the bess WG.
Zzh> In addition, the bess draft supports *other* multicast trees (IP, mLDP 
besides SR-P2MP) using a consistent way.

1)  Does this technology support the SR P2MP features
that distributes candidate paths which connect
a multicast distribution tree (tree to leaves).

Zzh> It is one way to use BGP to support that. The bess draft specifies another 
way.

2) Is the technology correctly specified for the
NLRI (AFI/SAFI) and the tunnel encapsulation attribute
additions (sections 2 and 3)?

Zzh> The specified SAFI and tunnel encapsulation attribute additions are one 
way for the BGP signaling for SR-P2MP. The bess draft specifies another way.

3) Does the P2MP policy operation (section 4)
provide enough information for those implementing this
technology and those deploying the technology?

4) Do you think this multicast technology is a good
Place to start for P2MP policy advertisement via BGP?

Zzh> Both ways are good place to start. We just need to figure out how to 
proceed with the two proposals.

5) Do you think this SR P2MP policies should not be advertised
via BGP?

Zzh> I do think BGP signaling for SR P2MP is appropriate. We just need to 
discuss the two ways and figure out how to proceed. The authors have discussed 
before though we have not reached consensus.
Zzh> Thanks!
Zzh> Jeffrey

Cheers, Susan Hares
___
BESS mailing list
BESS@ietf.org
https://www.ietf.org/mailman/listinfo/bess

Re: [bess] Benjamin Kaduk's Discuss on draft-ietf-bess-evpn-bum-procedure-updates-11: (with DISCUSS and COMMENT)

[Jeffrey (Zhaohui) Zhang]

Hi Ben,

Text snipped to focus on outstanding issues. The draft posting window is not 
open yet, so let me post a diff file here.

Please see zzh3> below.

-

(By the way, I see that one place in §3.3 changed from saying that the
route key for the Leaf A-D route is the route-type specific field of the
triggering route, to saying that it's the NLRI of the triggering route.
That distinction may have been part of why I was confused and put a Discuss
in.  But it's all clear now, so there's nothing to do.)

zzh3> Yes - there was indeed a text error. Thanks for your original question - 
it led to the discovery of this error.

By the way (and probably unrelated), I filed
https://urldefense.com/v3/__https://www.rfc-editor.org/errata/eid6724__;!!NEt6yMaO-gk!UqH90SqHM2qJynm-VnBnIZRpYUfjzBBPsJ5_pWD03kOhlk1YFyd3kuF75bpuZwSD$
  against RFC 7177 based on a
paragraph from it that this draft quotes.  I think this draft should
continue to quote the actual text in RFC 7117, though, so am not sure that
there are any changes to make to this draft as a result of that errata
report.

Zzh3> I see that it's an editorial errata - "tunnel type" instead of "tunnel 
identifier". I think we can get away w/o doing anything here, as the error is 
obvious - anyone who need to understand the paragraph should be able to figure 
out.

> >
> >For inter-area segmentation, [RFC7524] requires the use of Inter-area
> >P2MP Segmented Next-Hop Extended Community (S-NH-EC), and the setting
> >of "Leaf Information Required" L flag in PTA in certain situations.
> >Either of these could be optional in case of EVPN.  Removing these
> >
> > "Could be"?  It sometimes is and sometimes isn't?  When is it still
> > mandatory?
>
> Zzh2> This is in the "descriptive" part of the document. Later in the 
> normative part, I do have the following:

My point is that these are not "optional" in the sense that an
implementation has a choice to make -- we know exactly when they will or
will not be used.  It seems unhelpful to the reader to be ambiguous about
whether there is a requirement here, since there is required behavior
specified later on.  We might, for example, say that these requirements, or
when they apply, are modified for the EVPN case, or "In the EVPN case, the
requirements around S-NH-EC and the PTA "L" flag differ from [RFC7524]".
This continues to let the reader know that there is divergence from RFC
7524, but sets the expectation that more details will appear later in this
document.

Zzh3>  ok changed.

> >
> > Section 5.2
> >
> >considered as leaves (as proxies for those PEs in other ASes).  Note
> >that in case of Ingress Replication, when an ASBR re-advertises IMET
> >A-D routes to IBGP peers, it MUST advertise the same label for all
> >those for the same Ethernet Tag ID and the same EVI.  When an ingress
> >
> > This seems like an eminently reasonable thing to require.  I wonder if
> > it's worth saying a little more about why it is required, though -- what
> > breaks if you don't do this?
>
> Zzh2> I thought only SHOULD requires text explain what happens if it is not 
> done 

I don't think there's a hard rule (in either case, actually).  Sometimes it
is useful to say, and sometimes not.

> Zzh2> If they did not advertise the same label, then the ingress PE will send 
> multiple copies to the ASBR.

Is that just using up extra bandwidth, or would there be risk of the
multiple copies propagating further in the network?  If we require a
behavior in order to protect the network (or CE) from receiving duplicate
packets, that could be important enough (i.e., a security consideration) to
tilt the balance in favor of adding the extra explanation.

Zzh3> OK I added "Otherwise, duplicated copies will be sent by the ingress PE 
and received by egress PEs in other regions."

> >
> > Section 5.3
> >
> >o  An egress PE sends Leaf A-D routes in response to I-PMSI routes,
> >   if the PTA has the L flag set (by the re-advertising ASBRs).
> >
> > I don't think I understand the parenthetical.  Which previous text is it
> > intending to refer to?
>
> Zzh2> While an ingress PE does not set the L flag, it may be set by an ASBR 
> when the route is re-advertised.

Ah.  Maybe "added by the re-advertising ASBRs" or "as might have been added
by the re-advertising ASBRs", then?

Zzh3> What's the difference between the "set" and "add" here? The flag is a bit 
in a bit field. Do you mean I should/could simply remove the parenthesis, like 
"if the PTA has the L flag set by the re-advertising ASBR"?

>
> > Section 1
> >
> >o  IMET A-D route [RFC7432]: Inclusive Multicast Ethernet Tag A-D
> >   route.  The EVPN equivalent of MVPN Intra-AS I-PMSI A-D route.
> >
> > I would say that a de novo explanation is likely to be of more general
> > applicability than a dense MVPN reference.  Perhaps "Advertised by PEs
> > to enable reception of BUM traffic for a given VLAN" or similar?
>
> Zzh2> The main point is 

Re: [bess] Benjamin Kaduk's Discuss on draft-ietf-bess-evpn-bum-procedure-updates-11: (with DISCUSS and COMMENT)

[Jeffrey (Zhaohui) Zhang]

Hi Ben,

I have posted -012 revision. It should address most of your comments.

https://www.ietf.org/rfcdiff?url2=draft-ietf-bess-evpn-bum-procedure-updates-12.txt

Please see zzh2> below for both the DISCUSS and COMMENT points below.

-Original Message-
From: Benjamin Kaduk 
Sent: Thursday, October 21, 2021 11:08 PM
To: Jeffrey (Zhaohui) Zhang 
Cc: The IESG ; 
draft-ietf-bess-evpn-bum-procedure-upda...@ietf.org; bess-cha...@ietf.org; 
bess@ietf.org; ext-zzhang_i...@hotmail.com 
Subject: Re: Benjamin Kaduk's Discuss on 
draft-ietf-bess-evpn-bum-procedure-updates-11: (with DISCUSS and COMMENT)

[External Email. Be cautious of content]


Hi Jeffrey,

On Thu, Oct 21, 2021 at 02:11:01PM +0000, Jeffrey (Zhaohui) Zhang wrote:
> Hi Ben,
>
> Thanks for your review and comments. Let me first address the DISCUSS point 
> below and then follow up with another email on other points.

Sure, that sounds good.

> -Original Message-
> From: Benjamin Kaduk via Datatracker 
> Sent: Thursday, October 21, 2021 1:50 AM
> To: The IESG 
> Cc: draft-ietf-bess-evpn-bum-procedure-upda...@ietf.org; 
> bess-cha...@ietf.org; bess@ietf.org; ext-zzhang_i...@hotmail.com 
> ; ext-zzhang_i...@hotmail.com 
> 
> Subject: Benjamin Kaduk's Discuss on 
> draft-ietf-bess-evpn-bum-procedure-updates-11: (with DISCUSS and COMMENT)
>
> [External Email. Be cautious of content]
>
>
> Benjamin Kaduk has entered the following ballot position for
> draft-ietf-bess-evpn-bum-procedure-updates-11: 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.com/v3/__https://www.ietf.org/blog/handling-iesg-ballot-positions/__;!!NEt6yMaO-gk!S0XsefTxpcM08Cegf69h1Kt6chs_TkO5AGOfS5hXEhy1jFTSKNgIn4vlXZV7E-lH$
> for more information about how to handle DISCUSS and COMMENT positions.
>
>
> The document, along with other ballot positions, can be found here:
> https://urldefense.com/v3/__https://datatracker.ietf.org/doc/draft-ietf-bess-evpn-bum-procedure-updates/__;!!NEt6yMaO-gk!S0XsefTxpcM08Cegf69h1Kt6chs_TkO5AGOfS5hXEhy1jFTSKNgIn4vlXVyyzOC6$
>
>
>
> --
> DISCUSS:
> --
>
> I'm not sure whether the Leaf A-D route (route type specific field) as
> specified by this document is guaranteed to have a unique
> interpretation (§3.3).  It's supposed to start with the "route key",
> which is just the route-type-specific field of the PMSI route that
> triggered the Leaf A-D route.  That makes the route key variable length
> (as stated), and this variation is clearly achieved given that even the
> Per-Region I-PMSI A-D route and S-PMSI A-D route defined in this
> document have different length and layout.  I'm not sure what
> information is expected to be available to bound and determine the
> length of this "route key" field, other than "not the rest of the
> stuff".  "The rest of the stuff" is the originator's address and length
> thereof, but the length is in the middle of the structure, so even if we
> start parsing from the back we still can't distinguish reliably between
> a 4-byte IPv4 address and a 16-byte IPv6 address.  It seems that the
> Originator's Addr Length would need to be the last field in order to
> provide a unique interpretation, with "parse backwards" used to extract
> the Originator's Address, and "the rest of the stuff" being the route
> key that can be matched to the triggering PMSI route.  Is there some
> other procedure or contextual information available that ensurs a unique
> interpretation of this data?  Looking at RFCs 6514 and 7117, it does not
> seem like this document has some key change that renders it
> fundamentally different in this regard, so I mostly assume that the
> received route can be disambiguated somehow; I just don't know what that
> way is.
>
> Zzh> All routes have the following format:
>
> +---+
> |Route Type (1 octet)   |
> +---+
> | Length (1 octet)  |
> +---+
> | Route Type specific (variable)|
> +---+
> Zzh> For a Leaf A-D route, its "Route Type specific" part is the triggering 
> PMSI route's NLRI, so it explodes into the following (the three lines marked 
> with '*' are the trigg

Re: [bess] Benjamin Kaduk's Discuss on draft-ietf-bess-evpn-bum-procedure-updates-11: (with DISCUSS and COMMENT)

[Jeffrey (Zhaohui) Zhang]

Hi Ben,

Thanks for your review and comments. Let me first address the DISCUSS point 
below and then follow up with another email on other points.

-Original Message-
From: Benjamin Kaduk via Datatracker 
Sent: Thursday, October 21, 2021 1:50 AM
To: The IESG 
Cc: draft-ietf-bess-evpn-bum-procedure-upda...@ietf.org; bess-cha...@ietf.org; 
bess@ietf.org; ext-zzhang_i...@hotmail.com ; 
ext-zzhang_i...@hotmail.com 
Subject: Benjamin Kaduk's Discuss on 
draft-ietf-bess-evpn-bum-procedure-updates-11: (with DISCUSS and COMMENT)

[External Email. Be cautious of content]


Benjamin Kaduk has entered the following ballot position for
draft-ietf-bess-evpn-bum-procedure-updates-11: 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.com/v3/__https://www.ietf.org/blog/handling-iesg-ballot-positions/__;!!NEt6yMaO-gk!S0XsefTxpcM08Cegf69h1Kt6chs_TkO5AGOfS5hXEhy1jFTSKNgIn4vlXZV7E-lH$
for more information about how to handle DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://urldefense.com/v3/__https://datatracker.ietf.org/doc/draft-ietf-bess-evpn-bum-procedure-updates/__;!!NEt6yMaO-gk!S0XsefTxpcM08Cegf69h1Kt6chs_TkO5AGOfS5hXEhy1jFTSKNgIn4vlXVyyzOC6$



--
DISCUSS:
--

I'm not sure whether the Leaf A-D route (route type specific field) as
specified by this document is guaranteed to have a unique
interpretation (§3.3).  It's supposed to start with the "route key",
which is just the route-type-specific field of the PMSI route that
triggered the Leaf A-D route.  That makes the route key variable length
(as stated), and this variation is clearly achieved given that even the
Per-Region I-PMSI A-D route and S-PMSI A-D route defined in this
document have different length and layout.  I'm not sure what
information is expected to be available to bound and determine the
length of this "route key" field, other than "not the rest of the
stuff".  "The rest of the stuff" is the originator's address and length
thereof, but the length is in the middle of the structure, so even if we
start parsing from the back we still can't distinguish reliably between
a 4-byte IPv4 address and a 16-byte IPv6 address.  It seems that the
Originator's Addr Length would need to be the last field in order to
provide a unique interpretation, with "parse backwards" used to extract
the Originator's Address, and "the rest of the stuff" being the route
key that can be matched to the triggering PMSI route.  Is there some
other procedure or contextual information available that ensurs a unique
interpretation of this data?  Looking at RFCs 6514 and 7117, it does not
seem like this document has some key change that renders it
fundamentally different in this regard, so I mostly assume that the
received route can be disambiguated somehow; I just don't know what that
way is.

Zzh> All routes have the following format:

+---+
|Route Type (1 octet)   |
+---+
| Length (1 octet)  |
+---+
| Route Type specific (variable)|
+---+
Zzh> For a Leaf A-D route, its "Route Type specific" part is the triggering 
PMSI route's NLRI, so it explodes into the following (the three lines marked 
with '*' are the triggering PMSI).

   Route Type 11 (Leaf A-D)
   Length (of the entire Leaf A-D route NLRI)
   * Route Type x (for the triggering PMSI route)
   * Length (of the PMSI route NLRI)
   * Route Type specific (for the PMSI route)
   Originator's Addr Length (for the Leaf A-D route)
   Originator's Addr (for the Leaf A-D route)

Zzh> With the above, there should be no problem parsing the NLRI?
Zzh> Thanks.
Zzh> Jeffrey

--
COMMENT:
--

Section 1

   It is expected that audience is familiar with EVPN and MVPN concepts
   and terminologies.  For convenience, the following terms are briefly

Please provide references for EVPN and MVPN that would serve as entry
points for gaining such familiarity.  E.g., RFCs 7432 and 6513/6514.

   explained.

I suggest including PMSI Tunnel Attribute in this list, especially since
RFC 6514 does not actually use the PTA acronym.

Section 2.1

   There is a difference between MVPN and VPLS multicast inter-as
   segmentation.  For simplicity, EVPN will use 

Re: [bess] Murray Kucherawy's Discuss on draft-ietf-bess-evpn-bum-procedure-updates-11: (with DISCUSS and COMMENT)

[Jeffrey (Zhaohui) Zhang]

Hi Murray, Ben,

Thanks for your review and comments.
Indeed the registry is the one to be created in the other draft. I will make 
the text clearer in a revision.

Jeffrey

From: Murray S. Kucherawy 
Sent: Thursday, October 21, 2021 3:42 AM
To: Benjamin Kaduk 
Cc: The IESG ; ext-zzhang_i...@hotmail.com 
; bess-cha...@ietf.org; 
draft-ietf-bess-evpn-bum-procedure-upda...@ietf.org; BESS 
Subject: Re: Murray Kucherawy's Discuss on 
draft-ietf-bess-evpn-bum-procedure-updates-11: (with DISCUSS and COMMENT)

[External Email. Be cautious of content]

On Wed, Oct 20, 2021 at 11:17 PM Benjamin Kaduk 
mailto:ka...@mit.edu>> wrote:

I'm pretty sure it's the registry to be created by
draft-ietf-bess-evpn-igmp-mld-proxy (also on this week's telechat), though
the specification there doesn't really provide a clear title for the new
registry itself.

Looks like it's on the 10/28 telechat.  I'll have a look at it.  A vague title 
would indeed be a problem.

-MSK


Juniper Business Use Only
___
BESS mailing list
BESS@ietf.org
https://www.ietf.org/mailman/listinfo/bess

Re: [bess] Roman Danyliw's No Objection on draft-ietf-bess-evpn-bum-procedure-updates-11: (with COMMENT)

[Jeffrey (Zhaohui) Zhang]

Hi Roman,

Thanks for your review and comments. Please see zzh> below.

-Original Message-
From: Roman Danyliw via Datatracker 
Sent: Tuesday, October 19, 2021 7:07 PM
To: The IESG 
Cc: draft-ietf-bess-evpn-bum-procedure-upda...@ietf.org; bess-cha...@ietf.org; 
bess@ietf.org; ext-zzhang_i...@hotmail.com ; 
ext-zzhang_i...@hotmail.com 
Subject: Roman Danyliw's No Objection on 
draft-ietf-bess-evpn-bum-procedure-updates-11: (with COMMENT)

[External Email. Be cautious of content]


Roman Danyliw has entered the following ballot position for
draft-ietf-bess-evpn-bum-procedure-updates-11: 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://urldefense.com/v3/__https://www.ietf.org/blog/handling-iesg-ballot-positions/__;!!NEt6yMaO-gk!W9aXZSC6YB_tGS-I05oE_xAchhv7ZbAc7eyvp9QLkay63a9oKtRPkl9f-wuQRPzJ$
for more information about how to handle DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://urldefense.com/v3/__https://datatracker.ietf.org/doc/draft-ietf-bess-evpn-bum-procedure-updates/__;!!NEt6yMaO-gk!W9aXZSC6YB_tGS-I05oE_xAchhv7ZbAc7eyvp9QLkay63a9oKtRPkl9f-5KAvuRS$



--
COMMENT:
--

** I support Lars Eggert’s DISCUSS position.  I have come to the same
conclusion as the GENART reviewer (Paul Kyzivat).  It isn’t clear what this
document is updating.

-- The document header and abstract explicitly say that RC7432 is updated.
However, I can’t find a clear explanation of how the next in this documents
updates RFC7432

-- Section 5.1. is titled as “Changes to Section 7.2.2 of [RFC7117]” and
changes behavior in RFC7117, but RFC7117 is not being updated (according to the
header and abstract).

Zzh> This document updates RFC7432 in that it provides extensions to support: 
a) selective tunnels b) tunnel segmentation. Perhaps it's arguable that counts 
as "updates". I am fine with removing the "update" tag if that does not count 
as "updates".
Zzh> This document does NOT update RFC7117/7524, which are for VPLS. This 
document is for EVPN (though both are different solutions for ethernet VPNs), 
but it refers to the selective or segmented tunnel procedures for VPLS defined 
in 7117/7524. While minor changes/modifications are needed to apply to EVPN 
(and they are pointed out in this document as you noted), the procedures for 
VPLS are not modified (therefore this document does not update 7117/7524).

Zzh> It was an intentional choice not to copy text from 7117/7524. I understand 
that is causing some concern here but I hope we'd eventually agree that it is 
better than copying text.

** Section 9.
   They do not introduce new security concerns besides what have been
   discussed in [RFC6514], [RFC7117], [RFC7432] and [RFC7524].

Which parts of these security considerations specifically apply here.  For
example, RFC7524 and RFC7432 makes references to MPLS mechanisms (which seem
out of scope here).  Additionally, it appears some of the guidance across these
documents is directed at securing generic EVPN technology – this is helpful,
but please be clear about this case.  What specific guidance is relevant to the
procedures for handling BUM traffic?

Zzh> No guidance. It simply says that there are no new issues/concerns 
introduced by this document, so whatever discussed in those referenced RFCs 
applies here as well.
Zzh> Thanks!
Zzh> Jeffrey



Juniper Business Use Only
___
BESS mailing list
BESS@ietf.org
https://www.ietf.org/mailman/listinfo/bess

Re: [bess] Opsdir telechat review of draft-ietf-bess-evpn-bum-procedure-updates-11

[Jeffrey (Zhaohui) Zhang]

Hi Scott,

Please see zzh> below.

-Original Message-
From: Scott Bradner via Datatracker 
Sent: Monday, October 11, 2021 10:18 AM
To: ops-...@ietf.org
Cc: bess@ietf.org; draft-ietf-bess-evpn-bum-procedure-updates@ietf.org; 
last-c...@ietf.org
Subject: Opsdir telechat review of draft-ietf-bess-evpn-bum-procedure-updates-11

[External Email. Be cautious of content]


Reviewer: Scott Bradner
Review result: Has Nits

Thanks for the updates since the last version I reviewed (09) - The new version
is somewhat easier to follow but I still find it a hard read - no so hard as to
suggest holding the document for a rewrite but (imo) not as clear as it could be

My last review objected to a SHOULD being used in section 5.3.1 and that was
replaced by a  MUST, which I think is a better choice but you have added a new
SHOULD at the end of the same section and I have the same objection to the use
of SHOULD in this case - it is my opinion that a MUST is better than a SHOULD
unless you explain the exceptions to the SHOULD - so I think you need to change
the text to use MUST or you need to add text that explains when one would not
do what the text says to do

zzh> Hmm ... I did not add a new SHOULD - they were there before.
Zzh> The designated ASBR election is only needed when there are legacy PEs, and 
the DF Election EC is only needed when the election is needed. So, if it is 
known that there are no legacy PEs present, the DF Election EC is not needed 
and received DF Election EC will just be ignored. That's why I used SHOULD, and 
the ignore action is implied.
Zzh> I'll take your advice and simply change to MUST.
Zzh> Thanks!
Zzh> Jeffrey


Juniper Business Use Only
___
BESS mailing list
BESS@ietf.org
https://www.ietf.org/mailman/listinfo/bess

Re: [bess] Éric Vyncke's No Objection on draft-ietf-bess-evpn-bum-procedure-updates-11: (with COMMENT)

[Jeffrey (Zhaohui) Zhang]

Hi Eric,

Thanks for your comments. Please see zzh> below.

-Original Message-
From: Éric Vyncke via Datatracker 
Sent: Monday, October 18, 2021 7:34 AM
To: The IESG 
Cc: draft-ietf-bess-evpn-bum-procedure-upda...@ietf.org; bess-cha...@ietf.org; 
bess@ietf.org; ext-zzhang_i...@hotmail.com ; 
ext-zzhang_i...@hotmail.com 
Subject: Éric Vyncke's No Objection on 
draft-ietf-bess-evpn-bum-procedure-updates-11: (with COMMENT)

[External Email. Be cautious of content]


Éric Vyncke has entered the following ballot position for
draft-ietf-bess-evpn-bum-procedure-updates-11: 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://urldefense.com/v3/__https://www.ietf.org/blog/handling-iesg-ballot-positions/__;!!NEt6yMaO-gk!QSe_FVZLy9LiJjxKR9913uZakS6q0nf4lprT6--xZZ7CwkXwfslLa8KJOu_WRx2D$
for more information about how to handle DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://urldefense.com/v3/__https://datatracker.ietf.org/doc/draft-ietf-bess-evpn-bum-procedure-updates/__;!!NEt6yMaO-gk!QSe_FVZLy9LiJjxKR9913uZakS6q0nf4lprT6--xZZ7CwkXwfslLa8KJOljIAkWT$



--
COMMENT:
--

Thank you for the work put into this document.

Please find below some non-blocking COMMENT points (but replies would be
appreciated even if only for my own education).

Special thanks to Zheng Zhang for his shepherd's write-up about the WG
consensus.

I hope that this helps to improve the document,

Regards,

-éric

-- Section 3 --

It is a little unclear whether the first list of values are applicable to the
'route type' field. The reader can only guess when reading the pre-amble to the
2nd list.

Zzh> Yes they're applicable to the 'route type' field. I will change the 
following text:

   "So far eight types have been defined in [RFC7432] ..."

Zzh> to the following (adding "route"):

   "So far eight route types have been defined in [RFC7432] ..."

-- Section 5.1 --
The text in this section appears to also update RFC 7117: "The following bullet
in Section 7.2.2.2 of [RFC7117]: ... s changed to the following when applied to
EVPN:". Should this document also formally update RFC 7117 ?

Zzh> RFC 7117 is for VPLS, though we're borrowing some of its text for EVPN BUM 
(with changes pointed out when applied to EVPN) instead of repeating the text. 
Because of that, this does not update RFC 7117 (because we're not changing the 
procedures for VPLS).

Zzh> Thanks!
Zzh> Jeffrey


Juniper Business Use Only
___
BESS mailing list
BESS@ietf.org
https://www.ietf.org/mailman/listinfo/bess

Re: [bess] RTG-DIR early review: draft-ietf-bess-evpn-bum-procedure-updates-10

[Jeffrey (Zhaohui) Zhang]

Hi Sasha,

Thank you so much for your review and comments/suggestions. It was a pleasant 
experience working with you to address the issues you pointed out.

I have submitted revision -11 that addresses the two concerns you raised: 
https://datatracker.ietf.org/doc/draft-ietf-bess-evpn-bum-procedure-updates/

Thanks!
Jeffrey

From: BESS  On Behalf Of Alexander Vainshtein
Sent: Thursday, October 7, 2021 8:48 AM
To: bess-cha...@ietf.org; 
draft-ietf-bess-evpm-bum-procedure-updates@ietf.org
Cc: rtg-...@ietf.org; Luc André Burdet ; bess@ietf.org
Subject: [bess] RTG-DIR early review: 
draft-ietf-bess-evpn-bum-procedure-updates-10

[External Email. Be cautious of content]


Hello

I have been selected to do a routing directorate “early” review of this draft:  
draft-ietf-bess-evpn-bum-procedure-updates-10<https://urldefense.com/v3/__https:/datatracker.ietf.org/doc/html/draft-ietf-bess-evpn-bum-procedure-updates-10__;!!NEt6yMaO-gk!RZeb-QnJHpkipVRZAUFJL92vdgTYhHeHc9Fu-ObilFS5scomMz3AbGZpuGJiAfr-$>.

The routing directorate will, on request from the working group chair, perform 
an “early” review of a draft before it is submitted for publication to the 
IESG. The early review can be performed at any time during the draft’s lifetime 
as a working group document. The purpose of the early review depends on the 
stage that the document has reached.

As this document is in working group last call, my focus for the review was to 
determine whether the document is ready to be published. Please consider my 
comments along with the other working group last call comments.

For more information about the Routing Directorate, please see 
​http://trac.tools.ietf.org/area/rtg/trac/wiki/RtgDir<https://urldefense.com/v3/__http:/trac.tools.ietf.org/area/rtg/trac/wiki/RtgDir__;!!NEt6yMaO-gk!RZeb-QnJHpkipVRZAUFJL92vdgTYhHeHc9Fu-ObilFS5scomMz3AbGZpuHxmV7zA$>

Document: draft-ietf-bess-evpn-bum-procedure-updates-10

Reviewer: Alexander (”Sasha”) Vainshtein

Review Date: 05-Oct-21

Intended Status: Standards Track

Summary:

I have some minor concerns about this document that I think should be resolved 
before it is submitted to the IESG.

Comments:

The draft defines updates to RFC 7432 that deal with two aspects of handling 
broadcast, unknown unicast and multicast (BUM) traffic:

  1.  Usage of segmented Provider P2MP tunnels for implementing Provider 
Multicast Service Interface (PMSI) for deliver of BUM traffic in EVPN. In this 
regard the draft extends original definition of inter-AS segmented P-tunnels in 
NG MVPN defined in RFC 6513/RFC 6514 and continues the work on usage of such 
tunnels in VPLS  (RFC 7117) and in inter-area (as opposed to inter-AS) 
scenarios for both MVPN and VPLS (RFC 7524).
  2.  Usage of selective PMSI for delivery of specific multicast flows just to 
the PEs that have expressed interest in these flows using P2MP tunnel LSPs. In 
this regard the draft extends the work started in 
draft-ietf-bess-evpn-igmp-mld-proxy where selective delivery of BUM traffic is 
limited to ingress replication (IR) provider tunneling technology.

The draft is written in a very dense way. E.g., Section 5.1 of the draft 
contains just the deltas between the mechanisms already defined in RFC 7117 and 
the mechanisms proposed in this draft.  The authors explicitly state that they 
have intentionally selected this style, and, of course, it is quite valid to 
use it – but it requires very good understanding of the “previous art” in order 
to understand this draft. I cannot say whether this s or is not inevitable, but 
it definitely does not make the life of the reader/implementer simple.

While the draft provides a good description of motivation for using segmented 
P-tunnels for delivery of BUM traffic in intra-AS as well as inter-AS 
scenarios, personally I wonder how such usage is related with the techniques 
used for inter-AS/inter-domain “known unicast” traffic in EVPN. Specifically I 
doubt usage of segmented P-tunnels for delivery of BUM traffic within a single 
AS is justified if an analog of “inter-AS Option C” is used for end-to-end 
delivery of known unicast traffic in the same service. It would be nice if the 
authors could elaborate on this point. Please note that this is not an issue to 
be addressed in the next revisions of the draft, just a point of personal 
interest.

I have presented my early comments on the draft to the authors, and received 
timely and satisfactory responses. I would like to specially thank Jeffrey 
(Zhaohui Zhang) for excellent cooperation.

The following has raised some concerns for me.

  1.  Section 7 “Multi-homing Support” discusses two deployment scenarios:

 *   Multi-homed segments do not span different ACs or regions. In this 
case the draft says that “a segmentation point will remove the ESI label from 
the packets”. I have two issues with this text:

 i.This text does not 
represent a requirement (no capi

Re: [bess] Last Call: (Updates on EVPN BUM Procedures) to Proposed Standard

[Jeffrey (Zhaohui) Zhang]

Hi Scott, Gorry, Paul,

I posted -10 revision to address some comments you posted. Thanks a lot!

https://datatracker.ietf.org/doc/html/draft-ietf-bess-evpn-bum-procedure-updates-10

Jeffrey

-Original Message-
From: iesg-secret...@ietf.org 
Sent: Tuesday, August 24, 2021 10:33 AM
To: IETF-Announce 
Cc: ext-zzhang_i...@hotmail.com ; 
bess-cha...@ietf.org; bess@ietf.org; 
draft-ietf-bess-evpn-bum-procedure-upda...@ietf.org; 
martin.vigour...@nokia.com; ext-zzhang_i...@hotmail.com 

Subject: Last Call:  
(Updates on EVPN BUM Procedures) to Proposed Standard

[External Email. Be cautious of content]


The IESG has received a request from the BGP Enabled ServiceS WG (bess) to
consider the following document: - 'Updates on EVPN BUM Procedures'
   as Proposed Standard

The IESG plans to make a decision in the next few weeks, and solicits final
comments on this action. Please send substantive comments to the
last-c...@ietf.org mailing lists by 2021-09-07. Exceptionally, comments may
be sent to i...@ietf.org instead. In either case, please retain the beginning
of the Subject line to allow automated sorting.

Abstract


   This document specifies procedure updates for broadcast, unknown
   unicast, and multicast (BUM) traffic in Ethernet VPNs (EVPN),
   including selective multicast, and provider tunnel segmentation.
   This document updates RFC 7432.





The file can be obtained via
https://urldefense.com/v3/__https://datatracker.ietf.org/doc/draft-ietf-bess-evpn-bum-procedure-updates/__;!!NEt6yMaO-gk!XFnmjgtB6DhU4XxKmFW1nG1xjZTg3Q4dFAXEiWu0V1XPWjR87OjG1zTH1SnxcMDY$



No IPR declarations have been submitted directly on this I-D.






Juniper Business Use Only
___
BESS mailing list
BESS@ietf.org
https://www.ietf.org/mailman/listinfo/bess

Re: [bess] Last Call: (Updates on EVPN BUM Procedures) to Proposed Standard

[Jeffrey (Zhaohui) Zhang]

Hi Satya,

Yes it applies to MVPN as well. I am actually in the process of writing a draft 
to formally extend the inter-region segmentation and per-region aggregation to 
MVPN, and to do intra-region segmentation for assisted replication purpose.

Jeffrey

From: Satya Mohanty (satyamoh) 
Sent: Tuesday, September 14, 2021 8:50 PM
To: Jeffrey (Zhaohui) Zhang ; last-c...@ietf.org; 
IETF-Announce 
Cc: ext-zzhang_i...@hotmail.com ; 
martin.vigour...@nokia.com; bess-cha...@ietf.org; 
draft-ietf-bess-evpn-bum-procedure-upda...@ietf.org; bess@ietf.org
Subject: Re: [bess] Last Call: 
 (Updates on EVPN BUM 
Procedures) to Proposed Standard

[External Email. Be cautious of content]

Hi Jeffrey,

Thanks for your reply.
It makes perfect sense.

Am I to assume that the same reasoning applies to Inter-as MVPN as well since 
EVPN BUM procedures is based significantly on MVPN procedures?

Best Regards,
--Satya

From: "Jeffrey (Zhaohui) Zhang" mailto:zzh...@juniper.net>>
Date: Tuesday, September 14, 2021 at 12:31 PM
To: "Satya Mohanty (satyamoh)" mailto:satya...@cisco.com>>, 
"last-c...@ietf.org<mailto:last-c...@ietf.org>" 
mailto:last-c...@ietf.org>>, IETF-Announce 
mailto:ietf-annou...@ietf.org>>
Cc: "ext-zzhang_i...@hotmail.com<mailto:ext-zzhang_i...@hotmail.com>" 
mailto:zzhang_i...@hotmail.com>>, 
"martin.vigour...@nokia.com<mailto:martin.vigour...@nokia.com>" 
mailto:martin.vigour...@nokia.com>>, 
"bess-cha...@ietf.org<mailto:bess-cha...@ietf.org>" 
mailto:bess-cha...@ietf.org>>, 
"draft-ietf-bess-evpn-bum-procedure-upda...@ietf.org<mailto:draft-ietf-bess-evpn-bum-procedure-upda...@ietf.org>"
 
mailto:draft-ietf-bess-evpn-bum-procedure-upda...@ietf.org>>,
 "bess@ietf.org<mailto:bess@ietf.org>" mailto:bess@ietf.org>>
Subject: RE: [bess] Last Call: 
 (Updates on EVPN BUM 
Procedures) to Proposed Standard

Hi Satya,

That is part of the optional procedure to provide backwards compatibility. An 
implementation would likely to have configuration controlling whether this 
procedure is used or not.

For the origination of per-region I-PMSI routes, whether it is for the purpose 
of backwards compatibility or just for the aggregation purpose, some 
provisioning is needed – at least to enable per-region aggregation (perhaps at 
per-VPN level). We are adding per-VPN signaling and procedures, so per-VRF 
configuration should be reasonable (at least on the source ASBRs).

In summary, that is indeed a local implementation issue.

Thanks!
Jeffrey

From: Satya Mohanty (satyamoh) mailto:satya...@cisco.com>>
Sent: Friday, September 10, 2021 2:10 PM
To: last-c...@ietf.org<mailto:last-c...@ietf.org>; IETF-Announce 
mailto:ietf-annou...@ietf.org>>
Cc: ext-zzhang_i...@hotmail.com<mailto:ext-zzhang_i...@hotmail.com> 
mailto:zzhang_i...@hotmail.com>>; 
martin.vigour...@nokia.com<mailto:martin.vigour...@nokia.com>; 
bess-cha...@ietf.org<mailto:bess-cha...@ietf.org>; 
draft-ietf-bess-evpn-bum-procedure-upda...@ietf.org<mailto:draft-ietf-bess-evpn-bum-procedure-upda...@ietf.org>;
 bess@ietf.org<mailto:bess@ietf.org>
Subject: Re: [bess] Last Call: 
 (Updates on EVPN BUM 
Procedures) to Proposed Standard

[External Email. Be cautious of content]


Hi authors,



One question on the draft Page #11, last paragraph;



   "  The ASBRs in an AS originate per-region I-PMSI A-D routes and

  advertise to their external peers to advertise tunnels used to

  carry traffic from the local AS to other ASes.  Depending on the

  types of tunnels being used, the L flag in the PTA may be set, in

  which case the downstream ASBRs and upgraded PEs will send Leaf

  A-D routes to pull traffic from their upstream ASBRs."



How do we originate these per-region I-PMSI?

Is it implied that there are EVI configuration at the ASBR?

Or this is a local decision and is not to be discussed in the standard.



In L23VPN, usually ASBRs do not have VRFs configured. Therefore asking this 
question.



Thanks,

--Satya



On 8/24/21, 7:38 AM, "BESS on behalf of The IESG" mailto:bess-boun...@ietf.org%20on%20behalf%20of%20iesg-secret...@ietf.org>>
 wrote:





The IESG has received a request from the BGP Enabled ServiceS WG (bess) to

consider the following document: - 'Updates on EVPN BUM Procedures'

   as Proposed Standard



The IESG plans to make a decision in the next few weeks, and solicits final

comments on this action. Please send substantive comments to the

last-c...@ietf.org<mailto:last-c...@ietf.org> mailing lists by 2021-09-07. 
Exceptionally, comments may

be sent to i...@ietf.org<mailto:i...@ietf.org> instead. In either case, 
please retain the beginning

of the Subject line to allow automated sorting.



Abstract





   This document

Re: [bess] Opsdir last call review of draft-ietf-bess-evpn-bum-procedure-updates-09

[Jeffrey (Zhaohui) Zhang]

Hi Scott,

In the example of "5.3.  Backward Compatibility", seems that it is already in 
the following format?



" if you want to X then do these steps
1
2
3
"
---

Specifically, section 5.3 has the following text:

   The above procedures assume that all PEs are upgraded to support the
   segmentation procedures:
   ...
   If a deployment has legacy PEs that does not support the above ...

   To address this backward compatibility problem, the following
   procedure can be used (see Section 6.2 for per-PE/AS/region I-PMSI
   A-D routes) ...

Thanks.
Jeffrey

-Original Message-
From: Scott Bradner 
Sent: Wednesday, September 8, 2021 3:44 PM
To: Jeffrey (Zhaohui) Zhang 
Cc: ops-...@ietf.org; bess@ietf.org; 
draft-ietf-bess-evpn-bum-procedure-updates@ietf.org; last-c...@ietf.org
Subject: Re: Opsdir last call review of 
draft-ietf-bess-evpn-bum-procedure-updates-09

[External Email. Be cautious of content]


thanks

I do understand its complex but I would hope that the language can be reworked 
to make it more likley
that an operator will get it right when trying to set up

I would not remove ether backward compatibility information but, as above, see 
if the language can be simplified

maybe more of a
if you want to X then do these steps
1
2
3

Scott

> On Sep 8, 2021, at 12:49 PM, Jeffrey (Zhaohui) Zhang  
> wrote:
>
> Hi Scott,
>
> Thanks for your review and comments/suggestions.
>
> Yes I will change the SHOULD to MUST as you pointed out.
>
> As for the complexity, unfortunately due to the nature of the tunnel 
> segmentation (if different tunnel technology/instantiation is needed in 
> different regions) the procedures are indeed needed and they're actually very 
> much similar to what's specified in RFC 6514 (for MVPN), RFC7117 (for VPLS) 
> and RFC7524 (inter-area segmentation for both MVPN and EVPN).
>
> The need to address backward compatibility is another reason for some added 
> complexity. For example, section 5.3 could be removed if we would not need to 
> consider legacy PEs that do not support the procedures in this document.
>
> Thanks.
> Jeffrey
>
> -Original Message-
> From: Scott Bradner via Datatracker 
> Sent: Monday, September 6, 2021 12:45 PM
> To: ops-...@ietf.org
> Cc: bess@ietf.org; draft-ietf-bess-evpn-bum-procedure-updates@ietf.org; 
> last-c...@ietf.org
> Subject: Opsdir last call review of 
> draft-ietf-bess-evpn-bum-procedure-updates-09
>
> [External Email. Be cautious of content]
>
>
> Reviewer: Scott Bradner
> Review result: Has Issues
>
> This is an OPS-DIR review of “Updates on EVPN BUM Procedures”
> 
>
> These comments should be treated as any other last-call comments
>
> This ID describes procedures to be used to support unknown unicast, and
> multicast (BUM) traffic in Ethernet VPNs, and as such, will impact the
> operators of networks where the procedures are used.
>
> I found this document to be quite complex and expect that operators will have 
> a
> hard time getting all the details right when trying to implement it.  I do not
> know if it can be made more straightforward but I would not want to be 
> assigned
> to get this running properly on a big network.
>
> That said, the procedures seem useful enough to publish the document as
> requested but I hope the WG does a pass to see if it can be simplified first
> and deal with the following:
>
> Section 5.3.1 – uses SHOULD – but I do not see why a  SHOULD is used instead 
> of
> a MUST
>
>In my opinion, a SHOULD introduces operational or implementation
>confusion unless
> the SHOULD is accompanied with an explanation of what might happen if the
> SHOULD is not followed so that the implementer or operator knows if it’s
> important and why – if I were writing RFC 2119 today, knowing what has 
> happened
> since I did write it, I would not include SHOULD & SHOULD NOT – far better to
> say “MUST unless the following is the case” or “MUST NOT unless the following
> is the case” –
>
>if the authors fell that there is a reason to not use MUST & MUST NOT
>then it would
> help if they included the reason in the text
>
>
>
>
> Juniper Business Use Only


Juniper Business Use Only
___
BESS mailing list
BESS@ietf.org
https://www.ietf.org/mailman/listinfo/bess

Re: [bess] Tsvart last call review of draft-ietf-bess-evpn-bum-procedure-updates-09

[Jeffrey (Zhaohui) Zhang]

Hi Gorry,

Thank you for your comments. I missed it hence the late response. Sorry about 
that.

Please see zzh> below.

-Original Message-
From: Gorry Fairhurst via Datatracker 
Sent: Monday, August 30, 2021 5:59 AM
To: tsv-...@ietf.org
Cc: bess@ietf.org; draft-ietf-bess-evpn-bum-procedure-updates@ietf.org; 
last-c...@ietf.org
Subject: Tsvart last call review of 
draft-ietf-bess-evpn-bum-procedure-updates-09

[External Email. Be cautious of content]


Reviewer: Gorry Fairhurst
Review result: Ready with Nits

This document has been reviewed as part of the transport area review team's
ongoing effort to review key IETF documents. These comments were written
primarily for the transport area directors, but are copied to the document's
authors and WG to allow them to address any issues raised and also to the IETF
discussion list for information.

When done at the time of IETF Last Call, the authors should consider this
review as part of the last-call comments they receive. Please always CC
tsv-...@ietf.org if you reply to or forward this review.

This document specifies procedure updates for broadcast, unknown unicast, and
multicast (BUM) traffic in Ethernet VPNs (EVPN), including selective multicast,
and provider tunnel segmentation.  There is a normative reference to
draft-ietf-bess-evpn-igmp-mld-proxy, which normatively refers to this spec.

This draft focusses on topics beneath the transport layer. It does not appear
to introduce specific transport protocol concerns.

1. A common concern for transports using tunnels is the topic of fragmentation
and packet size discovery.  This is not mentioned, and it could be useful to
point to the relevant section of a spec (I note that path "segmentation" in
this draft relates to something different, in RFC 7524).

Zzh> This segmentation does not introduce addition overhead compared to 
non-segmented case. Tunnels are just stitched together - previous segment's 
encapsulation is taken off and new encapsulation is put on for the next 
segment. It is possible that the next segment's encap header is larger (due to 
different encapsulation), but that is not different from if the next segment's 
encapsulation is used in the non-segmented case.

Zzh> I will add some text to " 2.1.  Reasons for Tunnel Segmentation".

2. A general comment is that the draft section 1 states "It is expected that
audience is familiar with EVPN and MVPN concepts and terminologies", I suggest
it would none-the-less be very helpful to: * Include appropriate RFC references
to where these terms are defined (.e.g. RFC7432?); * Check all the
abbreviations and either define each in section 1 or simply expand on first use
in this document;

zzh> Will do.

3. Section 8. Describes a temporary IANA assignment, which I presume
publication of this draft confirms?  I expect an IANA note to this effect would
help the IANA Team.

Zzh> Yes. IANA has confirmed in their review, so it should be all set.

Zzh> Thanks!
Zzh> Jeffrey



Juniper Business Use Only
___
BESS mailing list
BESS@ietf.org
https://www.ietf.org/mailman/listinfo/bess

Re: [bess] Last Call: (Updates on EVPN BUM Procedures) to Proposed Standard

[Jeffrey (Zhaohui) Zhang]

Hi Satya,

That is part of the optional procedure to provide backwards compatibility. An 
implementation would likely to have configuration controlling whether this 
procedure is used or not.

For the origination of per-region I-PMSI routes, whether it is for the purpose 
of backwards compatibility or just for the aggregation purpose, some 
provisioning is needed – at least to enable per-region aggregation (perhaps at 
per-VPN level). We are adding per-VPN signaling and procedures, so per-VRF 
configuration should be reasonable (at least on the source ASBRs).

In summary, that is indeed a local implementation issue.

Thanks!
Jeffrey

From: Satya Mohanty (satyamoh) 
Sent: Friday, September 10, 2021 2:10 PM
To: last-c...@ietf.org; IETF-Announce 
Cc: ext-zzhang_i...@hotmail.com ; 
martin.vigour...@nokia.com; bess-cha...@ietf.org; 
draft-ietf-bess-evpn-bum-procedure-upda...@ietf.org; bess@ietf.org
Subject: Re: [bess] Last Call: 
 (Updates on EVPN BUM 
Procedures) to Proposed Standard

[External Email. Be cautious of content]


Hi authors,



One question on the draft Page #11, last paragraph;



   "  The ASBRs in an AS originate per-region I-PMSI A-D routes and

  advertise to their external peers to advertise tunnels used to

  carry traffic from the local AS to other ASes.  Depending on the

  types of tunnels being used, the L flag in the PTA may be set, in

  which case the downstream ASBRs and upgraded PEs will send Leaf

  A-D routes to pull traffic from their upstream ASBRs."



How do we originate these per-region I-PMSI?

Is it implied that there are EVI configuration at the ASBR?

Or this is a local decision and is not to be discussed in the standard.



In L23VPN, usually ASBRs do not have VRFs configured. Therefore asking this 
question.



Thanks,

--Satya



On 8/24/21, 7:38 AM, "BESS on behalf of The IESG" mailto:bess-boun...@ietf.org%20on%20behalf%20of%20iesg-secret...@ietf.org>>
 wrote:





The IESG has received a request from the BGP Enabled ServiceS WG (bess) to

consider the following document: - 'Updates on EVPN BUM Procedures'

   as Proposed Standard



The IESG plans to make a decision in the next few weeks, and solicits final

comments on this action. Please send substantive comments to the

last-c...@ietf.org mailing lists by 2021-09-07. 
Exceptionally, comments may

be sent to i...@ietf.org instead. In either case, 
please retain the beginning

of the Subject line to allow automated sorting.



Abstract





   This document specifies procedure updates for broadcast, unknown

   unicast, and multicast (BUM) traffic in Ethernet VPNs (EVPN),

   including selective multicast, and provider tunnel segmentation.

   This document updates RFC 7432.











The file can be obtained via

https://datatracker.ietf.org/doc/draft-ietf-bess-evpn-bum-procedure-updates/







No IPR declarations have been submitted directly on this I-D.











___

BESS mailing list

BESS@ietf.org

https://www.ietf.org/mailman/listinfo/bess


Juniper Business Use Only
___
BESS mailing list
BESS@ietf.org
https://www.ietf.org/mailman/listinfo/bess

Re: [bess] Opsdir last call review of draft-ietf-bess-evpn-bum-procedure-updates-09

[Jeffrey (Zhaohui) Zhang]

Hi Scott,

Thanks for your review and comments/suggestions.

Yes I will change the SHOULD to MUST as you pointed out.

As for the complexity, unfortunately due to the nature of the tunnel 
segmentation (if different tunnel technology/instantiation is needed in 
different regions) the procedures are indeed needed and they're actually very 
much similar to what's specified in RFC 6514 (for MVPN), RFC7117 (for VPLS) and 
RFC7524 (inter-area segmentation for both MVPN and EVPN).

The need to address backward compatibility is another reason for some added 
complexity. For example, section 5.3 could be removed if we would not need to 
consider legacy PEs that do not support the procedures in this document.

Thanks.
Jeffrey

-Original Message-
From: Scott Bradner via Datatracker 
Sent: Monday, September 6, 2021 12:45 PM
To: ops-...@ietf.org
Cc: bess@ietf.org; draft-ietf-bess-evpn-bum-procedure-updates@ietf.org; 
last-c...@ietf.org
Subject: Opsdir last call review of 
draft-ietf-bess-evpn-bum-procedure-updates-09

[External Email. Be cautious of content]


Reviewer: Scott Bradner
Review result: Has Issues

This is an OPS-DIR review of “Updates on EVPN BUM Procedures”


These comments should be treated as any other last-call comments

This ID describes procedures to be used to support unknown unicast, and
multicast (BUM) traffic in Ethernet VPNs, and as such, will impact the
operators of networks where the procedures are used.

I found this document to be quite complex and expect that operators will have a
hard time getting all the details right when trying to implement it.  I do not
know if it can be made more straightforward but I would not want to be assigned
to get this running properly on a big network.

That said, the procedures seem useful enough to publish the document as
requested but I hope the WG does a pass to see if it can be simplified first
and deal with the following:

Section 5.3.1 – uses SHOULD – but I do not see why a  SHOULD is used instead of
a MUST

In my opinion, a SHOULD introduces operational or implementation
confusion unless
the SHOULD is accompanied with an explanation of what might happen if the
SHOULD is not followed so that the implementer or operator knows if it’s
important and why – if I were writing RFC 2119 today, knowing what has happened
since I did write it, I would not include SHOULD & SHOULD NOT – far better to
say “MUST unless the following is the case” or “MUST NOT unless the following
is the case” –

if the authors fell that there is a reason to not use MUST & MUST NOT
then it would
help if they included the reason in the text




Juniper Business Use Only
___
BESS mailing list
BESS@ietf.org
https://www.ietf.org/mailman/listinfo/bess

Re: [bess] Benjamin Kaduk's No Objection on draft-ietf-bess-mvpn-msdp-sa-interoperation-07: (with COMMENT)

[Jeffrey (Zhaohui) Zhang]

Hi Benjamin,

Thanks for your review and comments. I have posted -08 revision.

Please see zzh> below.

-Original Message-
From: BESS  On Behalf Of Benjamin Kaduk via Datatracker
Sent: Wednesday, May 19, 2021 9:25 PM
To: The IESG 
Cc: Matthew Bocci ; manka...@cisco.com; 
bess-cha...@ietf.org; bess@ietf.org; 
draft-ietf-bess-mvpn-msdp-sa-interoperat...@ietf.org
Subject: [bess] Benjamin Kaduk's No Objection on 
draft-ietf-bess-mvpn-msdp-sa-interoperation-07: (with COMMENT)

[External Email. Be cautious of content]


Benjamin Kaduk has entered the following ballot position for
draft-ietf-bess-mvpn-msdp-sa-interoperation-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://urldefense.com/v3/__https://www.ietf.org/iesg/statement/discuss-criteria.html__;!!NEt6yMaO-gk!RpGeWZCeZBAreMzivXrQ0bVoJONE8ErGwazuYm6GFz0p3HbPN0W63F57Og8D0TOo$
for more information about DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://urldefense.com/v3/__https://datatracker.ietf.org/doc/draft-ietf-bess-mvpn-msdp-sa-interoperation/__;!!NEt6yMaO-gk!RpGeWZCeZBAreMzivXrQ0bVoJONE8ErGwazuYm6GFz0p3HbPN0W63F57OtPmQe7y$



--
COMMENT:
--

This looks like a nice, simple way to improve the interoperation scenarios.
All my comments are relatively minor (and most are explicitly classified as 
nits).

Section 2

   Section "14.  Supporting PIM-SM without Inter-Site Shared C-Trees" of
   [RFC6514] specifies the procedures for MVPN PEs to discover (C-S,C-G)
   via MVPN Source Active A-D routes and then send (C-S,C-G) C-multicast
   routes towards the ingress PEs, [...]

Just to check my understanding: when we say "send (C-S,C-G) C-multicast
routes toward the ingress PEs", does that refer to the "Source Tree Join
C-multicast route"s that RFC 6514 describes?  Would it be helpful to
write it out using the same terminology?

Zzh> Yes. Fixed.

Section 3

   When an MVPN PE advertises an MVPN SA route following procedures in
   [RFC6514] for the "spt-only" mode, it SHOULD attach an "MVPN SA RP-
   address Extended Community".  [...]

I don't really understand why this is only a "SHOULD".  If the whole
point of this document is to let MVPN S-A announcements get propagated
out to MSDP, it seems required, and people who don't care about that
scenario can ignore the document entirely; they don't need SHOULD vs
MUST to get out of it.

Zzh> That's reasonable. Fixed.

   In addition to procedures in [RFC6514], an MVPN PE may be provisioned
   to generate MSDP SA messages from received MVPN SA routes, with or

When would something that implements the rest of this document not be
expected to generate MSDP SA messages in such a manner?  (That is, why
use "may be"?)

zzh> "may be provisioned" wording is just because it is not a protocol behavior 
but an operator choice - it is about whether the procedures in this document is 
used or not per an operator's choice. I don't know what's the best way to go 
with this. I am fine with changing it to the following if necessary:

   In addition to procedures in [RFC6514], MVPN PE MUST
   generate MSDP SA messages from received MVPN SA routes if it has
   MSDP sessions to non-PE MSDP peers, with or
   without local MSDP policy control.

Section 4

I'm always a little wary of claims of "no additional security
considerations", though in many cases there are no *significant* new
security considerations, even if there are some considerations that are
new.  In this case, we have the option of using the local RP address for
the C-G when constructing a MSDP SA message (when the EC is not present
in the MVPN SA NRLI), and since this causes different nodes in the MVPN
to see different RPs for the group, it's not immediately clear that
there are no relevant security considerations from having different
views of the RP.  What is the behavior when different nodes are using
different RPs?

Zzh> That should not cause security concerns.
Zzh> MSDP propagtes (s,g) information to distributed RPs so that receiving RPs 
are able to join to the sources.
Zzh> The RP address in the MSDP messages are only used for RPF purpose - such 
that the MSDP messages are distributed in a tree format. Even if two PEs 
advertise with different RP address for the same (s,g), others MSDP speakers 
will be able to pick just one to use.

(There is also the fact that the address of the RP is now sent to a
larger population by virtue of being in the new BCP EC, which should
cause us to consider if there are any privacy considerations from the
broadedend information distribution.  I don't see anything noteworthy,
though.)

zzh> W/o this feature, the MSDP speakers will need to peer with each other at 
overlay, 

Re: [bess] John Scudder's No Objection on draft-ietf-bess-mvpn-msdp-sa-interoperation-06: (with COMMENT)

[Jeffrey (Zhaohui) Zhang]

Hi John,

You're spot on with all the points below. I have submitted -07 to address them: 
https://www.ietf.org/rfcdiff?url2=draft-ietf-bess-mvpn-msdp-sa-interoperation-07.txt.

Thanks!
Jeffrey

-Original Message-
From: John Scudder via Datatracker 
Sent: Friday, May 14, 2021 10:30 AM
To: The IESG 
Cc: draft-ietf-bess-mvpn-msdp-sa-interoperat...@ietf.org; bess-cha...@ietf.org; 
bess@ietf.org; Matthew Bocci ; mankamana mishra 
; manka...@cisco.com
Subject: John Scudder's No Objection on 
draft-ietf-bess-mvpn-msdp-sa-interoperation-06: (with COMMENT)

[External Email. Be cautious of content]


John Scudder has entered the following ballot position for
draft-ietf-bess-mvpn-msdp-sa-interoperation-06: 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://urldefense.com/v3/__https://www.ietf.org/iesg/statement/discuss-criteria.html__;!!NEt6yMaO-gk!S3O1rDSfiOzjUlEizB2V6P3TeJuNxlVD9pA4uWm2DWVtPn_h4lKifL7ETNjcI3OG$
for more information about DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://urldefense.com/v3/__https://datatracker.ietf.org/doc/draft-ietf-bess-mvpn-msdp-sa-interoperation/__;!!NEt6yMaO-gk!S3O1rDSfiOzjUlEizB2V6P3TeJuNxlVD9pA4uWm2DWVtPn_h4lKifL7ETGT9wxQb$



--
COMMENT:
--

Thanks for this short document! I have a few questions and comments, below.

1. Section 3

   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

On first reading I had difficulty following “it MUST NOT include other MSDP
speakers“. You mean, MSDP speakers from another VPN, right? It didn’t come
together for me until I reread it and realized the referent of “it“ is “the PE
mesh group“. Anyway, this confused at least one reader, it might stand a little
rewording. (Replacing “it” with “The PE mesh group” in the last sentence would
do the trick.)

2. Section 3

   In addition to procedures in [RFC6514], an MVPN PE may be provisioned
   to generate MSDP SA messages from received MVPN SA routes, with or
   without local policy control.  If a received MVPN SA route is to
   trigger MSDP SA message,

There are a couple things wrong with the preceding clause. First, it’s either
missing an article before “MSDP” as in “trigger an MSDP SA message” or possibly
“message” is supposed to be pluralized as in “trigger MSDP messages”. Second
and more troublesome, that “if... is to trigger” seems wrong, that’s normally a
construct which would introduce a precondition but that’s not what happens. Can
you reword this? Do you mean “if a received MVPN SA route triggers an MSDP SA
message”?

   it is treated as if a corresponding MSDP SA
   message was received from within the PE mesh group and normal MSDP
   procedure is followed (e.g. an MSDP SA message is advertised to other
   MSDP peers outside the PE mesh group).

Your use of “e.g.”, meaning “for example”, implies other things could happen
instead as a result of normal MSDP procedure, and this is just a for-instance.
Right? Just checking.

   The (S,G) information comes
   from the (C-S,C-G) encoding in the MVPN SA NLRI and the RP address
   comes from the "MVPN SA RP-address EC" mentioned above.  If the
   received MVPN SA route does not have the EC (this could be from a
   legacy PE that does not have the capability to attach the EC), the
   local RP address for the C-G is used.  In that case, it is possible
   that receiving PE's RP for the C-G is actually the MSDP peer to which

“The receiving PE’s”

   the generated MSDP message is advertised, causing the peer to discard
   it due to RPF failure.  To get around that problem the peer SHOULD
   use local policy to accept the MSDP SA message.

That sounds pretty gross considering the MSDP state is built dynamically (isn’t
it?) but ok.

   An MVPN PE MAY treat only the best MVPN SA route selected by BGP
   route selection process (instead of all MVPN SA routes) for a given

“The BGP route selection process”

   (C-S,C-G) as a received MSDP SA message (and advertise corresponding
   MSDP message).  In that case, if the selected best MVPN SA route does

“The corresponding”




Juniper Business Use Only
___
BESS mailing list
BESS@ietf.org
https://www.ietf.org/mailman/listinfo/bess

Re: [bess] Cross WG review request for draft-ietf-bier-evpn

[Jeffrey (Zhaohui) Zhang]

Hi Jingrong,

Please see zzh> below.

From: Xiejingrong (Jingrong) 
Sent: Friday, May 7, 2021 8:19 AM
To: Jeffrey (Zhaohui) Zhang ; slitkows.i...@gmail.com; 
bess@ietf.org
Cc: bess-cha...@ietf.org
Subject: RE: [bess] Cross WG review request for draft-ietf-bier-evpn

[External Email. Be cautious of content]

Hi Jeffrey, all,

First of all, I am not against the process of this draft.

What I really want to discuss is about the “right” design of BIER service 
solution to make it really implementable and deployable, before it goes to a 
wrong direction IMO.

Zzh> I am not sure if there is a question/problem of “wrong direction” here.

The first design of BIER is based on MPLS, and the first BIER overlay encoding 
is an VPN Label following BIER header, to make it more aligned with the 
“BIER-MPLS” underlay.

However, is this a good design to be just “more aligned”, first with MPLS , 
then with IP based vxlan/nvgre/geneve ?

When MPLS is not preferred encapsulation but BIER is, then MPLS Label encoding 
after BIER header may not be preferred, and one have to choose a better 
“aligned” BIER overlay encoding, for example Vxlan.

When Vxlan is not preferred for unicast but BIER is preferred for multicast, 
then a better “aligned” BIER overlay encoding is needed, say NVGRE.

When Nvgre is not preferred for unicast but BIER is preferred for multicast, 
then a better “aligned” BIER overlay encoding is needed, say GENEVE.

Zzh> As I mentioned in the previous reply, using VXLAN/NVGRE/GENEVE after BIER 
is *NOT* a random and single choice. It is based whether an operator uses for 
unicast. If operator 1 uses VXLAN for unicast, then for BUM it’s BIER header 
followed by the VXLAN header (w/ or w/o the IP/UDP header depending on whether 
PHP is needed); if operator 2 uses NVGRE for unicast, then for BUM it’s BIER 
header followed by the NVGRE header and so on so forth.

Remind that Vxlan and Nvgre is informational encapsulation and Geneve is 
standard, however a router may not support Geneve but support vxlan, and may or 
may not support BIER.

Also remind that, when considering IPv6 encapsulation, vxlan/nvgre/geneve may 
have another alternative of SRv6-network-programming [RFC8986].

Zzh> If an operator uses SRv6 network programing instead of VXLAN/NVGRE/GENEVE, 
then of course VXLAN/NVGRE/GENEVE won’t be used with BIER.

How about designing one “unified” encoding that is “independent” of these IP 
based vxlan/nvgre/geneve encodings? say a longer-than-20-bit integer value 
without Vxlan/Nvgre/Geneve encoding.

Zzh> Didn’t we have such “unified” encoding already – an MPLS label? 
Zzh> In our previous discussions, I had said that while I understand that an 
operator may not want to use MPLS for transport purpose, I really don’t see why 
MPLS labels can’t be used for service delimiting purpose. No matter how/what it 
is encoded/presented/called, a number is used to represent something and an 
action is performed when that number is matched. It could be an mpls label, or 
a VNI, or some SRv6 function/argument bits.

The design of such a “unified” encoding can also consider the requirements that 
have seen: PHP and the problem that the BFIR node information is lost (then 
basic function like MVPN RPF is lost) etc.

If the vxlan/nvgre/geneve is implemented in BIER, then please just ignore these 
discussions. If it is not, then I think such discussions may make some sense.

Zzh> Let me ask it this way – say you’re an operator/vendor who prefers SRv6 
for unicast service delimiting. Now for multicast with BIER, if I suggest to 
use an MPLS label for service delimiting, what would you say?
Zzh> If you as an operator use vxlan/nvgre/geneve for unicast service 
delimiting, and I suggest to use MPLS label for service delimiting for 
multicast with BIER, what would you say?

What’s your opinion ? Can the BESS chair also provide your points on this?

Zzh> There must be a reason for so many choices on unicast side. Unless we can 
force every operator to the same on unicast side, I don’t think we can/need to 
standardize on a single choice for multicast with BIER.
Zzh> Thanks.
Zzh> Jeffrey

Thanks
Jingrong



From: Jeffrey (Zhaohui) Zhang [mailto:zzh...@juniper.net]
Sent: Tuesday, May 4, 2021 2:39 AM
To: Xiejingrong (Jingrong) 
mailto:xiejingr...@huawei.com>>; 
slitkows.i...@gmail.com<mailto:slitkows.i...@gmail.com>; 
bess@ietf.org<mailto:bess@ietf.org>
Cc: bess-cha...@ietf.org<mailto:bess-cha...@ietf.org>
Subject: RE: [bess] Cross WG review request for draft-ietf-bier-evpn

Hi Jingrong, WG,

I somehow missed this email. Sorry for replying late.

Please see zzh> below.

From: BESS mailto:bess-boun...@ietf.org>> On Behalf Of 
Xiejingrong (Jingrong)
Sent: Wednesday, April 7, 2021 3:20 AM
To: slitkows.i...@gmail.com<mailto:slitkows.i...@gmail.com>; 
bess@ietf.org<mailto:bess@ietf.org>
Cc: bess-cha...@ietf.org<mailto:bess-cha...@ietf.org>
Subject: Re: [

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

[Jeffrey (Zhaohui) Zhang]

Hi Gyan,

Now your question and this discussion is really about RFC 6514.

As specified in RFC 6514 (section 14 & 13) and mentioned in this draft, there 
are two ways to support ASM over MVPN.

One way is to have a PE (its VRF to be exact) as a C-RP or with an MSDP session 
to an off-site C-RP is one way (section 14). Its purpose is to avoid 
establishing (*,g) tree (and subsequent rpt/spt switch) over the provider 
network, not to provide value-added service. That's why RFC has section title 
as "14.  Supporting PIM-SM without Inter-Site Shared C-Trees".

That has one missing feature when the customer also has its own MSDP 
infrastructure to distribute source information among its MSDP speakers, and 
that's what this draft is about.

What you describe below about how ASM is done is the other way (Section "13.  
Switching from a Shared C-Tree to a Source C-Tree" in RFC 6514).

Thanks.

Jeffrey

-Original Message-
From: Gyan Mishra 
Sent: Friday, May 7, 2021 12:55 PM
To: Jeffrey (Zhaohui) Zhang 
Cc: Lenny Giuliano ; Qin Wu ; bess 
; draft-ietf-bess-mvpn-msdp-sa-interoperation.all 
; last-call 
; ops-dir 
Subject: Re: [bess] Opsdir last call review of 
draft-ietf-bess-mvpn-msdp-sa-interoperation-05

[External Email. Be cautious of content]


Hi Jeffrey

I read the draft and saw your comments that RFC 6514 mentions MSDP on the
PE.

In what use case would SP have to run Anycast RP / MSDP on the PE when that
ASM control plane function can all be done on the CE.

I guess there maybe customers looking for value added service to have the
SP provide that function and in that case is where this draft would come
into play for SPT feature to make it work.

My understanding of the shared tree over MVPN using MVPN RFC 6513, 6514
procedures is as follows:

ASM

1. Egress receiver PE sends Type 6 shared tree (c-*,c-g)  is sent towards
the RP PE.

2. The join received by RP behind PE triggers a type 7 source tree join
(c-s,c-g) towards the source ingress PE.

3.  Ingress PE sends Type-5 source active to trigger SPT switchover back to
the RP PE and all PEs on the S-PMSI selective tree.

4.  Egress receiver PEs now sends Type-7 (c-s,c-g) to the source PE

5.  Multicast stream now flows over the selective tree S-PMSI from Ingress
Source PE to all egress receiver PEs.

SSM

1. Egress receiver PEs now sends Type-7 (c-s,c-g) to the source PE

2.  Multicast stream now flows over the selective tree S-PMSI from Ingress
Source PE to all egress receiver PEs.



Kind Regards


Gyan

On Thu, May 6, 2021 at 3:27 PM Jeffrey (Zhaohui) Zhang  wrote:

> Hi Qin,
>
>
>
> Thank you so much for the review and comments. I have posted -06 revision

Juniper Business Use Only
___
BESS mailing list
BESS@ietf.org
https://www.ietf.org/mailman/listinfo/bess

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

[Jeffrey (Zhaohui) Zhang]

Hi Qin,

Thank you so much for the review and comments. I have posted -06 revision.

Jeffrey

From: Qin Wu 
Sent: Friday, April 30, 2021 11:59 AM
To: Jeffrey (Zhaohui) Zhang ; Lenny Giuliano 
; ops-dir 
Cc: bess ; draft-ietf-bess-mvpn-msdp-sa-interoperation.all 
; last-call 

Subject: RE: Opsdir last call review of 
draft-ietf-bess-mvpn-msdp-sa-interoperation-05

[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!

-Qin
发件人： Jeffrey (Zhaohui) Zhangmailto:zzh...@juniper.net>>
收件人： Qin Wumailto:bill...@huawei.com>>;Lenny 
Giulianomailto:le...@juniper.net>>;ops-dirmailto:ops-...@ietf.org>>
抄送： 
bessmailto:bess@ietf.org>>;draft-ietf-bess-mvpn-msdp-sa-interoperation.allmailto:draft-ietf-bess-mvpn-msdp-sa-interoperation@ietf.org>>;last-callmailto:last-c...@ietf.org>>
主题： 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.  With non-PE MSDP speakers (e.g. a C-RP)
  2.  With other PEs

#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 mailto:bill...@huawei.com>>
Sent: Friday, April 30, 2021 10:21 AM
To: Jeffrey (Zhaohui) Zhang mailto:zzh...@juniper.net>>; 
Lenny Giuliano mailto:le...@juniper.net>>; 
ops-...@ietf.org<mailto:ops-...@ietf.org>
Cc: bess@ietf.org<mailto:bess@ietf.org>; 
draft-ietf-bess-mvpn-msdp-sa-interoperation@ietf.org<mailto:draft-ietf-bess-mvpn-msdp-sa-interoperation@ietf.org>;
 last-c...@ietf.org<mailto:last-c...@ietf.org>
Subject: RE: Opsdir last call review of 
draft-ietf-bess-mvpn-msdp-sa-interoperation-05

[External Email. Be cautious of content]

发件人: Jeffrey (Zhaohui) Zhang [mailto:zzh...@juniper.net]
发送时间: 2021年4月30日 22:05
收件人: Qin Wu mailto:bill...@huawei.com>>; Lenny Giuliano 
mailto:le...@juniper.net>>; 
ops-...@ietf.org<mailto:ops-...@ietf.org>
抄送: bess@ietf.org<mailto:bess@ietf.org>; 
draft-ietf-bess-mvpn-msdp-sa-interoperation@ietf.org<mailto:draft-ietf-bess-mvpn-msdp-sa-interoperation@ietf.org>;
 last-c...@ietf.org<mailto:last-c...@ietf.org>
主题: RE: Opsdir last call review of 
draft-ietf-bess-mvpn-msdp-sa-interoperation-05

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-
From: Qin Wu mailto:bill...@huawei.com>>
Sent: Friday, April 30, 2021 9:43 AM
To: Jeffrey (Zhaohui) Zhang mailto:zzh...@juniper.net>>; 
Lenny Giuliano mailto:le...@juniper.net>>; 
ops-...@ietf.org<mailto:ops-...@ietf.org>
Cc: bess@ietf.o

Re: [bess] Cross WG review request for draft-ietf-bier-evpn

[Jeffrey (Zhaohui) Zhang]

Hi Jingrong, WG,

I somehow missed this email. Sorry for replying late.

Please see zzh> below.

From: BESS  On Behalf Of Xiejingrong (Jingrong)
Sent: Wednesday, April 7, 2021 3:20 AM
To: slitkows.i...@gmail.com; bess@ietf.org
Cc: bess-cha...@ietf.org
Subject: Re: [bess] Cross WG review request for draft-ietf-bier-evpn

[External Email. Be cautious of content]

Hi,

I have some comments on this draft.

1. There are 3 different encapsulations VXLAN/NVGRE/GENEVE defined in this 
draft, but it is not clear if there is a mandatory one for  interoperable 
implementation, or all are mandatory ?

Zzh> For a particular deployment, only one is needed - whichever one that is 
used for (known) unicast.

The effort to make BIER-EVPN "unified" with Unicast-EVPN (by using 3 BIER proto 
values) doesn't seem to be convenient:
1) For implementation, the existing NVO3 VXLAN/NVGRE/GENEVE forwarding module 
(HW or SW) doesn't help much because the major gap is BIER.
2) For trouble-shooting like offline LAN analyzing (rfc8279), the existing NVO3 
VXLAN/NVGRE/GENEVE header doesn't help much because the major part is BIER.

>From my point of view, one uniform encapsulation is better because it is used 
>for one single purpose - to distinguish the tenant and still keep aligned with 
>NVO3 style where "VNI" is used.

Zzh> From operational point of view, if a customer uses VXLAN for unicast, it 
does not make sense if he is forced to use NVGRE/GENEVE as BIER payload?

2. In section 2.1:
 A well-known IP multicast address (to be assigned by IANA) is used as
the destination address and the egress PEs MUST be set up to receive
and process packets addressed to the address.

It is not clear what are the "set up" and "process" implying. For example:
1) For implementation, does the "set up" mean an MFIB entry populated into 
forwarding table ? A packet with well-known IP multicast address as destination 
address (like 224.0.0.1) is usually sent to CPU in a multicast router in my 
opinion.

Zzh> 224.0.0.1 is a good example for what "set up" and "processing" means - the 
router is prepared to process packets addressed to the well-know address. 
Whether it is sent to CPU for processing is a local implementation detail - a 
sane/normal implementation would handle it in fast path but the spec does not 
have to mandate that.

2) For error-handling, how to "process" if the TTL/Hop limit field in the IP 
header is 0/1/254/255 ?

Zzh> This is like typical TTL handling for VPN/EVPN. For example, in case of 
VPN/EVPN-MPLS, how the TTL field is set and processed for the tunnel label and 
VPN/BD label. Here the tunnel label's TTL field is the BIER TTL and the VPN/BD 
label's TTL is the IP header TTL. Neither RFC 7432 nor RFC 8556 has text about 
it, and we don't need text here either.

>From my point of view, the cost to support BIER-PHP this way is fairly high. I 
>am not sure if some words like "recommend" or "not recommend" can help to do 
>the trade-off for implementation/deployment.

Zzh> Perhaps that trade-off discussion should happen in the PHP spec?
Zzh> Thanks!
Zzh> Jeffrey

Thanks
Jingrong


From: BESS [mailto:bess-boun...@ietf.org] On Behalf Of 
slitkows.i...@gmail.com
Sent: Friday, April 2, 2021 2:47 PM
To: bess@ietf.org
Cc: bess-cha...@ietf.org
Subject: [bess] Cross WG review request for draft-ietf-bier-evpn

HI folks,

The BIER WG is in the last mile of review for draft-ietf-bier-evpn and requests 
our review on the document before progressing further.
Please have a deep look at it and provide your feedback or concerns.

Please close the review by April 20th.


Thanks in advance,


Stephane

https://datatracker.ietf.org/doc/draft-ietf-bier-evpn/



Juniper Business Use Only
___
BESS mailing list
BESS@ietf.org
https://www.ietf.org/mailman/listinfo/bess

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

[Jeffrey (Zhaohui) Zhang]

Hi Qin,

Before the mechanism in this document is introduced, a PE may need to have MSDP 
sessions of both of the following:


  1.  With non-PE MSDP speakers (e.g. a C-RP)
  2.  With other PEs

#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 
Sent: Friday, April 30, 2021 10:21 AM
To: Jeffrey (Zhaohui) Zhang ; Lenny Giuliano 
; ops-...@ietf.org
Cc: bess@ietf.org; draft-ietf-bess-mvpn-msdp-sa-interoperation@ietf.org; 
last-c...@ietf.org
Subject: RE: Opsdir last call review of 
draft-ietf-bess-mvpn-msdp-sa-interoperation-05

[External Email. Be cautious of content]

发件人: Jeffrey (Zhaohui) Zhang [mailto:zzh...@juniper.net]
发送时间: 2021年4月30日 22:05
收件人: Qin Wu mailto:bill...@huawei.com>>; Lenny Giuliano 
mailto:le...@juniper.net>>; 
ops-...@ietf.org<mailto:ops-...@ietf.org>
抄送: bess@ietf.org<mailto:bess@ietf.org>; 
draft-ietf-bess-mvpn-msdp-sa-interoperation@ietf.org<mailto:draft-ietf-bess-mvpn-msdp-sa-interoperation@ietf.org>;
 last-c...@ietf.org<mailto:last-c...@ietf.org>
主题: RE: Opsdir last call review of 
draft-ietf-bess-mvpn-msdp-sa-interoperation-05

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-
From: Qin Wu mailto:bill...@huawei.com>>
Sent: Friday, April 30, 2021 9:43 AM
To: Jeffrey (Zhaohui) Zhang mailto:zzh...@juniper.net>>; 
Lenny Giuliano mailto:le...@juniper.net>>; 
ops-...@ietf.org<mailto:ops-...@ietf.org>
Cc: bess@ietf.org<mailto:bess@ietf.org>; 
draft-ietf-bess-mvpn-msdp-sa-interoperation@ietf.org<mailto:draft-ietf-bess-mvpn-msdp-sa-interoperation@ietf.org>;
 last-c...@ietf.org<mailto:last-c...@ietf.org>
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 

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

[Jeffrey (Zhaohui) Zhang]

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 
Sent: Friday, April 30, 2021 9:43 AM
To: Jeffrey (Zhaohui) Zhang ; Lenny Giuliano 
; ops-...@ietf.org
Cc: bess@ietf.org; draft-ietf-bess-mvpn-msdp-sa-interoperation@ietf.org; 
last-c...@ietf.org
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 clar

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

[Jeffrey (Zhaohui) Zhang]

Hi Qin,

Please see zzh3> below, and attached diff.

-Original Message-
From: Qin Wu 
Sent: Tuesday, April 27, 2021 9:53 PM
To: Jeffrey (Zhaohui) Zhang ; Lenny Giuliano 
; ops-...@ietf.org
Cc: bess@ietf.org; draft-ietf-bess-mvpn-msdp-sa-interoperation@ietf.org; 
last-c...@ietf.org
Subject: RE: Opsdir last call review of 
draft-ietf-bess-mvpn-msdp-sa-interoperation-05

[External Email. Be cautious of content]


Thanks Jeffrey for clarification, I have better understanding on your document.
I suggest to add clarity to the text from two perspectives:
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.

Zzh3> I added "with other PEs":

   If a PE does advertise MSDP SA messages based on received MVPN SA
   routes, the VPN-specific MSDP sessions with other PEs are no longer needed.

Zzh3> The policy difference is actually irrelevant here.

2. Clarify only one PE exist in the MSDP mesh group

Zzh3> The "PE MSDP mesh group" actually includes all PEs that are either a C-RP 
or an MSDP peer. Please see below for further information.

See comments marked with [Qin2]

Zzh3> more responses below.

-邮件原件-
发件人: Jeffrey (Zhaohui) Zhang [mailto:zzh...@juniper.net]
发送时间: 2021年4月28日 3:18
收件人: Qin Wu ; Lenny Giuliano ; 
ops-...@ietf.org
抄送: bess@ietf.org; draft-ietf-bess-mvpn-msdp-sa-interoperation@ietf.org; 
last-c...@ietf.org
主题: RE: Opsdir last call review of 
draft-ietf-bess-mvpn-msdp-sa-interoperation-05

Hi Qin,

Please see zzh2> below for clarifications.

-Original Message-
From: Qin Wu 
Sent: Tuesday, April 27, 2021 2:38 AM
To: Jeffrey (Zhaohui) Zhang ; Lenny Giuliano 
; ops-...@ietf.org
Cc: bess@ietf.org; draft-ietf-bess-mvpn-msdp-sa-interoperation@ietf.org; 
last-c...@ietf.org
Subject: RE: Opsdir last call review of 
draft-ietf-bess-mvpn-msdp-sa-interoperation-05

[External Email. Be cautious of content]


Hi, Jeffrey:
-----邮件原件-
发件人: Jeffrey (Zhaohui) Zhang [mailto:zzh...@juniper.net]
发送时间: 2021年4月27日 4:35
收件人: Qin Wu ; Lenny Giuliano ; 
ops-...@ietf.org
抄送: bess@ietf.org; draft-ietf-bess-mvpn-msdp-sa-interoperation@ietf.org; 
last-c...@ietf.org
主题: RE: Opsdir last call review of 
draft-ietf-bess-mvpn-msdp-sa-interoperation-05

Hi Qin,

Thank you for your review and comments. Let me share a diff to see if it 
addresses the issues, before I post a revision.

Please see zzh> below.

-Original Message-
From: Qin Wu via Datatracker 
Sent: Friday, April 23, 2021 11:20 AM
To: ops-...@ietf.org
Cc: bess@ietf.org; draft-ietf-bess-mvpn-msdp-sa-interoperation@ietf.org; 
last-c...@ietf.org
Subject: Opsdir last call review of 
draft-ietf-bess-mvpn-msdp-sa-interoperation-05

[External Email. Be cautious of content]


Reviewer: Qin Wu
Review result: Ready

Reviewer: Qin Wu
Review result: Ready with nits

I have reviewed this document as part of the Operational directorate's ongoing 
effort to review all IETF documents being processed by the IESG.  These 
comments were written with the intent of improving the operational aspects of 
the IETF drafts. Comments that are not addressed in last call may be included 
in AD reviews during the IESG review.  Document editors and WG chairs should 
treat these comments just like any other last call comments.

This document describes how to convey the RP address information into the MVPN 
Source Active route using an Extended Community so this information can be 
shared with an existing MSDP infrastructure. It provides an update to RFC6514.

Major issues:
None

Minor issues:
I am wondering how MVPN and MSDP SA Interoperation is back compatible with 
existing source  discovery information dissemination methods? Is there any 
downside to make MVPN SA and MSDP SA work together.

Zzh> There is no downside. The RFC6514 specified MSDP SA -> MVPN SA but is 
missing the other direction (MVPN SA -> MSDP SA), which causes lots of 
headache. This document is to add the missing part, as explained in 
introduction section.
Zzh> The only backwards compatibility issue is with a scenario further 
explained at the end of this message - where PE2 is a legacy PE that does not 
attach the EC.

[Qin]: Thank for clarification, I am little bit worried about this, with the 
magic policy control, we can solve all the backward compatibility issues,:-)
Zzh2> Well at this time we don't foresee other issues 
[Qin2]:How about "rpt-spt" mode which is beyond scope of this document. I don't 
investigate this.
Zzh3> Because it is out of scope, it is irrelevant

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

[Jeffrey (Zhaohui) Zhang]

Hi Qin,

Please see zzh2> below for clarifications.

-Original Message-
From: Qin Wu 
Sent: Tuesday, April 27, 2021 2:38 AM
To: Jeffrey (Zhaohui) Zhang ; Lenny Giuliano 
; ops-...@ietf.org
Cc: bess@ietf.org; draft-ietf-bess-mvpn-msdp-sa-interoperation@ietf.org; 
last-c...@ietf.org
Subject: RE: Opsdir last call review of 
draft-ietf-bess-mvpn-msdp-sa-interoperation-05

[External Email. Be cautious of content]


Hi, Jeffrey:
-邮件原件-
发件人: Jeffrey (Zhaohui) Zhang [mailto:zzh...@juniper.net]
发送时间: 2021年4月27日 4:35
收件人: Qin Wu ; Lenny Giuliano ; 
ops-...@ietf.org
抄送: bess@ietf.org; draft-ietf-bess-mvpn-msdp-sa-interoperation@ietf.org; 
last-c...@ietf.org
主题: RE: Opsdir last call review of 
draft-ietf-bess-mvpn-msdp-sa-interoperation-05

Hi Qin,

Thank you for your review and comments. Let me share a diff to see if it 
addresses the issues, before I post a revision.

Please see zzh> below.

-Original Message-
From: Qin Wu via Datatracker 
Sent: Friday, April 23, 2021 11:20 AM
To: ops-...@ietf.org
Cc: bess@ietf.org; draft-ietf-bess-mvpn-msdp-sa-interoperation@ietf.org; 
last-c...@ietf.org
Subject: Opsdir last call review of 
draft-ietf-bess-mvpn-msdp-sa-interoperation-05

[External Email. Be cautious of content]


Reviewer: Qin Wu
Review result: Ready

Reviewer: Qin Wu
Review result: Ready with nits

I have reviewed this document as part of the Operational directorate's ongoing 
effort to review all IETF documents being processed by the IESG.  These 
comments were written with the intent of improving the operational aspects of 
the IETF drafts. Comments that are not addressed in last call may be included 
in AD reviews during the IESG review.  Document editors and WG chairs should 
treat these comments just like any other last call comments.

This document describes how to convey the RP address information into the MVPN 
Source Active route using an Extended Community so this information can be 
shared with an existing MSDP infrastructure. It provides an update to RFC6514.

Major issues:
None

Minor issues:
I am wondering how MVPN and MSDP SA Interoperation is back compatible with 
existing source  discovery information dissemination methods? Is there any 
downside to make MVPN SA and MSDP SA work together.

Zzh> There is no downside. The RFC6514 specified MSDP SA -> MVPN SA but is 
missing the other direction (MVPN SA -> MSDP SA), which causes lots of 
headache. This document is to add the missing part, as explained in 
introduction section.
Zzh> The only backwards compatibility issue is with a scenario further 
explained at the end of this message - where PE2 is a legacy PE that does not 
attach the EC.

[Qin]: Thank for clarification, I am little bit worried about this, with the 
magic policy control, we can solve all the backward compatibility issues,:-)
Zzh2> Well at this time we don't foresee other issues 

Section 1:
Suggest to add term for GTM, RPT, C-Multicast

Zzh> Added.

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...

   [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,  
<

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.

Section 3
What do you mean other MSDP speaker? Do we assume there is one or only one MSDP 
speaker in the MSDP mesh group? How MSDP speaker is different from MSDP peer?
Do you mean there is no session to be established between MSDP peer?

Zzh> MSDP sessions are established among MSDP speakers/peers. The text here 
means that the MVPN PEs that are running MSDP (with sessions to other non-PEs)  
form a mesh group and that group does not include other MSDP peers that are not 
PEs.

[Qin]:Confused, the first half sentence said the MSDP session is established 
between PE and non-PEs, the second half sentence said the group does not 
include non-PE as MSDP peers? Are you saying in the second half sentence that 
the group only include other MSDP peers that are not PEs?

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

[Jeffrey (Zhaohui) Zhang]

Hi Qin,

Thank you for your review and comments. Let me share a diff to see if it 
addresses the issues, before I post a revision.

Please see zzh> below.

-Original Message-
From: Qin Wu via Datatracker 
Sent: Friday, April 23, 2021 11:20 AM
To: ops-...@ietf.org
Cc: bess@ietf.org; draft-ietf-bess-mvpn-msdp-sa-interoperation@ietf.org; 
last-c...@ietf.org
Subject: Opsdir last call review of 
draft-ietf-bess-mvpn-msdp-sa-interoperation-05

[External Email. Be cautious of content]


Reviewer: Qin Wu
Review result: Ready

Reviewer: Qin Wu
Review result: Ready with nits

I have reviewed this document as part of the Operational directorate's ongoing
effort to review all IETF documents being processed by the IESG.  These
comments were written with the intent of improving the operational aspects of
the IETF drafts. Comments that are not addressed in last call may be included
in AD reviews during the IESG review.  Document editors and WG chairs should
treat these comments just like any other last call comments.

This document describes how to convey the RP address information into the MVPN
Source Active route using an Extended Community so this information can be
shared with an existing MSDP infrastructure. It provides an update to RFC6514.

Major issues:
None

Minor issues:
I am wondering how MVPN and MSDP SA Interoperation is back compatible with
existing source  discovery information dissemination methods? Is there any
downside to make MVPN SA and MSDP SA work together.

Zzh> There is no downside. The RFC6514 specified MSDP SA -> MVPN SA but is 
missing the other direction (MVPN SA -> MSDP SA), which causes lots of 
headache. This document is to add the missing part, as explained in 
introduction section.
Zzh> The only backwards compatibility issue is with a scenario further 
explained at the end of this message - where PE2 is a legacy PE that does not 
attach the EC.

Section 1:
Suggest to add term for GTM, RPT, C-Multicast

Zzh> Added.

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.

Section 3
What do you mean other MSDP speaker? Do we assume there is one or only one MSDP
speaker in the MSDP mesh group? How MSDP speaker is different from MSDP peer?
Do you mean there is no session to be established between MSDP peer?

Zzh> MSDP sessions are established among MSDP speakers/peers. The text here 
means that the MVPN PEs that are running MSDP (with sessions to other non-PEs)  
form a mesh group and that group does not include other MSDP peers that are not 
PEs.

Section 3, last paragraph:
When we say ” 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.”, which best route is
selected? Selected best MVPN SA route without EC or normal route with the EC?
It looks you assume the normal route with the EC is the best selected route as
well in this context?

Zzh> The BGP selected best route may not have the EC. In that case, for MSDP 
interop purpose, the next best route with the EC should be used.

Section 3
Can you provide an example of fine grained policy control? Is this related to
local policy? “accepted MSDP SA message when receiving PE’s RP for the C-G is
MSDP peer to which the generated MSDP message is advertised”

Zzh> Yes I changed it to local policy. We probably don't need examples here - 
just whatever MSDP policies that can be used in an MSDP deployment.
Zzh> The quoted text is part of the following description: a receiving PE1 
receives an SA route from another PE2 who does not attach the EC, so PE1 uses 
its own local RP address (say R1) to construct that MSDP SA message and 
advertise to its peer. If that peer happens to be R1, the peer will reject it 
because PE1 used R1 in constructing the message. To prevent this rejection, R1 
should configure MSDP policy to accept the message.
Zzh> Thanks!
Zzh> Jeffrey

Juniper Business Use Only
<<< text/html; name="Diff_ draft-ietf-bess-mvpn-sa-to-msdp.txt - draft-ietf-bess-mvpn-msdp-sa-interoperation-05.txt.html": Unrecognized >>>
___
BESS mailing list
BESS@ietf.org
https://www.ietf.org/mailman/listinfo/bess

Re: [bess] draft-ietf-bess-mvpn-evpn-aggregation-label-05 shepherd's review

[Jeffrey (Zhaohui) Zhang]

Hi Stephane,

Thanks again for your review, comments and suggestions. I have uploaded -06 
that should address all your comments.

Jeffrey

From: Stephane Litkowski (slitkows) 
Sent: Wednesday, April 14, 2021 3:59 AM
To: Jeffrey (Zhaohui) Zhang ; 
draft-ietf-bess-mvpn-evpn-aggregation-la...@ietf.org
Cc: bess@ietf.org
Subject: RE: draft-ietf-bess-mvpn-evpn-aggregation-label-05 shepherd's review

[External Email. Be cautious of content]

Hi Jeffrey,

I think you really need to find a better wording for the SRGB/DCB 
consideration. The sentence is BLUE will prevent the intersection between the 
two (if it’s a MUST, you cannot have the OR statement).
Can’t you say:

   If these PEs share other common

   label blocks (e.g.  SRGB) with other routers, the DCB MAY

   intersect with those common label blocks in such case those PEs MUST be

   considered as part of the "domain".


Brgds,



From: Jeffrey (Zhaohui) Zhang mailto:zzh...@juniper.net>>
Sent: mercredi 14 avril 2021 03:54
To: Stephane Litkowski (slitkows) 
mailto:slitk...@cisco.com>>; 
draft-ietf-bess-mvpn-evpn-aggregation-la...@ietf.org<mailto:draft-ietf-bess-mvpn-evpn-aggregation-la...@ietf.org>
Cc: bess@ietf.org<mailto:bess@ietf.org>
Subject: RE: draft-ietf-bess-mvpn-evpn-aggregation-label-05 shepherd's review

Hi, Stephane,

Thanks you so much for your review!

Please see zzh> below (I skipped all those that will be fixed as you pointed 
out).

From: Stephane Litkowski (slitkows) 
mailto:slitk...@cisco.com>>
Sent: Monday, April 12, 2021 5:56 AM
To: 
draft-ietf-bess-mvpn-evpn-aggregation-la...@ietf.org<mailto:draft-ietf-bess-mvpn-evpn-aggregation-la...@ietf.org>
Cc: bess@ietf.org<mailto:bess@ietf.org>
Subject: draft-ietf-bess-mvpn-evpn-aggregation-label-05 shepherd's review

[External Email. Be cautious of content]

Hi,

Here is my review of the document:

Section 2.2:
s/the DCB MUST not intersect/the DCB MUST NOT intersect/

I don’t fully understand the purpose of the second part of the sentence :

“or those routers MUST be
   considered as part of the "domain".”

I think the DCB must not intersect with any other label block (common, or 
dynamic), otherwise there will be some issues.
That’s different from SRGB where each node could have a different one. This 
should be highlighted I think.

Zzh> The complete text is:


   If these PEs share other common

   label blocks (e.g.  SRGB) with other routers, the DCB MUST not

   intersect with those common label blocks or those routers MUST be

   considered as part of the "domain".

Zzh> The DCB can actually be part of a SRGB that is a common block on all 
routers (then each DCB label will take place of a SID from the SRGB), but we 
don’t want to simply say that DCB is part of a common SRGB.
Zzh> The PEs can be considered to be in a domain of themselves (separate from 
the SR domain when all routers use a “common” SRGB – where all those SRGBs are 
the same) for the purpose of defining “Domain-common Label Block”. Let’s say 
there are 10 PEs and the DCB is [1000, 2000]. On those 10 PEs the [1000,2000] 
can’t be used for other purposes, but on internal P-routers, that [1000, 2000] 
can be used for other purposes and there is no need to set aside that block on 
those P-routers. In other words, the DCB does not have to, and better not to be 
part of the SRGB or some other common label blocks of for a larger set of 
routers. That’s what we try to say – either DCB does not intersect with for 
example SRGB (red text), or all the routers involved in the SRGB will have be 
considered as part of the domain for the DCB (purple text).
Zzh> Indeed it’s a bit convoluted, but hopefully now you see what we wanted to 
say. I’ll try to think of better wording – suggestions are appreciated.

Section 3.2:

“If PE Distiguisher…, they must be allocated” => should this be a MUST be ? 
Previous sentence is using normative language

“When a PE receives an x-PMSI…, it programs its…” => It should be :”it MUST 
program”

“The receiving PE then programs…” => It should be “Then, the receiving PE MUST 
program…”

“A PE MUST ignore a received route” => what do you mean by ignore ? drop the 
update received ?

zzh> I meant treat as if it was not received from MVPN/EVPN procedure point of 
view. I did not consider “dropping” it (such that it won’t be further 
propagated if this router is in the propagation path to more PEs). While I 
think it is fine if it is dropped because other PEs are supposed to ignore it 
as well, it may make debugging more difficult because you’d see it advertised 
by its peer yet kept not on this router.

Zzh> Yes we’ll add a security section  Somehow we missed it.
Zzh> It is always a headache section to me though . Do you have any suggestions 
or foresee any security concerns?
Zzh> Will share an update once we get all done.
Zzh> Thanks.
Zzh> Jeffrey

“the label in the PTA … is treated as” 

Re: [bess] draft-ietf-bess-mvpn-evpn-aggregation-label-05 shepherd's review

[Jeffrey (Zhaohui) Zhang]

Hi, Stephane,

Thanks you so much for your review!

Please see zzh> below (I skipped all those that will be fixed as you pointed 
out).

From: Stephane Litkowski (slitkows) 
Sent: Monday, April 12, 2021 5:56 AM
To: draft-ietf-bess-mvpn-evpn-aggregation-la...@ietf.org
Cc: bess@ietf.org
Subject: draft-ietf-bess-mvpn-evpn-aggregation-label-05 shepherd's review

[External Email. Be cautious of content]

Hi,

Here is my review of the document:

Section 2.2:
s/the DCB MUST not intersect/the DCB MUST NOT intersect/

I don’t fully understand the purpose of the second part of the sentence :

“or those routers MUST be
   considered as part of the "domain".”

I think the DCB must not intersect with any other label block (common, or 
dynamic), otherwise there will be some issues.
That’s different from SRGB where each node could have a different one. This 
should be highlighted I think.

Zzh> The complete text is:


   If these PEs share other common

   label blocks (e.g.  SRGB) with other routers, the DCB MUST not

   intersect with those common label blocks or those routers MUST be

   considered as part of the "domain".

Zzh> The DCB can actually be part of a SRGB that is a common block on all 
routers (then each DCB label will take place of a SID from the SRGB), but we 
don’t want to simply say that DCB is part of a common SRGB.
Zzh> The PEs can be considered to be in a domain of themselves (separate from 
the SR domain when all routers use a “common” SRGB – where all those SRGBs are 
the same) for the purpose of defining “Domain-common Label Block”. Let’s say 
there are 10 PEs and the DCB is [1000, 2000]. On those 10 PEs the [1000,2000] 
can’t be used for other purposes, but on internal P-routers, that [1000, 2000] 
can be used for other purposes and there is no need to set aside that block on 
those P-routers. In other words, the DCB does not have to, and better not to be 
part of the SRGB or some other common label blocks of for a larger set of 
routers. That’s what we try to say – either DCB does not intersect with for 
example SRGB (red text), or all the routers involved in the SRGB will have be 
considered as part of the domain for the DCB (purple text).
Zzh> Indeed it’s a bit convoluted, but hopefully now you see what we wanted to 
say. I’ll try to think of better wording – suggestions are appreciated.

Section 3.2:

“If PE Distiguisher…, they must be allocated” => should this be a MUST be ? 
Previous sentence is using normative language

“When a PE receives an x-PMSI…, it programs its…” => It should be :”it MUST 
program”

“The receiving PE then programs…” => It should be “Then, the receiving PE MUST 
program…”

“A PE MUST ignore a received route” => what do you mean by ignore ? drop the 
update received ?

zzh> I meant treat as if it was not received from MVPN/EVPN procedure point of 
view. I did not consider “dropping” it (such that it won’t be further 
propagated if this router is in the propagation path to more PEs). While I 
think it is fine if it is dropped because other PEs are supposed to ignore it 
as well, it may make debugging more difficult because you’d see it advertised 
by its peer yet kept not on this router.

Zzh> Yes we’ll add a security section  Somehow we missed it.
Zzh> It is always a headache section to me though . Do you have any suggestions 
or foresee any security concerns?
Zzh> Will share an update once we get all done.
Zzh> Thanks.
Zzh> Jeffrey

“the label in the PTA … is treated as” => MUST be treated as

s/must be followed/MUST be followed


IANA considerations:
Could you rewrite slightly the text with more formal allocation requests (the 
content is here, it is just the way it is expressed that sounds weird to me). 
You can reuse the code points from the early allocation:

Example:
“IANA is requested to allocate the followings:

  *   Bit 47 (DCB-Bit) in the “Additional PMSI Tunnel Attribute Flags”  registry



 Bit Name Reference

 --   -

 47  DCB-bit  This document





  *   Sub-type 0x08 from the “Transitive Opaque Extended Community Sub-Types” 
registry and associated to the “Context Label Space ID Extended Community”


 Bit Name  Reference

 ---

 0x08Context Label Space ID Extended Community This document








Please add a security considerations section

Please update the references of drafts that have become RFCs now.

Here are the list of nits related to references:


  Checking references for intended status: Proposed Standard

  



 (See RFCs 3967 and 4897 for information about using normative references

 to lower-maturity documents in RFCs)



  == Missing Reference: 'RFC 8279' is mentioned on 

Re: [bess] WG Adoption and IPR Poll for draft-mishra-bess-deployment-guide-ipv4nlri-ipv6nh-03

[Jeffrey (Zhaohui) Zhang]

Support.

Jeffrey

From: BESS  On Behalf Of Bocci, Matthew (Nokia - GB)
Sent: Tuesday, April 13, 2021 5:37 AM
To: draft-mishra-bess-deployment-guide-ipv4nlri-ipv...@ietf.org; bess@ietf.org
Subject: [bess] WG Adoption and IPR Poll for 
draft-mishra-bess-deployment-guide-ipv4nlri-ipv6nh-03

[External Email. Be cautious of content]

Hello,

This email begins a two-weeks WG adoption poll for 
draft-mishra-bess-deployment-guide-ipv4nlri-ipv6nh-03 [1].

Please review the draft and post any comments to the BESS working group list.

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 will not  progress 
without answers from all of the authors and contributors.

Currently, there are no IPR disclosures against this document.

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.

This poll for adoption closes on April 27th 2021.

Regards,
Matthew and Stephane


[1] 
https://datatracker.ietf.org/doc/draft-mishra-bess-deployment-guide-ipv4nlri-ipv6nh/




Juniper Business Use Only
___
BESS mailing list
BESS@ietf.org
https://www.ietf.org/mailman/listinfo/bess

Re: [bess] WG Last Call, IPR and Implementation Poll for draft-ietf-bess-mvpn-evpn-aggregation-label-04

[Jeffrey (Zhaohui) Zhang]

Hi Stephane,

I forgot to mention that Juniper has a Proof of Concept implementation.
As soon as Ice confirms his new affiliation I'll submit a new revision with 
updated contact information for Eric and Ice.

Thanks.
Jeffrey

From: slitkows.i...@gmail.com 
Sent: Monday, January 4, 2021 5:43 AM
To: draft-ietf-bess-mvpn-evpn-aggregation-la...@ietf.org; bess@ietf.org
Cc: bess-cha...@ietf.org
Subject: RE: [bess] WG Last Call, IPR and Implementation Poll for 
draft-ietf-bess-mvpn-evpn-aggregation-label-04

[External Email. Be cautious of content]

We are still missing couple of IPR replies to close the WGLC: Eric, Ice (their 
email contact has to be updated).

In addition, we haven't received any reply regarding an existing 
implementation. Is anyone aware of an implementation ?

Brgds,

Stephane




From: BESS mailto:bess-boun...@ietf.org>> on behalf of 
slitkows.i...@gmail.com 
mailto:slitkows.i...@gmail.com>>
Date: Friday, December 11, 2020 at 4:53 PM
To: 
draft-ietf-bess-mvpn-evpn-aggregation-la...@ietf.org
 
mailto:draft-ietf-bess-mvpn-evpn-aggregation-la...@ietf.org>>,
 bess@ietf.org mailto:bess@ietf.org>>
Cc: bess-cha...@ietf.org 
mailto:bess-cha...@ietf.org>>
Subject: [bess] WG Last Call, IPR and Implementation Poll for 
draft-ietf-bess-mvpn-evpn-aggregation-label-04
This email starts a two-week working group last call for 
draft-ietf-bess-mvpn-evpn-aggregation-label-04 [1]

Please review the draft and send any comments to the BESS list. Also, please 
indicate if you support publishing the draft as a standards track RFC.

This poll runs until the 28th December 2020

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. The Document won't progress without answers from all the 
Authors and Contributors.
There is currently one IPR disclosure.

In addition, we are polling for knowledge of implementations of this draft, per 
the BESS policy in [2].

Thank you,
Matthew & Stephane


[1] 
https://datatracker.ietf.org/doc/draft-ietf-bess-mvpn-evpn-aggregation-label/
[2] 
https://mailarchive.ietf.org/arch/msg/bess/cG3X1tTqb_vPC4rg56SEdkjqDpw



Juniper Business Use Only
___
BESS mailing list
BESS@ietf.org
https://www.ietf.org/mailman/listinfo/bess

Re: [bess] Éric Vyncke's Abstain on draft-ietf-bess-mvpn-fast-failover-13: (with COMMENT)

[Jeffrey (Zhaohui) Zhang]

Ah. Perhaps vendors forgot/neglected to respond on the implementation question 
for this particular spec, I know of two implementations.

Jeffrey

-Original Message-
From: BESS  On Behalf Of slitkows.i...@gmail.com
Sent: Wednesday, December 16, 2020 5:39 AM
To: 'Éric Vyncke' ; 'The IESG' 
Cc: bess-cha...@ietf.org; draft-ietf-bess-mvpn-fast-failo...@ietf.org; 
bess@ietf.org
Subject: Re: [bess] Éric Vyncke's Abstain on 
draft-ietf-bess-mvpn-fast-failover-13: (with COMMENT)

[External Email. Be cautious of content]


Hi Eric,

Speaking as BESS WG chair, you raised a very valid point on the publication of 
documents that have no implementation (or plan of implementation). This is also 
a concern that I have in general, as we cannot really prove that a 
technology/specification is working properly if it hasn't been implemented.
I think the discussion is a bit orthogonal to this particular document.
In the routing area, each WG is free to have its own policy regarding 
implementations. In BESS, the WG decided that there will be an implementation 
poll then if there is no implementation, and if WG is still fine progressing 
the doc without an implementation, the document will continue until 
publication. Good or bad that could be discussed but this is the WG consensus 
(it was there before I took over the chair seat). This policy differs across 
WGs.
I don't think that the date of the doc really matters, even if the doc was more 
recent, nothing says that there will be an implementation in future, so 
situation will be the same. I personally don't like having non implemented 
specs but it's not just up to me and again this goes beyond just this document.

Brgds,

Stephane

-Original Message-
From: Éric Vyncke via Datatracker 
Sent: mercredi 16 décembre 2020 11:06
To: The IESG 
Cc: draft-ietf-bess-mvpn-fast-failo...@ietf.org; bess-cha...@ietf.org; 
bess@ietf.org; Stephane Litkowski ; 
slitkows.i...@gmail.com
Subject: Éric Vyncke's Abstain on draft-ietf-bess-mvpn-fast-failover-13: (with 
COMMENT)

Éric Vyncke has entered the following ballot position for
draft-ietf-bess-mvpn-fast-failover-13: Abstain

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.com/v3/__https://www.ietf.org/iesg/statement/discuss-criteria.html__;!!NEt6yMaO-gk!VKBlE-qjDQeeCsz4ekqM-S0M5txGOaciHBeicTqvPGGcOfOv2F_kB0LkcPs169tg$
for more information about IESG DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://urldefense.com/v3/__https://datatracker.ietf.org/doc/draft-ietf-bess-mvpn-fast-failover/__;!!NEt6yMaO-gk!VKBlE-qjDQeeCsz4ekqM-S0M5txGOaciHBeicTqvPGGcOfOv2F_kB0LkcD1j6hff$



--
COMMENT:
--

Thank you for the work put into this document.

I have balloted ABSTAIN in the sense of "I oppose this document but understand 
that others differ and am not going to stand in the way of the others." because 
of the use outside of a node of the IPv4-mapped IPv6 addresses in section 
3.1.6.1. A reply on this topic will be welcome.

Stéphane in his doc shepherd's write up states that no implementation is known 
for a document born in 2008... Does the IETF really want to have this on the 
proposed standards track ?

Please find below my ABSTAIN point, some non-blocking COMMENT points (but 
replies would be appreciated), and one nits.

I hope that this helps to improve the document,

Regards,

-éric

== ABSTAIN ==
-- Section 3.1.6.1 --
I appreciate that the BFD WG relies on ":::127.0.0.0/104" but those 
IPv4-mapped IPv6 addresses are assumed to never leave a node and should never 
be transmitted over the Internet (see 
https://urldefense.com/v3/__https://tools.ietf.org/html/rfc5156*section-2.2__;Iw!!NEt6yMaO-gk!VKBlE-qjDQeeCsz4ekqM-S0M5txGOaciHBeicTqvPGGcOfOv2F_kB0LkcKQDD6CU$
 ). This is the cause of my ABSTAIN. As the inner packet is sent over a tunnel, 
why not using the a link-local address or the ff02::1 link-local multicast 
group ?

== COMMENTS ==

-- Section 2.3 --
The use of "upstream" and "Upstream" could be confusing... The latter could 
have been "Upstream PE/ABSR" (often used later in the document) or "ingress 
node"

-- Section 3.1.6 --
Could the "BFD Discreminator" attribute be used for other purpose than this 
document? If so, then why not specifying it in *another* document?

Should this document clearly state that it does not define any TLV ?

== NITS ==

As I am probably not the only reader have difficulties to remember RFC contents 
by their number, may I suggest to prefix the RFC numbers with their titles ?
Esp in the introduction ;-)




___
BESS mailing list
BESS@ietf.org

Re: [bess] WG Last Call, IPR and Implementation Poll for draft-ietf-bess-mvpn-evpn-aggregation-label-04

[Jeffrey (Zhaohui) Zhang]

Support as co-author.
Not aware of undisclosed IPRs.

Thanks.
Jeffrey

From: slitkows.i...@gmail.com 
Sent: Friday, December 11, 2020 10:53 AM
To: draft-ietf-bess-mvpn-evpn-aggregation-la...@ietf.org; bess@ietf.org
Cc: bess-cha...@ietf.org
Subject: WG Last Call, IPR and Implementation Poll for 
draft-ietf-bess-mvpn-evpn-aggregation-label-04

[External Email. Be cautious of content]

This email starts a two-week working group last call for 
draft-ietf-bess-mvpn-evpn-aggregation-label-04 [1]

Please review the draft and send any comments to the BESS list. Also, please 
indicate if you support publishing the draft as a standards track RFC.

This poll runs until the 28th December 2020

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. The Document won't progress without answers from all the 
Authors and Contributors.
There is currently one IPR disclosure.

In addition, we are polling for knowledge of implementations of this draft, per 
the BESS policy in [2].

Thank you,
Matthew & Stephane


[1] 
https://datatracker.ietf.org/doc/draft-ietf-bess-mvpn-evpn-aggregation-label/
[2] 
https://mailarchive.ietf.org/arch/msg/bess/cG3X1tTqb_vPC4rg56SEdkjqDpw



Juniper Business Use Only
___
BESS mailing list
BESS@ietf.org
https://www.ietf.org/mailman/listinfo/bess

Re: [bess] WG adoption for draft-skr-bess-evpn-redundant-mcast-source

[Jeffrey (Zhaohui) Zhang]

Support as co-author.
Not aware of IPRs.

Thanks.
Jeffrey

From: slitkows.i...@gmail.com 
Sent: Tuesday, December 1, 2020 4:31 AM
To: bess@ietf.org; draft-skr-bess-evpn-redundant-mcast-sou...@ietf.org
Subject: WG adoption for draft-skr-bess-evpn-redundant-mcast-source

[External Email. Be cautious of content]

Hello,

This email begins a two-weeks WG adoption poll for 
draft-skr-bess-evpn-redundant-mcast-source
 [1].

Please review the draft and post any comments to the BESS working group list.

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 will not  progress 
without answers from all of the authors and contributors.

Currently, there are no IPR disclosures against this document.

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.

This poll for adoption closes on 15th December 2020.

Regards,
Matthew and Stephane

[1]  
https://datatracker.ietf.org/doc/draft-skr-bess-evpn-redundant-mcast-source/






Juniper Business Use Only
___
BESS mailing list
BESS@ietf.org
https://www.ietf.org/mailman/listinfo/bess

Re: [bess] comments on draft-boutros-bess-elan-services-over-sr

[Jeffrey (Zhaohui) Zhang]

To clarify, when I said “evpn-like solution” I was referring to the fact that 
it uses service-SID/label instead of per-PW labels, and it supports split 
horizon for multi-homing.

As for control  plane learning vs. data plane learning, I don’t know about the 
history, but my impression is that control plane learning is considered as a 
feature but not as a fallback solution for not having the PW contexts for do 
data plane learning. I could be wrong though.

Jeffrey

From: Sami Boutros 
Sent: Thursday, November 19, 2020 12:11 PM
To: Rabadan, Jorge (Nokia - US/Mountain View) 
Cc: Jeffrey (Zhaohui) Zhang ; bess@ietf.org
Subject: Re: [bess] comments on draft-boutros-bess-elan-services-over-sr

[External Email. Be cautious of content]

Hi Jorge,



On Nov 19, 2020, at 5:09 AM, Rabadan, Jorge (Nokia - US/Mountain View) 
mailto:jorge.raba...@nokia.com>> wrote:

Hi everyone,

Jeffrey, not sure how much of EVPN this solution is, since there are no 
‘overlay’ routes advertised. In fact the draft says that no routes type 1..4 
are needed at all.
But I see your point Jeffrey, and I agree the concept of the source 
identification is not SR specific.

Agreed, source identification is not SR specific.



@Sami,

I couldn’t speak during the meeting so I’ll throw a couple of general 
comments/questions:


  1.  While I see the anycast-SID as an interesting point, I disagree with the 
document’s motivation that EVPN needed to introduce control-plane learning due 
to the MP2P tunnels.

What I said is with MP2P tunnels EVPN was forced to only control plane Mac 
learning. Are you saying this is incorrect? If so, Why?



  1.  Control plane learning has a lot of advantages and data-plane 
learning/aging has tons of issues. So this should be debated in the WG.

Sure, will be good to get Service providers input on that too. One thing to 
note here, our proposal is by no mean don’t use EVPN, it is simply another 
option that greatly simplify the control plane and remove tons of control plane 
overhead, as well simplify the data plane and remove need for any overlay 
convergence.




  1.  Irrespective, the anycast-SID idea could work in regular EVPN as an 
optional alternative to aliasing. You don’t need to do data-plane learning for 
that, right?

Agreed, any technology can use any cast SID.



  1.

  1.  The document seems to claim fast mac move. How can that be guaranteed if 
the mac learning is data plane based?

In data plane when a MAC move from one port to another, or one PW to another, 
routers simply adjust no need for any EVPN procedure for MAC move.




  1.  ARP suppression is not a merit of this solution. It could work even in 
RFC4761/74762 VPLS networks.


Agreed, we don’t claim any of that, the proposal doesn’t claim that it invented 
ARP suppression, or invented SR, it simply say it will use it this way, I hope 
this is OK.




I have a few more, but those are enough to start.

Thanks,

Sami

Thank you!
Jorge


From: BESS mailto:bess-boun...@ietf.org>>
Date: Thursday, November 19, 2020 at 12:46 PM
To: bess@ietf.org<mailto:bess@ietf.org> mailto:bess@ietf.org>>
Subject: [bess] comments on draft-boutros-bess-elan-services-over-sr
Hi,

It seems that the draft is about using data-plane mac learning in an EVPN-like 
solution. That retains other properties of EVPN, but removes the need for 
advertising MAC addresses, with the consequences/problems that Ali was trying 
to point out.

Leaving the pros and cons of data plane mac learning out, I want to point out 
that the idea is actually orthogonal with SR - even if SR were not invented 
this concept still applies. With VXLAN the source address corresponds to the 
"source node SID", and with MPLS the "PE Distinguisher Label" in MVPN (and 
extended to other use cases) serves the same purpose. That same "PE 
Distinguisher Label" concept is also used in my Generic Fragmentation proposal.

With that, the discussion for this draft should be in BESS, not in SPRING.

Jeffrey

Juniper Business Use Only

___
BESS mailing list
BESS@ietf.org<mailto:BESS@ietf.org>
https://www.ietf.org/mailman/listinfo/bess<https://urldefense.com/v3/__https:/www.ietf.org/mailman/listinfo/bess__;!!NEt6yMaO-gk!VxGsf2muy1oOc43yyMHygNmGkHp0T1soQk5peu2Fy52TPBZCmPstnw7sc4NEkzej$>
___
BESS mailing list
BESS@ietf.org<mailto:BESS@ietf.org>
https://www.ietf.org/mailman/listinfo/bess<https://urldefense.com/v3/__https:/www.ietf.org/mailman/listinfo/bess__;!!NEt6yMaO-gk!VxGsf2muy1oOc43yyMHygNmGkHp0T1soQk5peu2Fy52TPBZCmPstnw7sc4NEkzej$>



Juniper Business Use Only
___
BESS mailing list
BESS@ietf.org
https://www.ietf.org/mailman/listinfo/bess

Re: [bess] [Pals] Mail regarding draft-zzhang-tsvwg-generic-transport-functions

[Jeffrey (Zhaohui) Zhang]

Stewart,

Please see zzh2> below.

From: Stewart Bryant 
Sent: Thursday, November 19, 2020 1:21 AM
To: Jeffrey (Zhaohui) Zhang 
Cc: Stewart Bryant ; Andrew G. Malis 
; draft-zzhang-tsvwg-generic-transport-functi...@ietf.org; 
mpls ; p...@ietf.org; bess@ietf.org
Subject: Re: [Pals] Mail regarding 
draft-zzhang-tsvwg-generic-transport-functions

[External Email. Be cautious of content]

On 11 Nov 2020, at 16:32, Jeffrey (Zhaohui) Zhang 
mailto:zzh...@juniper.net>> wrote:

Zzh> I see what you mean. Perhaps we can separate the one-octet “Next Header” 
from the existing IP “Next Header” space so that the first nibble is always 
? That gives us 16 types of “Next Header” – or we only need to make sure 
the nibble is not 4 or 6 – that gives us more types.



You should use .

This is the IP version number space. 4 and 6 are taken as IP. BIER sits on 3, 
PWs sit on 0 and 1 (for OAM), and of course there is a chance that INT might 
like invent another IP at some time in the future (a general note and nothing 
to do with NewIP).

Zzh> Agreed.

Now what I am not sure about is why you need a next header as this is not 
needed elsewhere in MPLS PWs.

Zzh> PW fragmentation is in the context of PWs, and the egress PE does not need 
to care what the payload it is.
Zzh> With *generic* fragmentation, the egress PE does need to care what the 
reassembled payload is to continue processing, that’s why it needs a “next 
header” field.

If you do, then I would suggest that 16 is likely too few.

Zzh> Because of that, what was presented in BIER/BESS is that the “Hdr Len” 
field, not the “Next Header” field gets squeezed. The Next Header field is 
still 8-bit. The “Hdr Len” is 4-bit but in the unit of 8-octets, so it should 
be enough (and we could make it 16-octet units if necessary).

   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |0 0 0 0|  Next Header  |Hdr Len|  Fragment Offset|R|S|M|
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | Identification|
   |   (variable)  |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

The standard MPLS method is to trigger processing from the label, so if you 
want to do other processing then why not allocate a new label so you can vector 
straight to the right packet handler.

Zzh> There is a GFH label in front of the GFH, and that tells the packet 
handler that a GFH follows (and optionally tell who did the fragmentation – the 
reassembling node can advertise different GFH labels for different fragmenting 
nodes).
Zzh> It’s what happens after the reassembly that requires the “Next Header” in 
the GFH. Consider the EVPN-MPLS example, the fragments received by the egress 
PE have the following headers: , where the 
label stack1 is  and the label stack2 is . In potential other use cases (we’re talking about “generic” 
fragmentation), the payload after the GFH may be other types.

What I think you need is the existing PW frag design with the identification 
field appended. Then to advertise those propertied with the label.

Zzh> The intention is to have a generic solution, not tied to EVPN-MPLS or PW. 
You can see that while the immediate use case is EVPN-MPLS, the solution is not 
tied to it. *In theory*, this can be used for fragmenting at Ethernet level 
between two Ethernet nodes.
Zzh> Thanks!
Zzh> Jeffrey

- Stewart





Juniper Business Use Only
___
BESS mailing list
BESS@ietf.org
https://www.ietf.org/mailman/listinfo/bess

[bess] comments on draft-boutros-bess-elan-services-over-sr

[Jeffrey (Zhaohui) Zhang]

Hi,

It seems that the draft is about using data-plane mac learning in an EVPN-like 
solution. That retains other properties of EVPN, but removes the need for 
advertising MAC addresses, with the consequences/problems that Ali was trying 
to point out.

Leaving the pros and cons of data plane mac learning out, I want to point out 
that the idea is actually orthogonal with SR - even if SR were not invented 
this concept still applies. With VXLAN the source address corresponds to the 
"source node SID", and with MPLS the "PE Distinguisher Label" in MVPN (and 
extended to other use cases) serves the same purpose. That same "PE 
Distinguisher Label" concept is also used in my Generic Fragmentation proposal.

With that, the discussion for this draft should be in BESS, not in SPRING.

Jeffrey

Juniper Business Use Only

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

Re: [bess] [Pals] Mail regarding draft-zzhang-tsvwg-generic-transport-functions

[Jeffrey (Zhaohui) Zhang]

Hi Stewart,

In my previous email, I acknowledged that ECMP issue you brought up and 
proposed a solution.
In fact, we can make the GFH to start with nibble .

Thanks.
Jeffrey

From: Stewart Bryant 
Sent: Monday, November 16, 2020 4:35 AM
To: Jeffrey (Zhaohui) Zhang 
Cc: Stewart Bryant ; Andrew G. Malis 
; draft-zzhang-tsvwg-generic-transport-functi...@ietf.org; 
mpls ; p...@ietf.org; bess@ietf.org
Subject: Re: [Pals] Mail regarding 
draft-zzhang-tsvwg-generic-transport-functions

[External Email. Be cautious of content]

I think that it would be more productive to address the known issues first, 
particularly the issue of ECMP and the need to change the packet structure to 
make it ECMP safe, and then the WG discussion will be more focused.

- Stewart



On 12 Nov 2020, at 21:37, Jeffrey (Zhaohui) Zhang 
mailto:zzh...@juniper.net>> wrote:

Hi Stewart,

I hope you did not mean that the draft should not be presented. Whether 
detailed discussions can happen after the presentation in the session itself 
depends on many factors (we quite often run out of time in the sessions), and 
the presentation itself quite often is a good way to stir up wide discussions.

Thanks to your review and comment, I think we’re having good discussions on 
mailing lists on the draft. I hope I have answered your questions and addressed 
your main concerns, and I hope more people chime in, before and after the 
presentations in relevant WGs.

Thanks.
Jeffrey


From: Stewart Bryant mailto:stewart.bry...@gmail.com>>
Sent: Thursday, November 12, 2020 7:16 AM
To: Jeffrey (Zhaohui) Zhang mailto:zzh...@juniper.net>>
Cc: Stewart Bryant mailto:stewart.bry...@gmail.com>>; 
Andrew G. Malis mailto:agma...@gmail.com>>; 
draft-zzhang-tsvwg-generic-transport-functi...@ietf.org<mailto:draft-zzhang-tsvwg-generic-transport-functi...@ietf.org>;
 mpls mailto:m...@ietf.org>>; 
p...@ietf.org<mailto:p...@ietf.org>; bess@ietf.org<mailto:bess@ietf.org>
Subject: Re: [Pals] Mail regarding 
draft-zzhang-tsvwg-generic-transport-functions

[External Email. Be cautious of content]

In my view, the discussion on this draft demonstrate that it is not yet ready 
for detailed discussion by these working groups next week.

- Stewart




On 11 Nov 2020, at 16:32, Jeffrey (Zhaohui) Zhang 
mailto:zzh...@juniper.net>> wrote:

Hi Andy, Stewart,

Please see zzh> below.

From: Andrew G. Malis mailto:agma...@gmail.com>>
Sent: Wednesday, November 11, 2020 8:17 AM
To: Stewart Bryant mailto:stewart.bry...@gmail.com>>
Cc: Jeffrey (Zhaohui) Zhang mailto:zzh...@juniper.net>>; 
draft-zzhang-tsvwg-generic-transport-functi...@ietf.org<mailto:draft-zzhang-tsvwg-generic-transport-functi...@ietf.org>;
 mpls mailto:m...@ietf.org>>; p...@ietf.org<mailto:p...@ietf.org>
Subject: Re: [Pals] Mail regarding 
draft-zzhang-tsvwg-generic-transport-functions

[External Email. Be cautious of content]

Just to add a bit to Stewart's replies, I assume that you've read RFC 8469, 
which was the result of the "disorderly queue of operators at the door of PALS".

Zzh> Actually I need to read on that yet.

Also, regarding VPLS, VPLS is just a full mesh of P2P Ethernet PWs, and while 
RFC 4762 is silent on the CW, in practice many (most?) VPLS implementations use 
the CW.

Zzh> OK if VPLS relies on data plane mac learning for packets received from the 
core then indeed they’re a full mesh of PWs and that’s different from EVPN. 
I’ll need to dig deeper into that. Still, if we solve the EVPN problem using 
the generic fragmentation method, the solution works for VPLS/PW as well.

Cheers,
Andy


On Wed, Nov 11, 2020 at 8:11 AM Stewart Bryant 
mailto:stewart.bry...@gmail.com>> wrote:
Oh there is a deeper problem

Unless you guarantee that you have defeated ECMP, which I don’t think the 
design does since first nibble is not , I think the different fragments can 
get ECMPed differently. If that happens then (unlike the PW case) you cannot be 
sure that the fragments will arrive on the same LC, and that means that you 
need to support cross line card reassembly. If that happens your performance 
falls through the floor.
Zzh> I see what you mean. Perhaps we can separate the one-octet “Next Header” 
from the existing IP “Next Header” space so that the first nibble is always 
? That gives us 16 types of “Next Header” – or we only need to make sure 
the nibble is not 4 or 6 – that gives us more types.
Zzh> Thanks.
Zzh> Jeffrey

Of course you could argue that it will mostly work, just like people argued 
that not having the CW would work well enough in PW, and it did mostly work, 
until it didn’t and we had a disorderly :) queue of operators at the door of 
PALS WG.

Now what happens in the VPN cases in the existing design is that just like PW 
you will be seeing occasional Ethernet reordering, which mostly does not matter 
because what is being carried is IP, but as we fo

[bess] FW: [Pals] Mail regarding draft-zzhang-tsvwg-generic-transport-functions

[Jeffrey (Zhaohui) Zhang]

Forwarding this discussion to BESS list as the main use case now is EVPN.
This draft is also on the BESS agenda.


From: Jeffrey (Zhaohui) Zhang
Sent: Tuesday, November 10, 2020 6:13 PM
To: Andrew G. Malis ; Stewart Bryant 

Cc: draft-zzhang-tsvwg-generic-transport-functi...@ietf.org; mpls 
; p...@ietf.org
Subject: RE: [Pals] Mail regarding 
draft-zzhang-tsvwg-generic-transport-functions

Hi Andy, Stewart,

If I understand it correctly, RFC4623 is specifically for PWs (p2p) and cannot 
be used for EVPN/VPLS.

The reason is that the sequence number in the control word is specific to the 
PW and the fragmentation/reassembly is performed in the context of the PW. In 
case of EVPN/VPLS, an egress PE could receive fragments from different ingress 
PEs and reassembly must be done in the right context.

In addition, RFC 7432 (EVPN) specifically calls out that control word is either 
not used or only with all-0:

   - If a network uses deep packet inspection for its ECMP, then the
 "Preferred PW MPLS Control Word" 
[RFC4385<https://tools.ietf.org/html/rfc4385>] SHOULD be used with the
 value 0 (e.g., a 4-octet field with a value of zero) when sending
 EVPN-encapsulated packets over an MP2P LSP.

   - If a network uses entropy labels 
[RFC6790<https://tools.ietf.org/html/rfc6790>], then the control word
 SHOULD NOT be used when sending EVPN-encapsulated packets over an
 MP2P LSP.

   - When sending EVPN-encapsulated packets over a P2MP LSP or P2P LSP,
 then the control word SHOULD NOT be used.

This draft-zzhang allows the context to be determined from the extended 
“identification” field or from the outer header. In addition, it is “generic” 
such that it can be used for any situations where fragmentation is needed at 
any layer for any solution.

Thanks.

Jeffrey

From: Andrew G. Malis mailto:agma...@gmail.com>>
Sent: Tuesday, November 10, 2020 10:33 AM
To: Stewart Bryant mailto:stewart.bry...@gmail.com>>
Cc: 
draft-zzhang-tsvwg-generic-transport-functi...@ietf.org<mailto:draft-zzhang-tsvwg-generic-transport-functi...@ietf.org>;
 mpls mailto:m...@ietf.org>>; p...@ietf.org<mailto:p...@ietf.org>
Subject: Re: [Pals] Mail regarding 
draft-zzhang-tsvwg-generic-transport-functions

[External Email. Be cautious of content]

Indeed, this is an already-solved problem.

Cheers,
Andy


On Tue, Nov 10, 2020 at 9:57 AM Stewart Bryant 
mailto:stewart.bry...@gmail.com>> wrote:
Please can I draw the attention of the authors to 
https://tools.ietf.org/html/rfc4623<https://urldefense.com/v3/__https:/tools.ietf.org/html/rfc4623__;!!NEt6yMaO-gk!WnDW7J-i0YOpcV5sF1KDAfZnAaxHY5z-pG0oiSXKdSXdg9o9pRoRlJeq1ENEdsSd$>

This standards track RFC  specifies how you can sent a fragmented Ethernet 
frame over a PW in an MPLS network and would seem applicable to the problem 
that you address in your draft.

BR

Stewart
___
Pals mailing list
p...@ietf.org<mailto:p...@ietf.org>
https://www.ietf.org/mailman/listinfo/pals<https://urldefense.com/v3/__https:/www.ietf.org/mailman/listinfo/pals__;!!NEt6yMaO-gk!WnDW7J-i0YOpcV5sF1KDAfZnAaxHY5z-pG0oiSXKdSXdg9o9pRoRlJeq1KRQDg8M$>


Juniper Business Use Only
___
BESS mailing list
BESS@ietf.org
https://www.ietf.org/mailman/listinfo/bess