Subject: explonation of life's secret code

From: <[email-masked]>
Date: Sun, 30 Nov 2008 21:24:15 -0800 (PST)

About this mailing:
You are receiving this e-mail because you subscribed to
MSN Featured Offers. Microsoft respects your privacy. If you do not wish to receive this
MSN Featured Offers e-mail, please click the "Unsubscribe" link below. This will not unsubscribe
you from e-mail communications from third-party advertisers that may appear in MSN Feature Offers.
This shall not constitute an offer by MSN. MSN shall not be responsible or liable for the
advertisers' content nor any of the goods or service advertised. Prices and item availability
subject to change without notice.

2008 Microsoft |
Unsubscribe | More Newsletters |
Privacy

Microsoft Corporation, One Microsoft Way, Redmond, WA 98052

Envelope-to: [email-masked]
Delivery-date: Fri, 28 Nov 2008 18:56:52 +0000
Message-ID:
Reply-To: "Adrian Farrel"
From: "Adrian Farrel"
To:
Subject: CCAMP I-Ds pending last call
Date: Fri, 28 Nov 2008 18:54:47 -0000
MIME-Version: 1.0
Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original
Content-Transfer-Encoding: 7bit

Hi,

As discussed in Minneapolis, we have quite a long list of I-Ds pending last
call (see below).

We want to give reasonable time for review of each draft so we need to
stagger them. On the other hand, we don't want last calls to go on for ever,
so we will do them in batches. Nevertheless, this will probably takes until
well into March.

So, if you are the author of one of these drafts, please be patient.

draft-ietf-ccamp-path-key-ero-02.txt
draft-ietf-ccamp-gmpls-mln-extensions-03.txt
draft-ietf-ccamp-gmpls-ason-routing-ospf-06.txt
draft-ietf-ccamp-ethernet-traffic-parameters-06.txt
draft-ietf-ccamp-gmpls-dcsc-channel-ext-00.txt
draft-ietf-ccamp-gmpls-ether-svcs-02.txt
draft-ietf-ccamp-gmpls-mef-uni-01.txt
draft-ietf-ccamp-lsp-hierarchy-bis-05.txt
draft-ietf-ccamp-confirm-data-channel-status-02.txt
draft-ietf-ccamp-pc-spc-rsvpte-ext-02.txt

Cheers,
Adrian and Deborah

Envelope-to: [email-masked]
Delivery-date: Thu, 27 Nov 2008 23:14:22 +0000
Message-ID:
Reply-To: "Adrian Farrel"
From: "Adrian Farrel"
To: "Young Lee" , "Greg Bernstein" , "Wataru Imajuku"
Cc: , "Brungard, Deborah A, ALABS"
Subject: Renaming draft-ietf-ccamp-wavelength-switched-framework-01.txt
Date: Thu, 27 Nov 2008 23:10:02 -0000
MIME-Version: 1.0
Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original
Content-Transfer-Encoding: 7bit

Hi editors,

