Hi Alexander,
The solution here is to carry the next hop capability attribute when the route
is advertised. The capability carried here is the control word capability.
The specific format of the next hop capability can be referred to the draft.:
<draft-ietf-idr-next-hop-capability>
+------------------------------+
| Capability Code (2 octets) |
+------------------------------+
| Capability Length (2 octets) |
+------------------------------+
| Capability Value (variable) |
~ ~
+------------------------------+
For the control word capability , it may encode as :
+------------------------------+
| CW Capabality Type (TBD) |
+------------------------------+
| CW Length (0 or 3) |
+------------------------------+
| CWI Label (may not exist) |
+------------------------------+
CWI (Control word indication)
And the forwarding Packet example.
+------------------------------+
| Tunnel Label |
+------------------------------+
| EVI Label |
+------------------------------+
| CW Indicate Label |
+------------------------------+
| Control word |
+------------------------------+
The difference between the two methods is that which value should be use for
the control word capability indicates label.
Method 1, use reserved label, which should be assigned by IANA, (such as the
entropy label, which is the value of 7)
If we use this method, then the control word capability attribute’s CW length
use 0 is enough.
And the forwarding packet use the IANA specified value as the CWI (Control word
indication) Label .(Perhaps 8 or others)
Method2, use normal value, which is assigned by router.
If we use this method, then the router must assign a label used for the CWI.
Perhaps label. And the control word capability attribute’s CW length must be 3
and must contain the value in the update message.
The forwarding packet must use that value as the CWI label.
Regards,
Haibo
From: Alexander Vainshtein [mailto:alexander.vainsht...@ecitele.com]
Sent: Tuesday, October 23, 2018 6:09 PM
To: Wanghaibo (Rainsword) <rainsword.w...@huawei.com>
Cc: bess@ietf.org; draft-wang-bess-evpn-control-word.auth...@ietf.org
Subject: RE: A question regarding draft-wang-bess-evepn-control-word
Dear Haibo,
Lots of thanks for an extra-prompt response to my question.
There may be some misunderstanding here.
The draft says (the important text is highlighted):
There are two methods to specified the control word indicator label:
The first method is to apply for a reserved label to indicate
whether the packet contains a control word;
The second method is to apply for a new label when the sending
router advertises the control word capability, which is used to
indicate whether the control word is included in the packet.
My question referred just to the 2nd method, while your response seems to deal
with the 1st one.
Did I miss something?
Regards,
Sasha
Office: +972-39266302
Cell: +972-549266302
Email:
alexander.vainsht...@ecitele.com<mailto:alexander.vainsht...@ecitele.com>
From: BESS [mailto:bess-boun...@ietf.org] On Behalf Of Wanghaibo (Rainsword)
Sent: Tuesday, October 23, 2018 12:03 PM
To: Alexander Vainshtein
<alexander.vainsht...@ecitele.com<mailto:alexander.vainsht...@ecitele.com>>;
draft-wang-bess-evpn-control-word.auth...@ietf.org<mailto:draft-wang-bess-evpn-control-word.auth...@ietf.org>
Cc: bess@ietf.org<mailto:bess@ietf.org>
Subject: [bess] 答复: A question regarding draft-wang-bess-evepn-control-word
Hi Alexander,
The number of routes advertised by the Sender router in our solution will not
change, but only carries a next hop capability attribute with control word
capability
The Receiver router determines whether to carry the control word when
forwarding packets according to its own capabilities.
The following figure is an example.:
PE1----------PE2
|-----------PE3
When PE1 advertises a route, it carries the next hop attribute of the control
word capability. The routes received by PE2 and PE3 are the same.
If PE2 do not support the control word, it will not carry the control word
when forwarding packets to PE1.
PE1 cannot find the control word indication label when parsing the PE2 packet.
PE1 will treat the packet as normal.
If PE3 support the control word, it can add a control word when forwarding the
packet to the PE1, and add the control word indication label specified by the
PE1.
When the PE1 receives the packet and finds the control word indication label in
the packet. PE1 will correctly process the control word.
Thanks
Haibo
发件人: Alexander Vainshtein [mailto:alexander.vainsht...@ecitele.com]
发送时间: 2018年10月23日 16:46
收件人:
draft-wang-bess-evpn-control-word.auth...@ietf.org<mailto:draft-wang-bess-evpn-control-word.auth...@ietf.org>
抄送: bess@ietf.org<mailto:bess@ietf.org>
主题: A question regarding draft-wang-bess-evepn-control-word
Dear authors of
draft-wang-bess-evpn-control-word<https://tools.ietf.org/html/draft-wang-bess-evpn-control-word-00>,
I have doubts regarding at least one of the approaches for negotiating the CW
usage in the EVPN encapsulation between egress and ingress PE that is defined
in the draft.
In the case when the egress PE can receive EVPN-encapsulated packets both with
and without CW, the draft seems to propose (as one of the possibilities)
advertisement of two EVPN routes for each ES or MAC/IP pair:
- One of these routes would use the CW Capability to indicate that it
refers to the EVPN encapsulation that uses the CW, and would carry the
appropriate label in its NLRI
- The other route would not use the CW Capability to indicate that it
refers to the EVPN encapsulation that does not use the CW, and carry a
different label in its NLRI
The ingress PE that accepts these routes would then use one of them based on
its own ability to use the CW (or lack thereof), and use the corresponding
label it its EVPN encapsulation, while the DP in the egress PW would infer
presence or absence of the CW from the received EVPN application label.
Unfortunately, I do not think that this can work because, as per RFC
7432<https://tools.ietf.org/html/rfc7432>, labels in the labeled NLRI of EVPN
routes are not part of the route key for the purpose of the BGP route key
processing, while the label is treated just as the BGP attribute. This means
that, unless some form of BGP multi-path is enabled in the ingress PE (and in
all RRs on the way between the egress PE and ingress PE) for the L2VPN/EVPN
AFI/SAFI, only one of these routes will be selected by the BGP selection
process.
Did I miss something substantial here?
Regards, and lots of thanks in advance,
Sasha
Office: +972-39266302
Cell: +972-549266302
Email:
alexander.vainsht...@ecitele.com<mailto:alexander.vainsht...@ecitele.com>
___________________________________________________________________________
This e-mail message is intended for the recipient only and contains information
which is
CONFIDENTIAL and which may be proprietary to ECI Telecom. If you have received
this
transmission in error, please inform us by e-mail, phone or fax, and then
delete the original
and all copies thereof.
___________________________________________________________________________
___________________________________________________________________________
This e-mail message is intended for the recipient only and contains information
which is
CONFIDENTIAL and which may be proprietary to ECI Telecom. If you have received
this
transmission in error, please inform us by e-mail, phone or fax, and then
delete the original
and all copies thereof.
___________________________________________________________________________
_______________________________________________
BESS mailing list
BESS@ietf.org
https://www.ietf.org/mailman/listinfo/bess
