Hi authors,
I also have some other comments on draft-ietf-bess-rfc7432bis-04,
they are about entropy label, flow label and control word,
maybe some of them are also related to the OPE TLV of
draft-heitz-bess-evpn-option-b or RFC7447.
5) Is the entropy label in the following paragraph (in section 18) an entropy
label of PSN tunnel (e.g. LDP LSP)?
or is it just an entropy label inside the EVPN label?
I noticed that RFC7447 (after RFC7432) had deprecated the BGP Entropy Label
Capability (ELC) attribute.
and RFC7447 says that "A forthcoming document will propose a replacement".
Has the replacement of old BGP ELC attribute been defined?
Does the following paragraph have any relation with (new) BGP ELC attribute?
" * If a network uses entropy labels per [RFC6790], then the control
word SHOULD NOT be used when sending EVPN-encapsulated packets
over an MP2P LSP."
6）In previous question 2, I am a little confused in the option b scenario where
ASBR may change all inter-AS RT-2 routes' nexthop
into the same IP address (identifying that ASBR).
But some of these RT-2 route may originate from PEs with flow label
capability,
while some of these RT-2 route may originate from PEs without flow label
capability,
How can these different flow label capabilities of RT-2 routes be
distinguished?
I think the IMET route's Originator IP Address may help,
but RT-2 routes don't carry an originator IP address, maybe the OPE TLV of
draft-heitz-bess-evpn-option-b-01 can be used,
in order to find out the correct flow label capability and avoid the
black-hole caused by incorrect flow label capability.
I think this is very similar to the procedures used to select leaf labels
for EVPN E-Tree services.
7) I noticed that RFC7432 has already used a control-word, although RFC7432
don't recognize a C bit (or L2-Attr EC).
So when PE1 sends a Inclusive Multicast route to an old RFC7432-only node
PE2 along with a C bit = 1,
but PE2 doesn't insert a control-word for it in the data packet,
I think PE1 may not decapsulate that data packet correctly.
Because PE1 can't know that PE2 doesn't insert a control word.
It may be easy to determine whether a data packet is inserted with a flow
label,
but it is not easy to determine whether a data packet is inserted with a
control word.
I think there may be compatibility issues in such scenarios.
Otherwise maybe the IMET route from PE1 to PE2 and the IMET route from PE2
to PE1 should be used together to determine whether a control word can be
expected in the data plane. This may requires a PED label similar to that is in
draft-ietf-bess-evpn-virtual-hub.
But a special purpose label (similar to ELI label) may be easier to
indicate there is (or isn't) a control-word in the data packet.
8) IMHO, the problem which is pointed out by RFC7447 is a common problem, not
just the ELC Attribute will be affected.
Other BGP Attributes (e.g. flow label, control word) which can match the
following features will all have the similar problems:
8.1) these attributes are optional transitive BGP attributes
8.2) these attributes has a corresponding protocol-header in the data
packets (e.g. flow label, control word, leaf label by OPE TLV)
Maybe we need a new attr. flag (thus we don't have to set the transitive
flag in the future optional attributes when we want such optional attributes to
pass through a future RR which can't recognize it) to address these problems.
9) How can the egress PE know whether the ingress PE will use a P2P RSVP-TE LSP
or not ?
how should the egress PE know whether it can expect there is a control word
in corresponding data packet or not?
In RFC7432, these responsibilities is left to manual configurations,
but now it is a dynamical signalling/negotiation, the manual work may not
need to care about these things any more.
* When sending EVPN-encapsulated packets over a P2MP or P2P RSVP-TE
LSP, then the control word SHOULD NOT be used.
Thanks
Yubao
原始邮件
发件人：王玉保10045807
收件人：draft-ietf-bess-rfc7432...@ietf.org;
抄送人：bess@ietf.org;
日 期 ：2022年03月17日 13:36
主 题 ：Comments on L2-Attr Extended Community of draft-ietf-bess-rfc7432bis-04
Hi authors,
I read draft-ietf-bess-rfc7432bis-04 and I have the follwing questions and
comments:
1) In section 7.11.1, F bit (flow label capability) of L2 Attr Extended
Community is conveyed in Inclusive Multicast routes only,
and F bit will not be conveyed in Etherne A-D per EVI routes.
It will mean that the Inclusive Multicast route (which is used for BUM packets
only in RFC7432) will be used for known-unicast packets too?
Because that the flow label is not pushed onto BUM packets, it is only pushed
onto known-unicast packets.
