Subject: RE: Comments on draft-kurapati-dynamicrp-bgpmvpn-00.txt

From: Kurt Windisch <[email-masked]>
Date: Fri, 26 Jul 2013 01:05:25 +0000

Eric and Stig, 

Sorry for the delay in responding to your excellent feedback. All of 
your comments are very appreciated and I will try to address them as 
best I can below. There are very good points here that can be 
addressed in a new revision of the draft.

Eric wrote:

> We are wondering why the draft proposes to use a new SAFI, rather than
  reusing the MCAST-VPN SAFI. (…)
 
<Kurt>The reason for choosing to use a new SAFI is for support of the 
BSR routes to be negotiated by SAFI. If we were to find a way to leverage 
end-of-rib signaling in routine sets of NLRI updates, a separate SAFI 
would have other benefits (but see the end-of-rib comments below).

Alternately, it may be possible to simply rely on implementations 
to properly discard NLRIs of unknown types within the MCAST-VPN SAFI.

> The draft seems to allow an AFI of "IPv6" to be used together with an IPv4
  BSR address, or vice versa. (…)
 
<Kurt>This is not the intent. The only intended use of "mixed" AFIs would 
be in the "Originating PE's IP Address", which is the PE's address 
in the service provider core and may be a different AFI than the AFI 
of the customer network for which this SAFI is advertising BSR. 
For consistency, we should adopt the convention of RFC 6515 here 
as the issues are the same. We should also explicitly require that 
the AFI of other IP addresses in the NLRIs match the AFI of the NLRI.
Current language describing the possible values of "len of BSR 
address" and other similar passages must be tightened accordingly.
 
> For RP addresses and Group addresses the draft proposes to use the
  "encoded" formats from the PIM spec.  These formats contain an octet that
  identifies the address family.  There should be a requirement that the
  address family as encoded in the "encoded format" be the same as the
  address family identified in the BGP Update's AFI, and that the lengths be
  appropriate for that address family.
 
<Kurt>Agreed.
 
> In the BGP Update, parsing would be simpler if the Length field that
  precedes an "encoded group format" field or an "encoded unicast address
  field" contains the length of that field, not the length of the address
  prefix that appears within the encoded format.
 
<Kurt>Agreed.
 
> The mention of the "VRF Route Import Extended Community" in section 4.1
  should say "VRF Route Import Extended Community" or "VRF Route Import IPv6
  Address Specific Extended Community", to cover the case of a SP with an
  IPv6 infrastructure.  (It also needs to be made clear that this applies to
  the NLRI of sections 4.2 and 4.3 as well.)
 
<Kurt>Agreed.
 
> What action is to be taken if a BGP Update with an MCAST-VPN-BSR NLRI is
  received, but there is no BSR-BGP Path attribute?
 
<Kurt>Since all BGP-BSR NLRI route types must carry the BGP-BSR Path 
attribute per the current text, I think the proper response to a
route update lacking this attribute is to declare it malformed and 
require that the NLRI be discarded without processing of its contents.
 
> It's hard to interpret phrases like "the group count for this NLRI is not
  set".  How does one send this attribute without "setting" all its fields?
  Does "not set" just mean "set to zero", or does it mean only that certain
  fields are irrelevant to the processing of certain NLRIs.
 
<Kurt>While it's true that certain fields are not relevant to all NLRIs 
(see the next comment), this language can be clarified to be "set to zero."
The next comment does a nice job of defining these behaviors.
 
> The draft could use a little table to show which fields affect the
  processing which received NLRIs: 
  (…)
  Where a particular NLRI/field combination is "No", perhaps what the draft
  should say is that the field MUST be ignored when processing that type of
  NLRI.  That would allow the ignored field to carry any value, without risk
  of any interoperability problems.  If one only says "SHOULD be ignored",
  there may be interoperability problems.
 
<Kurt>This is correct and the draft should adopt these excellent suggestions.
 
