@ietf.org
Subject: RE: [bess] Question regarding RFC6625 and this draft-->//RE: I-D
Action: draft-ietf-bess-mvpn-expl-track-13.txt
Robert,
You may want to leave the previous tunnel (if it is no longer needed for other
traffic). E.g., sending an mldp label withdrawal or withdrawing a Leaf
Cc: Xiejingrong ;
draft-ietf-bess-mvpn-expl-tr...@ietf.org; bess@ietf.org
Subject: Re: [bess] Question regarding RFC6625 and this draft-->//RE: I-D
Action: draft-ietf-bess-mvpn-expl-track-13.txt
Hi Jeffrey,
Isn't this just a matter of how you would be implementing "tunneling
Hi Jeffrey,
Isn't this just a matter of how you would be implementing "tunneling" ?
For vast majority of decapsulations there is no state as such, but it is
just part of one of normal switching vectors in the router.
Best,
R.
On Wed, Jan 23, 2019, 21:40 Jeffrey (Zhaohui) Zhang The receiver PE
The receiver PE cannot keep its state to receive on both tunnels forever. After
some time, it has to leave the old tunnel.
Jeffrey
> -Original Message-
> From: Xiejingrong [mailto:xiejingr...@huawei.com]
> Sent: Wednesday, January 23, 2019 9:09 PM
> To: Jeffrey (Zhaohui) Zhang ; draft-ie
Hi Jeffrey,
Thanks for the explaination.
I have the same understanding "the text in RFC6625 is really/mainly about which
tunnel to send/receive on in a steady state."
What confusing me is the "which tunnel to receive" decision, obviously on
receiver site PE.
In my opinion, the receiver site PE
Hi Jingrong,
You're right that to avoid disruption and duplication a switchover delay is
needed on the source PE and desired on the receiver PE, and that means the
forwarding state needs to accommodate that.
However, the text is in RFC6625 is really/mainly about which tunnel to
send/receive on
Hi Jeffrey,
The sender PE need to work on (*,*) tunnel for a while (switch-over timer) and
then switch to the (S,G) tunnel.
To quote RFC6513 section 7.1.1
The decision to bind a particular C-flow (designated as (C-S,C-G)) to
a particular P-tunnel, or to switch a particular C-flow to a
p
Jingrong,
> It is determined by the sender site PE whether to steer the flow of (C-S,
> C-G) into (*,*) PMSI-tunnel or (S,G)PMSI-tunnel, and the receiver site PE
> should work correctly in any case.
Why would the sender PE send into (*, *) when there is a match for (S,G)?
Jeffrey
> -Origi
Hi,
I have a question regarding RFC6625 and this draft, since this draft is based
on the RFC6625.
In RFC6625 section "3.2.1 Finding the match for (C-S,C-G) for Data Reception":
It defined the rules for Finding the matched S-PMSI A-D route for a (C-S,C-G)
state on a receiver site PE.
It seems to
