Subject: Re: [Status] Summary of STATUS BOF and the next steps

From: Anoop Ghanwani <[email-masked]>
Date: Wed, 4 Sep 2013 06:26:06 -0700

Some folks use BGP to perform the function of an IGP.  It looks like the
proposed charter would exclude them from taking advantage of this
technology.  It might be worthwhile adding BGP to that list of protocols to
be enhanced for this.

With respect to the text about working with existing data paths -- I wonder
if there is some way to capture that it might not work with all existing
implementations.  For example, the number of labels required to be pushed
at the ingress device may prevent some existing implementations from taking
advantage of this technology, depending on the size of the topology.

Anoop

On Wed, Sep 4, 2013 at 3:24 AM, Stewart Bryant <[email-masked]> wrote:

>
> May I suggest that we use the name "SR" and worry
> about what it binds to later.
>
> The higher priority item is the charter text. Does
> anyone have any comments on the text proposed
> so far, or the text in the BOF proposal:
>
>
> The Stacked Tunnels for Source Routing (STATUS) Working Group
> is chartered to develop a framework and use cases for source-routed
> flows in packet switched networks.
>
> IP previously had a source-based routing mechanism made
> available through an IP Option. This mechanism has, however,
> not been widely used and has a number of issues that make its
> use inadvisable, and other mechanisms (such as RFC 1940)
> do not appear to have been implemented at all.
>
> The ability of a router to influence or control the forwarding
> path of an individual packet or all the packets of a given
> Forwarding Equivalence Class (FEC) is a desirable feature
> for a number of reasons including Label Switched Path stitching,
> egress protection, explicit routing, egress ASBR link selection,
> and backup (bypass tunnels, Remote Loop-Free Alternates)
> routing. This can be achieved by facilitating source-initiated
> selection of routes to complement the route selection
> provided by existing routing protocols for both inter- domain
> and intra-domain routes.
>
> Historically, distribution of MPLS label binding information
> was done by relying on label distribution protocols
> such as LDP and RSVP-TE.
>
> The use cases documented by the working group will
> indicate the network function that is being facilitated
> and indicate which packet data plane is to be used.
>
> The framework developed by the working group will
> consider forwarding of IPv4, IPv6, and MPLS using the
> existing unicast data planes. Multicast forwarding will
> be for future study and the choice of data planes will
> be limited to those for which use cases exist. A key
> objective of the work will be to ensure that source-
> routed packets can be handled seamlessly by existing
> deployed equipment. A major objective will be that the
> new function does not modify existing data plane behavior
> or architectures, and that it can be enabled through only
> control and management plane software upgrades at
> deployed devices.
>
> Once the working group has established a framework
> and there is demonstrable consensus for use cases,
> the working group will move forward to specify protocol
> solutions for installing forwarding information through
> the use of the IGPs (OSPF and IS-IS), or through the
> management plane. In the course of developing protocol
> extensions, the working group will work closely with
> other IETF working groups responsible for the protocols
> being modified (such as OSPF, ISIS, and I2RS).
>
>     The working group is chartered for the following work items:
>
>     A framework for the use of the existing MPLS data plane to
>     support tunnel-based unicast source routing.
>
>     Develop use cases for tunnel-based unicast source routing
>     that demonstrate the need and support for solutions. Care
>     should be taken to avoid clustering use cases that might seem
>     to imply support for multiple use cases when only some of the
>     cluster actually have wide-scale support.
>
>     Develop ISIS and OSPF protocol extensions necessary for
>    distribution of MPLS forwarding information.
>
>     The working group will consider management (including
>     configuration, reporting, diagnostics, and OAM) and security
>     implications of its work and document them in separate
>     documents as appropriate.
>
>     The working group is not chartered to make any changes to
>     the MPLS or IPv6 data planes. Any proposed changes to the
>     data planes are to be specified in the working groups responsible
>     for the data planes (that is, the MPLS and 6MAN working groups,
>     respectively).
>
> - Stewart
>
>
> _______________________________________________
> status mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/status
>
>