As discussed in CCAMP in Minneapolis, this I-D really needs to be renamed to
show that it is limited to RWA (just like draft-ietf-ccamp-rwa-info-01.txt

Could you please resubmit it as draft-ietf-ccamp-rwa-wson-framework-00.txt

Deborah and I will make sure it is flagged as replacing the current I-D.

Thanks,
Adrian

Envelope-to: [email-masked]
Delivery-date: Thu, 27 Nov 2008 11:43:34 +0000
From: Nic Neate
To: Aria - Adrian Farrel Personal , "[email-masked]"
Date: Thu, 27 Nov 2008 11:41:22 +0000
Subject: FW: Clearing up your misunderstanding of the Association ID
Thread-Topic: Clearing up your misunderstanding of the Association ID
Thread-Index: AclJzdNZSY7CnagwTjiuqh0mbygxywAqn7pQAYMWaWA=
Message-ID: <[email-masked]>
Accept-Language: en-US
Content-Language: en-US
acceptlanguage: en-US
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0

Hi all,

Following up on this Association ID discussion, I think we're now in sync o=
n the technical issues. It is possible to signal both end-to-end and segme=
nt protection using association type 1 as defined. However, the usage of t=
he Association ID is different in the two cases, resulting in
- complex processing rules for ASSOCIATION objects at merge nodes
- an overlap in Association ID and LSP ID spaces
- a corresponding restriction on the mplsTunnelInstance values available t=
o branch nodes.

Our proposal (draft-rhodes-ccamp-rsvp-recovery-fix) was to avoid these issu=
es by using a different association type for segment recovery. That would =
be a non-back-compatible change, and if adopted then existing segment recov=
ery implementations would have to be modified. However, I think it also cl=
arifies the protocol and could improve interoperability longer term.

Does anyone have a strong preference for one option or the other? Or any a=
lternatives to propose?

Thanks,

Nic

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf =
Of Nic Neate
Sent: 19 November 2008 22:01
To: Aria - Adrian Farrel Personal
Cc: [email-masked]
Subject: RE: Clearing up your misunderstanding of the Association ID

Hi Adrian,

As we discussed earlier, there's also an Association ID / LSP ID space over=
lap issue here that's worth drawing out.

The branch node is generating ASSOCIATION objects for both end-to-end prote=
ction and segment protection, and always uses the same Association Type and=
Source. The Association IDs that it chooses must therefore not clash. In=
the end-to-end case, the Association ID is actually an LSP ID. Your first=
rule for the merge node is to check the Association ID against other segme=
nt Association IDs. Therefore, LSP IDs allocated to end-to-end protected L=
SPs must not clash with (existing or future) segment Association IDs.

LSP IDs are actually allocated by the management tool / MIB interface (mpls=
TunnelInstance). I think this therefore amounts to a restriction on the MI=
B interface / management tool.

Nic

-----Original Message-----
From: Aria - Adrian Farrel Personal
Sent: 18 November 2008 22:34
To: Nic Neate
Cc: [email-masked]
Subject: Re: Clearing up your misunderstanding of the Association ID

So...

Nic and I sat down today and discussed this particluar issue: how to interp=
ret the Association ID in a received Path message in order to associate a n=
ew LSP with some other LSP at a merge point.

There are two cases that arise. If the new LSP is part of a segment protect=
ion relationship, the Association ID is a unique "set identifier" in the co=
ntext of the Association Source. If the LSP is part of an end-to-end protec=
tion relationship, the Association ID identifies the LSP ID of the protecti=
on partner.

Nic's concern (and he convinced me for a while :-) is that there is an issu=
e with distinguishing this case when a segment protection LSP is, itself, p=
rotected along its whole path in an end-to-end manner.

Having thought about this more, I believe the following processing rules th=
at can be applied to make this work. I would be interested in any use cases=
(in particular message arrival variants) that anyone believes breaks these=
rules.

For each Association Object on the received Path message...

1. Look for an existing LSP with association object that matches {Associati=
on Source, Association ID} from the new Path message. If found, this is seg=
ment protection protecting from the Association Source to this node. Stop.

2. Look for existing LSP with matching {dest, tunnel ID, extended tunnel ID=
} and with LSP ID equal to received Association ID. The Association Source =
can (and probably should) also be checked against the sender source address=
on the matched LSP. If found, this is end-to-end protection from Associati=
on Source to dest.

Note that there may be multiple Association objects on a Path message. Note=
also, that 4872 requires the use of the same Session specifically to enabl=
e the use of the Association ID to LSP ID mapping.

As far as I can see, this addresses all cases.

Cheers,
Adrian

----- Original Message -----
From: "Nic Neate"
To: "Aria - Adrian Farrel Personal"
Cc: ; "labn - Lou Berger" ; "ALU - Di=
mitri Papadimitriou"
Sent: Tuesday, November 18, 2008 3:07 PM
Subject: RE: Clearing up your misunderstanding of the Association ID

Thanks Adrian,

I think the key source of confusion is that RFC 4873 makes no reference to =
changing the specific procedures defined in 4872 for setting the associatio=
n ID to the LSP ID of the protecting/protected LSP.

For example, in section 5.1:

5.1. Identifiers

...

To allow distinguishing the working LSP (from which the signal is
taken) from the protecting LSP, the working LSP is signaled by
setting in the PROTECTION object the S bit to 0, the P bit to 0, and
in the ASSOCIATION object, the Association ID to the protecting
LSP_ID. The protecting LSP is signaled by setting in the PROTECTION
object the S bit to 0, the P bit to 1, and in the ASSOCIATION object,
the Association ID to the associated protected LSP_ID.

Your email and discussion with Lou has helped expain the intention of 4873.
However, I still have some concerns about interworking of end-to-end and se=
gment recovery - see my email to Lou.

Nic

-----Original Message-----
From: Aria - Adrian Farrel Personal
Sent: 18 November 2008 14:00
To: Nic Neate
Cc: [email-masked]
Subject: Clearing up your misunderstanding of the Association ID

Hi Nic,

I think there are a bunch of issues that you are raising, and we should try=
to itemise them to make sure we close them all off.

For the issue of the use of Association ID in segment protection, I think y=
ou may have misread the relevant RFCs. I don't believe any new Association =
ID type is needed to achieve the function: we can simply use the 4872 assoc=
iation type.

Section 4.3 of 4872 says...
The ASSOCIATION object, introduced in Section 16, is used to
associate the working and protecting LSPs.

When used for signaling the working LSP, the Association ID of the
ASSOCIATION object (see Section 16) identifies the protecting LSP.
When used for signaling the protecting LSP, this field identifies the
LSP protected by the protecting LSP.

That gives us the basis of everything we need.

Then, in Section 16...
The ASSOCIATION object is used to associate LSPs with each
other. In the context of end-to-end LSP recovery, the association
MUST only identify LSPs that support the same Tunnel ID as well
as the same tunnel sender address and tunnel endpoint address.
The Association Type, Association Source, and Association ID
fields of the object together uniquely identify an association.

I suspect that this is the source of your misunderstanding. But note that i=
n 4873, the context is not end-to-end LSP recovery so the restriction on t=
he Tunnel ID does not apply.

If you follow this through now, I suspect you will discover that most of yo=
ur issues go away.

Cheers,
Adrian

Envelope-to: [email-masked]
Delivery-date: Mon, 24 Nov 2008 14:19:35 +0000
Message-ID: <03A5339A999247849861E8DB3D331DB3@your029b8cecfe>
Reply-To: "Adrian Farrel"
From: "Adrian Farrel"
To:
Subject: Fw: [OSPF] WG Last Call on draft-ietf-ospf-te-node-addr-05.txt
Date: Mon, 24 Nov 2008 14:17:12 -0000
MIME-Version: 1.0
Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=response
Content-Transfer-Encoding: 7bit

Hi CCAMP,

This last call in the OSPF working group may be of interest to you.

Adrian
----- Original Message -----
From: "Acee Lindem"
To: "OSPF List"
Sent: Sunday, November 23, 2008 8:09 PM
Subject: [OSPF] WG Last Call on draft-ietf-ospf-te-node-addr-05.txt

> This starts the WG last for "Advertising a Router's Local Addresses
> in OSPF TE Extensions" - draft-ietf-ospf-te-node-addr-05.txt. It will
> conclude on Monday, December 8th, 2008 at 12:00 AM.
>
> This document was previously WG last called about 2 years back. We
> delayed advancing it in our to align with the ASON requirements. With
> the addition of the IPv4 and IPv6 prefix length, we now feel it will
> be usable for ASCON as well.
>
> Thanks,
> Acee & Abhay
> _______________________________________________
> OSPF mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ospf
>

Envelope-to: [email-masked]
Delivery-date: Fri, 21 Nov 2008 15:50:51 +0000
Message-ID:
Reply-To: "Adrian Farrel"
From: "Adrian Farrel"
To:
Cc: "Loa Andersson"
Subject: working group last call on MPLS and GMPLS security framework
Date: Fri, 21 Nov 2008 15:48:57 -0000
MIME-Version: 1.0
Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=response
Content-Transfer-Encoding: 7bit

The MPLS working group is holding a last call on this draft.

It is very important that you review it and comment. Please send comments to
the MPLS list if you are subscribed. Otherwise then them to CCAMP and I will
forward them.

Thanks,
Adrian
----- Original Message -----
From: "Loa Andersson"
To:
Cc: "Ross Callon" ; "David Ward"
Sent: Friday, November 21, 2008 2:58 PM
Subject: [mpls] working group last call on MPLS and GMPLS security framework

> Working Group,
>
> this is to start a two week working group last call on:
>
> Security Framework for MPLS and GMPLS Networks
> draft-ietf-mpls-mpls-and-gmpls-security-framework-04.txt
>
> please send your comments to the working group mailing list or
> directly to the wg co-chairs.
>
> This working group last will end EOB Fri Dec 5 2008.
>
> Loa and Geoge
>
> --
>
>
> Loa Andersson
>
> Sr Strategy and Standards Manager
> Redback Networks phone: +46 8 632 77 14
> An Ericsson company
> email:
> [email-masked]
> [email-masked]
>
> _______________________________________________
> mpls mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/mpls
>

Envelope-to: [email-masked]
Delivery-date: Fri, 21 Nov 2008 00:39:06 +0000
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="US-ASCII"
Content-Transfer-Encoding: quoted-printable
Subject: Working Group Last Call: draft-ietf-ccamp-path-key-ero-02.txt
Date: Thu, 20 Nov 2008 19:36:00 -0500
Message-ID:
Thread-Topic: Working Group Last Call: draft-ietf-ccamp-path-key-ero-02.txt
Thread-Index: AclLcSBkC9PN1RWSRrquCv8jL/wuaA==
From: "BRUNGARD, DEBORAH A, ATTLABS"
To:

This is to initiate a Working Group Last Call on:
http://www.ietf.org/internet-drafts/draft-ietf-ccamp-path-key-ero-02.txt

Please send your comments to the mailing list prior to EOB Dec 5.

Thanks,
Deborah and Adrian

Envelope-to: [email-masked]
Delivery-date: Wed, 19 Nov 2008 22:03:02 +0000
From: Nic Neate
To: Aria - Adrian Farrel Personal
CC: "[email-masked]"
Date: Wed, 19 Nov 2008 22:00:49 +0000
Subject: RE: Clearing up your misunderstanding of the Association ID
Thread-Topic: Clearing up your misunderstanding of the Association ID
Thread-Index: AclJzdNZSY7CnagwTjiuqh0mbygxywAqn7pQ
Message-ID: <[email-masked]>
Accept-Language: en-US
Content-Language: en-US
acceptlanguage: en-US
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0

Hi Adrian,

As we discussed earlier, there's also an Association ID / LSP ID space over=
lap issue here that's worth drawing out.

The branch node is generating ASSOCIATION objects for both end-to-end prote=
ction and segment protection, and always uses the same Association Type and=
Source. The Association IDs that it chooses must therefore not clash. In=
the end-to-end case, the Association ID is actually an LSP ID. Your first=
rule for the merge node is to check the Association ID against other segme=
nt Association IDs. Therefore, LSP IDs allocated to end-to-end protected L=
SPs must not clash with (existing or future) segment Association IDs.

LSP IDs are actually allocated by the management tool / MIB interface (mpls=
TunnelInstance). I think this therefore amounts to a restriction on the MI=
B interface / management tool.

Nic

-----Original Message-----
From: Aria - Adrian Farrel Personal
Sent: 18 November 2008 22:34
To: Nic Neate
Cc: [email-masked]
Subject: Re: Clearing up your misunderstanding of the Association ID

So...

Nic and I sat down today and discussed this particluar issue: how to interp=
ret the Association ID in a received Path message in order to associate a n=
ew LSP with some other LSP at a merge point.

There are two cases that arise. If the new LSP is part of a segment protect=
ion relationship, the Association ID is a unique "set identifier" in the co=
ntext of the Association Source. If the LSP is part of an end-to-end protec=
tion relationship, the Association ID identifies the LSP ID of the protecti=
on partner.

Nic's concern (and he convinced me for a while :-) is that there is an issu=
e with distinguishing this case when a segment protection LSP is, itself, p=
rotected along its whole path in an end-to-end manner.

Having thought about this more, I believe the following processing rules th=
at can be applied to make this work. I would be interested in any use cases=
(in particular message arrival variants) that anyone believes breaks these=
rules.

For each Association Object on the received Path message...

1. Look for an existing LSP with association object that matches {Associati=
on Source, Association ID} from the new Path message. If found, this is seg=
ment protection protecting from the Association Source to this node. Stop.

2. Look for existing LSP with matching {dest, tunnel ID, extended tunnel ID=
} and with LSP ID equal to received Association ID. The Association Source =
can (and probably should) also be checked against the sender source address=
on the matched LSP. If found, this is end-to-end protection from Associati=
on Source to dest.

Note that there may be multiple Association objects on a Path message. Note=
also, that 4872 requires the use of the same Session specifically to enabl=
e the use of the Association ID to LSP ID mapping.

As far as I can see, this addresses all cases.

Cheers,
Adrian

----- Original Message -----
From: "Nic Neate"
To: "Aria - Adrian Farrel Personal"
Cc: ; "labn - Lou Berger" ; "ALU - Di=
mitri Papadimitriou"
Sent: Tuesday, November 18, 2008 3:07 PM
Subject: RE: Clearing up your misunderstanding of the Association ID

Thanks Adrian,

I think the key source of confusion is that RFC 4873 makes no reference to =
changing the specific procedures defined in 4872 for setting the associatio=
n ID to the LSP ID of the protecting/protected LSP.

For example, in section 5.1:

5.1. Identifiers

...

To allow distinguishing the working LSP (from which the signal is
taken) from the protecting LSP, the working LSP is signaled by
setting in the PROTECTION object the S bit to 0, the P bit to 0, and
in the ASSOCIATION object, the Association ID to the protecting
LSP_ID. The protecting LSP is signaled by setting in the PROTECTION
object the S bit to 0, the P bit to 1, and in the ASSOCIATION object,
the Association ID to the associated protected LSP_ID.

Your email and discussion with Lou has helped expain the intention of 4873.
However, I still have some concerns about interworking of end-to-end and se=
gment recovery - see my email to Lou.

Nic

-----Original Message-----
From: Aria - Adrian Farrel Personal
Sent: 18 November 2008 14:00
To: Nic Neate
Cc: [email-masked]
Subject: Clearing up your misunderstanding of the Association ID

Hi Nic,

I think there are a bunch of issues that you are raising, and we should try=
to itemise them to make sure we close them all off.

For the issue of the use of Association ID in segment protection, I think y=
ou may have misread the relevant RFCs. I don't believe any new Association =
ID type is needed to achieve the function: we can simply use the 4872 assoc=
iation type.

Section 4.3 of 4872 says...
The ASSOCIATION object, introduced in Section 16, is used to
associate the working and protecting LSPs.

When used for signaling the working LSP, the Association ID of the
ASSOCIATION object (see Section 16) identifies the protecting LSP.
When used for signaling the protecting LSP, this field identifies the
LSP protected by the protecting LSP.

That gives us the basis of everything we need.

Then, in Section 16...
The ASSOCIATION object is used to associate LSPs with each
other. In the context of end-to-end LSP recovery, the association
MUST only identify LSPs that support the same Tunnel ID as well
as the same tunnel sender address and tunnel endpoint address.
The Association Type, Association Source, and Association ID
fields of the object together uniquely identify an association.

I suspect that this is the source of your misunderstanding. But note that i=
n 4873, the context is not end-to-end LSP recovery so the restriction on t=
he Tunnel ID does not apply.

If you follow this through now, I suspect you will discover that most of yo=
ur issues go away.

Cheers,
Adrian

Envelope-to: [email-masked]
Delivery-date: Tue, 18 Nov 2008 22:35:42 +0000
Message-ID:
Reply-To: "Adrian Farrel"
From: "Adrian Farrel"
To: "Nic Neate"
Cc:
Subject: Re: Clearing up your misunderstanding of the Association ID
Date: Tue, 18 Nov 2008 22:34:14 -0000
MIME-Version: 1.0
Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original
Content-Transfer-Encoding: 7bit

So...

Nic and I sat down today and discussed this particluar issue: how to
interpret the Association ID in a received Path message in order to
associate a new LSP with some other LSP at a merge point.

There are two cases that arise. If the new LSP is part of a segment
protection relationship, the Association ID is a unique "set identifier" in
the context of the Association Source. If the LSP is part of an end-to-end
protection relationship, the Association ID identifies the LSP ID of the
protection partner.

Nic's concern (and he convinced me for a while :-) is that there is an issue
with distinguishing this case when a segment protection LSP is, itself,
protected along its whole path in an end-to-end manner.

Having thought about this more, I believe the following processing rules
that can be applied to make this work. I would be interested in any use
cases (in particular message arrival variants) that anyone believes breaks
these rules.

For each Association Object on the received Path message...

1. Look for an existing LSP with association object that matches
{Association Source, Association ID} from the new Path message. If found,
this is segment protection protecting from the Association Source to this
node. Stop.

2. Look for existing LSP with matching {dest, tunnel ID, extended tunnel ID}
and with LSP ID equal to received Association ID. The Association Source can
(and probably should) also be checked against the sender source address on
the matched LSP. If found, this is end-to-end protection from Association
Source to dest.

Note that there may be multiple Association objects on a Path message. Note
also, that 4872 requires the use of the same Session specifically to enable
the use of the Association ID to LSP ID mapping.

As far as I can see, this addresses all cases.

Cheers,
Adrian

----- Original Message -----
From: "Nic Neate"
To: "Aria - Adrian Farrel Personal"
Cc: ; "labn - Lou Berger" ; "ALU -
Dimitri Papadimitriou"
Sent: Tuesday, November 18, 2008 3:07 PM
Subject: RE: Clearing up your misunderstanding of the Association ID

Thanks Adrian,

I think the key source of confusion is that RFC 4873 makes no reference to
changing the specific procedures defined in 4872 for setting the association
ID to the LSP ID of the protecting/protected LSP.

For example, in section 5.1:

5.1. Identifiers

...

To allow distinguishing the working LSP (from which the signal is
taken) from the protecting LSP, the working LSP is signaled by
setting in the PROTECTION object the S bit to 0, the P bit to 0, and
in the ASSOCIATION object, the Association ID to the protecting
LSP_ID. The protecting LSP is signaled by setting in the PROTECTION
object the S bit to 0, the P bit to 1, and in the ASSOCIATION object,
the Association ID to the associated protected LSP_ID.

Your email and discussion with Lou has helped expain the intention of 4873.
However, I still have some concerns about interworking of end-to-end and
segment recovery - see my email to Lou.

Nic

-----Original Message-----
From: Aria - Adrian Farrel Personal
Sent: 18 November 2008 14:00
To: Nic Neate
Cc: [email-masked]
Subject: Clearing up your misunderstanding of the Association ID

Hi Nic,

I think there are a bunch of issues that you are raising, and we should try
to itemise them to make sure we close them all off.

For the issue of the use of Association ID in segment protection, I think
you may have misread the relevant RFCs. I don't believe any new Association
ID type is needed to achieve the function: we can simply use the 4872
association type.

Section 4.3 of 4872 says...
The ASSOCIATION object, introduced in Section 16, is used to
associate the working and protecting LSPs.

When used for signaling the working LSP, the Association ID of the
ASSOCIATION object (see Section 16) identifies the protecting LSP.
When used for signaling the protecting LSP, this field identifies the
LSP protected by the protecting LSP.

That gives us the basis of everything we need.

Then, in Section 16...
The ASSOCIATION object is used to associate LSPs with each
other. In the context of end-to-end LSP recovery, the association
MUST only identify LSPs that support the same Tunnel ID as well
as the same tunnel sender address and tunnel endpoint address.
The Association Type, Association Source, and Association ID
fields of the object together uniquely identify an association.

I suspect that this is the source of your misunderstanding. But note that in
4873, the context is not end-to-end LSP recovery so the restriction on the
Tunnel ID does not apply.

If you follow this through now, I suspect you will discover that most of
your issues go away.

Cheers,
Adrian

Envelope-to: [email-masked]
Delivery-date: Tue, 18 Nov 2008 18:37:55 +0000
Message-ID: <[email-masked]>
Date: Tue, 18 Nov 2008 12:36:47 -0600
From: Greg Bernstein
User-Agent: Thunderbird 2.0.0.17 (Windows/20080914)
MIME-Version: 1.0
To: ccamp
Subject: VCAT/LCAS draft update...
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

Hi folks, I edited the VCAT/LCAS draft to use the CALL_ATTRIBUTES object
from the MLN extensions draft.
We define a new VCAT TLV for use in the aforementioned object. All
procedures and encodings otherwise are the same as the previous draft.
Note that the draft will now be contingent on the MLN extensions draft
moving forward.

A URL for the Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-ccamp-gmpls-vcat-lcas-06.txt

Regards

Greg

--
===================================================
Dr Greg Bernstein, Grotto Networking (510) 573-2237

Envelope-to: [email-masked]
Delivery-date: Tue, 18 Nov 2008 17:16:28 +0000
From: [email-masked]
To: [email-masked]
Cc: [email-masked]
Subject: I-D ACTION:draft-ietf-ccamp-gmpls-vcat-lcas-06.txt
Content-Type: Multipart/Mixed; Boundary="NextPart"
Mime-Version: 1.0
Message-Id: <[email-masked]>
Date: Tue, 18 Nov 2008 09:15:01 -0800 (PST)

--NextPart

A New Internet-Draft is available from the on-line Internet-Drafts
directories.
This draft is a work item of the Common Control and Measurement Plane Working Group of the IETF.

Title : Operating Virtual Concatenation (VCAT) and the Link Capacity Adjustment Scheme (LCAS) with Generalized Multi-Protocol Label Switching (GMPLS)
Author(s) : G. Bernstein
Filename : draft-ietf-ccamp-gmpls-vcat-lcas-06.txt
Pages : 22
Date : 2008-11-18

This document describes requirements for, and use of, the Generalized
Multi-Protocol Label Switching (GMPLS) control plane in conjunction
with the Virtual Concatenation (VCAT) layer 1 inverse multiplexing
mechanism and its companion Link Capacity Adjustment Scheme (LCAS)
which can be used for hitless dynamic resizing of the inverse
multiplex group. These techniques apply to Optical Transport Network
(OTN), Synchronous Optical Network (SONET), Synchronous Digital
Hierarchy (SDH), and Plesiochronous Digital Hierarchy (PDH) signals.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-ccamp-gmpls-vcat-lcas-06.txt

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

--NextPart
Content-Type: Message/External-body;
name="draft-ietf-ccamp-gmpls-vcat-lcas-06.txt";
site="ftp.ietf.org";
access-type="anon-ftp";
directory="internet-drafts"

Content-Type: text/plain
Content-ID: <[email-masked]>

--NextPart--

Envelope-to: [email-masked]
Delivery-date: Tue, 18 Nov 2008 16:23:13 +0000
Message-ID: <[email-masked]>
Date: Tue, 18 Nov 2008 10:22:25 -0600
From: Greg Bernstein
User-Agent: Thunderbird 2.0.0.17 (Windows/20080914)
MIME-Version: 1.0
CC: ccamp
Subject: Re: Materials for Semi-Formal WSON meeting today...
Content-Type: multipart/alternative; boundary="------------050608080100010602030803"

This is a multi-part message in MIME format.
--------------050608080100010602030803
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

Whoops, sorry about that, I meant "semi-*informal*". This is not an IETF
meeting, but an somewhat organized meeting of co-authors and interested
parties.

Thanks

Greg

Adrian Farrel wrote:
> Hi Greg,
>
> Thanks for taking care of this.
>
> Just for the record...
>
> The meeting isn't really "semi-formal." That is, it is not an IETF
> meeting, but a meeting of co-authors and interested parties.
>
> Cheers,
> Adrian
> ----- Original Message ----- From: "Greg Bernstein"
>
> To: "Wson (E-mail)" ; "ccamp"
>
> Sent: Tuesday, November 18, 2008 3:54 PM
> Subject: Materials for Semi-Formal WSON meeting today...
>
>
>> Hi folks interested in WSON in Minneapolis, we've got the Ramsey Room in
>> the Hilton, Tuesday (today) from 3:20PM-5:20PM for our extra WSON
>> discussion session.
>> When I last checked this room was set up in "meeting room"
>> configuration, that is, everyone around a big table. This is good for
>> discussion but there wasn't a projector. Some of the slides we were
>> going to use are:
>>
>> Existing optical draft discussion:
>> http://www.grotto-networking.com/sites/default/files/WSON-Extra-Meeting-Minneapolis-Nov-2008_0.ppt
>>
>>
>> Optical Impairment:
>> http://www.grotto-networking.com/sites/default/files/WSON-impairments-CCAMP-MinneapolisV2.ppt
>>
>> http://www.grotto-networking.com/sites/default/files/WSON-impairments-info%20CCAMP-IETF-73-V2.ppt
>>
>>
>> Please download these so you can follow along. Others with slides,
>> please let folks know where to get them so folks can follow along on
>> their laptops.
>>
>> Also, I highly recommend that folks go to the ITU-T web page for the G
>> series of recommendations http://www.itu.int/rec/T-REC-G/e and pickup
>> the PDFs for *G.671* (characteristics of optical components and
>> subsystems), *G.680* (transfer functions of optical networks elements),
>> and *G.697* (optical monitoring). No excuses! these are free and you
>> should have these if you are interested in optical impairments.
>>
>> Regards
>>
>> Greg
>>
>> --
>> ===================================================
>> Dr Greg Bernstein, Grotto Networking (510) 573-2237
>>
>>
>>
>
>

--
===================================================
Dr Greg Bernstein, Grotto Networking (510) 573-2237

--------------050608080100010602030803
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit

Whoops, sorry about that, I meant "semi-informal". This is not
an IETF meeting, but an somewhat organized meeting of co-authors and
interested parties.

Thanks

Greg

Adrian Farrel wrote:

Hi Greg,

Thanks for taking care of this.

Just for the record...

The meeting isn't really "semi-formal." That is, it is not an IETF
meeting, but a meeting of co-authors and interested parties.

Cheers,

Adrian

----- Original Message ----- From: "Greg Bernstein"
<[email-masked]>

To: "Wson (E-mail)" <[email-masked]>; "ccamp"
<[email-masked]>

Sent: Tuesday, November 18, 2008 3:54 PM

Subject: Materials for Semi-Formal WSON meeting today...

Hi folks interested in WSON in Minneapolis,
we've got the Ramsey Room in

the Hilton, Tuesday (today) from 3:20PM-5:20PM for our extra WSON

discussion session.

When I last checked this room was set up in "meeting room"

configuration, that is, everyone around a big table. This is good for

discussion but there wasn't a projector. Some of the slides we were

going to use are:

Existing optical draft discussion:

http://www.grotto-networking.com/sites/default/files/WSON-Extra-Meeting-Minneapolis-Nov-2008_0.ppt

Optical Impairment:

http://www.grotto-networking.com/sites/default/files/WSON-impairments-CCAMP-MinneapolisV2.ppt

http://www.grotto-networking.com/sites/default/files/WSON-impairments-info%20CCAMP-IETF-73-V2.ppt

Please download these so you can follow along. Others with slides,

please let folks know where to get them so folks can follow along on

their laptops.

Also, I  highly recommend that folks go to the ITU-T web page for the G

series of recommendations http://www.itu.int/rec/T-REC-G/e and pickup

the PDFs for *G.671* (characteristics of optical components and

subsystems), *G.680* (transfer functions of optical networks elements),

and *G.697* (optical monitoring). No excuses! these are free and you

should have these if you are interested in optical impairments.

Regards

Greg

--

===================================================

Dr Greg Bernstein, Grotto Networking (510) 573-2237

--
===================================================
Dr Greg Bernstein, Grotto Networking (510) 573-2237

--------------050608080100010602030803--

Envelope-to: [email-masked]
Delivery-date: Tue, 18 Nov 2008 16:09:24 +0000
Message-ID: <141ADD61D0FD4515B7D0C382666267D7@your029b8cecfe>
Reply-To: "Adrian Farrel"
From: "Adrian Farrel"
To: "Greg Bernstein" , "Wson \(E-mail\)" , "ccamp"
Subject: Re: Materials for Semi-Formal WSON meeting today...
Date: Tue, 18 Nov 2008 16:08:16 -0000
MIME-Version: 1.0
Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original
Content-Transfer-Encoding: 7bit

Hi Greg,

Thanks for taking care of this.

Just for the record...

The meeting isn't really "semi-formal." That is, it is not an IETF meeting,
but a meeting of co-authors and interested parties.

Cheers,
Adrian
----- Original Message -----
From: "Greg Bernstein"
To: "Wson (E-mail)" ; "ccamp"

Sent: Tuesday, November 18, 2008 3:54 PM
Subject: Materials for Semi-Formal WSON meeting today...

> Hi folks interested in WSON in Minneapolis, we've got the Ramsey Room in
> the Hilton, Tuesday (today) from 3:20PM-5:20PM for our extra WSON
> discussion session.
> When I last checked this room was set up in "meeting room"
> configuration, that is, everyone around a big table. This is good for
> discussion but there wasn't a projector. Some of the slides we were
> going to use are:
>
> Existing optical draft discussion:
> http://www.grotto-networking.com/sites/default/files/WSON-Extra-Meeting-Minneapolis-Nov-2008_0.ppt
>
> Optical Impairment:
> http://www.grotto-networking.com/sites/default/files/WSON-impairments-CCAMP-MinneapolisV2.ppt
> http://www.grotto-networking.com/sites/default/files/WSON-impairments-info%20CCAMP-IETF-73-V2.ppt
>
> Please download these so you can follow along. Others with slides,
> please let folks know where to get them so folks can follow along on
> their laptops.
>
> Also, I highly recommend that folks go to the ITU-T web page for the G
> series of recommendations http://www.itu.int/rec/T-REC-G/e and pickup
> the PDFs for *G.671* (characteristics of optical components and
> subsystems), *G.680* (transfer functions of optical networks elements),
> and *G.697* (optical monitoring). No excuses! these are free and you
> should have these if you are interested in optical impairments.
>
> Regards
>
> Greg
>
> --
> ===================================================
> Dr Greg Bernstein, Grotto Networking (510) 573-2237
>
>
>

Envelope-to: [email-masked]
Delivery-date: Tue, 18 Nov 2008 16:07:41 +0000
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=default; d=labn.net; h=Received:X-Mailer:Date:To:From:Subject:Cc:In-Reply-To:References:Mime-Version:Content-Type:X-Identified-User; b=eyudLN17gDzm7hAuW9EItqjXdS7+IyoZbUY1DRR7kw+N+oNWWoMlYM/+VLWO0OtxExURZlUNVEJ4a6sRjjJAiNwWq479v2v6TK2Rvwa1ftasPH2JBPVYR27eawmwx6Us;
Date: Tue, 18 Nov 2008 11:05:16 -0600
To: Nic Neate
From: Lou Berger
Subject: RE: Agenda updated
Cc: Lou Berger , "[email-masked]" , Aria - Adrian Farrel Personal , "[email-masked]" , ALU - Dimitri Papadimitriou
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Message-Id:

Nic,

See below.

At 08:06 AM 11/18/2008, Nic Neate wrote:
>Hi Lou,
>
>Following up on our conversation in CCAMP.
>
>I think you agreed that the "Resource Sharing" association type 2 is
>not relevant to this discussion.
>
>You also said that the intent of the statement from 3.2.1
>"processing and identification occur with respect to segment
>recovery LSPs" is to indicate that the procedures defined in RFC
>4872 for setting the association ID to an LSP ID are not
>used. Instead, a unique identifier should be chosen by the
>association source (as suggested in our draft).
>
>I find this quite a stretch, and think a clarification would improve
>the chances of interoperability.

As you know, in there's always opportunity for more detailed
discussion in any document and that there will always be someone who
doesn't understand the more detailed explanation. It's up to the
author's and the WG to agree that a draft is sufficient. At the time
the document was written, we did.

I accept that more language could be helpful to those new to segment
recovery. As I suggested to you, I believe the proper way to address
this (and to ask for and to get formal clarification) is to open an Errata.

>I'm also concerned with the reuse of association type 1 with
>different semantics in segment recovery to those defined for
>end-to-end recovery.

How are the semantics different?

Per RFC4872:
16.1. Format

The IPv4 ASSOCIATION object (Class-Num of the form 11bbbbbb with
value = 199, C-Type = 1) has the format:

0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Length | Class-Num(199)| C-Type (1) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Association Type | Association ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IPv4 Association Source |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Association Type: 16 bits

Indicates the type of association being identified. Note that
this value is considered when determining association. The
following are values defined in this document.

Value Type
----- ----
0 Reserved
1 Recovery (R)

Association ID: 16 bits

A value assigned by the LSP head-end. When combined with the
Association Type and Association Source, this value uniquely
identifies an association.

Association Source: 4 or 16 bytes

An IPv4 or IPv6 address, respectively, that is associated to
the node that originated the association.

And RFC4873 says:
3.2.1. Recovery Type Processing

Recovery type processing procedures are the same as those defined in
[RFC4872], but processing and identification occur with respect to
segment recovery LSPs. Note that this means that multiple
ASSOCIATION objects of type recovery may be present on an LSP.

>Consider the case where a segment recovery LSP is itself end-to-end
>protected. Then there will be two type 1 association objects, and
>the merge node must process each differently.

yes, as is explicity stated in the RFC.

>How does the implementation you mentioned decide which is which?

What protocol question are you asking here?

If you want to see code, most folks don't make that available or
charge a fee (I know of some sources of such code, and can provide
this info offline if you'd like).

>You also dismissed the other issues raised in
>draft-rhodes-rsvp-recovery-signaling relating to protection of
>recovery LSPs and overlaping protection.

Per RFC4873:

Segment protection or restoration is signaled using a working LSP and
one or more segment recovery LSPs. Each segment recovery LSP is
signaled as an independent LSP. Specifically, the Sender_Template
object uses the IP address of the node originating the recovery path,
e.g., node C in the topology shown above, and the Session object
contains the IP address of the node terminating the recovery path,
e.g., node E shown above. There is no specific requirement on LSP ID
value, Tunnel ID, and Extended Tunnel ID. Values for these fields
are selected normally, including consideration for the make-before-
break concept (as described in [RFC3209]). Intermediate nodes follow
standard signaling procedures when processing segment recovery LSPs.
A segment recovery LSP may be protected itself using segment or end-
to-end protection/restoration. Note, in PSC environments, it may be
desirable to construct the Sender_Template and Session objects per
[RFC4090].

When [RFC4090] isn't being used, the association between segment
recovery LSPs with other LSPs is indicated using the ASSOCIATION
object defined in [RFC4872]. The ASSOCIATION object is used to
associate recovery LSPs with the LSP they are protecting.

>Please could you respond on the specific technical points raised in the draft?

I suggest bringing points you'd like to discuss to the
list. Although, I think resolution of the basic understanding of
segment recovery is needed to move the discussion further.

Again, I suggest filing the errata...

Lou

>I'd be glad to meet up and discuss this in person while we're in Minneapolis.
>
>Thanks,
>
>Nic
>
>
>-----Original Message-----
>From: [email-masked] [mailto:[email-masked]] On
>Behalf Of labn - Lou Berger
>Sent: 16 November 2008 22:46
>To: Nic Neate
>Cc: labn - Lou Berger; [email-masked]; Aria - Adrian
>Farrel Personal; [email-masked]; ALU - Dimitri Papadimitriou
>Subject: RE: Agenda updated
>
>I agree with Dimitri.
>
>also, note:
>
> 3.2.1. Recovery Type Processing
>
> Recovery type processing procedures are the same as those defined in
> [RFC4872], but processing and identification occur with respect to
> segment recovery LSPs.
>
>Lou
>
>At 05:36 PM 11/16/2008, PAPADIMITRIOU Dimitri wrote:
> >nick,
> >
> >you mention:
> >
> >"3.1 Association between LSPs in different sessions
> >
> > Segment recovery protecting LSPs may have a different endpoint
> > address from the corresponding protected LSP. The protected and
> > protecting LSPs are therefore in different Sessions. The Association
> > object of type 1 (recovery) is not effective in this case, as the
> > Association ID can only associate to an LSP ID within the same
> > Session."
> >
> >but segment recovery makes use of:
> >
> >"9.1. New Association Type Assignment
> >
> >
> > IANA has made the following assignment to the "Association Types"
> > Registry (see [RFC4872]) in the "ASSOCIATION (object)" section of the
> > "RSVP PARAMETERS" registry located at
> > http://www.iana.org/assignments/rsvp-parameters.
> >
> > Value Type
> > ----- ----
> > 2 Resource Sharing (R) [RFC4873]"
> >
> >and states:
> >
> >"Consider the following topology:
> >
> > A---B---C---D---E---F
> > \ /
> > G---I
> >
> > In this topology, end-to-end protection and recovery is not possible
> > for an LSP going between node A and node F, but it is possible to
> > protect/recover a portion of the LSP. Specifically, if the LSP uses
> > a working path of [A,B,C,D,E,F], then a protection or restoration LSP
> > can be established along the path [C,G,I,E]."
> >
> >[...]
> >
> >"Segment protection or restoration is signaled using a working LSP and
> > one or more segment recovery LSPs. Each segment recovery LSP is
> > signaled as an independent LSP. Specifically, the Sender_Template
> > object uses the IP address of the node originating the recovery path,
> > e.g., node C in the topology shown above, and the Session object
> > contains the IP address of the node terminating the recovery path,
> > e.g., node E shown above. There is no specific requirement on LSP ID
> > value, Tunnel ID, and Extended Tunnel ID."
> >
> >so where is the issue ?
> >
> >-d.
> >
> > > -----Original Message-----
> > > From: Nic Neate [mailto:[email-masked]]
> > > Sent: Friday, November 14, 2008 4:46 PM
> > > To: labn - Lou Berger; [email-masked]; PAPADIMITRIOU
> > > Dimitri; Aria - Adrian Farrel Personal
> > > Cc: [email-masked]
> > > Subject: FW: Agenda updated
> > >
> > > RFC 4873 authors,
> > >
> > > Just wanted to flag that I'm presenting a problem in segment
> > > recovery signaling on Monday, together with a suggested solution.
> > >
> > > Problem statement:
> > > http://tools.ietf.org/html/draft-rhodes-rsvp-recovery-signaling-00.
> > > Suggested fix:
> > > http://tools.ietf.org/html/draft-rhodes-ccamp-rsvp-recovery-fix-00.
> > >
> > >
> > > Nic
> > >
> > > -----Original Message-----
> > > From: [email-masked]
> > > [mailto:[email-masked]] On Behalf Of Aria - Adrian Farrel
> > > Personal
> > > Sent: 07 November 2008 19:29
> > > To: [email-masked]
> > > Subject: Agenda updated
> > >
> > > I have made some updates.
> > >
> > > http://www.ietf.org/proceedings/08nov/agenda/ccamp.htm
> > >
> > > Please shout if there further issues.
> > >
> > > Thanks,
> > > Adrian
> > >
> > >

Envelope-to: [email-masked]
Delivery-date: Tue, 18 Nov 2008 15:55:46 +0000
Message-ID: <[email-masked]>
Date: Tue, 18 Nov 2008 09:54:27 -0600
From: Greg Bernstein
User-Agent: Thunderbird 2.0.0.17 (Windows/20080914)
MIME-Version: 1.0
To: "Wson (E-mail)" , ccamp
Subject: Materials for Semi-Formal WSON meeting today...
Content-Type: multipart/alternative; boundary="------------070600070603090202080004"

This is a multi-part message in MIME format.
--------------070600070603090202080004
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

Hi folks interested in WSON in Minneapolis, we've got the Ramsey Room in
the Hilton, Tuesday (today) from 3:20PM-5:20PM for our extra WSON
discussion session.
When I last checked this room was set up in "meeting room"
configuration, that is, everyone around a big table. This is good for
discussion but there wasn't a projector. Some of the slides we were
going to use are:

Existing optical draft discussion:
http://www.grotto-networking.com/sites/default/files/WSON-Extra-Meeting-Minneapolis-Nov-2008_0.ppt

Optical Impairment:
http://www.grotto-networking.com/sites/default/files/WSON-impairments-CCAMP-MinneapolisV2.ppt
http://www.grotto-networking.com/sites/default/files/WSON-impairments-info%20CCAMP-IETF-73-V2.ppt

Please download these so you can follow along. Others with slides,
please let folks know where to get them so folks can follow along on
their laptops.

Also, I highly recommend that folks go to the ITU-T web page for the G
series of recommendations http://www.itu.int/rec/T-REC-G/e and pickup
the PDFs for *G.671* (characteristics of optical components and
subsystems), *G.680* (transfer functions of optical networks elements),
and *G.697* (optical monitoring). No excuses! these are free and you
should have these if you are interested in optical impairments.

Regards

Greg

--
===================================================
Dr Greg Bernstein, Grotto Networking (510) 573-2237

--------------070600070603090202080004
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit

Hi folks interested in WSON in Minneapolis, we've got the Ramsey Room
in the Hilton, Tuesday (today) from 3:20PM-5:20PM for our extra WSON
discussion session.

When I last checked this room was set up in "meeting room"
configuration, that is, everyone around a big table. This is good for
discussion but there wasn't a projector. Some of the slides we were
going to use are:

Existing optical draft discussion:

http://www.grotto-networking.com/sites/default/files/WSON-Extra-Meeting-Minneapolis-Nov-2008_0.ppt

Optical Impairment:

http://www.grotto-networking.com/sites/default/files/WSON-impairments-CCAMP-MinneapolisV2.ppt

http://www.grotto-networking.com/sites/default/files/WSON-impairments-info%20CCAMP-IETF-73-V2.ppt

Please download these so you can follow along. Others with slides,
please let folks know where to get them so folks can follow along on
their laptops.

Also, I  highly recommend that folks go to the ITU-T web page for the G
series of recommendations http://www.itu.int/rec/T-REC-G/e
and pickup the PDFs for G.671 (characteristics of optical
components and subsystems), G.680 (transfer functions of
optical networks elements), and G.697 (optical monitoring). No
excuses! these are free and you should have these if you are interested
in optical impairments.

Regards

Greg

--
===================================================
Dr Greg Bernstein, Grotto Networking (510) 573-2237

--------------070600070603090202080004--

Envelope-to: [email-masked]
Delivery-date: Tue, 18 Nov 2008 15:08:04 +0000
From: Nic Neate
To: Aria - Adrian Farrel Personal
CC: "[email-masked]" , labn - Lou Berger , ALU - Dimitri Papadimitriou
Date: Tue, 18 Nov 2008 15:07:36 +0000
Subject: RE: Clearing up your misunderstanding of the Association ID
Thread-Topic: Clearing up your misunderstanding of the Association ID
Thread-Index: AclJhfbNLbyZOjCkQsmXDXM+Gp8/+QACLLEg
Message-ID: <[email-masked]>
Accept-Language: en-US
Content-Language: en-US
acceptlanguage: en-US
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0

Thanks Adrian,

I think the key source of confusion is that RFC 4873 makes no reference to =
changing the specific procedures defined in 4872 for setting the associatio=
n ID to the LSP ID of the protecting/protected LSP.

For example, in section 5.1:

5.1. Identifiers

...

To allow distinguishing the working LSP (from which the signal is
taken) from the protecting LSP, the working LSP is signaled by
setting in the PROTECTION object the S bit to 0, the P bit to 0, and
in the ASSOCIATION object, the Association ID to the protecting
LSP_ID. The protecting LSP is signaled by setting in the PROTECTION
object the S bit to 0, the P bit to 1, and in the ASSOCIATION object,
the Association ID to the associated protected LSP_ID.

Your email and discussion with Lou has helped expain the intention of 4873.=
However, I still have some concerns about interworking of end-to-end and =
segment recovery - see my email to Lou.

Nic

-----Original Message-----
From: Aria - Adrian Farrel Personal
Sent: 18 November 2008 14:00
To: Nic Neate
Cc: [email-masked]
Subject: Clearing up your misunderstanding of the Association ID

Hi Nic,

I think there are a bunch of issues that you are raising, and we should try=
to itemise them to make sure we close them all off.

For the issue of the use of Association ID in segment protection, I think y=
ou may have misread the relevant RFCs. I don't believe any new Association =
ID type is needed to achieve the function: we can simply use the 4872 assoc=
iation type.

Section 4.3 of 4872 says...
The ASSOCIATION object, introduced in Section 16, is used to
associate the working and protecting LSPs.

When used for signaling the working LSP, the Association ID of the
ASSOCIATION object (see Section 16) identifies the protecting LSP.
When used for signaling the protecting LSP, this field identifies the
LSP protected by the protecting LSP.

That gives us the basis of everything we need.

Then, in Section 16...
The ASSOCIATION object is used to associate LSPs with each
other. In the context of end-to-end LSP recovery, the association
MUST only identify LSPs that support the same Tunnel ID as well
as the same tunnel sender address and tunnel endpoint address.
The Association Type, Association Source, and Association ID
fields of the object together uniquely identify an association.

I suspect that this is the source of your misunderstanding. But note that i=
n 4873, the context is not end-to-end LSP recovery so the restriction on t=
he Tunnel ID does not apply.

If you follow this through now, I suspect you will discover that most of yo=
ur issues go away.

Cheers,
Adrian

Envelope-to: [email-masked]
Delivery-date: Tue, 18 Nov 2008 15:02:38 +0000
From: The IESG
To: IETF-Announce
Cc: Internet Architecture Board , RFC Editor , ccamp mailing list , ccamp chair
Subject: Document Action: 'GMPLS Asymmetric Bandwidth Bidirectional Label Switched Paths (LSPs)' to Experimental RFC
Message-Id: <[email-masked]>
Date: Tue, 18 Nov 2008 07:01:14 -0800 (PST)

The IESG has approved the following document:

- 'GMPLS Asymmetric Bandwidth Bidirectional Label Switched Paths (LSPs) '
as an Experimental RFC

This document is the product of the Common Control and Measurement Plane
Working Group.

The IESG contact persons are Ross Callon and David Ward.

A URL of this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-ccamp-asymm-bw-bidir-lsps-02.txt

Technical Summary

This experimental document defines a method for the support of
GMPLS Asymmetric Bandwidth Bidirectional Label Switched Paths
(LSPs). The presented approach is applicable to any switching
technology and builds on the original RSVP model for the
transport of traffic related parameters.

Working Group Summary

No controversy reported. These protocol extensions have full
support of the working group, but are being submitted as
experimental because there is no immediate intention to build
or deploy product containing these features. See PROTO writeup
by Adrian Farrel (posted to the tracker by Amy Vezza).

Document Quality

No existing implementations. No announced plans. The document
has had ample review for a experimental straightforward
extension to an existing protocol. An alternate approach that
was considered, along with the reason that it was not selected,
is discussed in an Appendix.

Personnel

Adrian Farrel is the Document Shepherd for this document.
Ross Callon is the Responsible Area Director.

Envelope-to: [email-masked]
Delivery-date: Tue, 18 Nov 2008 14:16:59 +0000
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Subject: RE: Agenda updated
Date: Tue, 18 Nov 2008 15:16:02 +0100
Message-ID: <[email-masked]>
Thread-Topic: Agenda updated
Thread-Index: AclIPeh+pqzmg/rBStmo5d+6gtIapAA3sOeAABq6O2A=
From: "PAPADIMITRIOU Dimitri"
To: "Nic Neate" , "labn - Lou Berger"
Cc: , "Aria - Adrian Farrel Personal" ,

hi nic,

my 2 cents here below:=20

> -----Original Message-----
> From: Nic Neate [mailto:[email-masked]]=20
> Sent: Tuesday, November 18, 2008 3:07 PM
> To: labn - Lou Berger
> Cc: [email-masked]; Aria - Adrian Farrel Personal;=20
> [email-masked]; PAPADIMITRIOU Dimitri
> Subject: RE: Agenda updated
>=20
> Hi Lou,
>=20
> Following up on our conversation in CCAMP.
>=20
> I think you agreed that the "Resource Sharing" association=20
> type 2 is not relevant to this discussion.
>=20
> You also said that the intent of the statement from 3.2.1=20
> "processing and identification occur with respect to segment=20
> recovery LSPs" is to indicate that the procedures defined in=20
> RFC 4872 for setting the association ID to an LSP ID are not=20
> used. Instead, a unique identifier should be chosen by the=20
> association source (as suggested in our draft).
>=20
> I find this quite a stretch, and think a clarification would=20
> improve the chances of interoperability.

where is the stretch ? in end-to-end the source of the tunnel is the
source of the association whereas in the segment case they are not the
same.

> I'm also concerned with the reuse of association type 1 with=20
> different semantics in segment recovery to those defined for=20
> end-to-end recovery. Consider the case where a segment=20
> recovery LSP is itself end-to-end protected. =20

what does this actually mean ? does it refer to the case where there are
two 2 protecting segments ?

> Then there will=20
> be two type 1 association objects, and the merge node must=20
> process each differently. How does the implementation you=20
> mentioned decide which is which?
>
> You also dismissed the other issues raised in=20
> draft-rhodes-rsvp-recovery-signaling relating to protection=20
> of recovery LSPs and overlaping protection. Please could you=20
> respond on the specific technical points raised in the draft?

it is the same as the base case, if a segment recovery LSP is himself
protected partially the source of the association will not be the source
of protected recovery segment.
=20
thanks,
-d.
> I'd be glad to meet up and discuss this in person while we're=20
> in Minneapolis.
>=20
> Thanks,
>=20
> Nic
>=20
>=20
> -----Original Message-----
> From: [email-masked]=20
> [mailto:[email-masked]] On Behalf Of labn - Lou Berger
> Sent: 16 November 2008 22:46
> To: Nic Neate
> Cc: labn - Lou Berger; [email-masked]; Aria -=20
> Adrian Farrel Personal; [email-masked]; ALU - Dimitri=20
> Papadimitriou
> Subject: RE: Agenda updated
>=20
> I agree with Dimitri.
>=20
> also, note:
>=20
> 3.2.1. Recovery Type Processing
>=20
> Recovery type processing procedures are the same as those=20
> defined in
> [RFC4872], but processing and identification occur with respect to
> segment recovery LSPs.
>=20
> Lou
>=20
> At 05:36 PM 11/16/2008, PAPADIMITRIOU Dimitri wrote:
> >nick,
> >
> >you mention:
> >
> >"3.1 Association between LSPs in different sessions
> >
> > Segment recovery protecting LSPs may have a different endpoint
> > address from the corresponding protected LSP. The protected and
> > protecting LSPs are therefore in different Sessions. =20
> The Association
> > object of type 1 (recovery) is not effective in this case, as the
> > Association ID can only associate to an LSP ID within the same
> > Session."
> >
> >but segment recovery makes use of:
> >
> >"9.1. New Association Type Assignment
> >
> >
> > IANA has made the following assignment to the "Association Types"
> > Registry (see [RFC4872]) in the "ASSOCIATION (object)"=20
> section of the
> > "RSVP PARAMETERS" registry located at
> > http://www.iana.org/assignments/rsvp-parameters.
> >
> > Value Type
> > ----- ----
> > 2 Resource Sharing (R) [RFC4873]"
> >
> >and states:
> >
> >"Consider the following topology:
> >
> > A---B---C---D---E---F
> > \ /
> > G---I
> >
> > In this topology, end-to-end protection and recovery is=20
> not possible
> > for an LSP going between node A and node F, but it is possible to
> > protect/recover a portion of the LSP. Specifically, if=20
> the LSP uses
> > a working path of [A,B,C,D,E,F], then a protection or=20
> restoration LSP
> > can be established along the path [C,G,I,E]."
> >
> >[...]
> >
> >"Segment protection or restoration is signaled using a=20
> working LSP and
> > one or more segment recovery LSPs. Each segment recovery LSP is
> > signaled as an independent LSP. Specifically, the=20
> Sender_Template
> > object uses the IP address of the node originating the=20
> recovery path,
> > e.g., node C in the topology shown above, and the Session object
> > contains the IP address of the node terminating the=20
> recovery path,
> > e.g., node E shown above. There is no specific=20
> requirement on LSP ID
> > value, Tunnel ID, and Extended Tunnel ID."
> >
> >so where is the issue ?
> >
> >-d.
> >
> > > -----Original Message-----
> > > From: Nic Neate [mailto:[email-masked]]
> > > Sent: Friday, November 14, 2008 4:46 PM
> > > To: labn - Lou Berger; [email-masked]; PAPADIMITRIOU
> > > Dimitri; Aria - Adrian Farrel Personal
> > > Cc: [email-masked]
> > > Subject: FW: Agenda updated
> > >
> > > RFC 4873 authors,
> > >
> > > Just wanted to flag that I'm presenting a problem in segment
> > > recovery signaling on Monday, together with a suggested solution.
> > >
> > > Problem statement:
> > >=20
> http://tools.ietf.org/html/draft-rhodes-rsvp-recovery-signaling-00.
> > > Suggested fix:
> > >=20
> http://tools.ietf.org/html/draft-rhodes-ccamp-rsvp-recovery-fix-00.
> > >
> > >
> > > Nic
> > >
> > > -----Original Message-----
> > > From: [email-masked]
> > > [mailto:[email-masked]] On Behalf Of Aria -=20
> Adrian Farrel
> > > Personal
> > > Sent: 07 November 2008 19:29
> > > To: [email-masked]
> > > Subject: Agenda updated
> > >
> > > I have made some updates.
> > >
> > > http://www.ietf.org/proceedings/08nov/agenda/ccamp.htm
> > >
> > > Please shout if there further issues.
> > >
> > > Thanks,
> > > Adrian
> > >
> > >
>=20
>=20
>=20

Envelope-to: [email-masked]
Delivery-date: Tue, 18 Nov 2008 14:07:04 +0000
From: Nic Neate
To: labn - Lou Berger
CC: "[email-masked]" , Aria - Adrian Farrel Personal , "[email-masked]" , ALU - Dimitri Papadimitriou
Date: Tue, 18 Nov 2008 14:06:34 +0000
Subject: RE: Agenda updated
Thread-Topic: Agenda updated
Thread-Index: AclIPeh+pqzmg/rBStmo5d+6gtIapAA3sOeA
Message-ID: <[email-masked]>
Accept-Language: en-US
Content-Language: en-US
acceptlanguage: en-US
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0

Hi Lou,

Following up on our conversation in CCAMP.

I think you agreed that the "Resource Sharing" association type 2 is not re=
levant to this discussion.

You also said that the intent of the statement from 3.2.1 "processing and i=
dentification occur with respect to segment recovery LSPs" is to indicate t=
hat the procedures defined in RFC 4872 for setting the association ID to an=
LSP ID are not used. Instead, a unique identifier should be chosen by the=
association source (as suggested in our draft).

I find this quite a stretch, and think a clarification would improve the ch=
ances of interoperability.

I'm also concerned with the reuse of association type 1 with different sema=
ntics in segment recovery to those defined for end-to-end recovery. Consid=
er the case where a segment recovery LSP is itself end-to-end protected. T=
hen there will be two type 1 association objects, and the merge node must p=
rocess each differently. How does the implementation you mentioned decide =
which is which?

You also dismissed the other issues raised in draft-rhodes-rsvp-recovery-si=
gnaling relating to protection of recovery LSPs and overlaping protection. =
Please could you respond on the specific technical points raised in the dr=
aft?

I'd be glad to meet up and discuss this in person while we're in Minneapoli=
s.

Thanks,

Nic

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf =
Of labn - Lou Berger
Sent: 16 November 2008 22:46
To: Nic Neate
Cc: labn - Lou Berger; [email-masked]; Aria - Adrian Farrel Perso=
nal; [email-masked]; ALU - Dimitri Papadimitriou
Subject: RE: Agenda updated

I agree with Dimitri.

also, note:

3.2.1. Recovery Type Processing

Recovery type processing procedures are the same as those defined in
[RFC4872], but processing and identification occur with respect to
segment recovery LSPs.

Lou

At 05:36 PM 11/16/2008, PAPADIMITRIOU Dimitri wrote:
>nick,
>
>you mention:
>
>"3.1 Association between LSPs in different sessions
>
> Segment recovery protecting LSPs may have a different endpoint
> address from the corresponding protected LSP. The protected and
> protecting LSPs are therefore in different Sessions. The Association
> object of type 1 (recovery) is not effective in this case, as the
> Association ID can only associate to an LSP ID within the same
> Session."
>
>but segment recovery makes use of:
>
>"9.1. New Association Type Assignment
>
>
> IANA has made the following assignment to the "Association Types"
> Registry (see [RFC4872]) in the "ASSOCIATION (object)" section of the
> "RSVP PARAMETERS" registry located at
> http://www.iana.org/assignments/rsvp-parameters.
>
> Value Type
> ----- ----
> 2 Resource Sharing (R) [RFC4873]"
>
>and states:
>
>"Consider the following topology:
>
> A---B---C---D---E---F
> \ /
> G---I
>
> In this topology, end-to-end protection and recovery is not possible
> for an LSP going between node A and node F, but it is possible to
> protect/recover a portion of the LSP. Specifically, if the LSP uses
> a working path of [A,B,C,D,E,F], then a protection or restoration LSP
> can be established along the path [C,G,I,E]."
>
>[...]
>
>"Segment protection or restoration is signaled using a working LSP and
> one or more segment recovery LSPs. Each segment recovery LSP is
> signaled as an independent LSP. Specifically, the Sender_Template
> object uses the IP address of the node originating the recovery path,
> e.g., node C in the topology shown above, and the Session object
> contains the IP address of the node terminating the recovery path,
> e.g., node E shown above. There is no specific requirement on LSP ID
> value, Tunnel ID, and Extended Tunnel ID."
>
>so where is the issue ?
>
>-d.
>
> > -----Original Message-----
> > From: Nic Neate [mailto:[email-masked]]
> > Sent: Friday, November 14, 2008 4:46 PM
> > To: labn - Lou Berger; [email-masked]; PAPADIMITRIOU
> > Dimitri; Aria - Adrian Farrel Personal
> > Cc: [email-masked]
> > Subject: FW: Agenda updated
> >
> > RFC 4873 authors,
> >
> > Just wanted to flag that I'm presenting a problem in segment
> > recovery signaling on Monday, together with a suggested solution.
> >
> > Problem statement:
> > http://tools.ietf.org/html/draft-rhodes-rsvp-recovery-signaling-00.
> > Suggested fix:
> > http://tools.ietf.org/html/draft-rhodes-ccamp-rsvp-recovery-fix-00.
> >
> >
> > Nic
> >
> > -----Original Message-----
> > From: [email-masked]
> > [mailto:[email-masked]] On Behalf Of Aria - Adrian Farrel
> > Personal
> > Sent: 07 November 2008 19:29
> > To: [email-masked]
> > Subject: Agenda updated
> >
> > I have made some updates.
> >
> > http://www.ietf.org/proceedings/08nov/agenda/ccamp.htm
> >
> > Please shout if there further issues.
> >
> > Thanks,
> > Adrian
> >
> >

Envelope-to: [email-masked]
Delivery-date: Tue, 18 Nov 2008 14:01:20 +0000
Message-ID: <020938B8234C48209399F0FF21BD4C31@your029b8cecfe>
Reply-To: "Adrian Farrel"
From: "Adrian Farrel"
To: "Nic Neate"
Cc:
Subject: Clearing up your misunderstanding of the Association ID
Date: Tue, 18 Nov 2008 13:59:56 -0000
MIME-Version: 1.0
Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original
Content-Transfer-Encoding: 7bit

Hi Nic,

I think there are a bunch of issues that you are raising, and we should try
to itemise them to make sure we close them all off.

For the issue of the use of Association ID in segment protection, I think
you may have misread the relevant RFCs. I don't believe any new Association
ID type is needed to achieve the function: we can simply use the 4872
association
type.

Section 4.3 of 4872 says...
The ASSOCIATION object, introduced in Section 16, is used to
associate the working and protecting LSPs.

When used for signaling the working LSP, the Association ID of the
ASSOCIATION object (see Section 16) identifies the protecting LSP.
When used for signaling the protecting LSP, this field identifies the
LSP protected by the protecting LSP.

That gives us the basis of everything we need.

Then, in Section 16...
The ASSOCIATION object is used to associate LSPs with each
other. In the context of end-to-end LSP recovery, the association
MUST only identify LSPs that support the same Tunnel ID as well
as the same tunnel sender address and tunnel endpoint address.
The Association Type, Association Source, and Association ID
fields of the object together uniquely identify an association.

I suspect that this is the source of your misunderstanding. But note that in
4873, the context is not end-to-end LSP
recovery so the restriction on the Tunnel ID does not apply.

If you follow this through now, I suspect you will discover that most of
your issues go away.

Cheers,
Adrian

Envelope-to: [email-masked]
Delivery-date: Tue, 18 Nov 2008 13:00:25 +0000
Message-ID:
Reply-To: "Adrian Farrel"
From: "Adrian Farrel"
To:
Subject: Did anyone listen to CCAMP on audio streaming?
Date: Tue, 18 Nov 2008 12:58:13 -0000
MIME-Version: 1.0
Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original
Content-Transfer-Encoding: 7bit

Can you drop me an email so we can find out how it sounded.

Thanks,
Adrian

Envelope-to: [email-masked]
Delivery-date: Mon, 17 Nov 2008 22:24:19 +0000
Message-ID: <79713195F7CF4AF99120D6E9672D586F@your029b8cecfe>
Reply-To: "Adrian Farrel"
From: "Adrian Farrel"
To:
Cc: "Michael H. Behringer" , "Francois Le Faucheur"
Subject: Soliciting feedback ondraft-ietf-tsvwg-rsvp-security-groupkeying
Date: Mon, 17 Nov 2008 22:22:19 -0000
MIME-Version: 1.0
Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original
Content-Transfer-Encoding: 7bit

Hi CCAMP,

The TSVWG is doing work on group keys for RSVP. These might also be
applicable to GMPLS/RSVP-TE so please review the draft (specifically section
5) and send comments to the author (Michael Behringer )
and to the CCAMP list (and preferably the TSVWG list as well).

http://tools.ietf.org/wg/tsvwg/draft-ietf-tsvwg-rsvp-security-groupkeying/

Thanks,
Adrian

Envelope-to: [email-masked]
Delivery-date: Mon, 17 Nov 2008 19:31:14 +0000
From: [email-masked]
To: [email-masked]
Cc: [email-masked]
Subject: I-D Action:draft-ietf-ccamp-asymm-bw-bidir-lsps-02.txt
Content-Type: Multipart/Mixed; Boundary="NextPart"
Mime-Version: 1.0
Message-Id: <[email-masked]>
Date: Mon, 17 Nov 2008 11:30:01 -0800 (PST)

--NextPart

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Common Control and Measurement Plane Working Group of the IETF.

Title : GMPLS Asymmetric Bandwidth Bidirectional Label Switched Paths (LSPs)
Author(s) : L. Berger, et al.
Filename : draft-ietf-ccamp-asymm-bw-bidir-lsps-02.txt
Pages : 15
Date : 2008-11-17

This document defines a method for the support of GMPLS Asymmetric
Bandwidth Bidirectional Label Switched Paths (LSPs). The presented
approach is applicable to any switching technology and builds on the
original RSVP model for the transport of traffic related parameters.
The procedures described in this document are experimental.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-ccamp-asymm-bw-bidir-lsps-02.txt

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

--NextPart
Content-Type: Message/External-body;
name="draft-ietf-ccamp-asymm-bw-bidir-lsps-02.txt";
site="ftp.ietf.org";
access-type="anon-ftp";
directory="internet-drafts"

Content-Type: text/plain
Content-ID: <[email-masked]>

--NextPart--

Envelope-to: [email-masked]
Delivery-date: Mon, 17 Nov 2008 15:46:55 +0000
Message-ID: <[email-masked]>
Date: Mon, 17 Nov 2008 09:45:30 -0600
From: Greg Bernstein
User-Agent: Thunderbird 2.0.0.17 (Windows/20080914)
MIME-Version: 1.0
To: ccamp
Subject: Informal WSON discussion meeting...
Content-Type: multipart/alternative; boundary="------------050503050002070708070803"

This is a multi-part message in MIME format.
--------------050503050002070708070803
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

Hi CCAMPers, wavelength switched optical networks (WSON) are very
interesting from both a technical and organizational standpoint
(multiple SDOs are involved) . To promote better understanding, there
will be a semi-informal WSON meeting on Tuesday from 3:20-5:20PM in the
Ramsey conference room (2nd floor of the Hilton).

Discussion Topics may include:
(a) WSON Framework and RWA Information model document contents and
structure *
(b) Wavelength converter pool model for use in path computation
(c) Signaling extensions -- other uses of wavelength set metric
(d) Optical Impairments and the control plane *

It is assumed that everyone attending will have *read all the related
drafts*. Also this discussion section probably isn't recommended for
"tourists".

Regards

Greg

--
===================================================
Dr Greg Bernstein, Grotto Networking (510) 573-2237

--------------050503050002070708070803
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit

Hi CCAMPers, wavelength switched optical networks (WSON) are very
interesting from both a technical and organizational standpoint
(multiple SDOs are involved) . To promote better understanding, there
will be a semi-informal WSON meeting on Tuesday from 3:20-5:20PM in the
Ramsey conference room (2nd floor of the Hilton).

Discussion Topics may include:

(a) WSON Framework and RWA Information model document contents and
structure *

(b) Wavelength converter pool model for use in path computation

(c) Signaling extensions -- other uses of wavelength set metric

(d) Optical Impairments and the control plane  *

It is assumed that everyone attending will have read all the
related drafts. Also this discussion section probably isn't
recommended for "tourists".

Regards

Greg

--
===================================================
Dr Greg Bernstein, Grotto Networking (510) 573-2237

--------------050503050002070708070803--

Envelope-to: [email-masked]
Delivery-date: Mon, 17 Nov 2008 15:46:46 +0000
Message-ID: <[email-masked]>
Date: Mon, 17 Nov 2008 09:45:07 -0600
From: Greg Bernstein
User-Agent: Thunderbird 2.0.0.17 (Windows/20080914)
MIME-Version: 1.0
To: ccamp
Subject: Informal WSON discussion meeting...
Content-Type: multipart/alternative; boundary="------------000507000806090106010203"

This is a multi-part message in MIME format.
--------------000507000806090106010203
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

Hi CCAMPers, wavelength switched optical networks (WSON) are very
interesting from both a technical and organizational standpoint
(multiple SDOs are involved) . To promote better understanding, there
will be a semi-informal WSON meeting on Tuesday from 3:20-5:20PM in the
Ramsey conference room (2nd floor of the Hilton).

Discussion Topics may include:
(a) WSON Framework and RWA Information model document contents and
structure *
(b) Wavelength converter pool model for use in path computation
(c) Signaling extensions -- other uses of wavelength set metric
(d) Optical Impairments and the control plane *

It is assumed that everyone attending will have *read all the related
drafts*. Also this discussion section probably isn't recommended for
"tourists".

Regards

Greg

--
===================================================
Dr Greg Bernstein, Grotto Networking (510) 573-2237

--------------000507000806090106010203
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit

Hi CCAMPers, wavelength switched optical networks (WSON) are very
interesting from both a technical and organizational standpoint
(multiple SDOs are involved) . To promote better understanding, there
will be a semi-informal WSON meeting on Tuesday from 3:20-5:20PM in the
Ramsey conference room (2nd floor of the Hilton).

Discussion Topics may include:

(a) WSON Framework and RWA Information model document contents and
structure *

(b) Wavelength converter pool model for use in path computation

(c) Signaling extensions -- other uses of wavelength set metric

(d) Optical Impairments and the control plane  *

It is assumed that everyone attending will have read all the
related drafts. Also this discussion section probably isn't
recommended for "tourists".

Regards

Greg

--
===================================================
Dr Greg Bernstein, Grotto Networking (510) 573-2237

--------------000507000806090106010203--

Envelope-to: [email-masked]
Delivery-date: Mon, 17 Nov 2008 13:09:55 +0000
Message-ID:
Reply-To: "Adrian Farrel"
From: "Adrian Farrel"
To:
Subject: Wondering about the new boiler plate?
Date: Mon, 17 Nov 2008 13:06:19 -0000
MIME-Version: 1.0
Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original
Content-Transfer-Encoding: 7bit

Were you wondering how to get the new boiler plate text right in your draft
submissions?

You may find it easiest to crib from an existing draft by stealing the top
and tail.

I think you will find it right in

http://www.ietf.org/internet-drafts/draft-ietf-pce-path-key-04.txt

Cheers,
Adrian

Envelope-to: [email-masked]
Delivery-date: Mon, 17 Nov 2008 03:15:03 +0000
Message-ID:
Reply-To: "Adrian Farrel"
From: "Adrian Farrel"
To: "PAPADIMITRIOU Dimitri" ,
Subject: Re: Slides arriving and being posted
Date: Mon, 17 Nov 2008 03:13:23 -0000
MIME-Version: 1.0
Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original
Content-Transfer-Encoding: 7bit

You are right, I missed this off the list.

It will be there before Monday afternoon.

A
----- Original Message -----
From: "PAPADIMITRIOU Dimitri"
To: "Adrian Farrel" ;
Sent: Sunday, November 16, 2008 10:48 PM
Subject: RE: Slides arriving and being posted

adrian - looking at your slides and except if i missed it

the doc

the new release includes clarification on index field encoding. so
except if there is any remaining issue from known implementations this
doc is also ready for WG LC.

thx,
-d.
> -----Original Message-----
> From: [email-masked]
> [mailto:[email-masked]] On Behalf Of Adrian Farrel
> Sent: Sunday, November 16, 2008 2:43 PM
> To: [email-masked]
> Subject: Slides arriving and being posted
>
> Hi,
>
> Thanks to all that have sent slides already.
>
> Please check that they are correctly posted by visiting
> http://www.ietf.org/proceedings/08nov/agenda/ccamp.htm
>
> We're still missing a few.
>
> Thanks,
> Adrian
>
>
>

Envelope-to: [email-masked]
Delivery-date: Mon, 17 Nov 2008 03:11:21 +0000
Message-ID: <7463A5AFD3FF4622A0296F8EFC5A3855@your029b8cecfe>
Reply-To: "Adrian Farrel"
From: "Adrian Farrel"
To:
Subject: Fw: Last Call: draft-dasgupta-ccamp-path-comp-analysis (Performance Analysis of Inter-Domain Path Computation Methodologies) to Informational RFC
Date: Mon, 17 Nov 2008 03:09:09 -0000
MIME-Version: 1.0
Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original
Content-Transfer-Encoding: 7bit

Heads up!
----- Original Message -----
From: "The IESG"
To: "IETF-Announce"
Sent: Sunday, November 16, 2008 10:54 PM
Subject: Last Call: draft-dasgupta-ccamp-path-comp-analysis (Performance
Analysis of Inter-Domain Path Computation Methodologies) to Informational
RFC

> The IESG has received a request from an individual submitter to consider
> the following document:
>
> - 'Performance Analysis of Inter-Domain Path Computation Methodologies '
> as an Informational RFC
>
> The IESG plans to make a decision in the next few weeks, and solicits
> final comments on this action. Please send substantive comments to the
> [email-masked] mailing lists by 2008-12-14. Exceptionally,
> comments may be sent to [email-masked] instead. In either case, please
> retain the beginning of the Subject line to allow automated sorting.
>
> The file can be obtained via
> http://www.ietf.org/internet-drafts/draft-dasgupta-ccamp-path-comp-analysis-02.txt
>
>
> IESG discussion can be tracked via
> https://datatracker.ietf.org/public/pidtracker.cgi?command=view_id&dTag=16050&rfc_flag=0
>
> _______________________________________________
> IETF-Announce mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ietf-announce
>

Envelope-to: [email-masked]
Delivery-date: Mon, 17 Nov 2008 00:34:32 +0000
From: Nic Neate
To: labn - Lou Berger , ALU - Dimitri Papadimitriou
CC: "[email-masked]" , Aria - Adrian Farrel Personal , "[email-masked]"
Date: Mon, 17 Nov 2008 00:32:57 +0000
Subject: RE: Agenda updated
Thread-Topic: Agenda updated
Thread-Index: AclIPeh+pqzmg/rBStmo5d+6gtIapAADXPIg
Message-ID: <[email-masked]>
Accept-Language: en-US
Content-Language: en-US
acceptlanguage: en-US
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0

Hi Lou, Dimitri,

I agree that association type 2, "Resource Sharing", allows LSPs in differe=
nt session to be associated.

However, RFC 4873 defines its use as being for make-before-break of segment=
recovery LSPs, not for associating the recovery LSP with the protected LSP=
. See section 3.2.2:

3.2.2. Resource Sharing Association Type Processing

The ASSOCIATION object with an Association Type with the value
Resource Sharing is used to enable resource sharing during make-
before-break. Resource sharing during make-before-break is defined
in [RFC3209]. The defined support only works with LSPs that share
the same LSP egress. With the introduction of segment recovery LSPs,
it is now possible for an LSP endpoint to change during make-before-
break.

Association type 1, from RFC 4873, is still used to associate the segment r=
ecovery LSP with the protected LSP. Hence the problem described in our dra=
ft.

Nic

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf =
Of labn - Lou Berger
Sent: 16 November 2008 22:46
To: Nic Neate
Cc: labn - Lou Berger; [email-masked]; Aria - Adrian Farrel Perso=
nal; [email-masked]; ALU - Dimitri Papadimitriou
Subject: RE: Agenda updated

I agree with Dimitri.

also, note:

3.2.1. Recovery Type Processing

Recovery type processing procedures are the same as those defined in
[RFC4872], but processing and identification occur with respect to
segment recovery LSPs.

Lou

At 05:36 PM 11/16/2008, PAPADIMITRIOU Dimitri wrote:
>nick,
>
>you mention:
>
>"3.1 Association between LSPs in different sessions
>
> Segment recovery protecting LSPs may have a different endpoint
> address from the corresponding protected LSP. The protected and
> protecting LSPs are therefore in different Sessions. The Association
> object of type 1 (recovery) is not effective in this case, as the
> Association ID can only associate to an LSP ID within the same
> Session."
>
>but segment recovery makes use of:
>
>"9.1. New Association Type Assignment
>
>
> IANA has made the following assignment to the "Association Types"
> Registry (see [RFC4872]) in the "ASSOCIATION (object)" section of the
> "RSVP PARAMETERS" registry located at
> http://www.iana.org/assignments/rsvp-parameters.
>
> Value Type
> ----- ----
> 2 Resource Sharing (R) [RFC4873]"
>
>and states:
>
>"Consider the following topology:
>
> A---B---C---D---E---F
> \ /
> G---I
>
> In this topology, end-to-end protection and recovery is not possible
> for an LSP going between node A and node F, but it is possible to
> protect/recover a portion of the LSP. Specifically, if the LSP uses
> a working path of [A,B,C,D,E,F], then a protection or restoration LSP
> can be established along the path [C,G,I,E]."
>
>[...]
>
>"Segment protection or restoration is signaled using a working LSP and
> one or more segment recovery LSPs. Each segment recovery LSP is
> signaled as an independent LSP. Specifically, the Sender_Template
> object uses the IP address of the node originating the recovery path,
> e.g., node C in the topology shown above, and the Session object
> contains the IP address of the node terminating the recovery path,
> e.g., node E shown above. There is no specific requirement on LSP ID
> value, Tunnel ID, and Extended Tunnel ID."
>
>so where is the issue ?
>
>-d.
>
> > -----Original Message-----
> > From: Nic Neate [mailto:[email-masked]]
> > Sent: Friday, November 14, 2008 4:46 PM
> > To: labn - Lou Berger; [email-masked]; PAPADIMITRIOU
> > Dimitri; Aria - Adrian Farrel Personal
> > Cc: [email-masked]
> > Subject: FW: Agenda updated
> >
> > RFC 4873 authors,
> >
> > Just wanted to flag that I'm presenting a problem in segment
> > recovery signaling on Monday, together with a suggested solution.
> >
> > Problem statement:
> > http://tools.ietf.org/html/draft-rhodes-rsvp-recovery-signaling-00.
> > Suggested fix:
> > http://tools.ietf.org/html/draft-rhodes-ccamp-rsvp-recovery-fix-00.
> >
> >
> > Nic
> >
> > -----Original Message-----
> > From: [email-masked]
> > [mailto:[email-masked]] On Behalf Of Aria - Adrian Farrel
> > Personal
> > Sent: 07 November 2008 19:29
> > To: [email-masked]
> > Subject: Agenda updated
> >
> > I have made some updates.
> >
> > http://www.ietf.org/proceedings/08nov/agenda/ccamp.htm
> >
> > Please shout if there further issues.
> >
> > Thanks,
> > Adrian
> >
> >

Envelope-to: [email-masked]
Delivery-date: Sun, 16 Nov 2008 23:10:14 +0000
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Subject: RE: Two week last call on draft-ietf-ccamp-gmpls-ethernet-arch-03.txt
Date: Mon, 17 Nov 2008 00:09:21 +0100
Message-ID: <[email-masked]>
Thread-Topic: Two week last call on draft-ietf-ccamp-gmpls-ethernet-arch-03.txt
Thread-Index: AclGTUfGUC6gzat4SNynBlKXbv1N/QB8IvMA
From: "PAPADIMITRIOU Dimitri"
To: "Adrian Farrel" ,

hi adrian

reading this doc. the section 2

2 Background ................................................ 5
2.1 Ethernet Switching ........................................ 5
2.2 Operations, Administration, and Maintenance (OAM) ......... 7
2.3 Terminology ............................................... 8
2.3.1 Concepts .................................................. 8
2.3.2 Abbreviations and Acronyms ................................ 9
2.4 Ethernet and MPLS similarities and differences ............ 10

as it names indicates provides Ethernet background info while i thought
the doc. was meant to deal with protocol architecture issues. of course
there is a relationship but these sections should better be included in
an appendix or so. The sentence "Ethernet is similar to MPLS in that
there is a default payload type." i missed the def. of a payload type in
RFC3031.

Section 2.3 should also be made separate from this background
information on Ethernet techno itself.=20

Section 6 reads as a recommendation on protocol usage not on
architecture e.g. "It is RECOMMENDED that LMP not be used for Fault
management and instead the native Ethernet methods be used." I am not
sure to see why an IETF document shall preclude usage of its own
protocols except if there is a good reason for (use of LMP on shared
medium is tedious since on CC shall be setup between each node).

Other comments:

" Extensions to support non-IP based LSP identification in signaling,
i.e., replacement of the IP address in the RSVP SESSION or SENDER_TSPEC
objects, are not permitted under this framework."

-> Well i would phrase this in the other way around "Support of Ethernet
MUST strictly comply to the GMPLS protocol suite addressing as specific
in RFC3471, RFC3473 and related."

"This document allows for the support the signaling of Ethernet
parameters across multiple domains"

-> How do you define the term domain in the present context ? is it
related to the Ethernet partitioning and/or segmentation in
client/provider MAC address space ?

thanks,
-d.

> -----Original Message-----
> From: [email-masked]=20
> [mailto:[email-masked]] On Behalf Of Adrian Farrel
> Sent: Friday, November 14, 2008 12:34 PM
> To: [email-masked]
> Subject: Re: Two week last call on=20
> draft-ietf-ccamp-gmpls-ethernet-arch-03.txt
>=20
> Hi,
>=20
> Some thoughts in addition to Attila's comments...
>=20
> =3D=3D=3D
> Abstract
> Can you please expand acronyms (as will be required by the RFC Ed.)
> I see...
> SONET
> SDH
> TDM
> ATM
> GMPLS
> =3D=3D=3D
> Main body of the document.
> Each acronym needs to be set out in full the first time it is used.
> I see...
> SONET
> SDH
> TDM
> ATM
> IEEE
> ITU
> MEF (transfer from later use)
> GMPLS
> VLAN (transfer from later use)
> =3D=3D=3D
> Please be consistent with the use of a space in either "IEEE 802" or=20
> "IEEE802"
> The space looks better to me.
> =3D=3D=3D
> Section 1
> OLD
> procedures that will need to be changed is dependent
> NEW
> procedures that will need to be changed are dependent
> =3D=3D=3D
> Please be consistent "bidirectional" or "bi-directional"
> I prefer "bidirectional" and you only use "unidirectional"
> =3D=3D=3D
> Section 2.3.1
> OLD
> o Asymmetric Bandwidth
>=20
> This term refers to the property of a Bi-directional=20
> LSP may have
> differing bandwidth allocation in each direction.
> NEW
> o Asymmetric Bandwidth
>=20
> This term refers to a property of a bidirectional LSP=20
> that may have
> differing bandwidth allocation in each direction.
> =3D=3D=3D
> Section 2.3.1
> OLD
> o Bi-directional Congruent LSP
>=20
> This term refers to the property that an LSP shared the same
> nodes, ports and links. Ethernet data planes are normally bi-
> directional congruent.
> NEW
> o Bidirectional Congruent LSP
>=20
> This term refers to the property of a bidirectional=20
> LSP that uses
> only the same nodes, ports, and links in both=20
> directions. Ethernet
> data planes are normally bidirectional congruent.
> =3D=3D=3D
> Section 2.3.1
>=20
> o Shared forwarding
>=20
> Shared forwarding is a property of a data path where a single
> forwarding entry (VID + DMAC) may be used for frames from
> multiple sources (SMAC). Shared forwarding does not change any
> data plane behavior it saves forwarding information base (FIB)
> entries only. From all other aspects it behaves as if=20
> there were
> multiple FIB entries.
>=20
> I don't understand the last sentence. Since there is only one=20
> FIB entry, the=20
> behavior cannot be as if there were multiple FIB entries. I=20
> suggest you=20
> either strike this sentence or add an example of what you mean.
> =3D=3D=3D
> Section 2.3.1
> o Hierarchical Eth-LSP
>=20
> Hierarchical Eth-LSPs are Eth-LSPs that are encapsulated and
> tunneled, either individually or bundled, with other=20
> LSPs through
> a domain.
>=20
> I don't like this definition of hierarchical! Normally, we=20
> refer to the=20
> hierarchical LSP as the LSP that is the tunnel, not the LSP that is=20
> encapsulated. I think it would be helpful to remain=20
> consistent with RFC4206.
> =3D=3D=3D
> Section 2.4 etc.
> Please capitalise section headings
> =3D=3D=3D
> Section 2.4
> Ethernet is similar to MPLS in that there is a default=20
> payload type.
> In MPLS, the default payload is either another MPLS label or an IP
> packet. The IP packet may carry any type of service IP carries.
> Ethernet assumes an Ethernet frame as the default payload.=20
> The actual
> service can be anything that Ethernet carries.
>=20
> I find this paragraph pretty weird!
> - What do you mean by a "default payload". Try telling the PWE3
> working group that LSPs carry either another MPLS label or an
> IP packet!
> - How can "the default" payload be either one thing or another?
> - In what way does Ethernet assume that the default payload of
> Ethernet is also Ethernet? When would that assumption stop?
> It sounds arbitrarily recursive!
> It might help if you explained what value there is to knowing=20
> the default=20
> payload type. If there is no value *to*=20
> the*work*we*are*doing* in this=20
> document, then why bother mentioning it?
> =3D=3D=3D
> Section 2.4
> Ethernet bridging is different from MPLS in that while the=20
> switching
> decision is taken on whatever is defined as the Ethernet=20
> label, that
> label is usually not swapped at each hop.
>=20
> "Usually"?
> Note that in MPLS you can use the same label on incoming and outgoing=20
> interfaces, but because the label could be swapped, we=20
> implement a swapping=20
> mechanism in all cases.
> Now, "usually" implies that sometimes the label may be=20
> swapped. This has=20
> significant implications for implementation.
>=20
> Perhaps you need to clarify this paragraph quite a bit. It=20
> might also help=20
> to discuss the context of the label. MPLS label contexts fall=20
> into three=20
> categories:
> - node
> - link
> - upstream neighbor
> What can you say about Ethernet?
> =3D=3D=3D
> Section 3
> You list
> - priority level;
> - preemption characteristics;
> How are these different?
> =3D=3D=3D
> Section 3
> Remove spare blank line between last 2 paras
> =3D=3D=3D
> Section 1 and Section 4.1
> Please add a reference where you name LMP
> =3D=3D=3D
> Section 5
> I think you should reference RFC3473 alongside RFC3471
> =3D=3D=3D
> Section 5
> OLD
> Signaling enables the ability to
> dynamically establish a path from one ingress or egress node.
> NEW
> Signaling enables the ability to
> dynamically establish a path from an ingress node to an
> egress node.
> =3D=3D=3D
> Section 5
> Given this, Eth-
> LSPs MUST always use paths that share the same routes and fates.
> I believe you have defined a term specially for this?
> =3D=3D=3D
> Section 5
> Eth-
> LSPs may be either P2P or P2MP (see [RFC4875]).
> You should probably add that only unidirectional P2MP Eth-LSPs are=20
> supported.
> =3D=3D=3D
> Section 5
> Note that standard GMPLS does not support different=20
> bandwidth in each
> direction of a bidirectional LSP. See [GMPLS-ASYM] if asymmetric
> bandwidth bidirectional LSPs are required.
> Suggest you change to
> Note that GMPLS as originally defined in [RFC3471] and=20
> [RFC3473] does
> not support...
> =3D=3D=3D
> Section 8
> More detail will be added to the section in a later revision.
> You are running out of time :-)
> =3D=3D=3D
> Section 9
> OLD
> the ports over which a UNI is defined is trusted
> NEW
> the ports over which a UNI are defined is trusted
> =3D=3D=3D
> Section 9
> This section is a bit sparse.
> You should add a reference to=20
> draft-ietf-mpls-mpls-and-gmpls-security-framework (currently rev 04)
> You should describe why the change in data plane type does=20
> not impact the=20
> control plane security.
> You should mention the difference between in-band and=20
> out-of-band control=20
> planes in the Ethernet network since in this case, the data=20
> plane type does=20
> impact security. In particular, the in-band control plane can=20
> be used to=20
> attack the data plane capacity, and access to the data plane=20
> can be used to=20
> attack the control plane.
> =3D=3D=3D
>=20
> Thanks,
> Adrian
>=20
> PS. When you submit the updates, please use the new=20
> boilerplate and use=20
> idnits to verify everything.
>=20
> ----- Original Message -----=20
> From: "Adrian Farrel"
> To:
> Sent: Wednesday, October 29, 2008 7:47 PM
> Subject: Two week last call on=20
> draft-ietf-ccamp-gmpls-ethernet-arch-03.txt
>=20
>=20
> > This email starts a two week working group last call on=20
> "GMPLS Ethernet=20
> > Label Switching Architecture and Framework"
> >
> >=20
> http://www.ietf.org/internet-drafts/draft-ietf-ccamp-gmpls-eth
> ernet-arch-03.txt
> >
> > The I-D is marked as Informational.
> >
> > Please send your comments to the list by 12 noon GMT Friday=20
> 14th November.
> >
> > Thanks,
> > Adrian and Deborah
> >
> >=20
>=20
>=20
>=20

Envelope-to: [email-masked]
Delivery-date: Sun, 16 Nov 2008 22:49:24 +0000
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Subject: RE: Slides arriving and being posted
Date: Sun, 16 Nov 2008 23:48:55 +0100
Message-ID: <[email-masked]>
Thread-Topic: Slides arriving and being posted
Thread-Index: AclH8aWFOOOek7QhSt2A+L8D6SkHTwAS5hTw
From: "PAPADIMITRIOU Dimitri"
To: "Adrian Farrel" ,

=20
adrian - looking at your slides and except if i missed it

the doc

the new release includes clarification on index field encoding. so
except if there is any remaining issue from known implementations this
doc is also ready for WG LC.=20

thx,
-d.
> -----Original Message-----
> From: [email-masked]=20
> [mailto:[email-masked]] On Behalf Of Adrian Farrel
> Sent: Sunday, November 16, 2008 2:43 PM
> To: [email-masked]
> Subject: Slides arriving and being posted
>=20
> Hi,
>=20
> Thanks to all that have sent slides already.
>=20
> Please check that they are correctly posted by visiting=20
> http://www.ietf.org/proceedings/08nov/agenda/ccamp.htm
>=20
> We're still missing a few.
>=20
> Thanks,
> Adrian=20
>=20
>=20
>=20

Envelope-to: [email-masked]
Delivery-date: Sun, 16 Nov 2008 22:46:47 +0000
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=default; d=labn.net; h=Received:X-Mailer:Date:To:From:Subject:Cc:In-Reply-To:References:Mime-Version:Content-Type:X-Identified-User; b=XOx9LiFUHqi7Oz0/fidAK2+gB+hWspgL37r1XKeBJ+GI4/3pDDGWwUvn3XCCvQd80/0XmxvhAyxIMw2neLj5/b6La8/PIqytY2fSgVnmbNtyEQdI0XeRTRaC1Ab0SQZ8;
Date: Sun, 16 Nov 2008 17:45:57 -0500
To: "Nic Neate"
From: Lou Berger
Subject: RE: Agenda updated
Cc: "Lou Berger" ,, ,, "PAPADIMITRIOU Dimitri"
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Message-Id:

I agree with Dimitri.

also, note:

3.2.1. Recovery Type Processing

Recovery type processing procedures are the same as those defined in
[RFC4872], but processing and identification occur with respect to
segment recovery LSPs.

Lou

At 05:36 PM 11/16/2008, PAPADIMITRIOU Dimitri wrote:
>nick,
>
>you mention:
>
>"3.1 Association between LSPs in different sessions
>
> Segment recovery protecting LSPs may have a different endpoint
> address from the corresponding protected LSP. The protected and
> protecting LSPs are therefore in different Sessions. The Association
> object of type 1 (recovery) is not effective in this case, as the
> Association ID can only associate to an LSP ID within the same
> Session."
>
>but segment recovery makes use of:
>
>"9.1. New Association Type Assignment
>
>
> IANA has made the following assignment to the "Association Types"
> Registry (see [RFC4872]) in the "ASSOCIATION (object)" section of the
> "RSVP PARAMETERS" registry located at
> http://www.iana.org/assignments/rsvp-parameters.
>
> Value Type
> ----- ----
> 2 Resource Sharing (R) [RFC4873]"
>
>and states:
>
>"Consider the following topology:
>
> A---B---C---D---E---F
> \ /
> G---I
>
> In this topology, end-to-end protection and recovery is not possible
> for an LSP going between node A and node F, but it is possible to
> protect/recover a portion of the LSP. Specifically, if the LSP uses
> a working path of [A,B,C,D,E,F], then a protection or restoration LSP
> can be established along the path [C,G,I,E]."
>
>[...]
>
>"Segment protection or restoration is signaled using a working LSP and
> one or more segment recovery LSPs. Each segment recovery LSP is
> signaled as an independent LSP. Specifically, the Sender_Template
> object uses the IP address of the node originating the recovery path,
> e.g., node C in the topology shown above, and the Session object
> contains the IP address of the node terminating the recovery path,
> e.g., node E shown above. There is no specific requirement on LSP ID
> value, Tunnel ID, and Extended Tunnel ID."
>
>so where is the issue ?
>
>-d.
>
> > -----Original Message-----
> > From: Nic Neate [mailto:[email-masked]]
> > Sent: Friday, November 14, 2008 4:46 PM
> > To: labn - Lou Berger; [email-masked];
> > PAPADIMITRIOU Dimitri; Aria - Adrian Farrel Personal
> > Cc: [email-masked]
> > Subject: FW: Agenda updated
> >
> > RFC 4873 authors,
> >
> > Just wanted to flag that I'm presenting a problem in segment
> > recovery signaling on Monday, together with a suggested solution.
> >
> > Problem statement:
> > http://tools.ietf.org/html/draft-rhodes-rsvp-recovery-signaling-00.
> > Suggested fix:
> > http://tools.ietf.org/html/draft-rhodes-ccamp-rsvp-recovery-fix-00.
> >
> >
> > Nic
> >
> > -----Original Message-----
> > From: [email-masked]
> > [mailto:[email-masked]] On Behalf Of Aria - Adrian
> > Farrel Personal
> > Sent: 07 November 2008 19:29
> > To: [email-masked]
> > Subject: Agenda updated
> >
> > I have made some updates.
> >
> > http://www.ietf.org/proceedings/08nov/agenda/ccamp.htm
> >
> > Please shout if there further issues.
> >
> > Thanks,
> > Adrian
> >
> >

Envelope-to: [email-masked]
Delivery-date: Sun, 16 Nov 2008 22:38:49 +0000
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Subject: RE: Agenda updated
Date: Sun, 16 Nov 2008 23:36:59 +0100
Message-ID: <[email-masked]>
Thread-Topic: Agenda updated
Thread-Index: AclBEdrEXjU0mOCKQ3CvjSu7MB8uLADwUelgANoLACA=
From: "PAPADIMITRIOU Dimitri"
To: "Nic Neate" , "labn - Lou Berger" , , "Aria - Adrian Farrel Personal"
Cc:

nick,

you mention:

"3.1 Association between LSPs in different sessions

Segment recovery protecting LSPs may have a different endpoint
address from the corresponding protected LSP. The protected and
protecting LSPs are therefore in different Sessions. The Association
object of type 1 (recovery) is not effective in this case, as the
Association ID can only associate to an LSP ID within the same
Session."

but segment recovery makes use of:

"9.1. New Association Type Assignment

IANA has made the following assignment to the "Association Types"
Registry (see [RFC4872]) in the "ASSOCIATION (object)" section of the
"RSVP PARAMETERS" registry located at
http://www.iana.org/assignments/rsvp-parameters.

Value Type
----- ----
2 Resource Sharing (R) [RFC4873]"=20

and states:

"Consider the following topology:

A---B---C---D---E---F
\ /
G---I

In this topology, end-to-end protection and recovery is not possible
for an LSP going between node A and node F, but it is possible to
protect/recover a portion of the LSP. Specifically, if the LSP uses
a working path of [A,B,C,D,E,F], then a protection or restoration LSP
can be established along the path [C,G,I,E]."=20

[...]

"Segment protection or restoration is signaled using a working LSP and
one or more segment recovery LSPs. Each segment recovery LSP is
signaled as an independent LSP. Specifically, the Sender_Template
object uses the IP address of the node originating the recovery path,
e.g., node C in the topology shown above, and the Session object
contains the IP address of the node terminating the recovery path,
e.g., node E shown above. There is no specific requirement on LSP ID
value, Tunnel ID, and Extended Tunnel ID."

so where is the issue ?

-d.

> -----Original Message-----
> From: Nic Neate [mailto:[email-masked]]=20
> Sent: Friday, November 14, 2008 4:46 PM
> To: labn - Lou Berger; [email-masked];=20
> PAPADIMITRIOU Dimitri; Aria - Adrian Farrel Personal
> Cc: [email-masked]
> Subject: FW: Agenda updated
>=20
> RFC 4873 authors,
>=20
> Just wanted to flag that I'm presenting a problem in segment=20
> recovery signaling on Monday, together with a suggested solution.
>=20
> Problem statement:=20
> http://tools.ietf.org/html/draft-rhodes-rsvp-recovery-signaling-00.
> Suggested fix:=20
> http://tools.ietf.org/html/draft-rhodes-ccamp-rsvp-recovery-fix-00.
>=20
>=20
> Nic
>=20
> -----Original Message-----
> From: [email-masked]=20
> [mailto:[email-masked]] On Behalf Of Aria - Adrian=20
> Farrel Personal
> Sent: 07 November 2008 19:29
> To: [email-masked]
> Subject: Agenda updated
>=20
> I have made some updates.
>=20
> http://www.ietf.org/proceedings/08nov/agenda/ccamp.htm
>=20
> Please shout if there further issues.
>=20
> Thanks,
> Adrian
>=20
>=20

Envelope-to: [email-masked]
Delivery-date: Sun, 16 Nov 2008 13:45:45 +0000
Message-ID: <10D6170A47D844D4B23F91AFB9C72D36@your029b8cecfe>
Reply-To: "Adrian Farrel"
From: "Adrian Farrel"
To:
Subject: Slides arriving and being posted
Date: Sun, 16 Nov 2008 13:42:34 -0000
MIME-Version: 1.0
Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original
Content-Transfer-Encoding: 7bit

Hi,

Thanks to all that have sent slides already.

Please check that they are correctly posted by visiting
http://www.ietf.org/proceedings/08nov/agenda/ccamp.htm

We're still missing a few.

Thanks,
Adrian

Envelope-to: [email-masked]
Delivery-date: Fri, 14 Nov 2008 21:01:13 +0000
Message-ID: <0CC568AD2A524BECA648AE622D9A8CB8@your029b8cecfe>
Reply-To: "Adrian Farrel"
From: "Adrian Farrel"
To:
Subject: Last callcomplete : draft-ietf-ccamp-gmpls-ethernet-arch-03.txt
Date: Fri, 14 Nov 2008 20:59:16 -0000
MIME-Version: 1.0
Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=response
Content-Transfer-Encoding: 7bit

Authors,

You received some comments.
Mainly editorial.

The sooner you post a revision, the sooner it will go forward.

Thanks,
Adrian
----- Original Message -----
From: "Adrian Farrel"
To:
Sent: Wednesday, October 29, 2008 7:47 PM
Subject: Two week last call on draft-ietf-ccamp-gmpls-ethernet-arch-03.txt

> This email starts a two week working group last call on "GMPLS Ethernet
> Label Switching Architecture and Framework"
>
> http://www.ietf.org/internet-drafts/draft-ietf-ccamp-gmpls-ethernet-arch-03.txt
>
> The I-D is marked as Informational.
>
> Please send your comments to the list by 12 noon GMT Friday 14th November.
>
> Thanks,
> Adrian and Deborah
>
>

Envelope-to: [email-masked]
Delivery-date: Fri, 14 Nov 2008 15:48:18 +0000
From: Nic Neate
To: labn - Lou Berger , "[email-masked]" , ALU - Dimitri Papadimitriou , Aria - Adrian Farrel Personal
CC: "[email-masked]"
Date: Fri, 14 Nov 2008 15:46:25 +0000
Subject: FW: Agenda updated
Thread-Topic: Agenda updated
Thread-Index: AclBEdrEXjU0mOCKQ3CvjSu7MB8uLADwUelg
Message-ID: <[email-masked]>
Accept-Language: en-US
Content-Language: en-US
acceptlanguage: en-US
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0

RFC 4873 authors,

Just wanted to flag that I'm presenting a problem in segment recovery signa=
ling on Monday, together with a suggested solution.

Problem statement: http://tools.ietf.org/html/draft-rhodes-rsvp-recovery-si=
gnaling-00.
Suggested fix: http://tools.ietf.org/html/draft-rhodes-ccamp-rsvp-recovery-=
fix-00.

Nic

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf =
Of Aria - Adrian Farrel Personal
Sent: 07 November 2008 19:29
To: [email-masked]
Subject: Agenda updated

I have made some updates.

http://www.ietf.org/proceedings/08nov/agenda/ccamp.htm

Please shout if there further issues.

Thanks,
Adrian

Envelope-to: [email-masked]
Delivery-date: Fri, 14 Nov 2008 12:01:39 +0000
Message-ID: <0FE2923B03104207BBFBC2098F27399D@your029b8cecfe>
Reply-To: "Adrian Farrel"
From: "Adrian Farrel"
To: "tom.petch" ,
Subject: Re: A BNF specification for RSVP-GMPLS and LMP
Date: Fri, 14 Nov 2008 12:00:50 -0000
MIME-Version: 1.0
Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original
Content-Transfer-Encoding: 7bit

Tom,

> I have seen this announcement on a number of lists but I am unclear where
> you
> want the discussion to take place.

Anywhere :-)