> Regarding Fragmentation Tags
  There don't seem to be any clear instructions as to when the fragmentation
  tag field of the BSR-BGP attribute of a given NLRI actually needs to be
  changed. (…) why can't fragmentation  be entirely a local matter 
  (i.e., not communicated across the net)?
 
<Kurt>This is a good observation and we agree that the BSR Fragment Tag is 
not needed in BGP. It should be removed and the table from the previous 
comment can also be updated accordingly.

> Constructing BSMs from the Counts
  Suppose an ingress PE receives a BSM with 15 RP mappings for a given
  group.  Then it receives another BSM with 15 RP mappings for that group,
  10 of which are the same, and 5 of which are different.
 
  It seems that if the egress PE receives "withdraw, update, withdraw,
  update, withdraw, update, withdraw, update, withdraw, update", it could
  generate five BSMs.  Is our understanding correct, or are we missing
  something?
 
<Kurt>The egress PE may receive BGP NLRI updates as described above, such that
the counts contained in the NRLIs do not give the ability to determine
complete reception of the full set of updates that came from the BSM on the
ingress PE. 

The worst-case would be that each withdraw and new update arrives in a 
separate BGP UPDATE message, which depending on the implementation may 
trigger BSR to attempt to generate multiple BSMs to CEs. 

This is a worst-case scenario. The NRLI design attempts to account for 
the full set of updates using the various counters so that it can know
when it can send a complete BSM. But it must be acknowledged that the 
update stream that you give is one in which this protocol cannot operate
as well as native BSR.

However, it's likely that the ingress PE would batch the individual NLRI 
updates into a much fewer number of BGP UPDATE messages. 
The draft could make recommendations for the implementation to process all 
BGP NLRI updates that it has received before generating the new BSM to 
minimize the behavior above. 
 
One more point is that even if the NRLI updates arrive at the egress in 
separate BGP UPDATE messages at different times, triggering separate 
attempts to send BSMs, the BSR spec requires a minimum time between BSMs 
being sent (RFC 5059 specifies BS_min_interval with default of 10sec). 
Thus, it's likely that the second BSM would contain the updates to all 
15 mappings and the worst-case you described is mitigated. The issue 
then is the added delay to convergence introduced by the BS_min_interval
so it is still not ideal in comparison to native BSR.

> End of RIB 
  Given that there is almost always a route reflector between the ingress
  and egress PEs, how is the "End of RIB" marker going to be helpful in
  deciding when to originate a BSM?
 
<Pavan+Kurt>Thanks for pointing this out, that is correct.  Also, given that 
End of RIB implementations may differ, we will alter the draft 
in our next version accordingly to remove it.

> BS_Timeout
  There seems to be a problem with the following procedure from section
  6.2.2 ("Missing BSM") (…)
 
<Kurt>First off, I think this draft needs to clarify how it integrates with
the BSR state machine in the same terms of RFC5059. The precise events and
actions on the PEs needs to be specified so that it's clear how BGP events
on PEs interact with the local RP-Set and PE-CE BSMs.

Regarding the "Missing BSM" behavior, we need specify the following,
which will revise the original text and procedures:
* On the ingress PE, a timer must be run at the interval of 
  BS_Period (+ some small value to allow for jitter) such that if a BSM 
  has not been received from the local BSR, then the BSR Parameters NLRI.
* On the egress PE, upon withdrawal of the BSR parameters NLRI, the PE 
  must set its BS_Timeout to be BS_Timeout - BS_Period and BSMs must not
  be sent while the BSR Parameters NLRI is not present.

Thus, if timers are in sync and allowed jitter is small, behavior should 
mirror what would happen in native BSR from the points of view of CEs
on the egress side.
However, since we cannot rely on timers being perfectly in sync, it is
still possible for the egress site to retain the RPs from the missing 
BSM for up to one BS_Period.

This problem needs more thought to see if we can close this gap 
in relation to the native BSR operations.

> With regard to the sentence "As soon as the Type-1 is withdrawn,
  BS_Timeout period has to be started at the egress and upon its expiry, all
  the Type-2 and Type-3 entries MUST be deleted", it doesn't seem right for
  an egress PE to remove BGP installed routes based upon the expiry of a
  local timer.

