Subject: Routing Area Tuning - Update

From: "Adrian Farrel" <[email-masked]>
Date: Wed, 20 Aug 2014 23:07:42 +0100

Hi,
 
I wanted to take a moment to update you all on our progress and to poll you for
some more opinions.

Firstly there is a sense that this may all be a fait accompli with there being
no point in raising any questions or concerns. I'm sorry if this is how it came
over. The ADs have been thinking about this and discussing it for quite a while
and we spent quite a bit of time before and during IETF 90 seeking out different
viewpoints and having our opinions shaped. So we have built up strong views, but
we do want to hear your views and we particularly want to be told what we have
got wrong.

One question we are still thinking about concerns the arrangement of  TE-related
work across the MPLS, CCAMP, and PCE working groups. An option we had discussed
resulted in PCE unchanged, TEAS to take TE architecture and RSVP-TE, and CCAMP
to do technology-specific protocol work. But there is another option which would
leave:
   TEAS - TE architecture and requirement work, but no protocol work
   PCE - All PCEP work, PCE applicability and requirements, but PCE architecture
              goes to TEAS
   RSVP-TE - All generic protocol work for RSVP-TE from MPLS and CCAMP
   CCAMP - technology-specific protocol work.
This thinking is somewhat motivated by the way the IGP work happens at the
moment and somewhat by the thought that TEAS might be too large and have too
many distractions if it has protocol and architecture, while the motivation for
keeping  architecture and protocol together in TEAS is that it provides for
better energy and interaction. 

We would like to hear your opinions and get a better sense of the consensus
around TEAS.

At the moment Alia and I are recovering from Toronto and handling vacations, but
we have formed a rough order for working on the working groups.

First up is the RTGWG because that is a relatively straightforward tweak to an
existing charter.
Then we plan to group together {L2VPN, L3VPN, PWE3, NVO3} becoming {PALS, BESS,
NVO3}
Then we will look to work out how to handle the TE elements discussed above.

We'll be taking a bit of a two-pronged approach: identify chair candidates; spin
up draft charters.
We plan to work on the draft charters with the future chairs and put them out on
this list and on the relevant WG mailing lists as soon as we have them with the
aim of getting review and discussion.

One last point. All WGs should continue to operate according to their current
charters. We can handle the transition if/when it happens, but this work should
not get in the way of real technical work.

Please let us know what you think.

Adrian,
per pro Alia

---

From: "Joel M. Halpern" <[email-masked]>
Date: Wed, 20 Aug 2014 18:15:21 -0400

I am a little concerned that the proposed approach has TEAS doing the 
requirements for work to be done as protocol in other WGs.  While we 
made that work, for very good reasons, in KARP, it is frequently a 
source of friction and hinderance.

Yours,
Joel

On 8/20/14, 6:07 PM, Adrian Farrel wrote:
> _______________________________________________
> routing-discussion mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/routing-discussion
>

---

From: "Papadimitriou, Dimitri (Dimitri)" <[email-masked]>
Date: Wed, 20 Aug 2014 23:12:46 +0000

Hi Adrian, 

It remembers me the TEWG approach; there were additional considerations at that time also but IETF being an organization which produces protocols (often bottom-up) and info/data-models if a working group has none of them in its direct scope, this approach puts them from the start in a difficult position. On the other hand, limiting CCAMP to techno-specifics (and disconnect them from TE) looks to me as the replay of the IPO WG (that ended in Atlanta 2002 in the general indifference).

This being said, have you considered the following

Include TEAS activities in CCAMP (as the latter is mostly about TE) ? and then a set of protocol groups PCEP, Generic TE Routing protocols (IGP-TE + RSVP-TE), MPLS + LDP --note it doesn't change the number of working groups.

Thanks,
-dimitri.

