Hi Eric, Andrew
Thanks a lot for the updates done.
Here are more comments.
Overall comments:
- Please add a section that contains all the abbreviations expansions:
that may help non expert people to follow the acronyms without looking for the
first reference in the text.
[Eric] This is not generally required of an RFC.
ad> just to add, a reader should have read other RFCs first before reading this
which I believe define abbreviations we use. If you can point to any specific
abbreviation never explained we can spell out words before abbreviating for the
first tie in the text.
[SLI2] I agree that people should have read other RFCs...but we are all here to
create documents that are easy to read/understand and some reminders are always
helpful. Expanding abbreviations at first use is a good thing and thanks for
having done that, but it is usually helpful in addition to have a dedicated a
section with the abbreviation expansion consolidated. I do not thing that it is
a huge work.
- I usually like figures. For the intro, it may be wonderful to build
a figure that reminds the existing S-PMSI/Leaf A-D procedure. So without
reading the text, we can remember how it works.
- The interAS case may also be better with a Figure and an example (or
couples of).
[Eric] This seems like a matter of taste. Admitedly, I'd probably like figures
more if I had any skill in producing them ;-)
[SLI2] I agree that ASCII art is a pain but unfortunately RFCs do not allow
JPEG or PNG yet :)
Let me help on that. Please find attach some pictures that you may be able to
use and tune.
"The procedures of [RFC6625] do not clearly state how to handle an
S-PMSI A-D route if its NLRI contains wild cards, but its PTA
specifies "no tunnel info"."
[SLI] I quickly ran over RFC6625, it does not mention anything on explicit
tracking or Leaf A-D routes.So we assume that RFC6513/6514 only applies here.
[Eric] RFC 6625 specifies the handling of wildcard S-PMSI A-D routes, but did
not consider the case where the S-PMSI A-D routes do not carry a PTA. This
document corrects that.
[SLI2] My point was that RFC6625 does not specify anything regarding explicit
tracking while your sentence says "do not clearly state". In reality, it does
not state anything about how explicit tracking works for wildcard routes.
"If the LIR-pF flag is set in a given PTA, the LIR flag of that PTA
SHOULD also be set."
[SLI] Why not using a MUST ?
[Eric] If all the PEs support the LIR-pF flag, the procedures will work as
intended even if the LIR flag is not set. So I don't think a MUST is
appropriate.
[SLI2] Ok so do we really care of having the LIR flag set ? If not, couldn't be
a MAY ? I'm just wondering how important is to set the LIR-flag here. It seems
to be linked to the next sentence between parenthesis.
I understand that setting both allows to always have a response (per flow or
not per flow). Can we see this as an optional feature ?
Section3:
[SLI2] s/"There are other RFCS that update"/"There are other RFCs that update"
"We also introduce a new notion: the "match for tracking". This
differs from the "match for reception" as follows:"
[SLI] It would be better to give a definition of the "match for tracking"
before giving the rules. Here you're explaining only the rules, not the
difference in the meaning. Wouldn't it be easier to tell that the
implementation MUST consider only the S-PMSI A-D routes that have a LIR flag
and/or LR-pF flag set and then run the same rules as the RFC6625. Why do you
want to have S-PMSI routes with PTA and LIR unset in your route list for "match
for tracking" ? You need to take care here on your text proposal as one of your
previous statement updates the RFC6625 and the match reception procedure, so
the rules to be applied are the original one from RFC6625 and not the updated
one.
[Eric] IMO, the clearest way to express this is to give the rules and then
illustrate with a couple of examples.
[SLI2] You are right, I'm just challenging the fact that the text says that it
will explain how the match for tracking differs from the match from reception
but it does not. It's the job of the reader to deduce the difference from the
rule you are giving.
Two options:
- Change the sentence 'This differs from...' by something like: "The
match for tracking route SHOULD be found as follows:"
- Add a sentence at the end like: "Compared to the match for reception
procedure, the match for tracking procedure takes into account S-PMSI A-D
routes whose PTA specifies "no tunnel information" with either LIR or LIR-pf
set"
" Also note that if a match for tracking does not have the LIR flag or
the LIR-pF flag set, no explicit tracking information will be
generated. See Section 5."
[SLI] Again I do not see the value added of keeping such route as a match for
tracking as there is no tracking requested.
[Eric] As the terms are defined, there is always a "match for tracking" route
for each flow. If tracking is not requested, this route will have LIR and
LIR-pF clear. There are no unnecessary routes.
[SLI2] Agree, but based on my understanding such a route (with LIR and LIR-pF
clear) cannot be a match for tracking by definition : "ignore any S-PMSI A-D
route whose PTA specifies
"no tunnel information", but does not have either LIR or LIR-pF
Set"
So the statement "if a match for tracking does not have the LIR flag or the
LIR-pF flag set" is IMO wrong.
"If the match for tracking has LIR set and if either (a) the
egress node does not support LIR-pF, or (b) LIR-pF is not set,
then the egress node must respond to the match for tracking,
following procedures specified in other documents for the case
where LIR is set."
[SLI] Please state the relevant document references here.
[Eric] In the case described above, the handling of the LIR flag is not
modified by this document. I don't think it is necessary to cite a specific
set of documents that discuss the LIR flag.
ad> maybe we can say "the procedures specified in this document do not apply
are not applicable on the egress node" instead of "then the egress node..."
[SLI2] That's a good proposal
Moreover if new RD types are created, new siblings will have to be created.
[Eric] Your point is correct, but there hasn't been a new RD type in 20 years.
The draft shouldn't really say "add 16", it should just point out the new types.
[SLI2] I agree, but this may happen or not. I do not know if it is possible or
not but can we have an IANA point telling that any new RD type allocation
should in reality allocate two RD type values. My goal is to have an automated
way of allocating the sibling RD type for this use case and prevent a miss of
allocation if a new RD type is defined.
I'm also wondering if we really need to differentiate the reply to a LIR-pF and
to a LIR. The key point is for the ingress to know about the receivers for a
particular (S,G). If the reply comes from a LIR or LIR-pF, IMO, it does not
really matter. Is it ?
"However, if the PTA of the installed S-PMSI A-D route specifies "no
tunnel info", the egress ABR/ASBR MUST pass the PTA along unchanged
when it forwards the S-PMSI A-D route. (That is, a PTA specifying
"no tunnel info" MUST NOT be changed into a PTA specifying a tunnel.)
Furthermore, if the PTA specifies "no tunnel info", the LIR and LIR-
pF flags in the PTA MUST be passed along unchanged."
[SLI]Could you confirm that in case of SPMSI merging to IPMSI, the SPMSI route
is not forwarded.
I'm not fully familiar with interAS segmented case, but I have another
(possibly dumb) question. Is a merge case SPMSI regular (S,G) to SPMSI wildcard
possible ? (in a similar way as SPMSI to IPMSI). If yes, what are the
procedures here ?
Section 8.
[SLI] Do we have counter-measures against such "attack" ? Ingress PE dropping ?
[Eric] I consider the specification of such counter-measures to be outside the
scope of the document.
[SLI2] Fine, could you please state this in the security section ?
From: Eric C Rosen [mailto:ero...@juniper.net]
Sent: Tuesday, January 16, 2018 17:29
To: LITKOWSKI Stephane OBS/OINIS;
draft-ietf-bess-mvpn-expl-track.auth...@ietf.org<mailto:draft-ietf-bess-mvpn-expl-track.auth...@ietf.org>
Cc: bess@ietf.org<mailto:bess@ietf.org>;
bess-cha...@ietf.org<mailto:bess-cha...@ietf.org>
Subject: Re: Shepherd's review of draft-ietf-bess-mvpn-expl-track
Thanks for your review. I have posted revision -04 which I believe addresses
your substantive comments.
On 1/3/2018 8:01 AM,
stephane.litkow...@orange.com<mailto:stephane.litkow...@orange.com> wrote:
Hi,
As shepherd of this document, please find below some comments that I have:
Overall comments:
- Please add a section that contains all the abbreviations expansions:
that may help non expert people to follow the acronyms without looking for the
first reference in the text.
This is not generally required of an RFC.
- I usually like figures. For the intro, it may be wonderful to build
a figure that reminds the existing S-PMSI/Leaf A-D procedure. So without
reading the text, we can remember how it works.
- The interAS case may also be better with a Figure and an example (or
couples of).
This seems like a matter of taste. Admitedly, I'd probably like figures more
if I had any skill in producing them ;-)
Introduction:
"By originating one of these BGP routes, an ingress node advertises that
it is transmitting a particular multicast flow."
[SLI] Is "is transmitting" correct ? Can't we have situations where an S-PMSI
route is/was advertised but no traffic is flowing (no yet started or switched,
or stopped).
Fixed.
"Now
suppose that the ingress node wants explicit tracking for each
individual flow that it transmits (following the procedures of
[RFC6625] on that P-tunnel."
[SLI] Missing ")"
Fixed.
"This allows the
ingress node to determine the set of egress nodes that are receiving
flows from the ingress node."
[SLI] I think the Leaf A-D tells that there is a receiver interested by the
flow, but does not tell that it actually receives it.
Correct; fixed.
" Howver, this procedure requires several clarifications:"
[SLI] There is a typo s/Howver/However/
Fixed.
"The procedures of [RFC6625] do not clearly state how to handle an
S-PMSI A-D route if its NLRI contains wild cards, but its PTA
specifies "no tunnel info"."
[SLI] I quickly ran over RFC6625, it does not mention anything on explicit
tracking or Leaf A-D routes.So we assume that RFC6513/6514 only applies here.
RFC 6625 specifies the handling of wildcard S-PMSI A-D routes, but did not
consider the case where the S-PMSI A-D routes do not carry a PTA. This
document corrects that.
" * The explicit tracking procedures do not allow an ingress node
to "see" past the boundaries of the segmentation domain.
This particular problem is not further addressed in this
revision of this document.
"
[SLI] Do you plan to address it ? Or do we now consider it as out of scope ?
I think this is actually addressed in Section 5.3, so I've removed the remark.
Section 2:
"Prior specifications define one flag in the PTA, the "Leaf Info
Required" (LIR) flag, that is used for explicit tracking."
[SLI] Please point to the right reference
Fixed.
"If the LIR-pF flag is set in a given PTA, the LIR flag of that PTA
SHOULD also be set."
[SLI] Why not using a MUST ?
If all the PEs support the LIR-pF flag, the procedures will work as intended
even if the LIR flag is not set. So I don't think a MUST is appropriate.
"one forces a
a response to be sent an egress node that does not support LIR-pF"
[SLI] Is there a missing word like 'sent by an egress node" ?
Fixed.
Section 3:
"The definition of "match for reception" in [RFC6625] is hereby
modified as follows:"
[SLI] Please point to the section that you are updating.
In addition, section 3.2 of RFC6625 contains multiple if then else conditions
for each cases (C-S,C-G) and (C-*,C-G). Please give some precision in where do
you want to insert your new statement in this processing sequence. I guess it
is at the beginning.
I tried to make this clearer.
"When finding the "match for reception" for a given (C-S,C-G) or
(C-*,C-G), ignore any S-PMSI A-D route that has no PTA, or whose
PTA specifying "no tunnel information"."
[SLI] I would be in favor to introduce a normative statement here.
Fixed.
"We also introduce a new notion: the "match for tracking". This
differs from the "match for reception" as follows:"
[SLI] It would be better to give a definition of the "match for tracking"
before giving the rules. Here you're explaining only the rules, not the
difference in the meaning. Wouldn't it be easier to tell that the
implementation MUST consider only the S-PMSI A-D routes that have a LIR flag
and/or LR-pF flag set and then run the same rules as the RFC6625. Why do you
want to have S-PMSI routes with PTA and LIR unset in your route list for "match
for tracking" ? You need to take care here on your text proposal as one of your
previous statement updates the RFC6625 and the match reception procedure, so
the rules to be applied are the original one from RFC6625 and not the updated
one.
IMO, the clearest way to express this is to give the rules and then illustrate
with a couple of examples.
" Also note that if a match for tracking does not have the LIR flag or
the LIR-pF flag set, no explicit tracking information will be
generated. See Section 5."
[SLI] Again I do not see the value added of keeping such route as a match for
tracking as there is no tracking requested.
As the terms are defined, there is always a "match for tracking" route for each
flow. If tracking is not requested, this route will have LIR and LIR-pF
clear. There are no unnecessary routes.
Section 4:
"Such a route could be an
I-PMSI A-D route, a (C-*,C-G1) S-PMSI A-D route, a (C-S1,C-*)
S-PMSI A-D route, or a (C-*,C-*) S-PMSI A-D route. "
[SLI] Is per flow explicit tracking also required for I-PMSI ? I do not see it
listed in the goals of the doc ? The goal was to address wildcards S-PMSI AD
routes.
The above simply says that some route must specify the tunnel on which the
(C-S1,C-G1) is to be transmitted, and that this route could be an I-PMSI A-D
route.
"Further, if the ingress node originates a wildcard S-PMSI A-D
route carrying a PTA specifying the tunnel to be used for
carrying (C-S1,C-G1) traffic, and if that PTA has the LIR-pF bit
set, then explicit tracking for (C-S1,C-G1) is requested by that
S-PMSI A-D route. Thus the ingress node SHOULD NOT originate a
(C-S1,C-G1) S-PMSI A-D route whose PTA specifies "no tunnel
info"; such a route would not provide any additional
functionality."
[SLI] I do not fully understand this text in the context of your procedure 1.
which deals with an origination of an (C-S1,C-G1) S-PMSI A-D route (no
wildcard). As I understand the procedure for the wildcard is defined in 2.
This just says that there's no point in originating S-PMSI(C-S,C-G) with LIR
set if you've already originated S-PMSI(C-*,C-G) with LIR-pF set. That seems
to be an appropriate bit of advice.
"2. The following procedure can be used if (and only if) it is known
that the egress nodes support the optional LIR-pF flag."
I have some issue with this sentence. It does not seem to be normative as there
is no normative statement. However I understand it as a critical thing ("and
only if" !) so it may require at least a SHOULD.
Then the issue I see is that this knowledge does not come from the protocol, so
it sounds important to me to highlight the impact of a mistake.
BUT, reading the section 5. I understand that it is not as critical as it seems
as the receiver will ignore simply the LIR-pF flag and apply the standard
procedure (LIR set).
Please clarify the criticity to have or not this knowledge.
I added some text saying that procedure 2 may yield unexpected results if not
all the PEs support LIR-pF, and that the procedure SHOULD NOT be used in that
case.
" To terminate explicit tracking that has been initiated by an
S-PMSI A-D route whose PTA specifies a tunnel, the ingress node
re-originates the route without the LIR flag set"
[SLI] Do we also need to clear the LIR-pf ? It would make sense to do so.
Fixed.
"If the match for tracking has LIR set and if either (a) the
egress node does not support LIR-pF, or (b) LIR-pF is not set,
then the egress node must respond to the match for tracking,
following procedures specified in other documents for the case
where LIR is set."
[SLI] Please state the relevant document references here.
In the case described above, the handling of the LIR flag is not modified by
this document. I don't think it is necessary to cite a specific set of
documents that discuss the LIR flag.
Section 5.2
"Note that, per RFC4364, every RD begins with a two-octet type field
that is either 0, 1, or 2. By adding 16 to the second octet of the
RD, we force the type field to be 16, 17, or 18. "
[SLI] It works but we may need to ensure that the types > 16 cannot be used
anymore by new applications.
There is a registry for the Route Distinguisher Type field. Only types 16,
17, and 18 are defined here, other values are still available.
Moreover if new RD types are created, new siblings will have to be created.
Your point is correct, but there hasn't been a new RD type in 20 years. The
draft shouldn't really say "add 16", it should just point out the new types.
Wouldn't it be easier to set the MSB of the RD type to 1 ? so we only lock half
of the type space.
I think it is easier to use three new type values than to turn one of the bits
into a flag.
Or what could be the impact of using the RD of the local VRF of the egress node
?
The RD of the Leaf A-D route needs to be derived from the RD of the S-PMSI A-D
route that elicits it. Otherwise the ingress node receiving the Leaf A-D route
will have diffculty matching it to the corresponding S-PMSI A-D route.
Section 5.3
"In the case where the egress
node is not a PE, but rather an ABR or ASBR, it will not know whether
it needs to receive a given flow unless it receives a Leaf A-D route
whose NLRI specifies that flow and whose IP-address-specific RT
specifies an address of the egress node."
[SLI] The sentence works but when reading it I needed multiple reread to
understand that the "IP-address-specific RT
specifies an address of the egress node." was referring to the ASBR/ABR and
not the receiver PE.
Do you mind using "this egress node" or "this ABR/ASBR" ?
I tried to clarify that.
Section 8.
[SLI] Do we have counter-measures against such "attack" ? Ingress PE dropping ?
I consider the specification of such counter-measures to be outside the scope
of the document.
Section 9.2
I think RFC7524 needs to be referenced as normative giving that its knowledge
is required to understand section 5.3.
I'm not sure that RFC7524 should be a normative reference, as this draft does
not require segmentation at the ABRs. However, since RFC7524 is already
published, there's no harm in adding it to the "normative references" section.
I think that section 5.3 is also updating/complementing the procedures in
RFC7524 with the "no-tunnel info" case.
There don't seem to be any clear and objective criteria for determining whether
one document "updates" another.
_________________________________________________________________________________________________________________________
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.
Introduction (reminder of existing procedures):
+--------------------------------+
/ \
+ +
| |
| +---------> PE2 ---- RCV
| | | (G1)
| | |
| | |
| | |
| | |
| | |
| | |
SRC ---- PE1 ---------------+---------> PE3 ---- RCV
(S1) | | | (G1)
| | |
| | |
| | |
| +---------> PE4 ---- RCV
| | (G1)
+ +
\ /
+--------------------------------+
Multicast tree
+--------------------------------+
/ \
+ +
| |
| BGP Upd +---------> PE2 ---- RCV
| S-PMSI A-D | | (G1)
| - RD Type 0 1:1 | |
| - (S1,G1) | |
| - Orig PE1 | |
| PTA: LIR-set | |
| RT VPN_RT | |
| |
SRC ---- PE1 ------------> RR --------> PE3 ---- RCV
(S1) | | (G1)
| | |
| | |
| | |
| +---------> PE4 ---- RCV
| | (G1)
+ +
\ /
+--------------------------------+
Explicit tracking request
+--------------------------------+
/ \
+ a)BGP Upd +
| Leaf A-D |
| RD Type 0 1:1 |
| (S1,G1) |
| Orig PE1 |
| Orig PE2 |
| RT PE1:0 |
| +---------- PE2 ---- RCV
| | | (G1)
| | |
| | |
| | b)BGP Upd |
| | Leaf A-D |
| | RD Type 0 1:1|
| | (S1,G1) |
| | Orig PE1 |
| v Orig PE3 |
| <-----a)----- RT PE1:0 |
SRC ---- PE1 <-----b)----- RR <-------- PE3 ---- RCV
(S1) | <-----c)----- | (G1)
| ^ |
| | |
| | |
| +---------- PE4 ---- RCV
| c)BGP Upd | (G1)
| Leaf A-D |
| RD Type 0 1:1|
| (S1,G1) |
| Orig PE1 |
| Orig PE4 |
+ RT PE1:0 +
\ /
+--------------------------------+
Explicit tracking reply
LIR-pf procedure for a wildcard SPMSI:
+--------------------------------+
/ \
+ +
| |
| +---------> PE2 ---- RCV
| | | (G1)
| | |
| | |
| | |
| | |
| | |
| | |
SRC ---- PE1 ---------------+---------> PE3 ---- RCV
(S1,S2)| ---------------+---------> | (G1,G2)
| | |
| | |
| | |
| +---------> PE4 ---- RCV
| | (G2)
+ +
\ /
+--------------------------------+
+--------------------------------+
/ \
+ +
| |
| BGP Upd +---------> PE2 ---- RCV
| S-PMSI A-D | | (G1)
| - RD Type 0 1:1 | |
| - (*,*) | |
| - Orig PE1 | |
| PTA: | |
| tunnel typeX | |
| LIR set | |
| LIR-pF set | |
| RT VPN_RT | |
| |
SRC ---- PE1 ------------> RR --------> PE3 ---- RCV
(S1,S2)| | (G1,G2)
| | |
| | |
| | |
| +---------> PE4 ---- RCV
| | (G2)
+ +
\ /
+--------------------------------+
Per flow Explicit tracking request
+---------------------------------+
/ \
+ a)BGP Upd +
| Leaf A-D |
| RD Type 16 1:1 |
| (S1,G1) |
| Orig PE1 |
| Orig PE2 |
| RT PE1:0 |
| +---------- PE2 ---- RCV
| | | (G1)
| | |
| | |
| | b)BGP Upd |
| | Leaf A-D |
| | RD Type 16 1:1|
| | (S1,G1) |
| | Orig PE1 |
| v Orig PE3 |
| <-----a)----- RT PE1:0 |
SRC ---- PE1 <-----b)----- RR <-------- PE3 ---- RCV
(S1,S2)| <-----c)----- <-------- | (G1,G2)
| <-----d)----- ^ c)BGP Upd |
| | Leaf A-D |
| | RD Type 16 1:1|
| | (S2,G2) |
| | Orig PE1 |
| | Orig PE3 |
| | RT PE1:0 |
| | |
| | |
| | |
| +---------- PE4 ---- RCV
| d)BGP Upd | (G2)
| Leaf A-D |
| RD Type 16 1:1|
| (S2,G2) |
| Orig PE1 |
| Orig PE4 |
+ RT PE1:0 +
\ /
+---------------------------------+
Per flow Explicit tracking reply
ASBR case:
+----------+ +------------+
/ \ / \
+ + + +
| | | |
| | | +---> PE2 ---- RCV
| | | | | (G1)
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
SRC ---- PE1 ----->ASBR3----->ASBR4---RR---> PE3 ---- RCV
(S1) | | | | | (G1)
| | | | |
| | | | |
| | | | |
| | | +----> PE4 ---- RCV
| | | | (G1)
+ + + +
\ / \ /
+----------+ +------------+
+----------+ +----------------+
/ \ / \
+ + + BGP Upd +
| | | SPMSI A-D |
| | | RD1:1 type0+---> PE2 ---- RCV
| | | (* ,G1) | | (G1)
| | | Orig PE1 | |
| | | PTA: | |
| | | no tunnel | |
| | | LIR set | |
| | | LIR-pF set| |
| +--->RR | | +-------->RR----+ |
| | | | | | | | |
| | | | | | | | |
| | | | | | | v |
SRC ---- PE1 +-->ASBR3----------->ASBR4 | PE3 ---- RCV
(S1) | | BGP Upd | | | (G1)
| BGP Upd | SPMSI A-D | | |
| SPMSI A-D | RD1:1 type0| | |
| RD1:1 type0| (*,G1) | | |
| (*,G1) | Orig PE1 | +---> PE4 ---- RCV
| Orig PE1 | PTA: | | (G1)
| PTA: | no tunnel | |
| no tunnel | LIR set | |
| LIR set | LIR-pf set | |
+ LIR-pF set + + +
\ / \ /
+----------+ +----------------+
+----------+ +----------------+
/ \ / \
+ + + a)BGP Upd +
| | | Leaf A-D |
| | | RD1:1 Type16|
| | | (S1,G1) |
| | | Orig PE1 |
| | | Orig PE2 |
| | | RT ASBR4:0 |
| | | +------- PE2 ---- RCV
| | | | | (G1)
| | | | |
| | | | |
| | | +---a)---v |
| +----RR | | |+--b)--RR<------+ |
| | ^ | | ||+-c)-- ^ b) | |
| | | | | ||| | | |
| v | | <---a)------| vvv | | |
SRC ---- PE1 +---ASBR3<---b)------ASBR4 | PE3 ---- RCV
(S1) | | <---c)------| | | (G1)
|BGP Upd |Leaf A-D | | |
|Leaf A-D | RD1:1 Type16| | |
| RD1:1 Type 16| (S1,G1) | | |
| (S1,G1) | Orig PE1 | | |
| Orig PE1 | Orig ASBR4 | +------- PE4 ---- RCV
| Orig ASBR3 |RT ASBR3:0 | c)BGP Upd | (G1)
|RT PE1:0 | | Leaf A-D |
| | | RD3:1 Type 16|
| | | (S1,G1) |
| | | Orig ASBR4 |
| | | Orig PE4 |
| | | RT ASBR4:0 |
+ + + +
\ / \ /
+----------+ +----------------+_______________________________________________
BESS mailing list
BESS@ietf.org
https://www.ietf.org/mailman/listinfo/bess