If you have issues specific to the use of the I-D in a particular set of
documents for a protocol, take it to the list that owns that protocol.

If you have issues related to the draft itself, take it to the routing
discussion list ([email-masked])

Cheers,
Adrian

Envelope-to: [email-masked]
Delivery-date: Fri, 14 Nov 2008 11:48:40 +0000
Message-ID: <002601c94645$3f25cf20$0601a8c0@allison>
Reply-To: "tom.petch"
From: "tom.petch"
To: "Adrian Farrel" ,
Subject: Re: A BNF specification for RSVP-GMPLS and LMP
Date: Wed, 12 Nov 2008 18:42:14 +0100
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit

Adrian

I have seen this announcement on a number of lists but I am unclear where you
want the discussion to take place.

Tom Petch

----- Original Message -----
From: "Adrian Farrel"
To:
Sent: Friday, October 24, 2008 5:05 PM
Subject: A BNF specification for RSVP-GMPLS and LMP

> Hi,
>
> This draft provides a specification of the BNF we already use in RSVP-TE and
> LMP and makes it available for use in future protocol extensions.
>
> I intend asking that this draft progress in the standards process relatively
> soon.
>
> Please review and comment as soon as possible.
>
> Thanks,
> Adrian
> ----- Original Message -----
> From:
> To:
> Sent: Friday, October 24, 2008 5:00 PM
> Subject: I-D Action:draft-farrel-rtg-common-bnf-06.txt
>
>
> >A New Internet-Draft is available from the on-line Internet-Drafts
> >directories.
> >
> > Title : Reduced Backus-Naur Form (RBNF) A Syntax Used in Various
> > Protocol Specifications
> > Author(s) : A. Farrel
> > Filename : draft-farrel-rtg-common-bnf-06.txt
> > Pages : 12
> > Date : 2008-10-24
> >
> > Several protocols have been specified using a common variant of the
> > Backus-Naur Form (BNF) of representing message syntax. However, there
> > is no formal definition of this version of BNF.
> >
> > There is value in using the same variant of BNF for the set of
> > protocols that are commonly used together. This reduces confusion and
> > simplifies implementation.
> >
> > Updating existing documents to use some other variant of BNF that is
> > already formally documented would be a substantial piece of work.
> >
> > This document provides a formal definition of the variant of BNF that
> > has been used (that we call Reduced BNF), and makes it available for
> > use by new protocols.
> >
> > A URL for this Internet-Draft is:
> > http://www.ietf.org/internet-drafts/draft-farrel-rtg-common-bnf-06.txt
>
>

