Subject: RP overloading: Next Steps

From: Alex Zinin <[email-masked]>
Date: Fri, 1 Aug 2003 01:20:53 -0700

Folks-

 Below is my suggestion on how we move forward, as well as a reply to
 the messages from Russ and Robert. Comments are welcome.

 1. Define routing-related and non-routing related information
    and guidelines for acceptance of RP extensions.
 
    Since we already had a discussion on this topic on the rtg-dir,
    I would suggest that we ask the rtg-dir to come up with the draft
    on this topic and then discuss it here.

 2. Document concerns/considerations on overloading RPs with non-routing
    related information.

    dmm et al seem to be working on this part already.
    I suggest we formalize this as a design team and ask them
    to come back to this list with the document for further
    discussion.

 3. Document "meanwhile recommendations" for MP-BGP
    
    While we are discussing alternative distribution mechanisms, we
    may want document the considerations that we believe are important
    to know to deal with the stuff in the pipe already.

    It seems it should be possible to come up with an
    architecture-level document operating in terms defined within the
    BGP spec, not getting into the code-level details, and yet
    providing a list of requirements/recommendations that MP-BGP
    implementations should support.

 4. Start exploring the alternative space

    There is a considerable part of the community who believe that
    overloading MP-BGP is not the right thing in the long run. This
    was clear at the meeting, and is clear on this list too. While not
    all of us may agree with this, ignoring this would be plain wrong,
    I believe.

    I also believe that until we have some documented understanding of
    the functional requirements and design considerations for the
    alternative, the situation will not change and all our discussions
    will remain purely theoretical. Writing requirement and framework
    documents is not a pleasant exercise, but it seems that in this
    case we need something all of us can read and discuss. In fact, I
    think Eric's posting to the list could be a good start.

    What I think we should do is form a design team that would group
    people who believe that we DO need an alternative to MP-BGP for
    non-routing info distribution and know what functions it should
    perform. This team would then be asked to come up with these two
    documents, that would be discussed on this list and in Minneapolis
    (we would either bring it to the open RTG area meeting, or have a
    BOF for this topic explicitly.)

Comments to the messages inline below.

Russ White wrote :
> My general take: It might be nice to have a new protocol to carry stuff
> around between routers in. Especially if that stuff doesn't relate to
> routing. My questions, though, are:
> 
> -- How long will it wait to develop, deploy, and debug, the stuff protocol?

we don't know

> -- Will the providers stop asking for new features that require carrying
> non routing information between routers until the stuff protocol is fully
> deployed?

of course not

> I think the answers to these two questions make it apparent that
> might be useful to create such a stuff protocol, but we need to
> think realisitically about:
> 
> -- What do we mean by "non routing stuff?"

we need an agree upon definition of routing-related stuff. everything
else would be non-routing.

> -- What are we going to do with "non routing stuff" in the meantime?

I see the following possible options for a given app:

 a. an app-specific protocol is designed--might very well be the case
    for some apps
    
 b. we keep putting it on MP-BGP as we've been doing till now
 
 c. we put it on MP-BGP with a different TCP port number, assigned
    specifically for non-routing apps--this should encourage
    separation at least at the transport level

> -- What do we do when some mission critical app rolls out on the stuff
> protocol, and people start calling for us not to change it any more, since
> it will introduce stuff instability, and thus we need a "stuff 2" protocol
> to break out the "new stuff" from the "old stuff?"

I wouldn't think so.
If folk don't feel comfortable putting some critical app on the
"stuff" transport, a separate protocol for that app seems like
the right choice.

> -- Should, if we do a stuff protocol, go back and rip the "nonrouting
> stuff" out of BGP, if we can actually determine what that is, and put it in
> the stuff protocol?

I personally don't think so, but I could see how some people would
want this to happen.

Robert Raszuk said:
> IMHO the best thing that can be done today by RTG directorate/ADs/IETF
> is to mandate the clear separation of so called "non-routing"
> information being distributed into their own AFI/SAFIs. That for one
> will long term provide easy migration into a new transport (when such is
> available & deployed) as well kind of "force" better software
> engineering and code architecture.

To make sure I understand this correctly, do you mean that the
recommendation should be to introduce a new AFI/SAFI for each
new app, as opposed to overload NLRI and attributes for existing
AFI/SAFIs?

> It could be said that it is recommended by each implementation to have
> such a new AFI/SAFIs separated into their own RIBs, their own
> maintenance & operation routines given AFI/SAFI specific and be
> demultiplexed by general BGP inbound process based on the AFI/SAFI
> values very early. 

I guess I can see two parts here:

 a) a better description of the protocol model (including RIBs) that
    can be added to the updated MP-BGP spec, and

 b) implementation recommendations
    generally, this is the field that we don't want to step in,
    but if there's a strong agreement that this is the right thing
    to do, the topic is important enough to make an exception

> Looking realistically otherwise what we will see soon would an explosion
> of extended/flexible communities or new attribiutes use under current
> AFI/SAFIs which may in fact have very negative impact on current
> Internet stability.

Thanks.
Alex Zinin

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

---

From: "Hamid Ould-Brahim" <[email-masked]>
Date: Tue, 12 Aug 2003 09:40:59 -0400

Alex,

[clipped]...
>     BOF for this topic explicitly.)

Two comments on that:

- If I take the example of former ppvpn wg, there was in fact a design
  team created specifically for the discovery mechanism or to be
  more precise, a design team that explores requirements and
  alternatives to non MP-BGP provider-based VPN discovery for
  those who didn't like BGP option for one reason or another. 
  After much debate, the outcome of that design
  team was inconclusive and produced only a requirement document
  on that topic. 

  My question is how the above proposal is any different from
  what has already been done in former ppvpn wg?

- It looks to me even if some people believe we DO need alternative
  to MP-BGP for non routing info distribution, this in my opinion
  should be part of the discussions going on in each specific
  application (similarly to what has been done in ppvpn).
 
  I do not expect *routing-area* discussions/work to produce
  a protocol that is mainly intended for non routing related 
  application being pursued in other working groups.

Hamid.