[bess] RtgDir Early review: draft-ietf-bess-datacenter-gateway-10.txt

[Ravi Singh]

Hello

I have been selected to do a routing directorate “early” review of this draft.

draft-ietf-bess-datacenter-gateway

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.


Document: draft-ietf-bess-datacenter-gateway-10.txt
Reviewer: Ravi Singh
Review Date: 04/30/2021
Intended Status: Standards Track

Summary:
No issues found. This documents is ready to proceed to the IESG.

Regards
Ravi

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

[bess] Rtgdir last call review of draft-ietf-bess-evpn-proxy-arp-nd-09

[Ravi Singh via Datatracker]

Reviewer: Ravi Singh
Review result: Has Nits

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 Last Call
comments that you receive, and strive to resolve them through discussion or by
updating the draft.

Document: draft-ietf-bess-evpn-proxy-arp-nd
Reviewer: Ravi Singh
Review Date: 21 Dec 2020
Intended Status: Standards track (as listed on the draft)

Summary:

This document is basically ready for publication, but has nits that should be
considered prior to publication.

Comments:

The draft is generally well written and easy to understand.
It basically is a description to explain how ARP, ND, EVPN should work together
to reduce forwarding of ARP queries and/or NS messages, in an EVPN deployment,
by the use of gratuitous ARP/ND. The abstract, though, could be made more
direct by stating as such.

Major Issues: none found.

Minor Issues: none found.

Nits:
1. Figure 1: please show which device owns IP3, for more clarity.

2.  Section 4.6 (a):
a. "   IP moves before the timer expires (default value of N=5), it
   concludes that a duplicate IP situation has occurred.  An IP move". It
   would be nice to elaborate on why the default value of "5" is
   recommended. Why not 1? Too much thrashing? However, for the cases where
   there is no thrashing, having a value of 5 as default slows the DAD
   procedure. Any recommendation on how to address that?
b.  Minor typo: "   owner and spoofer keep replying to the
CONFIRM message, the PE
   will detect the duplicate IP within the M timer:" ->
"  owner and spoofer keep replying to the CONFIRM message,
the PE
   will detect the duplicate IP within the M-second timer:"

3. Biggest nit: the draft does not really specify any new messaging formats or
any new fields. It is basically saying how the existing ARP, ND, EVPN
messaging/machinery (should) work together to achieve flooding-minimization of
ARP/ND queries in EVPN. Given the foregoing, it is not clear to me if the draft
really should be considered "standards track" instead of "informational". The
chairs are requested to evaluate that.

Best regards
Ravi


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

[bess] RtgDir Early review: draft-ietf-bess-datacenter-gateway.txt

[Ravi Singh]

Hello

I have been selected to do a routing directorate “early” review of this draft.

https://datatracker.ietf.org/doc/draft-ietf-bess-datacenter-gateway/ 
<https://datatracker.ietf.org/doc/draft-ietf-bess-datacenter-gateway/> 

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.

Document: draft-ietf-bess-datacenter-gateway 
<https://datatracker.ietf.org/doc/draft-ietf-bess-datacenter-gateway/>.txt
Reviewer: Ravi Singh
Review Date: 06/26/2020
Intended Status: Standards track (but is it the right one? Should this be 
informational instead, since no new encodings are explicitly specified)

Summary:
I have some minor concerns about this document that I think should be resolved 
before it is submitted to the IESG.

Comments:
1. Draft track: does this need to be "standards track”? No new encodings are 
specified, even though there are requests for new IANA code-points.
2. Section 3:
a. Auto-discovery: setting the route-target to SR-ID: how to avoid 
conflicts in regards to route-target settings: some may represent the SR ID and 
other represent non-SR constructs? Some text in that regard would be helpful.
b. The draft would do well to explicitly state what happens if the GWs 
in a given domain end up getting configured with different SR IDs.
c. Is there a specific reason why neither the format for the SR tunnel 
TLV is listed nor a pointer given to a pre-existing definition in another doc?
3. Section. 5: could use an example with reference to figure 1.
4. Section 6: would be useful to describe, or provide pointer to section in the 
tunnel-encaps draft, stating logic for picking a specific encapsulation for a 
given packet.

Regards
Ravi

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

[bess] RtgDir review: draft-ietf-bess-nsh-bgp-control-plane-13

[Ravi Singh]

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 
<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 Last Call 
comments that you receive, and strive to resolve them through discussion or by 
updating the draft.

Document: draft-ietf-bess-nsh-bgp-control-plane-13.txt
Reviewer: Ravi Singh
Review Date: 01-26-2020
Intended Status: Standards Track

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


Comments: 
0.  Having finished reading through the entire doc, the whole picture comes 
together clearly. 
However, given the size of this document…..as one is reading this document it 
takes a high level of effort to stay with the picture.
I feel the readability could be somewhat improved.  See #1 under “minor issues” 
for a suggestion.

Major Issues:
No major issues found.

Minor issues:

1.
Section2: During an initial reading, the terminology comes across as overly 
repetitive and a bit pedantic….which takes away from the readability a bit when 
one is reading the sections in the order listed. Content of RFC7665/8300 are 
also contributors to this.
Eg: "In fact, each SI is mapped to one or more SFs that are implemented by one 
or more Service Function Instances (SFIs) that support those specified SFs. "  
: almost sounds like legalese when someone who has not grasped the complete 
picture of the draft.
 