Envelope-to: [email-masked]
Delivery-date: Fri, 14 Nov 2008 11:36:32 +0000
Message-ID: <6F406347BCC84ACBADFEFB8D805A04C6@your029b8cecfe>
Reply-To: "Adrian Farrel"
From: "Adrian Farrel"
To:
Subject: Re: Two week last call on draft-ietf-ccamp-gmpls-ethernet-arch-03.txt
Date: Fri, 14 Nov 2008 11:34:09 -0000
MIME-Version: 1.0
Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=response
Content-Transfer-Encoding: 7bit

Hi,

Some thoughts in addition to Attila's comments...

===
Abstract
Can you please expand acronyms (as will be required by the RFC Ed.)
I see...
SONET
SDH
TDM
ATM
GMPLS
===
Main body of the document.
Each acronym needs to be set out in full the first time it is used.
I see...
SONET
SDH
TDM
ATM
IEEE
ITU
MEF (transfer from later use)
GMPLS
VLAN (transfer from later use)
===
Please be consistent with the use of a space in either "IEEE 802" or
"IEEE802"
The space looks better to me.
===
Section 1
OLD
procedures that will need to be changed is dependent
NEW
procedures that will need to be changed are dependent
===
Please be consistent "bidirectional" or "bi-directional"
I prefer "bidirectional" and you only use "unidirectional"
===
Section 2.3.1
OLD
o Asymmetric Bandwidth