> -----Original Message-----
> From: routing-discussion [mailto:[email-masked]] On
> Behalf Of Joel M. Halpern
> Sent: Thursday, August 21, 2014 12:15 AM
> To: [email-masked]; [email-masked]
> Subject: Re: Routing Area Tuning - Update
> 
> requirements for work to be done as protocol in other WGs.  While we made
> that work, for very good reasons, in KARP, it is frequently a source of
> friction and hinderance.
> 
> Yours,
> Joel
> 
> > I wanted to take a moment to update you all on our progress and to
> > poll you for some more opinions.
> >
> > Firstly there is a sense that this may all be a fait accompli with
> > there being no point in raising any questions or concerns. I'm sorry
> > if this is how it came over. The ADs have been thinking about this and
> > discussing it for quite a while and we spent quite a bit of time
> > before and during IETF 90 seeking out different viewpoints and having
> > our opinions shaped. So we have built up strong views, but we do want
> > to hear your views and we particularly want to be told what we have got
> wrong.
> >
> > One question we are still thinking about concerns the arrangement of
> > TE-related work across the MPLS, CCAMP, and PCE working groups. An
> > option we had discussed resulted in PCE unchanged, TEAS to take TE
> > architecture and RSVP-TE, and CCAMP to do technology-specific protocol
> > work. But there is another option which would
> > leave:
> > This thinking is somewhat motivated by the way the IGP work happens at
> > the moment and somewhat by the thought that TEAS might be too large
> > and have too many distractions if it has protocol and architecture,
> > while the motivation for keeping  architecture and protocol together
> > in TEAS is that it provides for better energy and interaction.
> >
> > We would like to hear your opinions and get a better sense of the
> > consensus around TEAS.
> >
> > At the moment Alia and I are recovering from Toronto and handling
> > vacations, but we have formed a rough order for working on the working
> groups.
> >
> > First up is the RTGWG because that is a relatively straightforward
> > tweak to an existing charter.
> > Then we plan to group together {L2VPN, L3VPN, PWE3, NVO3} becoming
> > {PALS, BESS, NVO3} Then we will look to work out how to handle the TE
> > elements discussed above.
> >
> > We'll be taking a bit of a two-pronged approach: identify chair
> > candidates; spin up draft charters.
> > We plan to work on the draft charters with the future chairs and put
> > them out on this list and on the relevant WG mailing lists as soon as
> > we have them with the aim of getting review and discussion.
> >
> > One last point. All WGs should continue to operate according to their
> > current charters. We can handle the transition if/when it happens, but
> > this work should not get in the way of real technical work.
> >

---

From: "Andrew G. Malis" <[email-masked]>
Date: Thu, 21 Aug 2014 10:30:48 -0400

I agree with Joel - I think people find it hard to get motivated to do the
architecture and requirements if they also don't get to play around with
the protocols (the fun stuff), while the people doing the protocol work
also want their input into the architecture and requirements, since the
choices made there constrain what the protocol will look like. Of course,
you could have the same people tramping between two different WGs, but that
seems silly.

Cheers,
Andy

On Wed, Aug 20, 2014 at 6:15 PM, Joel M. Halpern <[email-masked]>
wrote:

>> TE-related
>> consensus
>> vacations, but
>> current

---

From: Loa Andersson <[email-masked]>
Date: Thu, 21 Aug 2014 16:40:00 +0200

Folks,

I agree with Andy and Joel, having had RSVP-TE split between two working
groups, not along requirements and protocol, but along what they would
be used for has been a strength. MPLS did requirements and protocol for
"packet", while CCAMP did it for "GMPLS".

That places the architectural issues as a coordination point between
two wg, but that coordination was never hard.

I understand that this could be taken as an argument to push MPLS and
CCAMP back to where they were. But we have running code that this works.

/Loa