Wrote up the above as I was reading that section for the first time.
However, after finishing the review…started to appreciate this.
 
In having read the sections in order, I think the readability would have been 
greatly enhanced if I had read section 8 first, else once just gets lost in all 
the details.
It would be worthwhile suggesting in the text that once the reader has read 
through section 2, it would help to read section 8 before reviewing the 
intervening sections.
 
2. Section 3.2.1: page 16:
"[RFC7606]
   revises BGP error handling specifically for the for UPDATE message,"
 
->
"[RFC7606]
   revises BGP error handling specifically for the UPDATE message,”

3. 
Page 17:
  a. Was the intention for treating error 4 any different from errors, 
[1,2,6,7]? If not, why the need to call out 4 separately?
  b. "Unknown SFIR-RD found in a Hop TLV." :
The format of the Hop TLV in section 3.2.1.2 contains no reference to an RD. 
So, was the intention instead to refer to the SFIR-RD list of one of the SFT 
TLVs inside the Hop TLV?

4.
Section 3.2.1.2: "At least one sub-TLV MUST be present. "
Where are these sub-TLVs defined?
In this regard,
  a. Section 3.2.1.3 says "The SFT TLV MAY be included in the list of sub-TLVs 
of the Hop TLV.":
  b. Section 3.2.1.4 says "The MPLS Swapping/Stacking TLV (Type value 4) is a 
zero length sub-TLV that is OPTIONAL in the Hop TLV "

In the absence of specific mention of details of sub-TLVs in section 3.2.1.2, 
is a reader to assume that SFT TLVs & the MPLS swap/stack TVLs are the only 
possible subTLVs under a hop-TLV (as intended in this revision of the ID)?
This aspect becomes clear later, when one gets to reading the description of 
the subsequently mentioned TLVs. Might be worth alluding to this in 3.2.1.2.

5.
"In the normal case the SPI remains unchanged and the SI will have been 
decremented to indicate the next SF along the path.": will SI really be 
decremented instead of just setting it to the appropriate value? As per this 
draft, set to an appropriate lower value…

6.
What exactly does the following mean? "Also, as described in [RFC8300], an SFF 
receiving an SI that is unknown in the context of the SPI can reduce the value 
to the next meaningful SI value in the SFP indicated by the SPI. If no such 
value exists or if the SFF does not support this function, the SFF drops the 
packet and should log the event: such logs are also subject to rate limits."

7. 
Figure 1: showing the SFIs hosted on SFF2 and SFF3 in the same conceptual block 
(just because they share the same type) is a bit confusing when the diagram is 
showing a logical view of the physical layout of the elements of the solution.

8.
Section 3.1:the following is an ambiguous sentence & I suggest rewording to 
clarify:
"Note that it is assumed that each SFF has one or more globally unique SFC 
Context Labels and that the context label space and the SPI address space are 
disjoint." 
This sounds like that th

Re: [bess] Suresh Krishnan's No Objection on draft-ietf-bess-bgp-vpls-control-flags-07: (with COMMENT)

[Ravi Singh]

Hi Suresh
I've incorporated your suggestions.
Good catch with the PE#.
Thanks
Ravi


> -Original Message-
> From: Suresh Krishnan via Datatracker [mailto:nore...@ietf.org]
> Sent: Wednesday, April 10, 2019 2:06 PM
> To: The IESG 
> Cc: draft-ietf-bess-bgp-vpls-control-fl...@ietf.org; Mach Chen
> ; bess-cha...@ietf.org; mach.c...@huawei.com;
> bess@ietf.org
> Subject: Suresh Krishnan's No Objection on draft-ietf-bess-bgp-vpls-control-
> flags-07: (with COMMENT)
> 
> Suresh Krishnan has entered the following ballot position for
> draft-ietf-bess-bgp-vpls-control-flags-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.proofpoint.com/v2/url?u=https-
> 3A__www.ietf.org_iesg_statement_discuss-
> 2Dcriteria.html&d=DwICaQ&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-
> ndb3voDTXcWzoCI&r=6ArkE4n20mNZQF6JxrMYwJyAGBWWjzhSIC2O3-
> fXPV4&m=pzsWkhBzz_3yLDUnmN0UbkPf_p5BADMOhJgrC_0jacg&s=j_gNqE_
> T0Hk311M_869rOxlH7UEi2ibzzk6wcL8OgXc&e=
> for more information about IESG DISCUSS and COMMENT positions.
> 
> 
> The document, along with other ballot positions, can be found here:
> https://urldefense.proofpoint.com/v2/url?u=https-
> 3A__datatracker.ietf.org_doc_draft-2Dietf-2Dbess-2Dbgp-2Dvpls-2Dcontrol-
> 2Dflags_&d=DwICaQ&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-
> ndb3voDTXcWzoCI&r=6ArkE4n20mNZQF6JxrMYwJyAGBWWjzhSIC2O3-
> fXPV4&m=pzsWkhBzz_3yLDUnmN0UbkPf_p5BADMOhJgrC_0jacg&s=O5fMim
> eqIH5jMTUK56EztAjp0d3qRHrPZPf-n2K_T6Q&e=
> 
> 
> 
> --
> COMMENT:
> --
> 
> * Section 6
> 
> I think this network diagram would be useful in understanding Section 5 and
> should be moved before the discussions in Section 5.
> 
> * Section 5.2
> 
> "and no PW between PE1 and PE4"
> 
> Shouldn't this be
> 
> "and no PW between PE2 and PE4"
> 
> as the draft was discussing multihomed connectivity from PE2 towards A5.
> 

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

