Subject: [CCAMP] Next steps on overlay

From: "BRUNGARD, DEBORAH A" <[email-masked]>
Date: Thu, 24 Jan 2013 20:03:44 +0000

CCAMP,

There's been quite a bit of discussion on the list, we'd like to see progress on this topic. Perhaps we've reached the point where it's time to update/author drafts to reflect current positions. This can either be done in one document or in multiple (authors' choice).

We also note that multiple viewpoints on how overlays may be deployed/operated have been discussed. We suggest that documenting these use cases, including data plane and control plane relationships/boundaries, would be helpful.

Thanks,
Deborah and Lou
CCAMP Chairs

---

From: Fatai Zhang <[email-masked]>
Date: Mon, 28 Jan 2013 03:54:33 +0000

Hi Deborah,

Thanks for your mail, which reminds me to resume my draft [draft-zhang-ccamp-gmpls-uni-app], :)

Best Regards

Fatai

From: [email-masked] [mailto:[email-masked]] On Behalf Of BRUNGARD, DEBORAH A
Sent: Friday, January 25, 2013 4:04 AM
To: [email-masked]
Subject: [CCAMP] Next steps on overlay

CCAMP,

Thanks,
Deborah and Lou
CCAMP Chairs

---

From: Daniele Ceccarelli <[email-masked]>
Date: Mon, 28 Jan 2013 16:29:39 +0000

Deborah, all,

agree that it's time to sum up.

As agreed in Atlanta draft-many-ccamp-gmpls-overlay-model<http://tools.ietf.org/id/draft-many-ccamp-gmpls-overlay-model-01.txt> will be updated in the next days so to reflect the discussions of the last months on the list and will try to reflect all the topics where there is no consensus and, if available, list all the proposed alternatives.

Basically:

- The overall doc will reflect my latest summary (v2) including the following comments basically from Lou and Igor.
- The terminology part will be based at the time being on VPNs (but open to be modified if needed)
- Use cases: will try to cover the ones in the E-NNI and L1VPN drafts. If more of them are needed please contact me.
- Description of the different advertisement models and service models. Basically we are defining a general topology service model so that existing VPN service models are particular cases of it.
- Relationship with MLN/MRN: the overlay interfaces does not necessarily need to be placed on a link between different technology domains (e.g. IP and WSON) but could be placed also withing the same NE between two layer of the same technology (e.g. an OTN deployment where the ODU3 layer is managed as a provided network providing connectivity between ODU2s which form the client network).

In addition, wrt latest discussion on Additional Overlay Protocol Extensions i think that's meat for the second document on the advertisement, where for each of them we need to say which info is needed AND NOT HOW IT ENCODED OR TRANSPORTED. This final part will be addressed in the third document dedicated to protocol extensions (this was the agreement in Atlanta and i think there is no reason to move from that).

It is definitely too early to move to doc #3 but we could start working on #2. Most of its content, wrt the Virtual Links advertisement model (former E-NNI) has already been widely explained by Igor and Lou, which seem to disagree on HOW to carry the info but not on WHICH of them are needed.

BR
Daniele

________________________________
From: [email-masked] [mailto:[email-masked]] On Behalf Of BRUNGARD, DEBORAH A
Sent: giovedì 24 gennaio 2013 21.04
To: [email-masked]
Subject: [CCAMP] Next steps on overlay

CCAMP,

Thanks,
Deborah and Lou
CCAMP Chairs

---

From: Lou Berger <[email-masked]>
Date: Mon, 28 Jan 2013 11:50:00 -0500

Daniele,
	
Much thanks for the summary. I look forward to the revised document.

WRT
> Most of its content, wrt the Virtual Links advertisement model
> (former E-NNI) has already been widely explained by Igor and Lou,

I think you give me too much credit.  Looking at the archive, the
majority of the comments/discussion were from/with others.  I hope that
their comments are incorporated as well.

Lou
(pick whichever hat you want!)

On 1/28/2013 11:29 AM, Daniele Ceccarelli wrote:
> As agreed in Atlanta draft-many-ccamp-gmpls-overlay-model
> <http://tools.ietf.org/id/draft-many-ccamp-gmpls-overlay-model-01.txt> will
> be updated in the next days so to reflect the discussions of the last
> months on the list and will try to reflect all the topics where there is
> no consensus and, if available, list all the proposed alternatives.
>  
> Basically:
>  
> - The overall doc will reflect my latest summary (v2) including the
> following comments basically from Lou and Igor.
> - Use cases: will try to cover the ones in the E-NNI and L1VPN drafts.
> If more of them are needed please contact me.
> - Description of the different advertisement models and service models.
> Basically we are defining a general topology service model so that
> existing VPN service models are particular cases of it.
> - Relationship with MLN/MRN: the overlay interfaces does not necessarily
> need to be placed on a link between different technology domains (e.g.
> IP and WSON) but could be placed also withing the same NE between two
> layer of the same technology (e.g. an OTN deployment where the ODU3
> layer is managed as a provided network providing connectivity between
> ODU2s which form the client network).
>  
> In addition, wrt latest discussion on Additional Overlay Protocol
> Extensions i think that's meat for the second document on the
> advertisement, where for each of them we need to say which info is
> needed AND NOT HOW IT ENCODED OR TRANSPORTED. This final part will be
> addressed in the third document dedicated to protocol extensions (this
> was the agreement in Atlanta and i think there is no reason to move from
> that).
>  
> It is definitely too early to move to doc #3 but we could start working
> on #2. Most of its content, wrt the Virtual Links advertisement model
> (former E-NNI) has already been widely explained by Igor and Lou, which
> seem to disagree on HOW to carry the info but not on WHICH of them are
> needed.
>  
> BR
> Daniele
>  
>  
> ------------------------------------------------------------------------
> *From:* [email-masked] [mailto:[email-masked]] *On
> Behalf Of *BRUNGARD, DEBORAH A
> *Sent:* giovedì 24 gennaio 2013 21.04
> *To:* [email-masked]
> *Subject:* [CCAMP] Next steps on overlay
> 
>     CCAMP,
>      
>     There’s been quite a bit of discussion on the list, we’d like to see
>     progress on this topic. Perhaps we’ve reached the point where it’s
>     time to update/author drafts to reflect current positions. This can
>     either be done in one document or in multiple (authors’ choice).
>      
>     We also note that multiple viewpoints on how overlays may be
>     deployed/operated have been discussed. We suggest that documenting
>     these use cases, including data plane and control plane
>     relationships/boundaries, would be helpful.
>      
>     Thanks,
>     Deborah and Lou
>     CCAMP Chairs
>      
>      
> 
> 
> 
> _______________________________________________
> CCAMP mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ccamp
>