<Kurt>Yes, this should read something to the effect that when BS_Timeout
expires on the egress PE, the RPs/groups discovered from the elected BSR
should be removed from the local RP-Set. The BGP routes will be deleted
when the ingress PE withdraws them.

Thanks again for the valuable comments.
We hope to produce a revisied draft in the coming weeks.

Thanks again
--Kurt

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Eric Rosen
Sent: Monday, June 24, 2013 2:51 PM
To: Pavan Kurapati
Cc: [email-masked]; [email-masked]; [email-masked]
Subject: Comments on draft-kurapati-dynamicrp-bgpmvpn-00.txt

Stig Venaas and I have discussed draft-kurapati-dynamicrp-bgpmvpn-00.text,
and together we have prepared the following set of questions and comments.

- We are wondering why the draft proposes to use a new SAFI, rather than
  reusing the MCAST-VPN SAFI.
  
  Using a new SAFI does provide a bit more freedom in designing the NLRI,
  but the draft sticks to the basic NLRI format of the MCAST-VPN SAFI
  anyway.  I don't think the new SAFI would be used on a BGP session unless
  the MCAST-VPN SAFI is also used on that session, so why not just use the
  MCAST-VPN SAFI for the new route types?

- The draft seems to allow an AFI of "IPv6" to be used together with an IPv4
  BSR address, or vice versa.

  When using the type 1-7 routes of the MCAST-VPN SAFI, the AFI designates
  the address family being used by the customer.  The address family being
  used by the service provider is inferred from the various length
  computations that are discussed in RFC 6515.  It seems best to stick with
  that same convention for the new BSR route types.  That would mean that
  the field "BSR Address" must be of the address family identified by the
  AFI.  The address length would then have to be appropriate for that
  address family, or the Update would be considered malformed.

  On the other hand, if it were to be decided to use a new SAFI, it might
  make more sense to dispense with the RFC 6515 hacks altogether and
  explicitly encode the address family of each address.

- For RP addresses and Group addresses the draft proposes to use the
  "encoded" formats from the PIM spec.  These formats contain an octet that
  identifies the address family.  There should be a requirement that the
  address family as encoded in the "encoded format" be the same as the
  address family identified in the BGP Update's AFI, and that the lengths be
  appropriate for that address family.

- In the BGP Update, parsing would be simpler if the Length field that
  precedes an "encoded group format" field or an "encoded unicast address
  field" contains the length of that field, not the length of the address
  prefix that appears within the encoded format.

- The mention of the "VRF Route Import Extended Community" in section 4.1
  should say "VRF Route Import Extended Community" or "VRF Route Import IPv6
  Address Specific Extended Community", to cover the case of a SP with an
  IPv6 infrastructure.  (It also needs to be made clear that this applies to
  the NLRI of sections 4.2 and 4.3 as well.)

- What action is to be taken if a BGP Update with an MCAST-VPN-BSR NLRI is
  received, but there is no BSR-BGP Path attribute?

- It's hard to interpret phrases like "the group count for this NLRI is not
  set".  How does one send this attribute without "setting" all its fields?
  Does "not set" just mean "set to zero", or does it mean only that certain
  fields are irrelevant to the processing of certain NLRIs.

- The draft could use a little table to show which fields affect the
  processing which received NLRIs:

          NLRI                          FragTag      RP Count    Group Count          

          BSR Parameters                Yes             No          Yes
          
          BSM Group Parameters          Yes             Yes         No

          BSM RP Parameters             Yes             No          No

  I think this table corresponds to your intentions.

  Where a particular NLRI/field combination is "No", perhaps what the draft
  should say is that the field MUST be ignored when processing that type of
  NLRI.  That would allow the ignored field to carry any value, without risk
  of any interoperability problems.  If one only says "SHOULD be ignored",
  there may be interoperability problems.