Re: [bess] Éric Vyncke's No Objection on draft-ietf-bess-bgp-vpls-control-flags-07: (with COMMENT)

[Ravi Singh]

Thanks Éric.
Addressed in -08.

> -Original Message-
> From: Éric Vyncke via Datatracker [mailto:nore...@ietf.org]
> Sent: Saturday, April 6, 2019 2:47 PM
> To: The IESG 
> Cc: draft-ietf-bess-bgp-vpls-control-fl...@ietf.org; Mach Chen
> ; bess-cha...@ietf.org; mach.c...@huawei.com;
> bess@ietf.org
> Subject: Éric Vyncke's No Objection on draft-ietf-bess-bgp-vpls-control-flags-
> 07: (with COMMENT)
> 
> Éric Vyncke has entered the following ballot position for
> draft-ietf-bess-bgp-vpls-control-flags-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.proofpoint.com/v2/url?u=https-
> 3A__www.ietf.org_iesg_statement_discuss-
> 2Dcriteria.html&d=DwIDaQ&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-
> ndb3voDTXcWzoCI&r=6ArkE4n20mNZQF6JxrMYwJyAGBWWjzhSIC2O3-
> fXPV4&m=DI1C2cqrKdjS4t1-9iiuLXEM-GA-
> AXYohN2TUfw48hI&s=YRPUgrdZlhwYEzosKM7zndApkDVI8VD0ms1Y3lImBSM
> &e=
> for more information about IESG DISCUSS and COMMENT positions.
> 
> 
> The document, along with other ballot positions, can be found here:
> https://urldefense.proofpoint.com/v2/url?u=https-
> 3A__datatracker.ietf.org_doc_draft-2Dietf-2Dbess-2Dbgp-2Dvpls-2Dcontrol-
> 2Dflags_&d=DwIDaQ&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-
> ndb3voDTXcWzoCI&r=6ArkE4n20mNZQF6JxrMYwJyAGBWWjzhSIC2O3-
> fXPV4&m=DI1C2cqrKdjS4t1-9iiuLXEM-GA-
> AXYohN2TUfw48hI&s=smwaBWBm_CPboPaBzcj-L_hy-
> qm9KBlnU3_VFaLAju4&e=
> 
> 
> 
> --
> COMMENT:
> --
> 
> Minor comment: sections 3.1 and 3.2 have different ways of describing a
> mismatch between the 2 PE. Text is clear and non ambiguous but I prefer
> section
> 3.2 "If the PEs at both ends of the PW do not agree" which is concise.
> 

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

Re: [bess] Barry Leiba's No Objection on draft-ietf-bess-bgp-vpls-control-flags-07: (with COMMENT)

[Ravi Singh]

Hi Barry
Thanks for your input.
Been addressed in -08.
Regards
Ravi


> -Original Message-
> From: Barry Leiba via Datatracker [mailto:nore...@ietf.org]
> Sent: Sunday, April 7, 2019 11:02 PM
> To: The IESG 
> Cc: draft-ietf-bess-bgp-vpls-control-fl...@ietf.org; Mach Chen
> ; bess@ietf.org
> Subject: Barry Leiba's No Objection on draft-ietf-bess-bgp-vpls-control-flags-
> 07: (with COMMENT)
> 
> Barry Leiba has entered the following ballot position for
> draft-ietf-bess-bgp-vpls-control-flags-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.proofpoint.com/v2/url?u=https-
> 3A__www.ietf.org_iesg_statement_discuss-
> 2Dcriteria.html&d=DwIDaQ&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-
> ndb3voDTXcWzoCI&r=6ArkE4n20mNZQF6JxrMYwJyAGBWWjzhSIC2O3-
> fXPV4&m=iYf8gbrFPSefanXbHRPp5582-Y-
> dLzDlAcHBoscJ0Do&s=anFZ7mbROjHZMCc_pKrheWD0xYtMm-
> z8Ihv0ZBTU_dE&e=
> for more information about IESG DISCUSS and COMMENT positions.
> 
> 
> The document, along with other ballot positions, can be found here:
> https://urldefense.proofpoint.com/v2/url?u=https-
> 3A__datatracker.ietf.org_doc_draft-2Dietf-2Dbess-2Dbgp-2Dvpls-2Dcontrol-
> 2Dflags_&d=DwIDaQ&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-
> ndb3voDTXcWzoCI&r=6ArkE4n20mNZQF6JxrMYwJyAGBWWjzhSIC2O3-
> fXPV4&m=iYf8gbrFPSefanXbHRPp5582-Y-
> dLzDlAcHBoscJ0Do&s=AvdGXE0aC9SvKnOrFh24zSPKqEvmZR27lIQTulUn05g&
> e=
> 
> 
> 
> --
> COMMENT:
> --
> 
> — Section 3.1 —
> 
>but the PW MUST
>NOT be prevented from coming up due to this mismatch. So, the PW MUST
>still come up but not use control word in either direction.
> 
> The second MUST seems wrong to me: the normative behaviour is already
> stated by the MUST NOT, but there could be other factors that legitimately
> prevent the PW from coming up, no?  Likely, this should say, “So, the PW will
> still come up, ...”
> 
> — Section 3.2 —
> 
>If the PEs at both ends of the PW do not agree on the
>setting of the S-bit, the PW SHOULD NOT come up.
> 
> Why SHOULD NOT?  Why might it be allowed to come up anyway, and what
> would the consequences of that be (which would need to be understood in
> order to not obey the SHOULD NOT)?
> 

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