This term refers to the property of a Bi-directional LSP may have
differing bandwidth allocation in each direction.
NEW
o Asymmetric Bandwidth

This term refers to a property of a bidirectional LSP that may have
differing bandwidth allocation in each direction.
===
Section 2.3.1
OLD
o Bi-directional Congruent LSP

This term refers to the property that an LSP shared the same
nodes, ports and links. Ethernet data planes are normally bi-
directional congruent.
NEW
o Bidirectional Congruent LSP

This term refers to the property of a bidirectional LSP that uses
only the same nodes, ports, and links in both directions. Ethernet
data planes are normally bidirectional congruent.
===
Section 2.3.1

o Shared forwarding

Shared forwarding is a property of a data path where a single
forwarding entry (VID + DMAC) may be used for frames from
multiple sources (SMAC). Shared forwarding does not change any
data plane behavior it saves forwarding information base (FIB)
entries only. From all other aspects it behaves as if there were
multiple FIB entries.

I don't understand the last sentence. Since there is only one FIB entry, the
behavior cannot be as if there were multiple FIB entries. I suggest you
either strike this sentence or add an example of what you mean.
===
Section 2.3.1
o Hierarchical Eth-LSP

Hierarchical Eth-LSPs are Eth-LSPs that are encapsulated and
tunneled, either individually or bundled, with other LSPs through
a domain.

I don't like this definition of hierarchical! Normally, we refer to the
hierarchical LSP as the LSP that is the tunnel, not the LSP that is
encapsulated. I think it would be helpful to remain consistent with RFC4206.
===
Section 2.4 etc.
Please capitalise section headings
===
Section 2.4
Ethernet is similar to MPLS in that there is a default payload type.
In MPLS, the default payload is either another MPLS label or an IP
packet. The IP packet may carry any type of service IP carries.
Ethernet assumes an Ethernet frame as the default payload. The actual
service can be anything that Ethernet carries.

I find this paragraph pretty weird!
- What do you mean by a "default payload". Try telling the PWE3
working group that LSPs carry either another MPLS label or an
IP packet!
- How can "the default" payload be either one thing or another?
- In what way does Ethernet assume that the default payload of
Ethernet is also Ethernet? When would that assumption stop?
It sounds arbitrarily recursive!
It might help if you explained what value there is to knowing the default
payload type. If there is no value *to* the*work*we*are*doing* in this
document, then why bother mentioning it?
===
Section 2.4
Ethernet bridging is different from MPLS in that while the switching
decision is taken on whatever is defined as the Ethernet label, that
label is usually not swapped at each hop.

"Usually"?
Note that in MPLS you can use the same label on incoming and outgoing
interfaces, but because the label could be swapped, we implement a swapping
mechanism in all cases.
Now, "usually" implies that sometimes the label may be swapped. This has
significant implications for implementation.

Perhaps you need to clarify this paragraph quite a bit. It might also help
to discuss the context of the label. MPLS label contexts fall into three
categories:
- node
- link
- upstream neighbor
What can you say about Ethernet?
===
Section 3
You list
- priority level;
- preemption characteristics;
How are these different?
===
Section 3
Remove spare blank line between last 2 paras
===
Section 1 and Section 4.1
Please add a reference where you name LMP
===
Section 5
I think you should reference RFC3473 alongside RFC3471
===
Section 5
OLD
Signaling enables the ability to
dynamically establish a path from one ingress or egress node.
NEW
Signaling enables the ability to
dynamically establish a path from an ingress node to an
egress node.
===
Section 5
Given this, Eth-
LSPs MUST always use paths that share the same routes and fates.
I believe you have defined a term specially for this?
===
Section 5
Eth-
LSPs may be either P2P or P2MP (see [RFC4875]).
You should probably add that only unidirectional P2MP Eth-LSPs are
supported.
===
Section 5
Note that standard GMPLS does not support different bandwidth in each
direction of a bidirectional LSP. See [GMPLS-ASYM] if asymmetric
bandwidth bidirectional LSPs are required.
Suggest you change to
Note that GMPLS as originally defined in [RFC3471] and [RFC3473] does
not support...
===
Section 8
More detail will be added to the section in a later revision.
You are running out of time :-)
===
Section 9
OLD
the ports over which a UNI is defined is trusted
NEW
the ports over which a UNI are defined is trusted
===
Section 9
This section is a bit sparse.
You should add a reference to
draft-ietf-mpls-mpls-and-gmpls-security-framework (currently rev 04)
You should describe why the change in data plane type does not impact the
control plane security.
You should mention the difference between in-band and out-of-band control
planes in the Ethernet network since in this case, the data plane type does
impact security. In particular, the in-band control plane can be used to
attack the data plane capacity, and access to the data plane can be used to
attack the control plane.
===

Thanks,
Adrian

PS. When you submit the updates, please use the new boilerplate and use
idnits to verify everything.

----- Original Message -----
From: "Adrian Farrel"
To:
Sent: Wednesday, October 29, 2008 7:47 PM
Subject: Two week last call on draft-ietf-ccamp-gmpls-ethernet-arch-03.txt

> This email starts a two week working group last call on "GMPLS Ethernet
> Label Switching Architecture and Framework"
>
> http://www.ietf.org/internet-drafts/draft-ietf-ccamp-gmpls-ethernet-arch-03.txt
>
> The I-D is marked as Informational.
>
> Please send your comments to the list by 12 noon GMT Friday 14th November.
>
> Thanks,
> Adrian and Deborah
>
>

Envelope-to: [email-masked]
Delivery-date: Wed, 12 Nov 2008 15:01:35 +0000
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Subject: RE: [mpls] Poll for MPLS-TP documents to become mpls workinggroupdocuments
Date: Wed, 12 Nov 2008 15:58:28 +0100
Message-ID: <[email-masked]>
Thread-Topic: [mpls] Poll for MPLS-TP documents to become mpls workinggroupdocuments
Thread-Index: Ack9vNPuOTzVZoPIS8u3G2GbWI2bwAG/pBpwAAawcoA=
From: "Sprecher, Nurit (NSN - IL/Hod HaSharon)"
To: "ext Annamaria Fulignoli" , "Loa Andersson" , , "pwe3" , "L2VPN" , "ccamp" , ,

I have also issued a few weeks ago some comments and questions on the =
framework. I hope the editors will address these comments.=20

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf =
Of ext Annamaria Fulignoli
Sent: Wednesday, November 12, 2008 13:45
To: Loa Andersson; [email-masked]; pwe3; L2VPN; ccamp; [email-masked]; =
[email-masked]
Subject: RE: [mpls] Poll for MPLS-TP documents to become mpls =
workinggroupdocuments

Hi all,
I support for all the four.

However I wonder if it's possible to have some more clarification now =
about draft-blb-mpls-tp-framework-01, Figure 3 and associated Editor's =
note:
"The figure above arose from discussions in the MPLS-TP design team. It =
will be clarified in a future version of this draft"

It's not clear to me the issue regarding OAM dmux without GAL/GACH.=20
My understanding was that:=20

"OAM, protection and forwarding of data packets MUST be able to operate =
without IP forwarding support " as reported by the same draft section 2

and

"... the operation of OAM functions MUST NOT rely on IP routing and =
forwarding capabilities"
as reported by draft-vigoureux-mpls-tp-oam-requirements-01 (section 2.1)

Thank you and Best Regards
Annamaria

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of =
Loa Andersson
Sent: luned=EC 3 novembre 2008 15.00
To: [email-masked]; pwe3; L2VPN; ccamp; [email-masked]; [email-masked]
Subject: [mpls] Poll for MPLS-TP documents to become mpls working =
groupdocuments

Working group(s)

we have four documents from the MPLS-TP effort that the authors think =
are ready to become working group documents. The documents are listed =
below.

This mail initiate a two week working poll for comments on three of the =
documents, for the fourth document
(draft-bocci-mpls-tp-gach-gal-00.txt) we already have an ongoing poll.

Please send your comments before Nov 11 for =
draft-bocci-mpls-tp-gach-gal-00.txt and Nov 17 for the other three-

*Note:*
Please send your responses to the *mpls working group mailing list*, a =
bit of discipline is needed, "replay all" won't do the trick ;).

Comments Nov 11 the latest:

Title : MPLS Generic Associated Channel
Author(s): M. Vigoureux, M. Bocci, D. Ward, G. Swallow,
R. Aggarwal
Filename : draft-bocci-mpls-tp-gach-gal-00.txt
Pages : 16
Date : 2008-10-27

Comments Nov 17 the latest:

Title : MPLS-TP Requirements
Author(s): B. Niven-Jenkins, et al.
Filename : draft-jenkins-mpls-mpls-tp-requirements-01.txt
Pages : 18
Date : 2008-10-31

Title : A Framework for MPLS in Transport Networks
Author(s): M. Bocci, S. Bryant
Filename : draft-blb-mpls-tp-framework-01.txt
Pages : 27
Date : 2008-10-31

Title : Requirements for OAM in MPLS Transport Networks
Author(s): M. Vigoureux, D. Ward, M. Betts, M. Bocci, I.Busi
Filename : draft-vigoureux-mpls-tp-oam-requirements-01.txt
Pages : 16
Date : 2008-11-1

Loa and George

--
Loa Andersson

Principal Networking Architect
Acreo AB phone: +46 8 632 77 14
Isafjordsgatan 22 mobile: +46 739 81 21 64
Kista, Sweden email: [email-masked]
[email-masked] =
_______________________________________________
mpls mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/mpls

Envelope-to: [email-masked]
Delivery-date: Wed, 12 Nov 2008 00:11:36 +0000
Message-ID: <56BC37215ECA446B84C9DB2EDEC1969D@your029b8cecfe>
Reply-To: "Adrian Farrel"
From: "Adrian Farrel"
To:
Subject: NOTE WELL: New Boilerplate Text Required for all new Submissions to IETF
Date: Wed, 12 Nov 2008 00:08:22 -0000
MIME-Version: 1.0
Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original
Content-Transfer-Encoding: 7bit

Note well. Your I-Ds will not be posted unless they conform to new
boiler-plate requirements.

