Subject: Routing Area Tuning - What I heard

From: "Adrian Farrel" <[email-masked]>
Date: Tue, 26 Aug 2014 21:32:25 +0100

Hi,

[Please respond on [email-masked] even though I am spamming several
lists]

Thanks for the input on this topic.

I heard a number of opinions about whether to split TE architecture away from
RSVP-TE. I think this leads to some roughish consensus as follows:

TEAS
- core RSVP-TE
- RSVP-TE for generic cases
- IGP-TE extensions in coordination with IGP WGs
- TE architecture
   - including the applicability of PCE for TE in association with PCE WG
- relationships with
   - OSPF and ISIS as above
   - PCE as above
   - MPLS for generalisation of packet-specific protocol extensions
   - CCAMP for generalisation of non-packet-specific protocol extensions

CCAMP
- non-packet technology-specific RSVP-TE
- non-packet technology-specific IGP-TE in association with IGP WGs
- consideration to generalise all protocol extensions via TEAS

That leaves...

MPLS as it is today, except:
- All RSVP-TE work that is not technology-specific for packet goes to TEAS
- Any TE architecture work goes to TEAS

PCE as it is today, except:
- Architectural application of PCE for TE goes to TEAS with coord back to PCE

Can you please let me know whether I misheard you badly. Is this a split you can
live with? Are there show-stopper issues?

Thanks,
Adrian

---

From: Lou Berger <[email-masked]>
Date: Tue, 26 Aug 2014 17:11:10 -0400

On 8/26/2014 4:32 PM, Adrian Farrel wrote:
>  Is this a split you can live with? 
Yes.

> Are there show-stopper issues?
>
We've heard from some new voices - so i think it was good/important that
you (ADs) restarted this discussion on list.

-- Much thanks,
Lou

---

From: Loa Andersson <[email-masked]>
Date: Wed, 27 Aug 2014 11:20:55 +0200

Adrian,

Yes I think I can live with this, when we talk about "TE" and
"TE architecture" this relates to RSVP-TE and extensions because of
RSVP-TE to the IGPs, right?

/Loa

On 2014-08-26 22:32, Adrian Farrel wrote:
> _______________________________________________
> mpls mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/mpls
>

-- 

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

---

From: Ross Callon <[email-masked]>
Date: Wed, 27 Aug 2014 20:53:59 +0000

>  Is this a split you can live with? 

Yes for me also.

Thanks, Ross

-----Original Message-----
From: routing-discussion [mailto:[email-masked]] On Behalf Of Lou Berger
Sent: Tuesday, August 26, 2014 5:11 PM
To: [email-masked]
Cc: Adrian Farrel; [email-masked]
Subject: Re: [CCAMP] Routing Area Tuning - What I heard

Yes.

-- Much thanks,
Lou

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

---

From: Abdussalam Baryun <[email-masked]>
Date: Thu, 28 Aug 2014 18:54:18 +0200

> you (ADs) restarted this discussion on list.
I can live too with that. However, I think we can live with splits, but
could we participate with similar efforts, is the key question.  IMHO, we
will need meeting consideration (as no conflicts in their timings so
participants can attend these related WGs), or will need to know how many
participants will attend these WGs, for example if A attends WG X before
split will A attend X1 and X2 after split.

In the proposal when it mentions "work", I usually understand it as work
as standard track or experimental, but for informational drafts, I consider
not all of them are working targets, but some are related to analysis of
work or explanations of rationale (as explanation target). I suggest that
if possible each WGs can do some informational drafts of that kind related
to architecture (rationale, analysis) to show the WG
considerations/recommendation (it will help in describing reasons of
related WG designs).

AB

---

From: "Adrian Farrel" <[email-masked]>
Date: Thu, 28 Aug 2014 18:43:17 +0100

> However, I think we can live with splits, but could we 
> participate with similar efforts, is the key question.  
> IMHO, we will need meeting consideration (as no 
> conflicts in their timings so participants can attend
> these related WGs), or will need to know how many
> participants will attend these WGs, for example if A 
> attends WG X before split will A attend X1 and X2 after
> split.

Yes, we already have to manage meeting conflicts. We do it pretty well with the occasional fumble.
Yes, the conflicts will change after these changes. I think we understand what conflicts will exist and need to be avoided.
Yes, the first time around will be some guesswork about attendance. Not the hardest problem in my life at the moment.

> In the proposal when it mentions "work", I usually 
> understand it as work as standard track or experimental,
> but for informational drafts, I consider not all of them are
> working targets, but some are related to analysis of work
> or explanations of rationale (as explanation target). 

No, "work" is not a reserved word in the IETF. It has its usual meaning.
I like "exertion or effort directed to produce or accomplish something" and (in the context of the IETF) I am amused by "productive activity".

In this context "work" means "stuff the working group is doing". And that expands a bit roughly to "stuff that is happening with a view to publishing RFCs."

> I suggest that if possible each WGs can do some informational drafts
> of that kind related to architecture (rationale, analysis) to show the 
> WG considerations/recommendation (it will help in describing reasons
> of related WG designs). 

Yes?
Well, I think you'll find that most WGs have done such things in the past.
Many have explicit charter items to do these things and are busy developing them.
Some WGs come up with additional documents (applicability statements, implementation reports, etc.) in an ad hoc way and drive them through if there is consensus to work on them and publish them.

Business as usual, I think, but everyone can review and comment on new charter proposals. These are starting to pop out now (see the email from Benson about NVO3).

Adrian