Re: [bess] Roman Danyliw's No Objection on draft-ietf-bess-bgp-vpls-control-flags-07: (with COMMENT)

[Ravi Singh]

Hi Roman
Thanks for your comments.
Been addressed in -08.
Regards
Ravi


> -Original Message-
> From: Roman Danyliw via Datatracker [mailto:nore...@ietf.org]
> Sent: Monday, April 8, 2019 6:33 PM
> To: The IESG 
> Cc: draft-ietf-bess-bgp-vpls-control-fl...@ietf.org; Mach Chen
> ; bess-cha...@ietf.org; mach.c...@huawei.com;
> bess@ietf.org
> Subject: Roman Danyliw's No Objection on draft-ietf-bess-bgp-vpls-control-
> flags-07: (with COMMENT)
> 
> Roman Danyliw has entered the following ballot position for
> draft-ietf-bess-bgp-vpls-control-flags-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.proofpoint.com/v2/url?u=https-
> 3A__www.ietf.org_iesg_statement_discuss-
> 2Dcriteria.html&d=DwICaQ&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-
> ndb3voDTXcWzoCI&r=6ArkE4n20mNZQF6JxrMYwJyAGBWWjzhSIC2O3-
> fXPV4&m=0jJMPd-
> uQpLDFs4Kmm1g6Bh4jYlCmUzfjzKWIz0KgpY&s=xDazhlZXoadWX75Ju_RrHqFZ
> xx8ULW5qCTkfH5Vx5Sk&e=
> for more information about IESG DISCUSS and COMMENT positions.
> 
> 
> The document, along with other ballot positions, can be found here:
> https://urldefense.proofpoint.com/v2/url?u=https-
> 3A__datatracker.ietf.org_doc_draft-2Dietf-2Dbess-2Dbgp-2Dvpls-2Dcontrol-
> 2Dflags_&d=DwICaQ&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-
> ndb3voDTXcWzoCI&r=6ArkE4n20mNZQF6JxrMYwJyAGBWWjzhSIC2O3-
> fXPV4&m=0jJMPd-
> uQpLDFs4Kmm1g6Bh4jYlCmUzfjzKWIz0KgpY&s=VTk2pEwEwTSP-r3dW-
> bfIMullpIKnWtu2DoBSDGXCt8&e=
> 
> 
> 
> --
> COMMENT:
> --
> 
> A few nits:
> 
> (1) In Section 3.1.  Typo.  s/seqence/sequence/
> 
> (2) Section 4.  Typo. s/VPLS,there/VPLS, there/
> 
> (3) Section 5.1.  Editorial.  s/the below specified network topology/the
> network topology specified in Section 6/
> 

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

Re: [bess] Mirja Kühlewind's No Objection on draft-ietf-bess-bgp-vpls-control-flags-07: (with COMMENT)

[Ravi Singh]

Hi Mirja
> Given this document updates the normative behaviour of RFC 4761, I would
> have expected to see some discussion about interoperability. Is the
> behaviour as specified in RFC 4761 not widely deployed/implemented or
> would it be possible to add some sentences about interoperability which
> already deployed devices?

There are no interop considerations since this is new add-on behavior to cause 
PW to come whereas earlier the PW would not even come up.
Regards
Ravi


> -Original Message-
> From: Mirja Kühlewind via Datatracker [mailto:nore...@ietf.org]
> Sent: Thursday, April 4, 2019 8:13 AM
> To: The IESG 
> Cc: draft-ietf-bess-bgp-vpls-control-fl...@ietf.org; Mach Chen
> ; bess-cha...@ietf.org; mach.c...@huawei.com;
> bess@ietf.org
> Subject: Mirja Kühlewind's No Objection on draft-ietf-bess-bgp-vpls-control-
> flags-07: (with COMMENT)
> 
> Mirja Kühlewind has entered the following ballot position for
> draft-ietf-bess-bgp-vpls-control-flags-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.proofpoint.com/v2/url?u=https-
> 3A__www.ietf.org_iesg_statement_discuss-
> 2Dcriteria.html&d=DwIDaQ&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-
> ndb3voDTXcWzoCI&r=6ArkE4n20mNZQF6JxrMYwJyAGBWWjzhSIC2O3-
> fXPV4&m=sRYoRhlmH7BG89gXNxxxppiwdiP1flSwEpo9K-EXMV0&s=kp-
> Yisx5GTzgoz49kcReFJc4zVl-a8FCsHWwPIvCXUc&e=
> for more information about IESG DISCUSS and COMMENT positions.
> 
> 
> The document, along with other ballot positions, can be found here:
> https://urldefense.proofpoint.com/v2/url?u=https-
> 3A__datatracker.ietf.org_doc_draft-2Dietf-2Dbess-2Dbgp-2Dvpls-2Dcontrol-
> 2Dflags_&d=DwIDaQ&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-
> ndb3voDTXcWzoCI&r=6ArkE4n20mNZQF6JxrMYwJyAGBWWjzhSIC2O3-
> fXPV4&m=sRYoRhlmH7BG89gXNxxxppiwdiP1flSwEpo9K-
> EXMV0&s=JbGb4ouK0vh5A38h3j65nEWXj9o9L1YR9WKIGs40QYs&e=
> 
> 
> 
> --
> COMMENT:
> --
> 
> Given this document updates the normative behaviour of RFC 4761, I would
> have expected to see some discussion about interoperability. Is the
> behaviour as specified in RFC 4761 not widely deployed/implemented or
> would it be possible to add some sentences about interoperability which
> already deployed devices?
> 
> One minor editorial request:
> - Please expand PE on first occurrence.
> 

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

