From: Snigdho Bardalai <SBardalai@infinera.com>
To: Lou Berger <lberger@labn.net>, Igor Bryskin <IBryskin@advaoptical.com>
Thread-Topic: [CCAMP] Additional overlay protocol extensions? (Was: Re:
 Overlay model framework v2)
Thread-Index: AQHN+ZHQb8QMYQmPakSWYQav74usa5hXQ+cg
Date: Wed, 23 Jan 2013 19:03:17 +0000
Message-ID: <6386D6323049044BA592CB99AB04BACB3F9498AB@SV-EXDB-PROD1.infinera.com>
References: <4A1562797D64E44993C5CBF38CF1BE4806C450@ESESSMB301.ericsson.se>
 <50F985EC.1050704@labn.net>
 <4A1562797D64E44993C5CBF38CF1BE4806E708@ESESSMB301.ericsson.se>
 <50FDBD5B.6030307@labn.net>
 <CDAC6F6F5401B245A2C68D0CF8AFDF0A1915DC80@atl-srv-mail10.atl.advaoptical.com>
 <50FEB554.6010907@labn.net>
 <0182DEA5604B3A44A2EE61F3EE3ED69E0B70806B@BL2PRD0510MB349.namprd05.prod.outlook.com>
 <50FEC37F.8090605@labn.net>
 <CDAC6F6F5401B245A2C68D0CF8AFDF0A1915ED91@atl-srv-mail10.atl.advaoptical.com>
 <13c634f0092.2764.9b4188e636579690ba6c69f2c8a0f1fd@labn.net>
 <CDAC6F6F5401B245A2C68D0CF8AFDF0A1915EE10@atl-srv-mail10.atl.advaoptical.com>
 <51000024.8010700@labn.net>
 <CDAC6F6F5401B245A2C68D0CF8AFDF0A1915F047@atl-srv-mail10.atl.advaoptical.com>
 <13c6884e536.2764.9b4188e636579690ba6c69f2c8a0f1fd@labn.net>
In-Reply-To: <13c6884e536.2764.9b4188e636579690ba6c69f2c8a0f1fd@labn.net>
Accept-Language: en-US
Content-Language: en-US
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Cc: CCAMP <ccamp@ietf.org>
Subject: Re: [CCAMP] Additional overlay protocol extensions? (Was: Re:	Overlay
 model framework v2)
Precedence: list

There is one use-case I don't see being mentioned - signaling LSPs that are=
 diverse in the provider network and do not have common CE nodes as head-en=
d or tail-end.

I believe this will require some extensions, not sure what yet!!

Regards
Snigdho

