Re: [bess] Benjamin Kaduk's Discuss on draft-ietf-bess-evpn-bum-procedure-updates-11: (with DISCUSS and COMMENT)

["Jeffrey (Zhaohui) Zhang" <[e-mail]>]

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 establish the equivalence between IMET route and I-PMSI route, and then the purpose of IMET route is explained via I-PMSI route.

To me, the current text doesn't seem like an "explanation" that provides
"convenience" for the reader.  I recognize that opinions may differ.

Zzh3> OK I added " used to announce the tunnels that instantiate an I-PMSI".

> > Section 6.1
> >
> >    changes the next hop to its own address and changes PTA to specify
> >    the tunnel type/identification in the neighboring region 3.  Now the
> >
> > I'm not sure that we ever explicitly named the region.  We implicitly do
> > in the following figure that says "segment 3", but the number and string
> > "region" don't seem paired anywhere directly.
>
> Zzh2> It's first mentioned in 2.1 as following:
>
>    [RFC7524] assumes that segmentation happens at area borders.
>    However, it could be at "regional" borders, where a region could be a
>    sub-area, or even an entire AS plus its external links (Section 6).

That talks about the concept of a region in general.  My remark was
specifically about "region 3".

> Zzh2> I now refer to section 6.1 specifically instead of section 6 in the above paragraph.
> Zzh2> I do see where the confusion comes from. The diagram is for "inter-as" not "inter-region" (I now have that clarified); but the text says that in that diagram, you can have the regions to include inter-as links so now you'd have fewer segments (one segment for each region).

First off, thanks for these changes!
However, if there is no figure that indicates anything that would
correspond to this "region 3", then I don't think there is much value in
using a region number in the prose.  Wouldn't it convey the same
information to just say "in the neighboring region"?

zzh3> I see. I removed " 3".

Zzh3> Thanks a lot!

Zzh3> Jeffrey


Juniper Business Use Only