Re: [bess] Benjamin Kaduk's No Objection on draft-ietf-bess-bgp-vpls-control-flags-07: (with COMMENT)

[Ravi Singh]

Hi Benjamin
Thanks for your detailed feedback.

Please see inline for .
Regards
Ravi


> -Original Message-
> From: Benjamin Kaduk via Datatracker [mailto:nore...@ietf.org]
> Sent: Tuesday, April 9, 2019 8:35 AM
> To: The IESG 
> Cc: draft-ietf-bess-bgp-vpls-control-fl...@ietf.org; Mach Chen
> ; bess-cha...@ietf.org; mach.c...@huawei.com;
> bess@ietf.org
> Subject: Benjamin Kaduk's No Objection on draft-ietf-bess-bgp-vpls-control-
> flags-07: (with COMMENT)
> 
> Benjamin Kaduk has entered the following ballot position for
> draft-ietf-bess-bgp-vpls-control-flags-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.proofpoint.com/v2/url?u=https-
> 3A__www.ietf.org_iesg_statement_discuss-
> 2Dcriteria.html&d=DwICaQ&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-
> ndb3voDTXcWzoCI&r=6ArkE4n20mNZQF6JxrMYwJyAGBWWjzhSIC2O3-
> fXPV4&m=bYCIT8qprRL9tp64crav4NXQbv-
> 9JtK1NodEE30aj4Y&s=gKACcDwG815F9IokZIdC2_-SkojE9jRvN6G5s46EJp0&e=
> for more information about IESG DISCUSS and COMMENT positions.
> 
> 
> The document, along with other ballot positions, can be found here:
> https://urldefense.proofpoint.com/v2/url?u=https-
> 3A__datatracker.ietf.org_doc_draft-2Dietf-2Dbess-2Dbgp-2Dvpls-2Dcontrol-
> 2Dflags_&d=DwICaQ&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-
> ndb3voDTXcWzoCI&r=6ArkE4n20mNZQF6JxrMYwJyAGBWWjzhSIC2O3-
> fXPV4&m=bYCIT8qprRL9tp64crav4NXQbv-
> 9JtK1NodEE30aj4Y&s=YK6yKMztrNqCa2EKzwI9j4Rp7lgy5gK6xuHRqJJSbdI&e=
> 
> 
> 
> --
> COMMENT:
> --
> 
> Thanks for this document; it's good to get this behavior clarified and made
> more usable.
> 
> Unfortunately, I cannot agree with the "no new security considerations"
> statement in Section 7.  I wavered for a while on whether to make this a
> DISCUSS-level point, but decided not to since I don't think the material
> consequences are especially severe.  Please take it under consideration,
> though.
> 

 I've updated the security considerations section.

> It seems to me that we are changing the expected tradeoff between
> availability and functionality, and that change should be documented as a
> new consideration.  Specifically, the state prior to this document (in 
> practice)
> seems to be that when a PE advertises the C-bit in its NLRI, all PWs in both
> directions that use that NLRI will use the CW, or will fail.  Any transient 
> error,
> random bit flip, attacker-induced bit flip, etc., would cause a PW failure
> which is presumably highly visible.  Using the recommendations in this
> document, we prioritize availability over using the CW feature, so those
> errors/bit-flips now cause the PW to be established but not use the CW,
> which may be a less visible event and have second-order effects for the
> traffic therein.  The operator deploying this technology should make an
> informed decision about its usage.
> 
> (We are also changing the behavior of the S bit so there would be some
> considerations there, too, though failure to agree on the S bit still results 
> in a
> highly visible outage, so the considerations are a little different.)
> 
> Some other, more minor, section-by-section comments follow.
> 
> Section 1
> 
> ["PE" is not listed as "well-known" at
> https://urldefense.proofpoint.com/v2/url?u=https-3A__www.rfc-
> 2Deditor.org_materials_abbrev.expansion.txt&d=DwICaQ&c=HAkYuh63rsuh
> r6Scbfh0UjBXeMK-
> ndb3voDTXcWzoCI&r=6ArkE4n20mNZQF6JxrMYwJyAGBWWjzhSIC2O3-
> fXPV4&m=bYCIT8qprRL9tp64crav4NXQbv-9JtK1NodEE30aj4Y&s=SPOx6ODer-
> K0xPN-CpKPGJii3Lb9cSv41y9d4ChYZb4&e= and thus would normally be a
> candidate for expansion on first use]