On 2014-08-21 16:30, Andrew G. Malis wrote:
> I agree with Joel - I think people find it hard to get motivated to do
> the architecture and requirements if they also don't get to play around
> with the protocols (the fun stuff), while the people doing the protocol
> work also want their input into the architecture and requirements, since
> the choices made there constrain what the protocol will look like. Of
> course, you could have the same people tramping between two different
> WGs, but that seems silly.
>
> Cheers,
> Andy
>
>
>
> On Wed, Aug 20, 2014 at 6:15 PM, Joel M. Halpern <[email-masked]
> <mailto:[email-masked]>> wrote:
>
>     I am a little concerned that the proposed approach has TEAS doing
>     the requirements for work to be done as protocol in other WGs.
>     While we made that work, for very good reasons, in KARP, it is
>     frequently a source of friction and hinderance.
>
>     Yours,
>     Joel
>
>
>         _________________________________________________
>         [email-masked] <mailto:[email-masked]>
>         https://www.ietf.org/mailman/__listinfo/routing-discussion
>         <https://www.ietf.org/mailman/listinfo/routing-discussion>
>
>
>     _________________________________________________
>     [email-masked] <mailto:[email-masked]>
>     https://www.ietf.org/mailman/__listinfo/routing-discussion
>     <https://www.ietf.org/mailman/listinfo/routing-discussion>
>
>
>
>

-- 

Loa Andersson                        email: [email-masked]
Senior MPLS Expert                          [email-masked]
Huawei Technologies (consultant)     phone: +46 739 81 21 64

---

From: "BRUNGARD, DEBORAH A" <[email-masked]>
Date: Thu, 21 Aug 2014 14:44:55 +0000

+1
I find the dynamics in IETF of having both requirements and protocol experts in the same group to be optimum. Immediate feedback vs. many cycles of throwing back and forth. As we have found multiple times, what is viewed as new requirements are often already supported by the protocol. More often than not, the requirements are based on a bad implementation.

From: routing-discussion [mailto:[email-masked]] On Behalf Of Andrew G. Malis
Sent: Thursday, August 21, 2014 10:31 AM
To: Joel M. Halpern
Cc: Adrian Farrel; [email-masked]
Subject: Re: Routing Area Tuning - Update

I agree with Joel - I think people find it hard to get motivated to do the architecture and requirements if they also don't get to play around with the protocols (the fun stuff), while the people doing the protocol work also want their input into the architecture and requirements, since the choices made there constrain what the protocol will look like. Of course, you could have the same people tramping between two different WGs, but that seems silly.

Cheers,
Andy

On Wed, Aug 20, 2014 at 6:15 PM, Joel M. Halpern <[email-masked]<mailto:[email-masked]>> wrote:
I am a little concerned that the proposed approach has TEAS doing the requirements for work to be done as protocol in other WGs.  While we made that work, for very good reasons, in KARP, it is frequently a source of friction and hinderance.

Yours,
Joel

Adrian,
per pro Alia

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

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

---

From: Abdussalam Baryun <[email-masked]>
Date: Thu, 21 Aug 2014 17:04:30 +0200

On Wednesday, August 20, 2014, Joel M. Halpern wrote:

> requirements for work to be done as protocol in other WGs.

I did not understand that from the proposal. Each work and work requirement
is done in same WG, so TEAS is not doing work requirement for another WG.
May be there are external and internal requirements.

AB

>> .

---

From: Lou Berger <[email-masked]>
Date: Thu, 21 Aug 2014 11:08:25 -0400

I'm not so sure. 

I think the tradeoffs are (a) architecture fragmentation/coordination vs
(b) protocol fragmentation/coordination vs (c) wg scope size, and a
desire/need to choose two.

With the approach presented in toronto we end up with architecture
fragmented across PCE and TEAS, and TEAS only able to ensure protocol
alignment between routing and signaling, but not PCE. Arguably, this is
how CCAMP has operated -- and I'd hope can be improved upon.  It also
means that folks that care only about an RSVP change need to sit through
/ track all the architecture-related work (aka noise).

I think a TEAS that is responsible for everything but the (routing,
signaling, pce, ...) protocol details would do a better job at ensuring
a consistent architecture/framework/model (and even encoding formats)
and not be "too big" (c).  Which is perhaps where Adrian was headed in
his mail.

If (c) wasn't an objective, I'd say have TEAS do all TE protocol
extensions to address Joel's (and the supporting) comments .

I think we can avoid a repeat of IPO in TEAS, even without it portion of
the protocol work, and that it is better for it to have all the high
level work (and ensure a consistent architecture/framework/model) than
for it to have a fragment of the high in order for it to also have a
fragment of the detail  work. 

