Hi Greg,
I've trimmed some text. Please see zzh3> below.
Because all PEs may arrive at a different
conclusion regarding the state of the tunnel,
procedures described in Section 9.1.1 of [RFC 6513] MUST be used
when using inclusive tunnels.
GIM3>> Got it, thx. Would s/may/could/ be acceptable to avoid questions about
RFC2119-like language?
Zzh2> I think it should be a MUST - otherwise you get duplicates when
different PEs pick different upstream PEs.
GIM4>> I've tried s/may/MUST/ and it doesn't read right:
Because all PEs MUST arrive at a different
conclusion regarding the state of the tunnel,
procedures described in Section 9.1.1 of [RFC 6513] MUST be used
when using inclusive tunnels.
I'll do s/may/could/ to have this text:
Because all PEs could arrive at a different
conclusion regarding the state of the tunnel,
procedures described in Section 9.1.1 of [RFC 6513] MUST be used
when using inclusive tunnels.
Zzh3> My bad. I thought you were talking about must/MUST. "could" is fine since
you were talking the "may".
Zzh2> I checked the surrounding text in this draft and section 5.1.3 in
RFC6513. I believe section 3 of this document, before its subsection 3.1 should
be re-written as following:
....
Zzh2> The reason is that for the candidate set is not ordered - it's just a set
to select from (either based on IP address or hashing).
GIM4>> Many thanks, Jeffrey! Please check the working verion or diff and let me
know if I've correctly applied the changes.
Zzh3> There is an extra "o":
o The first two options select the Upstream PE from a candidate PE
set either based on IP address or a hashing algorithm. When used
together with the optional procedure of considering the P-tunnel
status as in this document, a candidate upstream PE is included
in the set if it either:
o <-- EXTRA
A. advertise a PMSI bound to a tunnel, where the specified tunnel
is not known to be down or up
3.1.7. Per PE-CE link BFD Discriminator
...
Zzh2> Because you still want to track the tunnel state (in addition to pe-ce
interface state), you would need at least two discriminators - one for the
tunnel and one for the PE-CE link. However, the new "BGP- BFD attribute"
defined in this spec only accommodates one discriminator (and my understanding
is that you can't have more than one of the same attribute).
GIM4>> It is implied that the PE-CE link is monitored by p2p BFD session, most
likely as described in RFC 5881 for single-hop BFD. That would not require
bootstrapping.
Zzh3> I was saying that if you use "Per PE-CE link BFD Discriminator", then ...
Zzh2> The simplest solution is that just use the same discriminator (vs. per
PE-CE link discriminator). With that, the ENTIRE section 3.1.7 (including its
subsections) become the following:
GIM4>> I'm confused by "use the same Discriminator". The root advertises its
Discriminator to the downstream PEs. The value is only locally unique for the
root, not for any downstream PE. For a PE-CE link, if BFD is used, each PE must
pick its locally unique value to use it as My Discriminator. CE uses that value
in Your Discriminator field and thus the PE demultiplexes p2p sessions using
its locally unique value in the Your Discriminator field. Note that p2mp BFD
session among the root and the downstream PEs is such that PEs receives BFD
control packets with the value of Your Discriminator field zeroed, and PEs use
a different mechanism to demultiplex p2mp BFD sessions (as described in RFC
8562).
Zzh3> I meant that you don't use PE-CE link specific discriminator (e.g. value1
for the tunnel status, value2 for PE-CE link1 and value3 for PE-CE link2).
Whether you track the PE-CE link status or not, you just include the
discriminator that corresponds to the tunnel. I don't mean that all PEs use the
same discriminator.
3.1.7 Tracking upstream PE-CE link status
In case the PE-CE link on an upstream PE failed, even though the provider
tunnel is still up,
It is desired for the downstream PEs to switch to a backup upstream PE. To
achieve that,
If the upstream PE detects that its PE-CE link fails, it SHOULD set the
bfd.LocalDiag of the
p2mp BFD session to Concatenated Path Down and/or Reverse Concatenated Path
Down,
unless it switches to a new PE-CE link immediately (in that case the
upstream PE will start tracking
the status of the new PE-CE link).
When a downstream PE receives that bfd.LocalDiag code, it treats as if the
tunnel itself
failed and tries to switch to a backup PE.
GIM4>> Would the downstream PE be switching to the backup Provider Tunnel, not
to a backup PE? If yes, that option already listed in section 3.1.7.2
Zzh3> No.
Zzh3> Take one step back. When we don't track PE-CE link status on the ingress
PE, we only care about the tunnel status. If it is down, we don't use the
corresponding PE. There is no "backup tunnel". There is only a "backup upstream
PE".
Zzh3> Now add the PE-CE link to the picture. Even if the tunnel remains up but
if the PE-CE link is down, we don't use that upstream PE anymore. From the
downstream PE's point of view, there is no difference whether it is the tunnel
down or upstream PE-CE link down. It should not care.
Zzh3> That's why I say that the ENTIRE section of 3.1.7 should be replaced with
my proposed text. No more 3.1.7.1 and 3.1.7.2.
Jeffrey
Juniper Business Use Only
_______________________________________________
BESS mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/bess