: Addressed

> 
>The use of the Control Word (CW) helps prevent mis-ordering of IPv4
>or IPv6 Psuedo-Wire (PW) traffic over Equal Cost Multi-Path (ECMP)
>paths or Link Aggregation Group (LAG) bundles. [RFC4385] describes
>the format for CW that may be used over Point-to-Point PWs and over a
>VPLS. Along with [RFC3985], the document also describes sequence
>number usage for VPLS frames.
> 
> RFC 4385 seems to be carrying fairly generic disucssion, to me, without a
> clear statement that that CW format should be used for p2p PWs and VPLS
> usage.  (Though, I cannot dispute the "that may be used" statement, since
> the intent of 4385 seems to be quite generic.)  Perhaps it is more accurate to
> say "a format" than "the format", though, absent some other specification
> that mandates this particular one?

[] 
[] There is no other specification, AFAIK, for a control-word format other 
than what is in RFC4835.
So, "the format" seems appropriate.

> 
> Section 3.1
> 
> This new behavior means that any fault (or attacker influence) causes the PW
> to degrade to not using the CW, and possibly to do so "s

Re: [bess] Opsdir last call review of draft-ietf-bess-bgp-vpls-control-flags-07

[Ravi Singh]

Thanks Jouni.
Taken care of this feedback in latest version.

> -Original Message-
> From: Jouni Korhonen via Datatracker [mailto:nore...@ietf.org]
> Sent: Sunday, March 31, 2019 1:18 PM
> To: ops-...@ietf.org
> Cc: i...@ietf.org; draft-ietf-bess-bgp-vpls-control-flags@ietf.org;
> bess@ietf.org
> Subject: Opsdir last call review of draft-ietf-bess-bgp-vpls-control-flags-07
> 
> Reviewer: Jouni Korhonen
> Review result: Ready
> 
> I read the document and think it is ready. IDNits warnings and comments are
> easily/automatically fixed when new version is submitted.
> 
> I only have few editorial nits/suggestions.
> * Section 5.1 says "Assuming the below specified network topology.." while it
> could also use an exact reference to Figure 1. * Section 5 is written so that 
> it
> assumed the reader has already read Section 6. Maybe swapping Sections 5
> and
> 6 order would make sense?

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

Re: [bess] WG Last Call and IPR Poll for draft-ietf-bess-bgp-vpls-control-flags-04

[Ravi Singh]

Hi
>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 won't 
>progress without answers from all the authors and contributors.

Not aware of any undisclosed IPR.

> We are also polling for any existing implementations.

https://www.juniper.net/documentation/en_US/junos/topics/task/configuration/vpls-bgp-control-word-configuring.html
https://www.juniper.net/documentation/en_US/junos/topics/concept/vpls-bgp-control-word-overview.html

Regards
Ravi



From: BESS [mailto:bess-boun...@ietf.org] On Behalf Of 
stephane.litkow...@orange.com
Sent: Monday, April 23, 2018 8:01 AM
To: bess@ietf.org
Subject: [bess] WG Last Call and IPR Poll for 
draft-ietf-bess-bgp-vpls-control-flags-04

Hi WG,