Adrian
----- Original Message -----
From: "Ed Juskevicius"
To: "IETF Discussion" ; ;
; ; ; "RFC Editor"
;
Cc:
Sent: Tuesday, November 11, 2008 11:03 PM
Subject: Announcement: New Boilerplate Text Required for all new
Submissionsto IETF

> Greetings. This message is to draw your attention to the significance
> of the publication of RFC5377 and RFC5378 earlier today.
>
> * RFC5377 is Advice to the Trustees of the IETF Trust on Rights to Be
> Granted in IETF Documents
> * RFC5378 is Rights Contributors Provide to the IETF Trust
>
> Note that RFC5378 is also BCP0078. RFC5378 is an update to RFC2026, and
> RFC5378 obsoletes both RFC3978 and RFC4748.
>
> Coincident with the above, the IETF Trustees have posted a new policy
> document with guidance to the community on:
> * Legal Provisions Relating to IETF Documents at
> http://trustee.ietf.org/license-info/
>
> Taken as a set, the documents listed above specify changes that are now
> required in all new submissions into the IETF.
>
> Henrik Levkowetz has updated the idnit tool and AMS have updated the
> Internet-Draft submission tool to reflect the new requirements. An
> update to the xml2rfc has been requested.
>
> Please review the "Legal Provisions Relating to IETF Documents" and
> RFC5378 to discover the new boilerplate text that is now required.
> Please also take action to update the tools you use for creating your
> documents.
>
> New submissions using either the old or the new boilerplate text will be
> accepted starting today, until 01h00 UTC on December 16th, 2008. After
> this cutoff date, all new submissions will be required to use ONLY the
> new boilerplate text. All submissions using old boilerplate text after
> the cutoff date will be rejected.
>
> Regards and FYI.
>
> Ed Juskevicius
> IETF Trust Chair
> [email-masked]
>
> p.s. - Don't be surprised if you see periodic reminders about this as we
> approach December 16th.

Envelope-to: [email-masked]
Delivery-date: Tue, 11 Nov 2008 08:44:59 +0000
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Subject: RE: Two week last call on draft-ietf-ccamp-gmpls-ethernet-arch-03.txt
Date: Tue, 11 Nov 2008 09:41:39 +0100
Message-ID: <[email-masked]>
Thread-Topic: Two week last call on draft-ietf-ccamp-gmpls-ethernet-arch-03.txt
thread-index: Ack6AA/bxf8lkrpkSMuljVMOwLadUQJ2R12g
From: "Attila Takacs"
To: "Don Fedyk" , , "Loa Andersson"
Cc: "Adrian Farrel" ,

Hi all,
Some comments on the draft, mostly editorial.
Best regards,
Attila

-Move the abbreviation section (2.3.2) in the beginning of the document.
I would consider moving the whole terminology section (2.3) forward.

-Page 3, delete "Document History"

-Page 3, Introduction, last sentence of second paragraph, change "but
not an explicitly" ->"but not on explicitly"

-Page 3, Introduction, 5th paragraph: add a new reference to 802.1ad and
reword the first sentence

-Page 4, last paragraph change: "This document introduces and explains
the concept of an Ethernet
Label Switched Path (Eth-LSP)." -> "This document introduces and
explains GMPLS control plane deployment for Ethernet and the concept of
the Ethernet Label Switched Path (Eth-LSP)."

-Page 5, Background, second paragraph, first sentence change: "this
section is based on the on-going work" -> "this section is based on both
finished and on-going work"

-Page 7, bullet on I-tagged interfaces, change second sentence: "An
I-Tag contains a service identifier (24 bit I-SID) and priority
markings as well as some other flags." -> "An I-Tag contains a
service identifier (24 bit I-SID) and priority
markings as well as some other fields."

-Page 7, first paragraph after the bullet list, change: "In general, the
different switching type determines" -> "In general, the switching type
determines" and "The type may also" -> "The switching type may also"

-Page 7, last paragraph, delete: "For the Eth-LSP unicast mode of
behavior, the hardware performs unicast packet forwarding of known MAC
addresses leveraging existing Ethernet forwarding."

-Page 8, OAM, last paragraph, reword to: "Both Y.1731 & 802.1ag assumes
that bidirectional transactions (e.g., LBM/LBR) use the same VID in both
directions. However in some scenarios, especially with explicitly routed
paths [802.1Qay], it is possible that different VIDs are used upstream
and downstream. In the context of [802.1Qay] work is ongoing to update
[802.1ag] to support such scenarios."=20

-Page 8, Bi-directional Congruent LSP, typo, "LSP shared" -> "LSP
shares"

-Page 8, Shared forwarding: add at the end: "In contrast to merging
where control plane states as well as forwarding entries are merged,
with shared forwarding dedicated states for all Eth-LSP are maintained
regardless of shared forwarding entries."

-Page 8, add the definition of Eth-LSPs: "Eth-LSP: This term refers to
Ethernet service paths that are controlled via GMPLS."

-Page 10, Framework, first sentence: remove parenthesis around GMPLS

-Page 12, first paragraph reorder to read: "...This valid MAC checking
and broadcast supports Ethernet learning. A special case is when a VID
is
defined for only two ports on one bridge, effectively resulting in a
p2p forwarwading constraint, in this case all frames
tagged with that VID received over one of these ports are forward
over the
other port without address learning. [802.1Qay]
allows for turning off learning and hence the broadcast mechanism
providing means to create explicitly routed Ethernet connections."

-Page 16, section 8, delete last sentence "More detail will be added to
the section in a later revision." and/or add further details :-)
=20

> -----Original Message-----
> From: [email-masked]=20
> [mailto:[email-masked]] On Behalf Of Adrian Farrel
> Sent: Wednesday, October 29, 2008 8:48 PM
> To: [email-masked]
> Subject: Two week last call on=20
> draft-ietf-ccamp-gmpls-ethernet-arch-03.txt
>=20
> This email starts a two week working group last call on=20
> "GMPLS Ethernet Label Switching Architecture and Framework"
>=20
> http://www.ietf.org/internet-drafts/draft-ietf-ccamp-gmpls-eth
> ernet-arch-03.txt
>=20
> The I-D is marked as Informational.
>=20
> Please send your comments to the list by 12 noon GMT Friday=20
> 14th November.
>=20
> Thanks,
> Adrian and Deborah=20
>=20
>=20
>=20

Envelope-to: [email-masked]
Delivery-date: Mon, 10 Nov 2008 19:34:31 +0000
From: The IESG
To: IETF-Announce
Cc: Internet Architecture Board , RFC Editor , ccamp mailing list , ccamp chair
Subject: Protocol Action: 'Encoding of Attributes for Multiprotocol Label Switching (MPLS) Label Switched Path (LSP) Establishment Using RSVP-TE' to Proposed Standard
Message-Id: <[email-masked]>
Date: Mon, 10 Nov 2008 11:32:17 -0800 (PST)

The IESG has approved the following document:

- 'Encoding of Attributes for Multiprotocol Label Switching (MPLS) Label
Switched Path (LSP) Establishment Using RSVP-TE '
as a Proposed Standard

This document is the product of the Common Control and Measurement Plane
Working Group.

The IESG contact persons are Ross Callon and David Ward.

A URL of this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-ccamp-rfc4420bis-03.txt

Technical Summary

This document replaces and obsoletes RFC 4420. The only change is
in the encoding of the Type-Length-Variable (TLV) data structures.
This allows consistency with the use of TLV data structures in other
related documents, and therefore essentially corrects a bug in 4420.

Multiprotocol Label Switching (MPLS) Label Switched Paths (LSPs) may
be established using the Resource Reservation Protocol Traffic
Engineering (RSVP-TE) extensions. This protocol includes an object
(the SESSION_ATTRIBUTE object) that carries a Flags field used to
indicate options and attributes of the LSP. That Flags field has
eight bits allowing for eight options to be set. Recent proposals in
many documents that extend RSVP-TE have suggested uses for each of
the previously unused bits.

This document defines a new object for RSVP-TE messages that allows
the signaling of further attribute bits and also the carriage of
arbitrary attribute parameters to make RSVP-TE easily extensible to
support new requirements. Additionally, this document defines a way
to record the attributes applied to the LSP on a hop-by-hop basis.

The object mechanisms defined in this document are equally applicable
to Generalized MPLS (GMPLS) Packet Switch Capable (PSC) LSPs and to
GMPLS non-PSC LSPs.

Working Group Summary

This document corrects a bug in RFC4220 which was found during
interoperability testing. Once this bug was found, there was no
controversy regarding how to fix this.

Document Quality

Current implementations are compatible with this document
(and therefore no longer compatible with one detail in RFC4220).

Personnel

Deborah Brungard is the document shepherd. Ross Callon is the
responsible AD.

RFC Editor Note

Please update section 3 as follows:

OLD
Length

Indicates the total length of the TLV, i.e., 4 + the length of
the value field in octets. A value field whose length is not a
multiple of four MUST be zero-padded so that the TLV is four-
octet aligned.

Value

The data for the TLV padded as described above.

NEW

Length

Indicates the total length of the TLV in octets. That is the
combined length of the Type, Length, and Value fields, i.e.,
four plus the length of the Value field in octets.

The entire TLV MUST be padded with between zero and three
trailing zeros to make it four-octet aligned. The Length field
does not count any padding.

Value

The data carried in the TLV.

Envelope-to: [email-masked]
Delivery-date: Sun, 09 Nov 2008 13:18:20 +0000
Message-ID: <8FCD06A61E6C40518AF2E84A0E30F1C0@your029b8cecfe>
Reply-To: "Adrian Farrel"
From: "Adrian Farrel"
To:
Subject: Slides
Date: Sun, 9 Nov 2008 13:16:02 -0000
MIME-Version: 1.0
Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original
Content-Transfer-Encoding: 7bit

Please start sending in your slides so that I can post them for everyone to
see.

Thanks,
Adrian

Envelope-to: [email-masked]
Delivery-date: Fri, 07 Nov 2008 19:30:57 +0000
Message-ID: <984EFCBC86A84BD59181C6E179499780@your029b8cecfe>
Reply-To: "Adrian Farrel"
From: "Adrian Farrel"
To:
Subject: Agenda updated
Date: Fri, 7 Nov 2008 19:28:46 -0000
MIME-Version: 1.0
Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=response
Content-Transfer-Encoding: 7bit

I have made some updates.

http://www.ietf.org/proceedings/08nov/agenda/ccamp.htm

Please shout if there further issues.

Thanks,
Adrian

Envelope-to: [email-masked]
Delivery-date: Thu, 06 Nov 2008 21:28:39 +0000
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Subject: RE: [mpls] Updates to draft-ietf-ccamp-mpls-graceful-shutdown
Date: Thu, 6 Nov 2008 16:26:54 -0500
Message-ID:
Thread-Topic: [mpls] Updates to draft-ietf-ccamp-mpls-graceful-shutdown
Thread-Index: Ack53yEy/I+XfyB5TO2rHdRpEseqEwAA9bbAAAD+ZwABm7fF0A==
From: "Zafar Ali (zali)"
To: "AISSAOUI Mustapha" , "Lou Berger"
Cc: , "Newton, Jonathan" , , , "Anca Zamfir (ancaz)"
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=2949; t=1226006814; x=1226870814; c=relaxed/simple; s=rtpdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=[email-masked]; z=From:=20=22Zafar=20Ali=20(zali)=22=20 |Subject:=20RE=3A=20[mpls]=20Updates=20to=20draft-ietf-ccam p-mpls-graceful-shutdown |Sender:=20 |To:=20=22AISSAOUI=20Mustapha=22=20,=0A=20=20=20=20=20=20=20=20=22Lou=20Berger=22 =20; bh=M/y1Y3DEF7WpFFRoHyiGwMhBHZGmdpTLsajBG5IfaSs=; b=F42WUN+I/O5hU7OyLFzyeZatIHzrODeZKNdJPMw/xTYcB0BofsakrQ+lpx fPwwOqSTHwAEzi6ozS3VDp1oNTofeRohkpXo1NJCIoNl0JIxkDY/2s+sXcpb /saV+nwRhM;
Authentication-Results: rtp-dkim-2; header.From=[email-masked]; dkim=pass ( sig from cisco.com/rtpdkim2001 verified; );

Mustapha-=20

I think once we address Lou's comment, that will also address your
comment. So please wait for the new revision. We can try to publish it
during the IETF week.=20

Thanks

Regards... Zafar=20

> -----Original Message-----
> From: AISSAOUI Mustapha [mailto:[email-masked]]=20
> Sent: Thursday, November 06, 2008 1:05 PM
> To: Zafar Ali (zali); Lou Berger
> Cc: [email-masked]; Newton, Jonathan; [email-masked];=20
> [email-masked]; Anca Zamfir (ancaz)
> Subject: RE: [mpls] Updates to draft-ietf-ccamp-mpls-graceful-shutdown
>=20
> Hi Ali,
> I have an issue with not providing backwards compatibility=20
> with the "Notify" error code and the error sub-codes for link=20
> and node maintenance defined in RFC 4736. This draft has been=20
> using these codes for almost four years now and it is not=20
> acceptable they get changed in last call.
>=20
> Furthermore, draft-ietf-mpls-gmpls-lsp-reroute-02.txt=20
> suggests backwards compatibility must be provided when=20
> required. I believe this is one of those cases. When=20
> draft-ietf-mpls-gmpls-lsp-reroute-02.txt passes WG last call,=20
> it makes perfect sense to require new applications to start using it.
>=20
> Regards,
> Mustapha.=20
>=20
> > -----Original Message-----
> > From: [email-masked] [mailto:[email-masked]]=20
> On Behalf=20
> > Of Zafar Ali (zali)
> > Sent: Wednesday, October 29, 2008 12:35 PM
> > To: Lou Berger
> > Cc: [email-masked]; Newton, Jonathan; [email-masked];=20
> > [email-masked]; Anca Zamfir (ancaz)
> > Subject: Re: [mpls] Updates to=20
> draft-ietf-ccamp-mpls-graceful-shutdown
> >=20
> > Hi Lou-
> >=20
> > > -----Original Message-----
> > > From: [email-masked]
> > > [mailto:[email-masked]] On Behalf Of Lou Berger
> > > Sent: Wednesday, October 29, 2008 11:56 AM
> > > To: Zafar Ali (zali)
> > > Cc: Lou Berger; Adrian Farrel; [email-masked]; [email-masked];=20
> > > [email-masked]; Anca Zamfir (ancaz); Newton, Jonathan
> > > Subject: Re: Updates to draft-ietf-ccamp-mpls-graceful-shutdown
> > >=20
> > > Zafar,
> > >=20
> > > Why does the document define new error codes (and why 4)? =20
> > Is it that
> > > the reroute document isn't sufficient clear on how to
> > indicated each
> > > of the 4? Is it some other reason?
> > >=20
> >=20
> > This is because headend may be able to compute alternate route=20
> > ("reroute" action) for mb4b differently, depending on the resource=20
> > under graceful shutdown, as detailed in the document. Hence=20
> one code=20
> > is define for TE node, TE link, component link of a bundled=20
> TE link,=20
> > and label resource, each.
> >=20
> > Thanks
> >=20
> > Regards... Zafar
> >=20
> >
> > _______________________________________________
> > mpls mailing list
> > [email-masked]
> > https://www.ietf.org/mailman/listinfo/mpls
> >=20
>=20

Envelope-to: [email-masked]
Delivery-date: Thu, 06 Nov 2008 18:09:16 +0000
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Subject: RE: [mpls] Updates to draft-ietf-ccamp-mpls-graceful-shutdown
Date: Thu, 6 Nov 2008 12:04:48 -0600
Message-ID: <[email-masked]>
Thread-Topic: [mpls] Updates to draft-ietf-ccamp-mpls-graceful-shutdown
Thread-Index: Ack53yEy/I+XfyB5TO2rHdRpEseqEwAA9bbAAAD+ZwA=
From: "AISSAOUI Mustapha"
To: "Zafar Ali \(zali\)" , "Lou Berger"
Cc: , "Newton, Jonathan" , , , "Anca Zamfir \(ancaz\)"

Hi Ali,
I have an issue with not providing backwards compatibility with the
"Notify" error code and the error sub-codes for link and node
maintenance defined in RFC 4736. This draft has been using these codes
for almost four years now and it is not acceptable they get changed in
last call.

Furthermore, draft-ietf-mpls-gmpls-lsp-reroute-02.txt suggests backwards
compatibility must be provided when required. I believe this is one of
those cases. When draft-ietf-mpls-gmpls-lsp-reroute-02.txt passes WG
last call, it makes perfect sense to require new applications to start
using it.

Regards,
Mustapha.=20

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On=20
> Behalf Of Zafar Ali (zali)
> Sent: Wednesday, October 29, 2008 12:35 PM
> To: Lou Berger
> Cc: [email-masked]; Newton, Jonathan; [email-masked];=20
> [email-masked]; Anca Zamfir (ancaz)
> Subject: Re: [mpls] Updates to draft-ietf-ccamp-mpls-graceful-shutdown
>=20
> Hi Lou- =20
>=20
> > -----Original Message-----
> > From: [email-masked]
> > [mailto:[email-masked]] On Behalf Of Lou Berger
> > Sent: Wednesday, October 29, 2008 11:56 AM
> > To: Zafar Ali (zali)
> > Cc: Lou Berger; Adrian Farrel; [email-masked]; [email-masked];=20
> > [email-masked]; Anca Zamfir (ancaz); Newton, Jonathan
> > Subject: Re: Updates to draft-ietf-ccamp-mpls-graceful-shutdown
> >=20
> > Zafar,
> >=20
> > Why does the document define new error codes (and why 4)? =20
> Is it that=20
> > the reroute document isn't sufficient clear on how to=20
> indicated each=20
> > of the 4? Is it some other reason?
> >=20
>=20
> This is because headend may be able to compute alternate=20
> route ("reroute" action) for mb4b differently, depending on=20
> the resource under graceful shutdown, as detailed in the=20
> document. Hence one code is define for TE node, TE link,=20
> component link of a bundled TE link, and label resource, each.=20
>=20
> Thanks
>=20
> Regards... Zafar=20
>=20
>
> _______________________________________________
> mpls mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/mpls
>=20

Envelope-to: [email-masked]
Delivery-date: Tue, 04 Nov 2008 11:09:10 +0000
Message-ID: <[email-masked]>
Date: Tue, 04 Nov 2008 20:07:08 +0900
From: Masahiko Mizutani
User-Agent: Thunderbird 2.0.0.12 (Windows/20080213)
MIME-Version: 1.0
To: Loa Andersson , "[email-masked]" , pwe3 , L2VPN , ccamp , "[email-masked]" , "[email-masked]"
Subject: Re: [mpls-tp] Poll for MPLS-TP documents to become mpls working group documents
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

Support all documents.

Regards,
Masahiko Mizutani

Loa Andersson wrote:
> Working group(s)
>
> we have four documents from the MPLS-TP effort that the authors think
> are ready to become working group documents. The documents are listed below.
>
> This mail initiate a two week working poll for comments on three of the
> documents, for the fourth document
> (draft-bocci-mpls-tp-gach-gal-00.txt) we already have an ongoing poll.
>
> Please send your comments before Nov 11 for
> draft-bocci-mpls-tp-gach-gal-00.txt and Nov 17 for the other three-
>
> *Note:*
> Please send your responses to the *mpls working group mailing list*,
> a bit of discipline is needed, "replay all" won't do the trick ;).
>
> Comments Nov 11 the latest:
>
> Title : MPLS Generic Associated Channel
> Author(s): M. Vigoureux, M. Bocci, D. Ward, G. Swallow,
> R. Aggarwal
> Filename : draft-bocci-mpls-tp-gach-gal-00.txt
> Pages : 16
> Date : 2008-10-27
>
>
> Comments Nov 17 the latest:
>
> Title : MPLS-TP Requirements
> Author(s): B. Niven-Jenkins, et al.
> Filename : draft-jenkins-mpls-mpls-tp-requirements-01.txt
> Pages : 18
> Date : 2008-10-31
>
> Title : A Framework for MPLS in Transport Networks
> Author(s): M. Bocci, S. Bryant
> Filename : draft-blb-mpls-tp-framework-01.txt
> Pages : 27
> Date : 2008-10-31
>
> Title : Requirements for OAM in MPLS Transport Networks
> Author(s): M. Vigoureux, D. Ward, M. Betts, M. Bocci, I.Busi
> Filename : draft-vigoureux-mpls-tp-oam-requirements-01.txt
> Pages : 16
> Date : 2008-11-1
>
> Loa and George
>

Envelope-to: [email-masked]
Delivery-date: Mon, 03 Nov 2008 19:45:54 +0000
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Subject: RE: [mpls] Poll for MPLS-TP documents to become mpls working groupdocuments
Date: Mon, 3 Nov 2008 14:44:58 -0500
Message-ID: <[email-masked]>
Thread-Topic: [mpls] Poll for MPLS-TP documents to become mpls working groupdocuments
Thread-Index: Ack9vNVtCHsPlZ7CSQKUEf/VFXm4wAAL8wFQ
From: "Shah, Himanshu"
To: "Loa Andersson" , , "pwe3" , "L2VPN" , "ccamp" , ,

support all.

/himanshu=20

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
Loa Andersson
Sent: Monday, November 03, 2008 9:00 AM
To: [email-masked]; pwe3; L2VPN; ccamp; [email-masked]; [email-masked]
Subject: [mpls] Poll for MPLS-TP documents to become mpls working
groupdocuments

Working group(s)

we have four documents from the MPLS-TP effort that the authors think
are ready to become working group documents. The documents are listed
below.

This mail initiate a two week working poll for comments on three of the
documents, for the fourth document
(draft-bocci-mpls-tp-gach-gal-00.txt) we already have an ongoing poll.

Please send your comments before Nov 11 for
draft-bocci-mpls-tp-gach-gal-00.txt and Nov 17 for the other three-

*Note:*
Please send your responses to the *mpls working group mailing list*, a
bit of discipline is needed, "replay all" won't do the trick ;).

Comments Nov 11 the latest:

Title : MPLS Generic Associated Channel
Author(s): M. Vigoureux, M. Bocci, D. Ward, G. Swallow,
R. Aggarwal
Filename : draft-bocci-mpls-tp-gach-gal-00.txt
Pages : 16
Date : 2008-10-27

Comments Nov 17 the latest:

Title : MPLS-TP Requirements
Author(s): B. Niven-Jenkins, et al.
Filename : draft-jenkins-mpls-mpls-tp-requirements-01.txt
Pages : 18
Date : 2008-10-31

Title : A Framework for MPLS in Transport Networks
Author(s): M. Bocci, S. Bryant
Filename : draft-blb-mpls-tp-framework-01.txt
Pages : 27
Date : 2008-10-31

Title : Requirements for OAM in MPLS Transport Networks
Author(s): M. Vigoureux, D. Ward, M. Betts, M. Bocci, I.Busi
Filename : draft-vigoureux-mpls-tp-oam-requirements-01.txt
Pages : 16
Date : 2008-11-1

Loa and George

--
Loa Andersson

Principal Networking Architect
Acreo AB phone: +46 8 632 77 14
Isafjordsgatan 22 mobile: +46 739 81 21 64
Kista, Sweden email: [email-masked]
[email-masked]
_______________________________________________
mpls mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/mpls

Envelope-to: [email-masked]
Delivery-date: Mon, 03 Nov 2008 19:01:13 +0000
From: [email-masked]
To: [email-masked]
Cc: [email-masked]
Subject: I-D ACTION:draft-ietf-ccamp-gmpls-mln-extensions-03.txt
Content-Type: Multipart/Mixed; Boundary="NextPart"
Mime-Version: 1.0
Message-Id: <[email-masked]>
Date: Mon, 3 Nov 2008 11:00:01 -0800 (PST)

