Hi John,
Protocol extensions should be standardized by the WG focusing on the
protocol .. be it OSPF, ISIS, BGP you name it. It may very easily
compromise operation of the base protocol if done incorrectly.
Very recently we went via very similar discussions reg route server and
while it does not even introduce any new changes to BGP protocol on the
wire .. changes to BGP state were sufficient reason to split the draft
into operational focus in GROW WG and BGP behaviour change in IDR WG.
Similarly here rtg wg or mpls wg could define in separate documents how
you are going to use newly flooded information or how you are going to
collect and populate those information into IGPs.
Rgs,
R.
Hi,
I am a bit confused. I thought the proper home for this work would
either be the rtg wg or the mpls wg. I thought it was presented to
the OSPF wg for information only.
Thanks,
John
Sent from my iPhone
-----Original Message----- From: [email protected]
[mailto:[email protected]] On Behalf Of Alia Atlas Sent:
Tuesday, June 21, 2011 6:45 PM To: Acee Lindem Cc: Spencer
Giacalone; CCAMP; OSPF WG List Subject: Re: [CCAMP] [OSPF]
draft-giacalone-ospf-te-express-path-01
Hi Acee,
I do agree that we should explicitly document this in the draft&
work on better names for the sub-TLVs that might be confused. I
also agree that we need to give the decision explicit
consideration; to give this the exposure necessary and
consideration for applications was why we had this draft discussed
in rtgwg as well as ospf.
In addition to the obvious uses for RSVP-TE, another potential
application is the idea of a path-weighted ECMP, where traffic is
split to the different next-hops based upon the total path
bandwidths out those next-hops. This is a pure IP application (LDP
follows of course) and I'd prefer not to lose track of those
options when considering the RSVP-TE applications.
Alia
_______________________________________________
OSPF mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/ospf