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: David Meyer <[email-masked]>
Date: Fri, 1 Aug 2003 13:32:25 -0700

>>     to come back to this list with the document for further

Ok by me. Those who have expressed interest in working on such a
document are myself and Danny McPherson ([email-masked]). A few
other people have offered to review whatever we come up with.

Dave

---

From: David Meyer <[email-masked]>
Date: Fri, 1 Aug 2003 13:32:25 -0700

Dave

---

From: Yakov Rekhter <[email-masked]>
Date: Thu, 07 Aug 2003 11:33:00 -0700

Alex,

>  the messages from Russ and Robert. Comments are welcome.

see below...

>     on this topic and then discuss it here.

The draft should also provide a *rationale* explanation on why acceptance 
of RP extensions should take into consideration whether the information is 
classified as "routing-related" vs "non-routing related".

>     to come back to this list with the document for further

Provide *rationale* explanation on why these concerns/considerations
are not applicable to the information labeled as "routing", and are
limited only to the information labeled as "non-routing".  Moreover,
specify whether these concerns/considerations are of practical or
theoretical significance.
  
>     implementations should support.

Please also add "meanwhile recommendations" for ISIS and OSPF.
  
>     all of us may agree with this, ignoring this would be plain wrong,

The "overloading" issue (if one believe that it exists) is applicable
to ISIS and OSPF as well. Thus folks who believe in the overloading
issue need to consider not just MP-BGP, but ISIS and OSPF too.
Specifically these folks need to come up with an alternative not
just to MP-BGP, but to ISIS and OSPF as well.
  
>     perform. This team would then be asked to come up with these two

This team also needs to provider *rationale* arguments on why
the alternative is needed only for "non-routing" info distribution
and should not include "routing" info distribution.
 
>     BOF for this topic explicitly.)

Yakov.

---

From: Yakov Rekhter <[email-masked]>
Date: Thu, 07 Aug 2003 11:33:00 -0700

Alex,

see below...

  

  

Yakov.

---

From: Robert Raszuk <[email-masked]>
Date: Fri, 08 Aug 2003 04:13:31 +0200

Hi Yakov,

> to ISIS and OSPF as well.

I actually beileve folks which are concerned or worried should not limit
themselves to BGP, ISIS & OSPF. Why not also consider RSVP, SNMP, ICMP,
LDP or HTTP and many other protocols which were originally desinged for
something different and just evolved into other usefull uses ?

Taken HTTP for example ... wasn't it the primary application to have a
common protocol to access web pages ? Now aren't we also transporting
files with http ? Taken ICMP was it meant from day one to serve as tool
to determine link bandwith characteristics (pathchar) in the internet ?

Thx,
R.

---

From: Robert Raszuk <[email-masked]>
Date: Fri, 08 Aug 2003 04:13:31 +0200

Hi Yakov,

Thx,
R.

---

From: Danny McPherson <[email-masked]>
Date: Thu, 7 Aug 2003 22:37:56 -0600

> to determine link bandwith characteristics (pathchar) in the internet ?

Because this is the Routing Area and we're _primarily concerned with
routing protocols, not routed protocols.

-danny

---

From: Randy Bush <[email-masked]>
Date: Thu, 7 Aug 2003 21:46:00 -0700

> something different and just evolved into other usefull uses ?

i, for one, have done so consistently for years.  e.g., see my plenary
talk from the most recent san diego meeting.

but perhaps, instead of discussing personalities, we should stick to
principles?

randy

---

From: Randy Bush <[email-masked]>
Date: Thu, 7 Aug 2003 21:46:00 -0700

randy

---

From: Danny McPherson <[email-masked]>
Date: Thu, 7 Aug 2003 22:37:56 -0600

-danny