--NextPart

A New Internet-Draft is available from the on-line Internet-Drafts
directories.
This draft is a work item of the Common Control and Measurement Plane Working Group of the IETF.

Title : Generalized Multi-Protocol Label Switching (GMPLS) Protocol Extensions for Multi-Layer and Multi-Region Networks (MLN/MRN)
Author(s) : D. Papadimitriou, M. Vigoureux, K. Shiomoto, D. Brungard, J. Roux, E. Oki, I. Inoue, E. Dotaro, G. Grammel
Filename : draft-ietf-ccamp-gmpls-mln-extensions-03.txt
Pages : 21
Date : 2008-11-3

There are requirements for the support of networks comprising LSRs
with different data plane switching layers controlled by a single
Generalized Multi Protocol Label Switching (GMPLS) control plane
instance, referred to as GMPLS Multi-Layer Networks/Multi-Region
Networks (MLN/MRN).

This document defines extensions to GMPLS routing and signaling
protocols so as to support the operation of GMPLS Multi-Layer/Multi-
Region Networks. It covers the elements of a single GMPLS control
plane instance controlling multiple LSP regions or layers within a
single TE domain.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-ccamp-gmpls-mln-extensions-03.txt

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

--NextPart
Content-Type: Message/External-body;
name="draft-ietf-ccamp-gmpls-mln-extensions-03.txt";
site="ftp.ietf.org";
access-type="anon-ftp";
directory="internet-drafts"

Content-Type: text/plain
Content-ID: <[email-masked]>

--NextPart--

Envelope-to: [email-masked]
Delivery-date: Mon, 03 Nov 2008 18:15:45 +0000
From: [email-masked]
To: [email-masked]
Cc: [email-masked]
Subject: I-D Action:draft-ietf-ccamp-rwa-info-01.txt
Content-Type: Multipart/Mixed; Boundary="NextPart"
Mime-Version: 1.0
Message-Id: <[email-masked]>
Date: Mon, 3 Nov 2008 10:15:01 -0800 (PST)

--NextPart

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Common Control and Measurement Plane Working Group of the IETF.

Title : Routing and Wavelength Assignment Information Model for Wavelength Switched Optical Networks
Author(s) : G. Bernstein
Filename : draft-ietf-ccamp-rwa-info-01.txt
Pages : 17
Date : 2008-11-03

This document provides a model of information needed by the routing
and wavelength assignment (RWA) process in wavelength switched
optical networks (WSONs). The purpose of the information described
in this model is to facilitate constrained lightpath computation in
WSONs, particularly in cases where there are no or a limited number
of wavelength converters available. This model currently does not
include optical impairments.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-ccamp-rwa-info-01.txt

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

--NextPart
Content-Type: Message/External-body;
name="draft-ietf-ccamp-rwa-info-01.txt";
site="ftp.ietf.org";
access-type="anon-ftp";
directory="internet-drafts"

Content-Type: text/plain
Content-ID: <[email-masked]>

--NextPart--

Envelope-to: [email-masked]
Delivery-date: Mon, 03 Nov 2008 17:50:32 +0000
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Subject: RE: [mpls-tp] Poll for MPLS-TP documents to become mpls working groupdocuments
Date: Mon, 3 Nov 2008 18:48:37 +0100
Message-ID: <[email-masked]>
Thread-Topic: [mpls-tp] Poll for MPLS-TP documents to become mpls working groupdocuments
Thread-Index: Ack9vOlzwcsBl3UNRy2LKuiue/RPHgAH3Sgg
From: "Sprecher, Nurit (NSN - IL/Hod HaSharon)"
To: "ext Loa Andersson" , , "pwe3" , "L2VPN" , "ccamp" , ,

Support for all.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On
Behalf Of ext Loa Andersson
Sent: Monday, November 03, 2008 16:00
To: [email-masked]; pwe3; L2VPN; ccamp; [email-masked]; [email-masked]
Subject: [mpls-tp] Poll for MPLS-TP documents to become mpls working
groupdocuments

Working group(s)

we have four documents from the MPLS-TP effort that the authors think
are ready to become working group documents. The documents are listed
below.

This mail initiate a two week working poll for comments on three of the
documents, for the fourth document
(draft-bocci-mpls-tp-gach-gal-00.txt) we already have an ongoing poll.

Please send your comments before Nov 11 for
draft-bocci-mpls-tp-gach-gal-00.txt and Nov 17 for the other three-

*Note:*
Please send your responses to the *mpls working group mailing list*,
a bit of discipline is needed, "replay all" won't do the trick ;).

Comments Nov 11 the latest:

Title : MPLS Generic Associated Channel
Author(s): M. Vigoureux, M. Bocci, D. Ward, G. Swallow,
R. Aggarwal
Filename : draft-bocci-mpls-tp-gach-gal-00.txt
Pages : 16
Date : 2008-10-27

Comments Nov 17 the latest:

Title : MPLS-TP Requirements
Author(s): B. Niven-Jenkins, et al.
Filename : draft-jenkins-mpls-mpls-tp-requirements-01.txt
Pages : 18
Date : 2008-10-31

Title : A Framework for MPLS in Transport Networks
Author(s): M. Bocci, S. Bryant
Filename : draft-blb-mpls-tp-framework-01.txt
Pages : 27
Date : 2008-10-31

Title : Requirements for OAM in MPLS Transport Networks
Author(s): M. Vigoureux, D. Ward, M. Betts, M. Bocci, I.Busi
Filename : draft-vigoureux-mpls-tp-oam-requirements-01.txt
Pages : 16
Date : 2008-11-1

Loa and George

--=20
Loa Andersson

Principal Networking Architect
Acreo AB phone: +46 8 632 77 14
Isafjordsgatan 22 mobile: +46 739 81 21 64
Kista, Sweden email: [email-masked]
[email-masked]
_______________________________________________
mpls-tp mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/mpls-tp

Envelope-to: [email-masked]
Delivery-date: Mon, 03 Nov 2008 16:45:42 +0000
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="US-ASCII"
Content-Transfer-Encoding: quoted-printable
Subject: RE: Poll for MPLS-TP documents to become mpls working group documents
Date: Mon, 3 Nov 2008 22:13:05 +0530
Message-ID: <[email-masked]>
Thread-Topic: Poll for MPLS-TP documents to become mpls working group documents
thread-index: Ack9vI5OU+9/OWbJRrGHPlXvQ+wV6AAFp9ag
From: "Dutta, Pranjal K \(Pranjal\)"
To: "Loa Andersson" , , "pwe3" , "L2VPN" , "ccamp" , ,

Support for all.

Thanks,
Pranjal=20

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf
Of Loa Andersson
Sent: Monday, November 03, 2008 6:00 AM
To: [email-masked]; pwe3; L2VPN; ccamp; [email-masked]; [email-masked]
Subject: Poll for MPLS-TP documents to become mpls working group
documents

Working group(s)

we have four documents from the MPLS-TP effort that the authors think
are ready to become working group documents. The documents are listed
below.

This mail initiate a two week working poll for comments on three of the
documents, for the fourth document
(draft-bocci-mpls-tp-gach-gal-00.txt) we already have an ongoing poll.

Please send your comments before Nov 11 for
draft-bocci-mpls-tp-gach-gal-00.txt and Nov 17 for the other three-

*Note:*
Please send your responses to the *mpls working group mailing list*, a
bit of discipline is needed, "replay all" won't do the trick ;).

Comments Nov 11 the latest:

Title : MPLS Generic Associated Channel
Author(s): M. Vigoureux, M. Bocci, D. Ward, G. Swallow,
R. Aggarwal
Filename : draft-bocci-mpls-tp-gach-gal-00.txt
Pages : 16
Date : 2008-10-27

Comments Nov 17 the latest:

Title : MPLS-TP Requirements
Author(s): B. Niven-Jenkins, et al.
Filename : draft-jenkins-mpls-mpls-tp-requirements-01.txt
Pages : 18
Date : 2008-10-31

Title : A Framework for MPLS in Transport Networks
Author(s): M. Bocci, S. Bryant
Filename : draft-blb-mpls-tp-framework-01.txt
Pages : 27
Date : 2008-10-31

Title : Requirements for OAM in MPLS Transport Networks
Author(s): M. Vigoureux, D. Ward, M. Betts, M. Bocci, I.Busi
Filename : draft-vigoureux-mpls-tp-oam-requirements-01.txt
Pages : 16
Date : 2008-11-1

Loa and George

--
Loa Andersson

Principal Networking Architect
Acreo AB phone: +46 8 632 77 14
Isafjordsgatan 22 mobile: +46 739 81 21 64
Kista, Sweden email: [email-masked]
[email-masked]

Envelope-to: [email-masked]
Delivery-date: Mon, 03 Nov 2008 16:01:09 +0000
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Subject: RE: [mpls] Poll for MPLS-TP documents to become mpls working groupdocuments
Date: Mon, 3 Nov 2008 09:59:55 -0600
Message-ID: <[email-masked]>
Thread-Topic: [mpls] Poll for MPLS-TP documents to become mpls working groupdocuments
Thread-Index: Ack9vM/bULPCz8SJTFOBGgynqGwEfAAEGBrA
From: "AISSAOUI Mustapha"
To: "Loa Andersson" , , "pwe3" , "L2VPN" , "ccamp" , ,

support all.

Mustapha.=20

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On=20
> Behalf Of Loa Andersson
> Sent: Monday, November 03, 2008 9:00 AM
> To: [email-masked]; pwe3; L2VPN; ccamp; [email-masked];=20
> [email-masked]
> Subject: [mpls] Poll for MPLS-TP documents to become mpls=20
> working groupdocuments
>=20
> Working group(s)
>=20
> we have four documents from the MPLS-TP effort that the=20
> authors think are ready to become working group documents.=20
> The documents are listed below.
>=20
> This mail initiate a two week working poll for comments on=20
> three of the documents, for the fourth document
> (draft-bocci-mpls-tp-gach-gal-00.txt) we already have an ongoing poll.
>=20
> Please send your comments before Nov 11 for=20
> draft-bocci-mpls-tp-gach-gal-00.txt and Nov 17 for the other three-
>=20
> *Note:*
> Please send your responses to the *mpls working group mailing=20
> list*, a bit of discipline is needed, "replay all" won't do=20
> the trick ;).
>=20
> Comments Nov 11 the latest:
>=20
> Title : MPLS Generic Associated Channel
> Author(s): M. Vigoureux, M. Bocci, D. Ward, G. Swallow,
> R. Aggarwal
> Filename : draft-bocci-mpls-tp-gach-gal-00.txt
> Pages : 16
> Date : 2008-10-27
>=20
>=20
> Comments Nov 17 the latest:
>=20
> Title : MPLS-TP Requirements
> Author(s): B. Niven-Jenkins, et al.
> Filename : draft-jenkins-mpls-mpls-tp-requirements-01.txt
> Pages : 18
> Date : 2008-10-31
>=20
> Title : A Framework for MPLS in Transport Networks
> Author(s): M. Bocci, S. Bryant
> Filename : draft-blb-mpls-tp-framework-01.txt
> Pages : 27
> Date : 2008-10-31
>=20
> Title : Requirements for OAM in MPLS Transport Networks
> Author(s): M. Vigoureux, D. Ward, M. Betts, M. Bocci, I.Busi
> Filename : draft-vigoureux-mpls-tp-oam-requirements-01.txt
> Pages : 16
> Date : 2008-11-1
>=20
> Loa and George
>=20
> --
> Loa Andersson
>=20
> Principal Networking Architect
> Acreo AB phone: +46 8 632 77 14
> Isafjordsgatan 22 mobile: +46 739 81 21 64
> Kista, Sweden email: [email-masked]
> [email-masked]=20
> _______________________________________________
> mpls mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/mpls
>=20

Envelope-to: [email-masked]
Delivery-date: Mon, 03 Nov 2008 15:49:11 +0000
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Subject: RE: [mpls] Poll for MPLS-TP documents to become mpls working groupdocuments
Date: Mon, 3 Nov 2008 10:47:50 -0500
Message-ID:
Thread-Topic: [mpls] Poll for MPLS-TP documents to become mpls working groupdocuments
Thread-Index: Ack9vMqvzRuqx0AQToiUtY5hN6mruwACtm2w
From: "Zafar Ali (zali)"
To: "Loa Andersson" , , "pwe3" , "L2VPN" , "ccamp" , ,
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=2541; t=1225727307; x=1226591307; c=relaxed/simple; s=rtpdkim1001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=[email-masked]; z=From:=20=22Zafar=20Ali=20(zali)=22=20 |Subject:=20RE=3A=20[mpls]=20Poll=20for=20MPLS-TP=20documen ts=20to=20become=20mpls=20working=20groupdocuments |Sender:=20 |To:=20=22Loa=20Andersson=22=20,=20,=20=22pwe3=22=20,=0A=20=20=20=20=20=20=20= 20=22L2VPN=22=20,=20=22ccamp=22=20,=0A=20=20=20=20=20=20=20=20,=20< [email-masked]>; bh=dSJ0yOw52Vw8rXs75LMFQ8YiUwKPlN+ZW3lKtYHpjZc=; b=Bf0MRjQ7JZHF6Aanj3VqKvjH7n4FieBVCcBjYh4RF6jiPiZGtIDSaQ9tg9 UM8mWwDSp1GMSh+R7rO7L5F/Cwe0dcqDNvPahz1Xtmi6wY6nARQv+JXUwdB5 1V3yPHb+uQ;
Authentication-Results: rtp-dkim-1; header.From=[email-masked]; dkim=pass ( sig from cisco.com/rtpdkim1001 verified; );

Hi Loa-=20

In favor for all drafts to become WG docs.=20

Thanks

Regards... Zafar=20

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On=20
> Behalf Of Loa Andersson
> Sent: Monday, November 03, 2008 9:00 AM
> To: [email-masked]; pwe3; L2VPN; ccamp; [email-masked];=20
> [email-masked]
> Subject: [mpls] Poll for MPLS-TP documents to become mpls=20
> working groupdocuments
>=20
> Working group(s)
>=20
> we have four documents from the MPLS-TP effort that the=20
> authors think are ready to become working group documents.=20
> The documents are listed below.
>=20
> This mail initiate a two week working poll for comments on=20
> three of the documents, for the fourth document
> (draft-bocci-mpls-tp-gach-gal-00.txt) we already have an ongoing poll.
>=20
> Please send your comments before Nov 11 for=20
> draft-bocci-mpls-tp-gach-gal-00.txt and Nov 17 for the other three-
>=20
> *Note:*
> Please send your responses to the *mpls working group mailing=20
> list*, a bit of discipline is needed, "replay all" won't do=20
> the trick ;).
>=20
> Comments Nov 11 the latest:
>=20
> Title : MPLS Generic Associated Channel
> Author(s): M. Vigoureux, M. Bocci, D. Ward, G. Swallow,
> R. Aggarwal
> Filename : draft-bocci-mpls-tp-gach-gal-00.txt
> Pages : 16
> Date : 2008-10-27
>=20
>=20
> Comments Nov 17 the latest:
>=20
> Title : MPLS-TP Requirements
> Author(s): B. Niven-Jenkins, et al.
> Filename : draft-jenkins-mpls-mpls-tp-requirements-01.txt
> Pages : 18
> Date : 2008-10-31
>=20
> Title : A Framework for MPLS in Transport Networks
> Author(s): M. Bocci, S. Bryant
> Filename : draft-blb-mpls-tp-framework-01.txt
> Pages : 27
> Date : 2008-10-31
>=20
> Title : Requirements for OAM in MPLS Transport Networks
> Author(s): M. Vigoureux, D. Ward, M. Betts, M. Bocci, I.Busi
> Filename : draft-vigoureux-mpls-tp-oam-requirements-01.txt
> Pages : 16
> Date : 2008-11-1
>=20
> Loa and George
>=20
> --
> Loa Andersson
>=20
> Principal Networking Architect
> Acreo AB phone: +46 8 632 77 14
> Isafjordsgatan 22 mobile: +46 739 81 21 64
> Kista, Sweden email: [email-masked]
> [email-masked]=20
> _______________________________________________
> mpls mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/mpls
>=20

Envelope-to: [email-masked]
Delivery-date: Mon, 03 Nov 2008 15:12:04 +0000
Message-ID: <955F6D91F9074267920C29ABF7E129EE@your029b8cecfe>
Reply-To: "Adrian Farrel"
From: "Adrian Farrel"
To:
Subject: Draft agenda
Date: Mon, 3 Nov 2008 15:10:44 -0000
MIME-Version: 1.0
Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original
Content-Transfer-Encoding: 7bit

Hi,

Based on requests received and a few additional things we think ought to be
covered, we have put together a DRAFT agenda which you can see at
http://www.ietf.org/proceedings/08nov/agenda/ccamp.htm

Comments please.

Thanks,
Adrian and Deborah

Envelope-to: [email-masked]
Delivery-date: Mon, 03 Nov 2008 14:03:15 +0000
Message-ID: <[email-masked]>
Date: Mon, 03 Nov 2008 14:59:50 +0100
From: Loa Andersson
User-Agent: Thunderbird 2.0.0.17 (Windows/20080914)
MIME-Version: 1.0
To: "[email-masked]" , pwe3 , L2VPN , ccamp , "[email-masked]" , "[email-masked]"
Subject: Poll for MPLS-TP documents to become mpls working group documents
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit

Working group(s)

we have four documents from the MPLS-TP effort that the authors think
are ready to become working group documents. The documents are listed below.

This mail initiate a two week working poll for comments on three of the
documents, for the fourth document
(draft-bocci-mpls-tp-gach-gal-00.txt) we already have an ongoing poll.

Please send your comments before Nov 11 for
draft-bocci-mpls-tp-gach-gal-00.txt and Nov 17 for the other three-

*Note:*
Please send your responses to the *mpls working group mailing list*,
a bit of discipline is needed, "replay all" won't do the trick ;).

Comments Nov 11 the latest:

Title : MPLS Generic Associated Channel
Author(s): M. Vigoureux, M. Bocci, D. Ward, G. Swallow,
R. Aggarwal
Filename : draft-bocci-mpls-tp-gach-gal-00.txt
Pages : 16
Date : 2008-10-27

Comments Nov 17 the latest:

Title : MPLS-TP Requirements
Author(s): B. Niven-Jenkins, et al.
Filename : draft-jenkins-mpls-mpls-tp-requirements-01.txt
Pages : 18
Date : 2008-10-31

Title : A Framework for MPLS in Transport Networks
Author(s): M. Bocci, S. Bryant
Filename : draft-blb-mpls-tp-framework-01.txt
Pages : 27
Date : 2008-10-31

Title : Requirements for OAM in MPLS Transport Networks
Author(s): M. Vigoureux, D. Ward, M. Betts, M. Bocci, I.Busi
Filename : draft-vigoureux-mpls-tp-oam-requirements-01.txt
Pages : 16
Date : 2008-11-1

Loa and George

--
Loa Andersson

Principal Networking Architect
Acreo AB phone: +46 8 632 77 14
Isafjordsgatan 22 mobile: +46 739 81 21 64
Kista, Sweden email: [email-masked]
[email-masked]

Envelope-to: [email-masked]
Delivery-date: Mon, 03 Nov 2008 00:32:06 +0000
From: [email-masked]
To: [email-masked]
Cc: [email-masked]
Subject: I-D Action:draft-ietf-ccamp-confirm-data-channel-status-02.txt
Content-Type: Multipart/Mixed; Boundary="NextPart"
Mime-Version: 1.0
Message-Id: <[email-masked]>
Date: Sun, 2 Nov 2008 16:30:01 -0800 (PST)

--NextPart

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Common Control and Measurement Plane Working Group of the IETF.

Title : Data Channel Status Confirmation Extensions for the Link Management Protocol
Author(s) : D. Li, et al.
Filename : draft-ietf-ccamp-confirm-data-channel-status-02.txt
Pages : 15
Date : 2008-11-02

This document defines simple additions to the Link Management
Protocol (LMP) to provide a control plane tool that can assist in
the location of stranded resources by allowing adjacent LSRs to
confirm data channel statuses, and provides triggers for notifying
the management plane if any discrepancies are found.

Conventions used in this document

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119].

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-ccamp-confirm-data-channel-status-02.txt

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

--NextPart
Content-Type: Message/External-body;
name="draft-ietf-ccamp-confirm-data-channel-status-02.txt";
site="ftp.ietf.org";
access-type="anon-ftp";
directory="internet-drafts"

Content-Type: text/plain
Content-ID: <[email-masked]>

--NextPart--

Envelope-to: [email-masked]
Delivery-date: Sun, 02 Nov 2008 19:04:57 +0000
Message-ID: <382FB452E844407982AC4889177536B7@your029b8cecfe>
Reply-To: "Adrian Farrel"
From: "Adrian Farrel"
To: "PAPADIMITRIOU Dimitri" ,
Subject: Re: MRN ext. doc
Date: Sun, 2 Nov 2008 19:03:41 -0000
MIME-Version: 1.0
Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original
Content-Transfer-Encoding: 7bit

Hello again,

>>>>>> Section 4 appears to consider only the mapped server model
>>>>>> (allowing a many to one mapping), but not the multiplexed
>>>>>> server model. Is it the intention to defer this to Section 5?
>>>>>
>>>>> i don't understand the question.
>>>>
>>>> Hmm. I'm using ITU terminology.

[SNIP]

>>> can u please use the ietf terminology at least to make the point
>>> understandable to me (excuse my ignorance). what is a mapped
>>> server ?
>>
>> OK. Well, I did try to explain in my previous response.

[SNIP]

> ok, i think i barely understood where you are heading at. now what is
> the issue with the doc. ? honnestly, i do not catch the point you are
> trying to make: section 4 addresses purely signaling procedure issue
> (complements existing FA triggering/selection rules) and section 5 a
> well-known TE problem that is how to attract traffic when no bearer is
> setup (it is a particular case of the generic unknown adjcacency
> problem).

I didn't actually say there was anything wrong with the document :-)
I just asked what I hoped was a simple question.

>From our discussion it looks like the answer to my question was "yes". Let's
move on.

>>>>>> ===
>>>>>> The Call-Attributes object C-Num is picked from the 11bbbbbb
>>>>>> class. Why?
>>>>>> Surely if any node that processes the Notify message does not
>>>>>> understand the object, you want the Call to fail.
>>>>>
>>>>> this what has been agreed from last meeting. see Lou's preso.
>>>>
>>>> It doesn't make sense to use 11bbbbbb.

[SNIP]

>>> not sure. at the end the question is an attribute object class a
>>> criteria for which rejection is expected. going one step
>>> further one can mandate support of the class but it is the
>>> support of the associated capability that matters.. one would
>>> be still blocking on the latter anyway if that capability would
>>> not be supported independently of the object class. so it is
>>> the "mandatory or optional" nature of the attribute that induce
>>> support of the object not the other way around.
>>
>> I spoke to Lou.
>> He had suggested 11bbbbbb because he thought the object might
>> end up on a Path message. However, we don't think this would
>> actually be the case because the call request message is a Notify.
>> So he is more relaxed about this changing to 0bbbbbbb
>
> are call attributes mandatorily associated to calls (and which case
> one could simply mandate support of the related attribute) and their
> messaging/processing a must have feature of the protocol ? ... just to
> be clear 0bbbbbbb does not solve the former.

No, the Call_Attributes object is not mandatory on a Call request message
(as currently defined). And yes, you are right, using 0bbbbbbb would not
make it mandatory anyway.