This email begins a two-week working group last call for 
draft-ietf-bess-bgp-vpls-control-flags-04 [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 won't progress 
without answers from all the authors and contributors.

Currently there is one IPR declaration against this document 
(https://datatracker.ietf.org/ipr/search/?submit=draft&id=draft-ietf-bess-bgp-vpls-control-flags).

If you are 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 implementations.

The working group last call closes on 7th May.

Regards,

Matthew and Stéphane

[1] 
https://datatracker.ietf.org/doc/draft-ietf-bess-bgp-vpls-control-flags/


_



Ce message et ses pieces jointes peuvent contenir des informations 
confidentielles ou privilegiees et ne doivent donc

pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce 
message par erreur, veuillez le signaler

a l'expediteur et le detruire ainsi que les pieces jointes. Les messages 
electroniques etant susceptibles d'alteration,

Orange decline toute responsabilite si ce message a ete altere, deforme ou 
falsifie. Merci.



This message and its attachments may contain confidential or privileged 
information that may be protected by law;

they should not be distributed, used or copied without authorisation.

If you have received this email in error, please notify the sender and delete 
this message and its attachments.

As emails may be altered, Orange is not liable for messages that have been 
modified, changed or falsified.

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

[bess] RtgDir review: draft-ietf-bess-evpn-etree-12

[Ravi Singh]

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 Last Call 
comments that you receive, and strive to resolve them through discussion or by 
updating the draft.

Document: draft-ietf-bess-evpn-etree-12
Reviewer: Ravi Singh
Review Date: 08/15/2017
Intended Status: Standards track

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


I've reviewed this draft.
Most of my comments fall under the category of "minor comments" and "nits".
The only major comments pertain to
a.   Sections 5.2/8.1: which appear like an overkill and could be 
considered for dropping from text.
b.  Need for a new section on the doc:
Include section to address this specifically: "Is (PBB-)EVPN being a *more 
efficient* implementation of E-Tree functions demonstrated?" This is relevant 
since the abstract makes a pitch for this draft addressing how PBB(-EVPN) 
implement E-tree functionality more efficientlky. However, it takes a 
fine-toothed comb to glean that info. Eg. First para in section 3.1. Nowhere 
else in the text has the efficiency aspect been explicitly addressed.  This 
aspect could use a section of its own.


Feedback:
1.   Abstract: very clear
2.   Section1 : Introduction:
a.   How about referring to "[RFC7432] is a solution for multipoint L2VPN 
services"  as EVPN more directly?
3.   Section 2: E-tree scenarios
a.   Section 2.1: for the sake of terminology clarification, please edit 
the text to not mention the acronym until the full-expansion has been listed. 
The draft does list the full-expansion. Just not before first using the acronym.
b.  Section 2.2: "
thus color MAC addresses via a "color" flag in a new extended community as 
detailed in section 3.1." should be referring to section 5.1 instead.
4.   Section 3: Operation of EVPN
a.   3.1: "Extended Community with a Leaf indication flag is introduced 
[section5.2]"  ->
"Extended Community with a Leaf indication flag is introduced [section 5.1]"
b.  3.3.1 (& section 5.2 as well): specifying (as this draft does) that the 
ingress PE X acting for a root entity, be able to dictate to a PE Y acting on 
behalf of a leaf entity, that PE Y should "ingress replication" or otherwise 
sounds excessive. Also, this draft does not make a strong enough case for the 
need for the modification to "PMSI Tunnel Attribute". Even if the foregoing was 
ignored, the draft does not address how PE X behaves should PE Y choose not to 
honor the setting of the "composite-tunnel bit".

5.   Section 4: Operation of PBB-EVPN: no specific comments. However, a 
little more detail would be useful to avoid having the reader repeatedly refer 
back to the PBB-EPVN RFC7623.

6.   Section 5: BGP encoding
a.   This looks like an unexpected section given the "abstract" and the 
"introduction" section.
The abstract and the introduction seem to indicate that no signaling changes 
are needed to make (PBB-)EVPN provide E-tree services. Abstract/introduction 
could use some rewording on this count.
b.  Minor typo:
5.1: "The received PE" -> "The receiving PE"

5.2: it would enhance readability if the flags were presented as
   0 1 2 3 4 5 6 7
  +-+-+-+-+-+-+-+-+
  |C  |reserved  |L|
  +-+-+-+-+-+-+-+-+
C = composite-tunnel bit

Anyway, as stated above this draft does not make a strong enough case for the 
need for the modification to "PMSI Tunnel Attribute". The value added by this 
modification to the PMSI tunnel-attribute seems marginal. A leaf

7.   Section 8: IANA considerations: it would be useful to include text 
about the name of "E-Tree Flags" registry in section 5.1 and correlate these 2 
sections.
a.   Section 8.1: could be considered for dropping, in view of the previous 
comments on PMSI etc.
8.   Appendix A: too wordy. Could do with fewer better-chosen words to 
communicate the same message. Some minor singular/plural typos.

Regards
Ravi

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

Re: [bess] Poll for adoption: draft-singh-bess-bgp-vpls-control-flags

[Ravi Singh]

Hi Thomas, Martin
> Before adopting this draft, we would like hear people actually experiencing 
> pain
> related to not solving this issue and hear about implementations in actual
> products.

In a network where some BGP-VPLS PEs have ability to insert CW and some do not, 
not implementing section 3 has potential to cause the PW to not come up or 
cause dropped packets (depending on implementation).
Section 3 of this draft is implemented in JunOS. See last paragraph on
http://www.juniper.net/techpubs/en_US/junos14.1/topics/concept/vpls-bgp-control-word-overview.html
This was implemented in response to a specific-network-deployment-issue.

The key aspect of RFC4761 that necessitates the text of section 3 of this draft 
is that the NLRI-advertising-PE is predicating on all other PEs in the same 
VPLS, that they must or must-not insert the CW, for example, regardless of 
whether they have the capability or not. [See 
https://tools.ietf.org/html/rfc4761#section-3.2.4]
This is in contrast to the proposed modification (for a different purpose) 
where this PE is just advertising its ability 
(https://tools.ietf.org/html/draft-ietf-bess-fat-pw-bgp-00#section-2)

The proposed text in section 3 provides a way around presumption of other-PEs' 
abilities.
Section 4 provides an extension of the same intent for a deployment where the 
transport LSP maybe a p2mp LSP.
Section 5 generalizes the previous sections as deployed to multi-homing 
scenarios.

Both p2mp and multi-homing have some deployments and may run into the issue.

Regards
Ravi



> -Original Message-
> From: thomas.mo...@orange.com [mailto:thomas.mo...@orange.com]
> Sent: Monday, October 5, 2015 12:29 AM
> To: bess@ietf.org; draft-singh-bess-bgp-vpls-control-fl...@tools.ietf.org; 
> Ravi
> Singh ; Kireeti Kompella ;
> senad.palislamo...@alcatel-lucent.com
> Subject: Re: [bess] Poll for adoption: draft-singh-bess-bgp-vpls-control-flags
> 
> Authors of draft-singh-bess-bgp-vpls-control-flags, working group,
> 
> The support base for this proposal is not large.
> Before adopting this draft, we would like hear people actually experiencing 
> pain
> related to not solving this issue and hear about implementations in actual
> products.
> 
> Let's consider this poll for adoption open until we hear more.
> 
> Best,
> 
> Thomas/Martin
> 
> 
> thomas.mo...@orange.com :
> > Hello working group,
> >
> > This email starts a two-week poll on adopting
> > draft-singh-bess-bgp-vpls-control-flags-01 [1] as a working group item.
> >
> > Please send comments to the list and state if you support adoption or
> > not (in the later case, please also state the reasons).
> >
> > This poll runs until **September 29th**.
> >
> >
> > *Coincidentally*, we are also polling for knowledge of any IPR that
> > applies to this draft, 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 a document author or contributor please
> > respond to this email and indicate whether or not you are aware of any
> > relevant IPR.
> >
> > The draft will not be adopted until a response has been received from
> > each author and contributor.
> >
> > If you are not listed as an author or contributor, then please
> > explicitly respond only if you are aware of any IPR that has not yet
> > been disclosed in conformance with IETF rules.
> >
> > Thank you,
> >
> > Martin & Thomas
> > bess chairs
> >
> > [1]
> > https://tools.ietf.org/html/draft-singh-bess-bgp-vpls-control-flags
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> 
> 
> _
> 
> 
> Ce message et ses pieces jointes peuvent contenir des informations
> confidentielles ou privilegiees et ne doivent donc pas etre diffuses, 
> exploites ou
> copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le
> signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les 
> messages
> electroniques etant susceptibles d'alteration, Orange decline toute
> responsabilite si ce message a ete altere, deforme ou falsifie. Merci.
> 
> This message and its attachments may contain confidential or privileged
> information that may be protected by law; they should not be distributed, used
> or copied without authorisation.
> If you have received this email in error, please notify the sender and delete 
> this
> message and its attachments.
> As emails may be altered, Orange is not liable for messages that have been
> modified, changed or falsified.
> Thank you.

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

Re: [bess] Poll for adoption: draft-singh-bess-bgp-vpls-control-flags

[Ravi Singh]

[Cced the correct authors' alias]

Hi
Yes, support (as co-author).

The following IPR was disclosed.
http://www.ietf.org/mail-archive/web/ipr-announce/current/msg01016.html


Regards
Ravi

> -Original Message-
> From: BESS [mailto:bess-boun...@ietf.org] On Behalf Of
> thomas.mo...@orange.com
> Sent: Tuesday, September 15, 2015 12:44 AM
> To: bess@ietf.org
> Cc: draft-sajassi-bess-evpn-et...@tools.ietf.org
> Subject: [bess] Poll for adoption: draft-singh-bess-bgp-vpls-control-flags
> 
> Hello working group,
> 
> This email starts a two-week poll on adopting
> draft-singh-bess-bgp-vpls-control-flags-01 [1] as a working group item.
> 
> Please send comments to the list and state if you support adoption or not (in 
> the
> later case, please also state the reasons).
> 
> This poll runs until **September 29th**.
> 
> 
> *Coincidentally*, we are also polling for knowledge of any IPR that applies to
> this draft, 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 a document author or contributor please respond to
> this email and indicate whether or not you are aware of any relevant IPR.
> 
> The draft will not be adopted until a response has been received from each
> author and contributor.
> 
> If you are not listed as an author or contributor, then please explicitly 
> respond
> only if you are aware of any IPR that has not yet been disclosed in 
> conformance
> with IETF rules.
> 
> Thank you,
> 
> Martin & Thomas
> bess chairs
> 
> [1] https://tools.ietf.org/html/draft-singh-bess-bgp-vpls-control-flags
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> _
> 
> 
> Ce message et ses pieces jointes peuvent contenir des informations
> confidentielles ou privilegiees et ne doivent donc pas etre diffuses, 
> exploites ou
> copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le
> signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les 
> messages
> electroniques etant susceptibles d'alteration, Orange decline toute
> responsabilite si ce message a ete altere, deforme ou falsifie. Merci.
> 
> This message and its attachments may contain confidential or privileged
> information that may be protected by law; they should not be distributed, used
> or copied without authorisation.
> If you have received this email in error, please notify the sender and delete 
> this
> message and its attachments.
> As emails may be altered, Orange is not liable for messages that have been
> modified, changed or falsified.
> Thank you.
> 
> ___
> BESS mailing list
> BESS@ietf.org
> https://www.ietf.org/mailman/listinfo/bess

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

[bess] draft-singh-bess-bgp-vpls-control-flags:

[Ravi Singh]

Hi
This draft clarifies flags processing in the BGP-VPLS specification which was 
previously unaddressed.
https://tools.ietf.org/html/draft-singh-bess-bgp-vpls-control-flags-00

It draft was last presented at IETF-90 @ Toronto (in L2VPN WG).
http://www.ietf.org/proceedings/90/slides/slides-90-l2vpn-12.pdf
All previously received comments (during its time in l2vpn) have been 
incorporated.
We'd like to request any further comments from the WG.

Also, at the same time I'd like to request the chairs to consider this for 
WG-adoption.

Thanks
Ravi


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