---

From: <[email-masked]>
Date: Wed, 4 Sep 2013 16:00:35 +0200

Some folks use BGP to perform the function of an IGP.  It looks like the proposed charter would exclude them from taking advantage of this technology.  It might be worthwhile adding BGP to that list of protocols to be enhanced for this.

[SLI] The charter must not mention any protocol. In the charter, first we must do an analysis, then see which protocols must be fixed and how. But the charter must not define the solution :)

________________________________
De : [email-masked] [mailto:[email-masked]] De la part de Anoop Ghanwani
Envoyé : mercredi 4 septembre 2013 15:26
À : [email-masked]
Objet : Re: [Status] Summary of STATUS BOF and the next steps

Some folks use BGP to perform the function of an IGP.  It looks like the proposed charter would exclude them from taking advantage of this technology.  It might be worthwhile adding BGP to that list of protocols to be enhanced for this.

With respect to the text about working with existing data paths -- I wonder if there is some way to capture that it might not work with all existing implementations.  For example, the number of labels required to be pushed at the ingress device may prevent some existing implementations from taking advantage of this technology, depending on the size of the topology.

Anoop

On Wed, Sep 4, 2013 at 3:24 AM, Stewart Bryant <[email-masked]<mailto:[email-masked]>> wrote:

- Stewart

_______________________________________________
status mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/status

_________________________________________________________________________________________________________________________

Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.

This message and its attachments may contain confidential or privileged information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.
Thank you.

---

From: Mark Townsley <[email-masked]>
Date: Wed, 4 Sep 2013 16:18:11 +0200

> Some folks use BGP to perform the function of an IGP.  It looks like the proposed charter would exclude them from taking advantage of this technology.  It might be worthwhile adding BGP to that lis…

I agree that the statement "Develop ISIS and OSPF protocol extensions necessary for distribution of MPLS forwarding information." needs work, for two reasons. First, the extensions may not be strictly MPLS if the goal is to make this work for MPLS and IPv6. Second, I think it would be better for the ISIS and OSPF WGs to advance their own protocol extensions, rather than including that within the charter of SR as a deliverable. BGP, or any other routing protocol, could then adopt SR based on its own level of interest in that WG to do so. Would that suffice?

- Mark

---

From: Anoop Ghanwani <[email-masked]>
Date: Wed, 4 Sep 2013 07:40:40 -0700

On Wed, Sep 4, 2013 at 7:18 AM, Mark Townsley <[email-masked]> wrote:

> I agree that the statement "Develop ISIS and OSPF protocol extensions
> necessary for distribution of MPLS forwarding information." needs work, for
> two reasons. First, the extensions may not be strictly MPLS if the goal is
> to make this work for MPLS and IPv6. Second, I think it would be better for
> the ISIS and OSPF WGs to advance their own protocol extensions, rather than
> including that within the charter of SR as a deliverable. BGP, or any other
> routing protocol, could then adopt SR based on its own level of interest in
> that WG to do so. Would that suffice?
>

Yes, I think that would be reasonable.

Anoop

---

From: Hannes Gredler <[email-masked]>
Date: Thu, 5 Sep 2013 06:05:49 +0200

> I agree that the statement "Develop ISIS and OSPF protocol extensions necessary for distribution of MPLS forwarding information." needs work, for two reasons. First, the extensions may not be stric…

actually not. the whole point of forming a new WG is that
folks do not sneak-in "*-routing" ideas in the respective
protocol groups where people may not be paying attention.

back to the original argument: since what we are extending
are link-state protocols and there is an incarnation of BGP
to carry link-state graphs its perfectly legitimate to
add BGP to the list of to be worked on protocols.

---

From: Jeff Tantsura <[email-masked]>
Date: Thu, 5 Sep 2013 04:26:09 +0000

Agree with Hannes, BGP is a valid protocol to work on?

Regards,
Jeff

---

From: Robert Raszuk <[email-masked]>
Date: Thu, 5 Sep 2013 21:00:54 +0200

