Subject: [Idr] draft-pmohapat-idr-info-safi

From: Eric Rosen <[email-masked]>
Date: Tue, 28 Nov 2006 08:59:27 -0500

At the  IDR WG meeting,  several issues were  raised with respect  to draft-
pmohapat-idr-info-safi-00.txt.  Enclosed is my summary of the issues and how
I would like to address them. 

One issue is whether  the draft proposes a good way of  using BGP to signal,
e.g., multipoint-to-point  L2TPv3 tunnels.   The draft proposed  a dedicated
SAFI  to  be  used   for  distributing  encapsulation  information,  and  in
particular  for doing  the signaling  needed to  set  up multipoint-to-point
L2TPv3  tunnels.  This information  is encoded  in an  "L2TPv3 encapsulation
(optional, transitive)  attribute" which  is attached to  that SAFI,  and is
sent in an update originated by the receiving endpoint of the tunnel.

A  possible  alternative   that  was  suggested  is  to   send  the  "L2TPv3
encapsulation  attribute"  along  with  each  prefix for  which  the  tunnel
endpoint sends an update.  Then one wouldn't need the special purpose SAFI.

I don't  think this is  a very good  alternative, for the  following reason.
The  tunnel endpoint  may be  be  maintaining routing  information for  many
thousands  of prefixes.   If  the encapsulation  information  ever needs  to
change, this would require that each one of the prefixes be updated.

Granted, it  is rare for the  encaps info to  change, and it's not  like one
sends a separate update for each  prefix.  Still, the number of updates does
increase in  proportion to the number  of prefixes (even if  the constant of
proportionality is less than 1), and by using a dedicated SAFI one can avoid
this.  Why send more updates than one needs to? 

Also, if one includes the  encapsulation attribute with each prefix, one has
to  define a  new procedure  whereby  the attribute  is removed  by any  BGP
speaker that  does "next hop self".   I think this means  that the attribute
really  could not  be made  transitive, unless  supported with  a capability
advertisement.   With the  use of  a dedicated  SAFI, no  such  procedure is
needed, the encapsulation attribute is  just handled like any other optional
transitive  attribute.  (Though  perhaps the  two alternatives  don't behave
that  differently,   since  using  a   dedicated  SAFI  would   prevent  the
encapsulation info from passing through any BGP speaker that doesn't support
that SAFI.)

Overall, I think it turns out simpler to use the dedicated SAFI. 

Assuming we use a dedicated  SAFI for encapsulation signaling, another issue
is whether to  use one SAFI for all the  encapsulation protocols, or whether
to use  a different SAFI  for each  one.  It was  suggested that by  using a
different  SAFI  for  each  encapsulation  protocol,  a  BGP  speaker  would
automatically avoid  receiving encaps info for  encapsulation protocols that
it doesn't support.   However, I don't think this is a  good thing.  I think
we want to allow the encaps  info for a particular encapsulation protocol to
pass transparently  through BGP speakers that don't  support that particular
encapsulation  protocol, in  the manner  of optional  transitive attributes.
Certainly we don't want to have to update the route reflectors every time we
add a new encapsulation protocol.  So  I propose to keep a single SAFI which
can carry the encapsulation info for multiple protocols in a as attributes. 

Another issue is  the form of the  NLRI.  We have proposed that  the NLRI be
composed of the IP address of  the BGP speaker originating the update, along
with  a  two-byte  distinguisher.   The distinguisher  doesn't  provide  any
semantics, it  really just gives  you a way  to break the set  of attributes
into  several updates.   That allows  you to  modify and  update one  of the
encapsulation info  attributes without having  to include all the  others in
your  update.  This seems  to me  to be  a reasonable  feature, even  if not
really necessary. 

The final issue has to do with  the name of the new SAFI.  I've assumed that
the updates  might carry  not only encapsulation  info attributes,  but also
other  attributes that  might be  used to  help the  remote  tunnel endpoint
decide  which  encapsulation  to  use.   We've  proposed  that  these  other
attributes be communities or  extended communities.  Once these are allowed,
there's no  way to force  people to include  a particular community  only if
that community has something to  do with encapsulation.  However, as long as
that  is  understood,   I  have  no  problem  with   choosing  a  name  like
"encapsulation  signalling SAFI"  (I guess  it  would be  "encaps SAFI"  for
short.)  

Comments? 

_______________________________________________
Idr mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/idr

---

From: Robert Raszuk <[email-masked]>
Date: Tue, 28 Nov 2006 15:27:51 -0800

Eric & WG,

> Assuming we use a dedicated  SAFI for encapsulation signaling, another
> issue is whether to  use one SAFI for all the  encapsulation
> protocols, or whether to use  a different SAFI  for each  one.

I think your email below would be a good place to consider and get IDR
WG input and comments on one more alternative here.

For the number of years we are observing growing number of essentially
non routing information to be carried in routing protocols.

For IGPs we already have a set of predefined opaque TLVs which are
easily extendable when need arises to carry new information type. The
changes required to the IGP at such event are minimal. Clear separation
of opaque vs routing information also allows to treat and process opaque
info differently if needed.

Few months back when I revisited my former work on bgp auto discovery
the conclusion drawn was that again this is an classic example of opaque
information. So is encapsulation info, configuration parameters and
perhaps few more elements which if exchanged between bgp speakers could
provide a number of new services. Therefor the idea arised to define a
single opaque BGP SAFI with single BGP Informational Attribute which
could be used to carry per each NLRI different sets of non routing
information between interested nodes.

The very preliminary draft has been placed here for your review:
http://raszuk.net/info/draft-raszuk-idr-oid-base-00a.pdf

The official version will be posted for Prague IETF.

One of the major advantage is that BGP would not need to understand nor
process the opaque content. As long as the new opaque SAFI is supported
as well as single attribute known what is exchanged within this
attribute payload would be transparent to BGP code.

It would be client's responsibility to process the carried information
depending (per NLRI key) being router's encapsulation engine, ibgp peer
provisioning module etc ...

I also think that such approach offers very clear (AS IS) migration way
for using a new dedicated flooding distribution model (non BGP based)
without the need for any modification to service clients. And since I
think most of us agree that such a new information distribution protocol
is needed considering in the mean time introduction of a number of
dedicated new SAFIs as well as many new BGP attributes carrying opaque
information only to have the issue with their eminent removal seems not
too optimal.

Comments ?

Cheers,
R.