Lou

On 8/21/2014 10:44 AM, BRUNGARD, DEBORAH A wrote:
>
> +1
>
> I find the dynamics in IETF of having both requirements and protocol
> experts in the same group to be optimum. Immediate feedback vs. many
> cycles of throwing back and forth. As we have found multiple times,
> what is viewed as new requirements are often already supported by the
> protocol. More often than not, the requirements are based on a bad
> implementation.
>
>  
>
>  
>
> *From:*routing-discussion [mailto:[email-masked]]
> *On Behalf Of *Andrew G. Malis
> *Sent:* Thursday, August 21, 2014 10:31 AM
> *To:* Joel M. Halpern
> *Cc:* Adrian Farrel; [email-masked]
> *Subject:* Re: Routing Area Tuning - Update
>
>  
>
> the architecture and requirements if they also don't get to play
> around with the protocols (the fun stuff), while the people doing the
> protocol work also want their input into the architecture and
> requirements, since the choices made there constrain what the protocol
> will look like. Of course, you could have the same people tramping
> between two different WGs, but that seems silly.
>
>  
>
> Cheers,
>
> Andy
>
>  
>
>  
>
> there being

> {PALS, BESS,
> them out on

---

From: "George Swallow (swallow)" <[email-masked]>
Date: Thu, 21 Aug 2014 17:06:15 +0000

In addition to Joel's concern, which I share, I'm also very concerned that
we are replacing 3 WG with 5.  All 5 would need to be mutually exclusive
on the IETF meeting Agenda.  Of course there are quite a few other Wgs
that some of these would want to avoid colliding with.

George

On 8/20/14 6:15 PM, "Joel M. Halpern" <[email-masked]> wrote:

>>the

---

From: Lou Berger <[email-masked]>
Date: Thu, 21 Aug 2014 16:14:45 -0400

I think there are some tradeoffs here with some not so clear answers. 
Perhaps we should try the original proposal and see how it works out as
current voices seem to support this, and I wouldn't call it "wrong",
perhaps just "risky". 

I actually think that the current TEAS + all TE architecture would be
preferable, as splitting/fragmented architecture seems much more risky
to me than splitting/fragmented protocol work.  Given that this grouping
was rejected already in Toronto, my next choice would be to consolidate
all TE architecture/FW/Models/Encoding definition and break out protocol
mechanisms into their respective WGs. 

With this option we're likely end up with the same number of WG sessions
as TEAS is likely to need two sessions to cover the high level and
protocol extensions. (based on both the MPLS and CCAMP experience)

The mutual exclusive list is 3 (MPLS, TEAS, CCAMP) rather than 4 (MPLS,
TEAS, CCAMP, PCE) as PCE no longer has architecture.  Conflicts between
the protocol groups will be less critical as they are now just dealing
with their own protocol details, although I suspect chairs are going to
prefer to not conflict with TEAS as they'll want to track what's
happening there.

This split also has real benefits for folks just interested in specific
protocol mechanism extensions.  They no longer need to track/sit through
the noise of TEAS, they just go/subscribe to the specific protocol WG.

Perhaps I'm just wrong, but to me the approach of separating out the
protocol work seems much "cleaner" and less likely to result in
technology / inter-WG issues than breaking apart the architecture work. 
(Of course, I'd really prefer having arch+tech in TEASE, but I recognize
that this is even less likely/popular.)

Lou

On 8/21/2014 1:06 PM, George Swallow (swallow) wrote:
> In addition to Joel's concern, which I share, I'm also very concerned
> that we are replacing 3 WG with 5. All 5 would need to be mutually
> exclusive on the IETF meeting Agenda. Of course there are quite a few
> other Wgs that some of these would want to avoid colliding with.
> George On 8/20/14 6:15 PM, "Joel M. Halpern" <[email-masked]> wrote:
>> source of friction and hinderance. Yours, Joel On 8/20/14, 6:07 PM,
>> Adrian Farrel wrote:
>>> Hi, I wanted to take a moment to update you all on our progress and
>>> to poll you for some more opinions. Firstly there is a sense that
>>> this may all be a fait accompli with there being no point in raising
>>> any questions or concerns. I'm sorry if this is how it came over.
>>> The ADs have been thinking about this and discussing it for quite a
>>> while and we spent quite a bit of time before and during IETF 90
>>> seeking out different viewpoints and having our opinions shaped. So
>>> we have built up strong views, but we do want to hear your views and
>>> we particularly want to be told what we have got wrong. One question
>>> we are still thinking about concerns the arrangement of TE-related
>>> work across the MPLS, CCAMP, and PCE working groups. An option we
>>> had discussed resulted in PCE unchanged, TEAS to take TE
>>> architecture and RSVP-TE, and CCAMP to do technology-specific
>>> protocol work. But there is another option which would leave: TEAS -
>>> TE architecture and requirement work, but no protocol work PCE - All
>>> PCEP work, PCE applicability and requirements, but PCE architecture
>>> goes to TEAS RSVP-TE - All generic protocol work for RSVP-TE from
>>> MPLS and CCAMP CCAMP - technology-specific protocol work. This
>>> thinking is somewhat motivated by the way the IGP work happens at
>>> in TEAS is that it provides for better energy and interaction. We
>>> would like to hear your opinions and get a better sense of the
>>> consensus around TEAS. At the moment Alia and I are recovering from
>>> Toronto and handling vacations, but we have formed a rough order for
>>> working on the working groups. First up is the RTGWG because that is
>>> a relatively straightforward tweak to an existing charter. Then we
>>> plan to group together {L2VPN, L3VPN, PWE3, NVO3} becoming {PALS,
>>> BESS, NVO3} Then we will look to work out how to handle the TE
>>> elements discussed above. We'll be taking a bit of a two-pronged
>>> approach: identify chair candidates; spin up draft charters. We plan
>>> to work on the draft charters with the future chairs and put them
>>> out on this list and on the relevant WG mailing lists as soon as we
>>> have them with the aim of getting review and discussion. One last
>>> point. All WGs should continue to operate according to their current
>>> charters. We can handle the transition if/when it happens, but this
>>> work should not get in the way of real technical work. Please let us
>>> know what you think. Adrian, per pro Alia
>>> _______________________________________________ routing-discussion
>>> mailing list [email-masked]
>> _______________________________________________ routing-discussion
>> mailing list [email-masked]
> _______________________________________________ routing-discussion
> mailing list [email-masked]

---

From: Linda Dunbar <[email-masked]>
Date: Sun, 24 Aug 2014 04:53:44 +0000

+1.

Does any WG enforce proposed solutions to meet the WG’s endorsed “requirement” draft? Very often, the new solution drafts can be proposed years after the WG’s requirement draft being published. Do people still remember what are specified on the requirement RFC?

Linda

From: routing-discussion [mailto:[email-masked]] On Behalf Of Andrew G. Malis
Sent: Thursday, August 21, 2014 9:31 AM
To: Joel M. Halpern
Cc: Adrian Farrel; [email-masked]
Subject: Re: Routing Area Tuning - Update

Cheers,
Andy

Yours,
Joel

Adrian,
per pro Alia

---

From: Lou Berger <[email-masked]>
Date: Sun, 24 Aug 2014 23:19:08 -0400 (EDT)

Oscar alluded to some of the tensions in keeping PCE and ccamp in sync todate. TEAS and PCE will have more direct overlap (than PCE and ccamp).

What's the plan for ensuring the two efforts stay in sync?  What happens when there are conflicting architecture models and in which group does the alignment/resolution take place?

I had suggested that the solution was for TEAS be the authoritative WG for TE. Do folks think this is a good/bad idea?

Lou

On August 21, 2014, 10:30 AM, Andrew G. Malis wrote:
> On Wed, Aug 20, 2014 at 6:15 PM, Joel M. Halpern <> [email-masked]> > wrote:

---

From: Abdussalam Baryun <[email-masked]>
Date: Mon, 25 Aug 2014 07:00:46 +0200

On Monday, August 25, 2014, Lou Berger wrote:

>
> Oscar alluded to some of the tensions in keeping PCE and ccamp in sync
> todate. TEAS and PCE will have more direct overlap (than PCE and ccamp).
>
> What's the plan for ensuring the two efforts stay in sync?  What happens
> when there are conflicting architecture models and in which group does the
> alignment/resolution take place?

I think All IETF needs to sync related efforts/works, which is done through
its LC and IESG reviews.

>
> I had suggested that the solution was for TEAS be the authoritative WG for
> TE. Do folks think this is a good/bad idea?

 I don't know how the suggested authoritative WG will work with other WGs,
not sure of the procedure. I think that authoritative job is the AD
responsibility.

AB

---

From: Leeyoung <[email-masked]>
Date: Mon, 25 Aug 2014 15:18:16 +0000

Hi Lou,

With the current organization WG structure, in order to give TEAS WG the authority for TE work, it requires other TE-related WGs' consent. This may work out in theory. But it comes to practice, we need more than WG level consent. As Adbussalam alluded, this is beyond WG’s responsibility. And I believe this would potentially cause some conflict across WGs unless cross-WG relationship and its agreed upon charters that spell out this dependency/authority clearly have to work out.

Young

From: routing-discussion [mailto:[email-masked]] On Behalf Of Abdussalam Baryun
Sent: Monday, August 25, 2014 12:01 AM
To: Lou Berger
Cc: Adrian Farrel; Joel M. Halpern; [email-masked]
Subject: Re: Keeping TE architecture in sync? (Was: Re: Routing Area Tuning - Update)

I think All IETF needs to sync related efforts/works, which is done through its LC and IESG reviews.

 I don't know how the suggested authoritative WG will work with other WGs, not sure of the procedure. I think that authoritative job is the AD responsibility.

AB

---

From: Lou Berger <[email-masked]>
Date: Mon, 25 Aug 2014 11:37:47 -0400

Abdussalam,

On 08/25/2014 01:00 AM, Abdussalam Baryun wrote:
>     Oscar alluded to some of the tensions in keeping PCE and ccamp in
>     sync todate. TEAS and PCE will have more direct overlap (than PCE
>     and ccamp).
> 
>     What's the plan for ensuring the two efforts stay in sync?  What
>     happens when there are conflicting architecture models and in which
>     group does the alignment/resolution take place?
> 
> 

And WG scoping.

>  
> 
> 
>     I had suggested that the solution was for TEAS be the authoritative
>     WG for TE. Do folks think this is a good/bad idea?
> 
> 
>  I don't know how the suggested authoritative WG will work with other
> WGs, not sure of the procedure. I think that authoritative job is the AD
> responsibility. 
> 

Ultimately, yes and this is part of why they ultimately get to make the
call -- but there's day-to-day operation/coordination that needs to be
ironed out.  If it's scoped to 1 WG, the chairs (and the 1 WG) get to
work out the details.  If multiple WGs, it's the ADs (with support of
the appropriate WG chairs and WG participants) that need to
define/understand the details -- and this what I was asking about.

(I have previously suggest that scoping TE architecture to 1 WG as a
solution, but that doesn't seem to be getting much support...)

Lou

---

From: Abdussalam Baryun <[email-masked]>
Date: Mon, 25 Aug 2014 18:37:24 +0200

Hi Lou,

On Monday, August 25, 2014, Lou Berger wrote:

>
>
>   If multiple WGs, it's the ADs (with support of

 I support the proposed WG that works on architectures without protocols as
I understood from Adrian's message proposal. It can work independently in
the beginning, but in future we can see how community will shape it. I
don't agree with authorities among WGs. IMHO all WGs are already working
together and our WG chairs are already having high interaction.

The one WG for routing area architectures will have many advantages for
other WGs (they may use different architecture RFCs), but if we add
authorities/policy to that WG then many disadvantage may appear for the
area (better we leave area-authority to ADs rather than a WG).

If any WG passes a proposal to IESG/LC then all
area's participants/WGs should be responsible to improve the proposal,
specially when the proposal is an architecture draft (that architecture WG
will have some work dependencies and some challenges).

AB