I am *only* concerned by how the call recipient will process the Notify, how
(if?) they will respond, and whether this will waste processing in the
network, especially at the call recipient.

>>>>>> ===
>>>>>> I'm puzzled that the Call described in section 5.1 does not
>>>>>> indicate to the intended LSP egress in which layer or
>>>>>> region the soon-to-be-set-up LSP will be required to
>>>>>> operate.

[SNIP]

>>>> I meant...
>>>> Suppose the head and tail of the planned virtual TE link are
>>>> present in three regions (or layers, don't forget layers). One
>>>> is the client, and two are potential servers.
>>>> Shouldn't the call indicate which server the caller
>>>> wishes/intends to use?
>>>
>>> assume a base virtual TE link [PSC,PSC] and the two link
>>> sequence that can be followed by the FA-LSP are either
>>> [PSC,LSC]..[LSC,LSC]..[LSC,PSC] or [PSC,TDM..[TDM,
>>> TDM]..[TDM,PSC] it is the association between the TE
>>> link and LSP that determines to which FA that TE link is
>>> now related to
>>
>> I agree completely.
>> And that was my point.
>> The call is a negotiation between end points about what
>> connection will be set up, what adaptions will be applied,
>> and what TE link will be created.
>> This effectively requires the call request to state the set
>> of potential adaptations, and the call response to identify
>> the subset of acceptable adaptations. The connection can
>> then be signaled in the correct switching type, and the
>> resulting LSP can be associated to the TE link.
>
> per 4974, the LINK_CAPABILITY object can be used for
> this purpose with subobject Type 65.
>
> i did not mention it for two reasons a) it is implicit in the
> context (a Virtual Link by definition addresses the lowest SC
> value) and b) part of the procedure referenced by this doc.

Weeeeell...

That use of Link Capability is not particularly clear in RFC 4974.

According to section 4.3.3. of RFC 4974 this function allows the call
initiator to list a set of switching capablities for links that connect it
"to the network", and for the responder to reduce the list to those
switching capablities that it supports.

That is only half the function required.

We also need to let the call responder know that we intend using the LSP to
support a connection in a particular client layer/region. In other words, we
have to specify what adaptation function we want the responder to support.

It would be enough to add to the information already carried in the
Link_Capablity object the link capability we intend to create. This could go
in either the Link_Capablity object or in the Call_Attributes object.

Oh, by the way, Link_Capability uses a CNum of type 0bbbbbb

A

Envelope-to: [email-masked]
Delivery-date: Sun, 02 Nov 2008 18:26:46 +0000
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Subject: RE: MRN ext. doc
Date: Sun, 2 Nov 2008 19:24:05 +0100
Message-ID: <[email-masked]>
Thread-Topic: MRN ext. doc
Thread-Index: Ack9D7yCOPB7Oj16RRmWxD55Lc9zfgAAXFgg
From: "PAPADIMITRIOU Dimitri"
To: "Adrian Farrel" ,

=20
Hi adrian,

> -----Original Message-----
> From: Adrian Farrel [mailto:[email-masked]]=20
> Sent: Sunday, November 02, 2008 6:23 PM
> To: PAPADIMITRIOU Dimitri; [email-masked]
> Subject: Re: MRN ext. doc
>=20
> Hi Dimitri,
>=20
> >>>> =3D=3D=3D
> >>>> We will definitely (well, very probably) be asked if we can show
> >>>> traceability back to the requirements. In fact, RFC 5339
> >>>> includes section
> >>>> 4.1 that gives traceability from the evaluation back to the
> >>>> requirements.
> >>>> Section 2 of this document does not quite give the same level of
> >>>> traceability such that it is necessary to read most of 5339
> >>>> to ensure that all requirements have been met.
> >>>
> >>> the current doc. covers the "delta" in terms of mechanism.
> >>> so, do you mean that mechanisms not requiring any extensions
> >>> shall also be included/described in this document ?
> >>
> >> Nope.
> >> Simply that the I-D should explicitly call out the lacunae
> >> identified in RFC 5339.
> >> For example, you could say...
> >> The following features are identified in [RFC5339] as
> >> requiring protocol extensions:
> >> 1. Feature to do something. See Section 1.2.3 of [RFC5339]
> >> 2. ...
> >
> > ok - you would like a ref. to 5339.
>=20
> Yes. But not just a simple ref to the doc, but a ref to each of the=20
> unanswered requirements in 5339

this is what i meant.

> >>>> =3D=3D=3D
> >>>> Section 4 appears to consider only the mapped server model
> >>>> (allowing a many to one mapping), but not the multiplexed
> >>>> server model. Is it the intention to defer this to Section 5?
> >>>
> >>> i don't understand the question.
> >>
> >> Hmm. I'm using ITU terminology.
> >>
> >> Mapped server has a connection set up in the server layer "on
> >> demand" with only the bandwidth required by the client layer
> >> connection.
> >>
> >> Many-to-one mapped server allows that the server connection
> >> set up for a previous client layer connection may have "spare"
> >> bandwidth that can be allocated ("on demand") to support a
> >> further client layer connection.
> >>
> >> Multiplexed server model causes the "spare" bandwidth to be
> >> advertised in the client layer as a link.
> >>
> >> My question was trying to understand how the required
> >> function was split between the two sections 4 and 5.
> >
> > can u please use the ietf terminology at least to make the point
> > understandable to me (excuse my ignorance). what is a mapped
> > server ?
>=20
> OK. Well, I did try to explain in my previous response.
>=20
> In the mapped server model, a connection in used in the=20
> server layer/region=20
> in response to a specific demand for end-to-end connectivity=20
> in the client=20
> layer/region. In most cases, the server connection is created=20
> on-demand when=20
> the client connection request reaches the layer boundary. The client=20
> connection is "mapped" to the server connection using the adaptation=20
> function at the boundary node to provide continuous=20
> end-to-end connectivity.=20
> The server connection is not made into a link in the client=20
> layer/region=20
> because its purpose is only to server the current client=20
> connection. When=20
> the client connection is torn down, the server connection=20
> will normally be=20
> torn down as well.
>=20
> The many-to-one mapped server case is initiated in the same=20
> way, but it may=20
> be that it is actually possible to map more than one client=20
> connection to=20
> the server connection (effectively there is multiplexing in=20
> the adaptation=20
> function). However, since the server connection is not=20
> advertised as a link=20
> in the client layer/region, the second client connection to=20
> be requested=20
> behaves exactly the same except that the border node can=20
> (before setting up=20
> a new on-demand server connection) note that there is=20
> available capacity on=20
> an existing server connection and use that.
>=20
> I suppose that the mapped server cases equate to the creation=20
> of a data link=20
> that is not advertised (i.e. remains as a local client=20
> layer/region link=20
> across the server layer/region). The case where a TE link is=20
> created and=20
> advertised equates to the ITU's Multiplexed Server model.

ok, i think i barely understood where you are heading at. now what is
the issue with the doc. ? honnestly, i do not catch the point you are
trying to make: section 4 addresses purely signaling procedure issue
(complements existing FA triggering/selection rules) and section 5 a
well-known TE problem that is how to attract traffic when no bearer is
setup (it is a particular case of the generic unknown adjcacency
problem).

> >>>> The Call-Attributes object C-Num is picked from the 11bbbbbb
> >>>> class. Why?
> >>>> Surely if any node that processes the Notify message does not
> >>>> understand the object, you want the Call to fail.
> >>>
> >>> this what has been agreed from last meeting. see Lou's preso.
> >>
> >> Well, it's wrong! :-)
> >>
> >> It doesn't make sense to use 11bbbbbb.
> >> Consider that you are using a Notify message that is
> >> targetted. Therefore, the first node to process the
> >> Notify message is the intended end point of
> >> the call, or a deliberate transit call controller. That
> >> means that we require the recipient to be able to
> >> process the object.
> >> Furthermore, there is nowhere for the message to be
> >> forwarded if the object is not understood.
> >
> > not sure. at the end the question is an attribute object class a
> > criteria for which rejection is expected. going one step=20
> further one can
> > mandate support of the class but it is the support of the associated
> > capability that matters.. one would be still blocking on the latter
> > anyway if that capability would not be supported=20
> independently of the
> > object class. so it is the "mandatory or optional" nature of the
> > attribute that induce support of the object not the other=20
> way around.
>=20
> I spoke to Lou.
> He had suggested 11bbbbbb because he thought the object might=20
> end up on a=20
> Path message. However, we don't think this would actually be the case=20
> because the call request message is a Notify.
> So he is more relaxed about this changing to 0bbbbbbb

are call attributes mandatorily associated to calls (and which case one
could simply mandate support of the related attribute) and their
messaging/processing a must have feature of the protocol ? ... just to
be clear 0bbbbbbb does not solve the former.

> >> The special case of a Notify that is forwarded hop-by-hop
> >> does not require that the Call-Attributes object is processed
> >> since transit nodes "just forward the Notify message to the
> >> target node" without looking at the contents.
> >>
> >> We should use 0bbbbbbb
>=20
> >>>> =3D=3D=3D
> >>>> I'm puzzled that the Call described in section 5.1 does not
> >>>> indicate to the intended LSP egress in which layer or
> >>>> region the soon-to-be-set-up LSP will be required to
> >>>> operate.
> >>>
> >>> because
> >>>
> >>> - it is the FA setup that indicates to which bearer the virtual
> >>> link will be associated not the other way around
> >>>
> >>> - the virtual association is used by upper-region LSP so the
> >>> virtual link itself is an abstraction of the bearer/network (in
> >>> other terms - and by definition - one does not create Virtual
> >>> TE links over Virtual TE links)
> >>>
> >>> the only condition which can be verified from the TEDB is=20
> that both
> >>> ends of the bearer belongs to the same LSP region (symmetry).
> >>
> >> I meant...
> >> Suppose the head and tail of the planned virtual TE link are
> >> present in three regions (or layers, don't forget layers). One
> >> is the client, and two are potential servers.
> >> Shouldn't the call indicate which server the caller
> >> wishes/intends to use?
> >
> > assume a base virtual TE link [PSC,PSC] and the two link=20
> sequence that
> > can be followed by the FA-LSP are either=20
> [PSC,LSC]..[LSC,LSC]..[LSC,PSC]
> > or [PSC,TDM..[TDM,TDM]..[TDM,PSC] it is the association=20
> between the TE
> > link and LSP that determines to which FA that TE link is=20
> now related to
>=20
> I agree completely.
> And that was my point.
> The call is a negotiation between end points about what=20
> connection will be=20
> set up, what adaptions will be applied, and what TE link will=20
> be created.=20
> This effectively requires the call request to state the set=20
> of potential=20
> adaptations, and the call response to identify the subset of=20
> acceptable=20
> adaptations. The connection can then be signaled in the=20
> correct switching=20
> type, and the resulting LSP can be associated to the TE link.

per 4974, the LINK_CAPABILITY object can be used for this purpose with
subobject Type 65.=20

i did not mention it for two reasons a) it is implicit in the context (a
Virtual Link by definition addresses the lowest SC value) and b) part of
the procedure referenced by this doc.

> >>>> =3D=3D=3D
> >>>> I don't find section 3.2.1 clear on the co-existence within
> >>>> the Link TLV of the IACD sub-TLV and the ISCD sub-
> >>>> TLV [RFC4203].
> >>>
> >>> i will add a statement IACD does not modify format/messaging and
> >>> processing associated to the ISCD.
> >>
> >> Thanks.
> >>
> >> Now since there is an aggregate duplication of information
> >
> > where do you see the "duplication" of information b/w IACD=20
> and ISCD ?
>=20
> Well, in the ISCD I see a list of bandwidths available per priority.
> In the IACD I see a list of bandwidths available per priority.
>=20
> Clearly there is some relationship between these numbers=20
> because they refer=20
> to the same advertised link.
>=20
> I don't suppose that the sum of the priority 1 bandwidths for=20
> all IACDs is=20
> supposed to equal the advertised priority 1 bandwidth from=20
> the ISCD. But if=20
> the priority 1 bandwidths for one IACD was larger than that=20
> for the ISCD it=20
> would be strange (meaningless?).
>=20
> There is not a direct duplication of information, but there=20
> is some overlap=20
> of information and I am asking how it is resolved.

there is no overlap of information too. the IACD is a mean to advertize
adjustment capacity between two SC (so, by def. internal) that would
otherwise be unknown and thus result in LSP blocking when crossing that
LSR. i can give certain base rules of thumb for setting up values of
IACD and its accounting (that is similar per nature to current Max LSP
Bw) as part of the next revision but this is not going to prevent
mis-configuration and/or misuse.

-d.
> A=20
>=20
>=20

Envelope-to: [email-masked]
Delivery-date: Sun, 02 Nov 2008 17:26:26 +0000
Message-ID:
Reply-To: "Adrian Farrel"
From: "Adrian Farrel"
To: "PAPADIMITRIOU Dimitri" ,
Subject: Re: MRN ext. doc
Date: Sun, 2 Nov 2008 17:23:23 -0000
MIME-Version: 1.0
Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original
Content-Transfer-Encoding: 7bit

Hi Dimitri,

>>>> ===
>>>> We will definitely (well, very probably) be asked if we can show
>>>> traceability back to the requirements. In fact, RFC 5339
>>>> includes section
>>>> 4.1 that gives traceability from the evaluation back to the
>>>> requirements.
>>>> Section 2 of this document does not quite give the same level of
>>>> traceability such that it is necessary to read most of 5339
>>>> to ensure that all requirements have been met.
>>>
>>> the current doc. covers the "delta" in terms of mechanism.
>>> so, do you mean that mechanisms not requiring any extensions
>>> shall also be included/described in this document ?
>>
>> Nope.
>> Simply that the I-D should explicitly call out the lacunae
>> identified in RFC 5339.
>> For example, you could say...
>> The following features are identified in [RFC5339] as
>> requiring protocol extensions:
>> 1. Feature to do something. See Section 1.2.3 of [RFC5339]
>> 2. ...
>
> ok - you would like a ref. to 5339.

Yes. But not just a simple ref to the doc, but a ref to each of the
unanswered requirements in 5339

>>>> ===
>>>> Section 4 appears to consider only the mapped server model
>>>> (allowing a many to one mapping), but not the multiplexed
>>>> server model. Is it the intention to defer this to Section 5?
>>>
>>> i don't understand the question.
>>
>> Hmm. I'm using ITU terminology.
>>
>> Mapped server has a connection set up in the server layer "on
>> demand" with only the bandwidth required by the client layer
>> connection.
>>
>> Many-to-one mapped server allows that the server connection
>> set up for a previous client layer connection may have "spare"
>> bandwidth that can be allocated ("on demand") to support a
>> further client layer connection.
>>
>> Multiplexed server model causes the "spare" bandwidth to be
>> advertised in the client layer as a link.
>>
>> My question was trying to understand how the required
>> function was split between the two sections 4 and 5.
>
> can u please use the ietf terminology at least to make the point
> understandable to me (excuse my ignorance). what is a mapped
> server ?

OK. Well, I did try to explain in my previous response.

In the mapped server model, a connection in used in the server layer/region
in response to a specific demand for end-to-end connectivity in the client
layer/region. In most cases, the server connection is created on-demand when
the client connection request reaches the layer boundary. The client
connection is "mapped" to the server connection using the adaptation
function at the boundary node to provide continuous end-to-end connectivity.
The server connection is not made into a link in the client layer/region
because its purpose is only to server the current client connection. When
the client connection is torn down, the server connection will normally be
torn down as well.

The many-to-one mapped server case is initiated in the same way, but it may
be that it is actually possible to map more than one client connection to
the server connection (effectively there is multiplexing in the adaptation
function). However, since the server connection is not advertised as a link
in the client layer/region, the second client connection to be requested
behaves exactly the same except that the border node can (before setting up
a new on-demand server connection) note that there is available capacity on
an existing server connection and use that.

I suppose that the mapped server cases equate to the creation of a data link
that is not advertised (i.e. remains as a local client layer/region link
across the server layer/region). The case where a TE link is created and
advertised equates to the ITU's Multiplexed Server model.

>>>> The Call-Attributes object C-Num is picked from the 11bbbbbb
>>>> class. Why?
>>>> Surely if any node that processes the Notify message does not
>>>> understand the object, you want the Call to fail.
>>>
>>> this what has been agreed from last meeting. see Lou's preso.
>>
>> Well, it's wrong! :-)
>>
>> It doesn't make sense to use 11bbbbbb.
>> Consider that you are using a Notify message that is
>> targetted. Therefore, the first node to process the
>> Notify message is the intended end point of
>> the call, or a deliberate transit call controller. That
>> means that we require the recipient to be able to
>> process the object.
>> Furthermore, there is nowhere for the message to be
>> forwarded if the object is not understood.
>
> not sure. at the end the question is an attribute object class a
> criteria for which rejection is expected. going one step further one can
> mandate support of the class but it is the support of the associated
> capability that matters.. one would be still blocking on the latter
> anyway if that capability would not be supported independently of the
> object class. so it is the "mandatory or optional" nature of the
> attribute that induce support of the object not the other way around.

I spoke to Lou.
He had suggested 11bbbbbb because he thought the object might end up on a
Path message. However, we don't think this would actually be the case
because the call request message is a Notify.
So he is more relaxed about this changing to 0bbbbbbb

>> The special case of a Notify that is forwarded hop-by-hop
>> does not require that the Call-Attributes object is processed
>> since transit nodes "just forward the Notify message to the
>> target node" without looking at the contents.
>>
>> We should use 0bbbbbbb

>>>> ===
>>>> I'm puzzled that the Call described in section 5.1 does not
>>>> indicate to the intended LSP egress in which layer or
>>>> region the soon-to-be-set-up LSP will be required to
>>>> operate.
>>>
>>> because
>>>
>>> - it is the FA setup that indicates to which bearer the virtual
>>> link will be associated not the other way around
>>>
>>> - the virtual association is used by upper-region LSP so the
>>> virtual link itself is an abstraction of the bearer/network (in
>>> other terms - and by definition - one does not create Virtual
>>> TE links over Virtual TE links)
>>>
>>> the only condition which can be verified from the TEDB is that both
>>> ends of the bearer belongs to the same LSP region (symmetry).
>>
>> I meant...
>> Suppose the head and tail of the planned virtual TE link are
>> present in three regions (or layers, don't forget layers). One
>> is the client, and two are potential servers.
>> Shouldn't the call indicate which server the caller
>> wishes/intends to use?
>
> assume a base virtual TE link [PSC,PSC] and the two link sequence that
> can be followed by the FA-LSP are either [PSC,LSC]..[LSC,LSC]..[LSC,PSC]
> or [PSC,TDM..[TDM,TDM]..[TDM,PSC] it is the association between the TE
> link and LSP that determines to which FA that TE link is now related to

I agree completely.
And that was my point.
The call is a negotiation between end points about what connection will be
set up, what adaptions will be applied, and what TE link will be created.
This effectively requires the call request to state the set of potential
adaptations, and the call response to identify the subset of acceptable
adaptations. The connection can then be signaled in the correct switching
type, and the resulting LSP can be associated to the TE link.

>>>> ===
>>>> I don't find section 3.2.1 clear on the co-existence within
>>>> the Link TLV of the IACD sub-TLV and the ISCD sub-
>>>> TLV [RFC4203].
>>>
>>> i will add a statement IACD does not modify format/messaging and
>>> processing associated to the ISCD.
>>
>> Thanks.
>>
>> Now since there is an aggregate duplication of information
>
> where do you see the "duplication" of information b/w IACD and ISCD ?

Well, in the ISCD I see a list of bandwidths available per priority.
In the IACD I see a list of bandwidths available per priority.

Clearly there is some relationship between these numbers because they refer
to the same advertised link.

I don't suppose that the sum of the priority 1 bandwidths for all IACDs is
supposed to equal the advertised priority 1 bandwidth from the ISCD. But if
the priority 1 bandwidths for one IACD was larger than that for the ISCD it
would be strange (meaningless?).

There is not a direct duplication of information, but there is some overlap
of information and I am asking how it is resolved.

A

Envelope-to: [email-masked]
Delivery-date: Sat, 01 Nov 2008 21:02:53 +0000
From: [email-masked]
To: [email-masked]
Cc: [email-masked]
Subject: I-D ACTION:draft-ietf-ccamp-path-key-ero-02.txt
Content-Type: Multipart/Mixed; Boundary="NextPart"
Mime-Version: 1.0
Message-Id: <[email-masked]>
Date: Sat, 1 Nov 2008 14:00:01 -0700 (PDT)

--NextPart

A New Internet-Draft is available from the on-line Internet-Drafts
directories.
This draft is a work item of the Common Control and Measurement Plane Working Group of the IETF.

Title : RSVP Extensions for Path Key Support
Author(s) : R. Bradford, J. Vasseur, A. Farrel
Filename : draft-ietf-ccamp-path-key-ero-02.txt
Pages : 14
Date : 2008-11-1

The paths taken by Multiprotocol Label Switching (MPLS) and
Generalized MPLS (GMPLS) Traffic Engineering (TE) Label Switched
Paths (LSPs) may be computed by Path Computation Elements (PCEs).
Where the TE LSP crosses multiple domains, such as Autonomous Systems
(ASes), the path may be computed by multiple PCEs that cooperate,
with each responsible for computing a segment of the path.

To preserve confidentiality of topology within each AS, the PCEs
support a mechanism to hide the contents of a segment of a path (such
as the segment of the path that traverses an AS), called the
Confidential Path Segment (CPS), by encoding the contents as a Path
Key Subobject (PKS) and embedding this subobject within the result of
its path computation.

This document describes how to carry Path Key Subobjects in the
Resource Reservation Protocol (RSVP) Explicit Route Objects (EROs)
and Record Route Object (RROs) so as to facilitate confidentiality in
the signaling of inter-domain TE LSPs.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-ccamp-path-key-ero-02.txt

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

--NextPart
Content-Type: Message/External-body;
name="draft-ietf-ccamp-path-key-ero-02.txt";
site="ftp.ietf.org";
access-type="anon-ftp";
directory="internet-drafts"

Content-Type: text/plain
Content-ID: <[email-masked]>

--NextPart--

Envelope-to: [email-masked]
Delivery-date: Sat, 01 Nov 2008 21:02:30 +0000
From: [email-masked]
To: [email-masked]
Cc: [email-masked]
Subject: I-D ACTION:draft-ietf-ccamp-ethernet-traffic-parameters-06.txt
Content-Type: Multipart/Mixed; Boundary="NextPart"
Mime-Version: 1.0
Message-Id: <[email-masked]>
Date: Sat, 1 Nov 2008 14:00:01 -0700 (PDT)

--NextPart

A New Internet-Draft is available from the on-line Internet-Drafts
directories.
This draft is a work item of the Common Control and Measurement Plane Working Group of the IETF.

Title : Ethernet Traffic Parameters
Author(s) : D. Papadimitriou, I. Property
Filename : draft-ietf-ccamp-ethernet-traffic-parameters-06.txt
Pages : 13
Date : 2008-11-1

This document describes the Metro Ethernet Forum (MEF) - specific
Ethernet Traffic Parameters as described in MEF10.1 when using
Generalized Multi-Protocol Label Switching (GMPLS) Resource
ReSerVation Protocol - Traffic Engineering (RSVP-TE) signaling.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-ccamp-ethernet-traffic-parameters-06.txt

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

--NextPart
Content-Type: Message/External-body;
name="draft-ietf-ccamp-ethernet-traffic-parameters-06.txt";
site="ftp.ietf.org";
access-type="anon-ftp";
directory="internet-drafts"

Content-Type: text/plain
Content-ID: <[email-masked]>

--NextPart--