Re: WG LC: draft-ietf-l3vpn-2547bis-mcast-bgp

[Thomas Morin <[e-mail]>]

Hello,

Current specs allow a behavior where a PE does not advertise an I-PMSI
tunnel, and will only use S-PMSIs for the traffic. In that case, the PE
can choose to only instantiate an S-PMSI and a tunnel after the
reception of a C-multicast route.  

But there is a slight inconvenience : the downstream PEs don't have any
way to tell that an upstream PEs will behave in that way. Nothing
breaks, but it makes it harder to have smooth feedback on the CLI and
troubleshooting.

Here is a proposal : let's decide that when a PE will use such a
"delayed/S-PMSI only" approach, it still MUST advertise an I-PMSI A-D
route, with a PMSI Tunnel Attribute of type "No tunnel information
present" and a new flag "only delayed S-PMSI" set to 1.  On reception of
such a route, the "protocol behavior" of a downstream PEs is not
changed, except that it can do a best job at reporting issues to the
operator: if a PE has multicast state for which the UMH is a PE which
not advertise an I-PMSI with a real tunnel, and doesn't has this flag
set, this can be identified by the downstream PE as an error case.

I would thus suggest the following addition to section 5 of -bgp:
* add a flag S to the Flags field, "Only delayed S-PMSI"
* add the following text to the paragraph related to the "no tunnel
information present" type:
  This type MUST be used when the local policy on a PE is to not
  instantiate any I-PMSI tunnel for a VRF, and only use S-PMSI for which
  the instantiation may possibly be delayed until a C-multicast route is
  imported in that VRF. In that case, the "Only delayed S-PMSI" flag
  (S) MUST be set. 

(maybe the text above would be better placed ni 9.1.1 of -bgp)

Moreover, when preparing the above text, it occurred to me that section
9.1.1 of -bgp and section 6.1.1 or arch says imply that the PMSI tunnel
attribute can possibly be omitted : I think we should exclude that case
where an impose that the PMSI tunnel attribute is *always*present*, but
possibly set to a type of "no tunnel information".

Thank you,

-Thomas


Danny McPherson :
> Please consider today the start of a 2-week last call
> for draft-ietf-l3vpn-2547bis-mcast-bgp, available here:
> 
> http://tools.ietf.org/html/draft-ietf-l3vpn-2547bis-mcast-bgp-05
> 
> Input on this draft's suitability for publication as an
> Internet Standards Track document is solicited, feedback
> ends December 9, 2008.
> 
> Thanks in advance for your feedback!
> 
> Danny & Marshall