- Regarding Fragmentation Tags

  There don't seem to be any clear instructions as to when the fragmentation
  tag field of the BSR-BGP attribute of a given NLRI actually needs to be
  changed.  As a result, it's difficult to figure out its uses.  If some
  customer is sending fragmented BSMs every minute, one doesn't want to have
  BGP update all its RP mappings every minute.  So just when does the
  attribute value have to change?  Hopefully not too often, or there will be
  a lot of BGP thrashing.

  It's difficult to understand why a fragmentation tag field is needed in the
  BSR-BGP attribute at all.  The Group Count and RP Count fields are really
  what control when an egress PE can send a BSM.  If an ingress PE doesn't
  advertise changes to a groups RP mappings until it has all the mappings
  for that group (which I think is required in BSR), why can't fragmentation
  be entirely a local matter (i.e., not communicated across the net)?  What
  are we missing?

- Constructing BSMs from the Counts

  Suppose an ingress PE receives a BSM with 15 RP mappings for a given
  group.  Then it receives another BSM with 15 RP mappings for that group,
  10 of which are the same, and 5 of which are different.

  It seems that if the egress PE receives "withdraw, update, withdraw,
  update, withdraw, update, withdraw, update, withdraw, update", it could
  generate five BSMs.  Is our understanding correct, or are we missing
  something?

- End of RIB

  Given that there is almost always a route reflector between the ingress
  and egress PEs, how is the "End of RIB" marker going to be helpful in
  deciding when to originate a BSM?

- BS_Timeout

  There seems to be a problem with the following procedure from section
  6.2.2 ("Missing BSM"):

       "Egress PE receiving a withdrawn "BSR Parameters" route (Type-1)
       MUST still keep the corresponding Type-2 and Type-3 entries.
       However, it MUST NOT advertise the BSM to the CE without the
       Type-1 route present.  As soon as the Type-1 is withdrawn,
       BS_Timeout period has to be started at the egress and upon its
       expiry, all the Type-2 and Type-3 entries MUST be deleted.

       Say the egress has generated BSM at t=0.  At t=1 BS_Period
       expired at ingress PE and ingress PE did not get the periodic
       BSM.  So, it withdraws type-1 (BSR Parameters).  Egress PE has
       already generated BSM just before the type-1 withdrawal was
       received.  The egress PE skips the next periodic BSM towards the
       CE.  But CE is "off" by BS_Period interval by now.  Once the
       BS_Timeout expires, egress PE removes all the type-2 and type-3
       entries.  CEs connected to egress PE will remove the same, a
       whole BS_Period later.  Hence, to avoid this issue, once the
       BS_Timeout expires,an egress PE MUST generate a new BSM towards
       CE with RP hold time set to "0" for all the type-2 and type-3
       entries.  This will make the CEs in sinc with the the PEs.  After
       generating the BSM, PE removes all the Type-2 and Type-3 entries
       as stated above.

   The problem is the following.  The holding times of the individual RP
   mapping entries may be longer than the BS_Timeout.  Typically if
   BS_Timeout fires, the remaining holding time of an RP mapping entry will
   be the difference between (a) its holding time as reported in the last
   received BSM and (b) BS_Timeout.  The above seems to set the RP holding
   times to zero as soon as BS_Timeout expires.  The problem with this is
   that it may cause the RP mappings to timeout before a new BSR can be
   elected.

   Perhaps the withdrawal of a BSR parameters route should trigger the
   transmission of a new BSM that doesn't set the RP-mapping holding times
   to zero, but that just reduces each RP-mapping holding time by
   BS_Timeout.  Well, that would correct the RP-mapping holding times
   downstream of an egress PE, but it would also have the side effect of
   restarting the BS_Timeout at the routers downstream of the egress PE.  So
   that doesn't seem right either.

- With regard to the sentence "As soon as the Type-1 is withdrawn,
  BS_Timeout period has to be started at the egress and upon its expiry, all
  the Type-2 and Type-3 entries MUST be deleted", it doesn't seem right for
  an egress PE to remove BGP installed routes based upon the expiry of a
  local timer.