> protocol groups where people may not be paying attention.

Thx for making the objective of this new WG finally very clear ;)

In fact I would recommend we frame the above and make it as a charter.

That way the new soon to be formed WG will be serving as *routing area
preview/policy working group* preventing anyone to be able to
"sneak-in" any protocol extension to respective routing protocols WGs
without making sure such extensions are politically correct and
approved by unanimity voting of anyone subscribed to the list.

Cheers,
R.

PS. It's amazing to see this WG being formed considering a vast
majority of people attending the quote "non working group forming BOF"
in Berlin indicated no support for such new working group and segment
routing architecture to be discussed in current rtwg.

---

From: "Alvaro Retana (aretana)" <[email-masked]>
Date: Thu, 5 Sep 2013 19:31:02 +0000

>approved by unanimity voting of anyone subscribed to the list.

Robert:

Hi!

I assume you mean "preview/policy WG" for the technology in the charter
(segment routing, or however you want to call it), and not for the whole
routing area, right? ;-)

Thanks!

Alvaro.

---

From: Robert Raszuk <[email-masked]>
Date: Thu, 5 Sep 2013 21:49:03 +0200

Why not whole routing area if:

"the whole point of forming a new WG is that
folks do not sneak-in "*-routing" ideas in the respective
protocol groups where people may not be paying attention."

Let's set it up once and be done.

Cheers,
R.

---

From: Hannes Gredler <[email-masked]>
Date: Thu, 5 Sep 2013 23:17:15 +0200

robert,

given that current RTGWG chairs have already declined to work on
architectural work on stacking labels do you have a suggestion where
else this work should get done ? - CCAMP or perhaps MPLS (sic!) ?

if not would you then consider for a moment the alternative and the implications
if architectural work involving more than one target protocol would get done
at the respective protocol-WGs ? i'd predict a whole lot of hush-hush
protocol extensions, some even without requirements, some without use-cases
leaving a mess of incompatible protocols, leading in turn to multi-annual protocol
wars where at the end everybody has to support all protocols.
have seen this movie several times before and
as far as i am concerned i do not want this, nor my customers -
- they are interested in shipping, interoperable code.

shortcutting the process aka "awww we do not all of this"
an inspiring unwarranted fear of "the protocol-policy wants to control us"
does not help to achieve the above.

/hannes

---

From: Robert Raszuk <[email-masked]>
Date: Thu, 5 Sep 2013 23:43:12 +0200

Hi Hannes,

So you are saying that Alvaro declined to work on this in RTGWG where
there is only 7 pretty stable active WG documents yet is keen on
working on it in separate WG ?

As far as I recall if chairs decline to work on what IETF community
considers to be useful, chairs get replaced rather then new WGs get
formed.

Moreover I do not see any need for any "architectural work on stacking
labels" .. as far as I recall stacking labels has been day one
property of MPLS. Label POP - say without PHP - has also been pretty
well known MPLS day one feature. Ooops there is no swap - does this
grant new architecture ?

Is this hypothetical WG also going to get involved in source routing
work going on in homenet ? If not why not ?

For the topic of movie being replayed I have pretty good history of
similar past strategies where to block the substantial work various
artificial requirements are being placed (say multicast, security,
hold any progress of protocol extensions till architecture becomes
normative document etc ...).

I can bet that when let's say MPLS based segment routing data plane is
complete the argument why to do this again in IPv6 will be brought up.
Will that strategy help all customers ... clearly no.

Cheers,
R.

>On Thu, Sep 5, 2013 at 11:17 PM, Hannes Gredler <[email-masked]> wrote:
> robert,
>

---

From: "Stewart Bryant (stbryant)" <[email-masked]>
Date: Thu, 5 Sep 2013 21:50:28 +0000

Robert, please read my summary email that started this thread.

Given 7 WGs that need to contribute (before we even consider OAM and Management, or the inevitable feature creep ) and the work potentially spanning two IETF areas, there needs to be some group that can see the whole picture, and act a as a focus to ensure a consistent design.