> -----Original Message-----
> From: ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] On Behalf
> Of Lou Berger
> Sent: Wednesday, January 23, 2013 9:48 AM
> To: Igor Bryskin
> Cc: CCAMP
> Subject: Re: [CCAMP] Additional overlay protocol extensions? (Was: Re:
> Overlay model framework v2)
>=20
> Igor,
>=20
> See below for responses in line.
>=20
> On January 23, 2013 11:42:40 AM Igor Bryskin <IBryskin@advaoptical.com>
> wrote:
> > Lou,
> >
> > Required protocol extensions (just to start with):
> > 1. MELGs +VL's committed/uncommitted status advertising
>=20
> Understood, although you and I may not agree on some of the details,
> but that discussion can wait.
>=20
> > 2. Signaling extensions to set correctly client device RSVP timers
> and
> > to communicate the state and status of underlying server trail (e.g.
> > taking into account delays due to the server trail setup).
>=20
> Isn't this possible with any H-LSP), I.e. not unique to ONTs (or
> whatever you call it)?
>=20
> > Issue of RROs: a client device signals the LSP path in terms of
> > VLs/VNs, what about RROs?;
>=20
> How is this a new problem? The issue is present/covered in 4208.
>=20
> > 3. ONT  OAM extensions and procedures (how to associate DP
> > alarms/failures happened on real links and nodes with VLs and VNs
> that
> > depend on them, so that client LSP restoration could be controlled by
> > the client?);
>=20
> This too seems like a generic problem, I.e., one present in H-LSPs,
> L1VPNs, and MLN.
>=20
> > 4. VN related extensions (do we need to advertise TE RTR TLV on
> behalf
> > of a VN, what are the procedures if several real nodes constitute VN,
> > what is the signaling address to use if a VN is selected, etc.);
>=20
> My understanding of existing RFCs (and discussion) is that virtual
> nodes/links are advertised just like real nodes/links.  This sounds
> like an informational, or at most a BCP, document.
>=20
> > 5. VN connectivity matrix for addressing VN's blocking/asymmetric
> > nature, including the detailed connectivity matrix (entries with
> > associated costs, which will also require signaling extensions: e.g.
> > how to specify in the ERO that a given connectivity matrix entry is
> > selected?);
>=20
> What as a VN connectivity matrix? Does it differ from the connectivity
> matrix already defined by this group?
>=20
> If yes, it sounds like an extension to the existing work.
>=20
> If no, sounds like another informational/BCP.
>=20
> > 6. Routing extensions to separate VN's internals from the outside
> > world;
>=20
> Sounds like information exchanged between overlay edge nodes (PEs).
> Basically the  information that would be needed to support L1VPN
> enhanced mode.
>=20
> > 7. Access/inter-domain links LMP extensions;
>=20
> Isn't this the same as is needed when using rfc5251 or 4208?
>=20
> > 8. Split-VN specific extensions ( when a blocking real node is
> > presented via several symmetrical VNs, the VN IDs could be assigned
> > and changed  automatically (to remove extra configuration burden),
> how
> > the client NEs learn that the remote node ID of an access link is
> > (re-)assigned?)
>=20
> This is a specific example of item 6 above, right?
>=20
> > 9. Routing extensions to address independent address spaces;
>=20
> Part of this is already covered by L1VPN basic mode, and the rest is
> also required by L1VPN enhanced mode.
>=20
> > 10. VPN related extensions: how to advertise VL's association with
> one
> > or several VPNs? How to provide VPN-specific VN's connectivity
> matrix;
>=20
> I think you already covered this above.
>=20
> > 11. Etc.
> >
> > All of the above mentioned things obviously cannot be done without a
> > well-understood framework with, yes, tightly defined definitions.
> > Hence the definitions is a very important start.
> >
>=20
> Wow that's a long list!
>=20
> It seems  to me that a number/most of the items above, can be done as
> focused and incremental extensions to  existing RFCs/WG products, in a
> generic way, without any further discussion/agreement on the high level
> overlay topic. Just like the other (soon to be) new WG documents.
>=20
> Certainly the informational/BCP documents would require good
> understanding of the target use cases.  Given the clear, and seemingly
> circular, disagreements on basic terminology it might make most sense
> to spend some time documenting the different use cases/models before
> continuing the definitions discussion.
>=20
> Lou (as contributor)
>=20
> > Cheers,
> > Igor
> >
> > -----Original Message-----
> > From: Lou Berger [mailto:lberger@labn.net]
> > Sent: Wednesday, January 23, 2013 10:22 AM
> > To: Igor Bryskin
> > Cc: John E Drake; CCAMP; Stewart Bryant; adrian@olddog.co.uk; 'George
> > Swallow (swallow)'
> > Subject: Additional overlay protocol extensions? (Was: Re: [CCAMP]
> > Overlay model framework v2)
> >
> >
> >
> > On 1/22/2013 1:58 PM, Igor Bryskin wrote:
> > >...
> > > Besides, I believe nothing (terminology, architecture,  protocol
> > >solutions, etc.)  of MLN/MRN is relevant to what we are/were trying
> > >to achieve with ONTs.
> > >
> > > Igor
> > > ...
> >
> > Igor,
> >
> > Can we take a step back for a moment from the (seemingly endless)
> > terminology/architecture/framework debate?
> >
> > What additional (i.e., not already covered in a standalone draft,
> > e.g.,
> > draft-ali-...) *protocol extensions* do you think need to be
> > standardized (as PS)?
> >
> > Is it more than just MELG?
> >
> > Lou
>=20
>=20
> _______________________________________________
> CCAMP mailing list
> CCAMP@ietf.org
> https://www.ietf.org/mailman/listinfo/ccamp