Stewart

Sent from my iPad

---

From: "Alvaro Retana (aretana)" <[email-masked]>
Date: Thu, 5 Sep 2013 21:57:31 +0000

On 9/5/13 4:17 PM, "Hannes Gredler" <[email-masked]> wrote:

Hannes:

>architectural work on stacking labels

Just to clarify: the decision was made by the IESG/ADs to hold the BOF and
then the resulting train of events.

The work that is chartered in rtgwg (or any other WG for that matter) is
not a decision made by the chairs, but it is a result of WG consensus and
(if needed) rechartering approved by the IESG/Ads.

Alvaro.

---

From: "Stewart Bryant (stbryant)" <[email-masked]>
Date: Thu, 5 Sep 2013 22:09:57 +0000

Robert,

You should set aside the the name of the WG, and whether it is a new WG or and existing one, and consider the charter.

WGs are constrained to only work on items specified in their charter, so whether we spin up a new WG, or put the work in an existing WG, we need a precise definition of the work, from dataplane(s), through control planes, OAM, management etc, since all of these will be impacted to some degree, small or large, by the need to provide the consistent collection of protocol updates that will provide the SR functionality. 

So for the moment, can we focus on the a definition of the objective of the work, and an estimate of the work needed to produce a consistent design, i.e. focus on the charter.

Stewart

Sent from my iPad

---

From: Hannes Gredler <[email-masked]>
Date: Fri, 6 Sep 2013 00:16:07 +0200

robert,

On Sep 5, 2013, at 11:43 PM, Robert Raszuk wrote:

> [ … ]

and even if you dislike it - its a valid question -
all i am asking is that we have to document the use-cases for each data plane
(especially for new ones) seperatetly prior to change of protocols.
i need really a bit more more substance rather than
"aww this could be interesting for service chaining …."
before commencing expensive ASIC rework for introducing data plane #4
on the global internet.
i am sorry that the "reqs-before-protocol-work" diligence
and asking questions "if the same thing can get achieved using existing
technology" is being perceived as slow down tactics - its not;
its prudent work, nothing else.

/hannes

---

From: Alia Atlas <[email-masked]>
Date: Thu, 5 Sep 2013 20:04:05 -0400

Robert,

If you look at the charter for RTGWG, it is chartered to work on hop-by-hop
fast-reroute and
"The Routing area receives occasional proposals for the development
and publication
of RFCs dealing with routing topics, but for which the required work does
not yet rise to the level where a new working group is justified, yet the
topic does not fit with an existing working group, and it is either not
ready for a BOF or a single BOF would not provide the time to ensure a
mature proposal. The RTGWG will serve as the forum for developing these
types of proposals."

The size of the work for STATUS would take over a significant part of the
WG and hinder it from serving its current purposes.  I think that the work
doesn't fall in the parameters currently expressed in the charter.  When a
casual glance reveals at least 8+ drafts to be coordinated among many
working groups, it is naive to assume that is the extend of the work
involved.

Obviously, the WG chairs serve at the pleasure of the ADs and work on the
charter specified by the IESG.

RTGWG is not busy with a large number of WG drafts, but we nonetheless keep
occupied.  Feel free to come by sometime and see :-)

Alia

---

From: <[email-masked]>
Date: Fri, 6 Sep 2013 09:09:45 +0200

Stewart,

OAM work will start initially, I hope. As I mentioned, there's a prototype applying SR technology (without the extensions required by any of the 7 WGs of course). Still, experience collected there allows work on OAM requirements and features.

I'm exchanging mails with some interested colleagues already. We'd be happy to continue the OAM discussion on a public list.

Regards,

Ruediger

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Stewart Bryant (stbryant)
Sent: Thursday, September 05, 2013 11:50 PM
To: Robert Raszuk
Cc: Hannes Gredler; [email-masked]
Subject: Re: [Status] Summary of STATUS BOF and the next steps

Stewart

Sent from my iPad