Subject: [Mpls-interop] [Fwd: (Forward to attendees) Meeting invitation: MEAD]

From: Stewart Bryant <[email-masked]>
Date: Sat, 28 Feb 2009 07:40:31 +0000

I am not sure whether you will also get this direct from the tool, but 
better two copies than none.

Stewart

Subject: (Forward to attendees) Meeting invitation: MEAD
From: Stewart Bryant <[email-masked]>
To: [email-masked]
Date: Sat, 28 Feb 2009 07:38:25 GMT

**** You can forward this email invitation to attendees **** 

Hello ,

Stewart Bryant invites you to attend this online meeting.

Topic: MEAD
Date: Tuesday, March 3, 2009
Time: 5:00 pm, GMT Standard Time (GMT -00:00, London)
Meeting Number: 607 706 291
Meeting Password: mead

Please click the link below to see more information, or to join the meeting.

-------------------------------------------------------
To join the online meeting
-------------------------------------------------------
1. Go to https://ciscosales.webex.com/ciscosales/j.php?ED=10027&UID=0&PW=8dbdfd0938100b
2. Enter your name and email address.
3. Enter the meeting password: mead
4. Click "Join Now".
5. A 'Join Teleconference' dialogue box will be presented, select your country code, then enter your local number and click OK from the Web Conference to join the Voice Conference portion of the meeting.

------------------------------------------------------- 
To join the teleconference only 
------------------------------------------------------- 
1. Dial into Cisco WebEx (view all Global Access Numbers at 
http://cisco.com/en/US/about/doing_business/conferencing/index.html 
2. Press 3 to attend the meeting. 
3. Follow the prompts to enter the Meeting Number (listed above) or Access Code followed by the # sign. 

San Jose, CA: +1.408.525.6800 RTP: +1.919.392.3330 

US/Canada: +1.866.432.9903 United Kingdom: +44.20.8824.0117 

India: +91.80.4103.3979 Germany: +49.619.6773.9002 

Japan: +81.3.5763.9394 China: +86.10.8515.5666 

Toll-free dialing restrictions: http://www.webex.com/pdf/tollfree_restrictions.pdf

------------------------------------------------------- 
Cost Savings Tips and Tricks
-------------------------------------------------------

-  Whenever possible, call the local number (if there is no charge to you). http://www.cisco.com/web/about/doing_business/conferencing/index.html 

-  When using a U.S. cell phone in the United States, always call the local number, otherwise the company is charged twice (once for the minutes and again for the toll-free number). 

-  When staying in a hotel, dial the local number from your cell phone, have the system call you, or use IP Communicator.

-------------------------------------------------------
For assistance
-------------------------------------------------------
1. Go to https://ciscosales.webex.com/ciscosales/mc
2. On the left navigation bar, click "Support".

You can contact me at:
[email-masked]
44-20-8824 8828

To add this meeting to your calendar program (for example Microsoft Outlook), click this link:
https://ciscosales.webex.com/ciscosales/j.php?ED=10027&UID=0&ICS=MI&LD=1&RD=2&ST=1&SHA2=hN/CmP6zzCkpLgvww4WupBCVbZvHQNpmWOVUMKWxbkw=

The playback of UCF (Universal Communications Format) rich media files requires appropriate players. To view this type of rich media files in the meeting, please check whether you have the players installed on your computer by going to  https://ciscosales.webex.com/ciscosales/systemdiagnosis.php

Sign up for a free trial of WebEx
http://www.webex.com/go/mcemfreetrial

http://www.webex.com 
We've got to start meeting like this(TM)

IMPORTANT NOTICE: This WebEx service includes a feature that allows audio and any documents and other materials exchanged or viewed during the session to be recorded. By joining this session, you automatically consent to such recordings. If you do not consent to the recording, do not join the session.

---

From: "Sprecher, Nurit (NSN - IL/Hod HaSharon)" <[email-masked]>
Date: Sat, 28 Feb 2009 18:06:05 +0100

I did not get it, thanks for forwarding.

-----Original Message-----
From: [email-masked]
[mailto:[email-masked]] On Behalf Of ext Stewart Bryant
Sent: Saturday, February 28, 2009 09:41
To: MEAD team
Subject: [Mpls-interop] [Fwd: (Forward to attendees) Meeting
invitation:MEAD]

Stewart

Content-class: urn:content-classes:message
Date: Thu, 5 Feb 2009 09:21:35 +0100
From: "Sprecher, Nurit (NSN - IL/Hod HaSharon)" <[email-masked]>
To: "ext Ben Niven-Jenkins" <[email-masked]>
Cc: "Weingarten, Yaacov \(NSN - IL/Hod HaSharon\)" <[email-masked]>, [email-masked]
Subject: [Mpls-interop] 1:N Protection Switching

This is a multi-part message in MIME format.

------_=_NextPart_001_01C9876A.CC16DD5E
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

Hi Ben,

In the requirements for protection it is specified that for 1:n that
"Unidirectional 1:n protection for P2MP connectivity MUST be
supported.". 
Is it really required or it may be that the 1+1 is satisfactory to cover
this case of unidirectional P2MP?
I ask it basically because of the need in 1:n to notify the source that
there is an error which requires the switch over. Then the source needs
to communicate this to all leaves. This requires a path back from the
leaf to the source. We may assume that there is a path back, out-of-band
control channel between source and leaves, but it looks more constrained
assumption. 

I would propose to remove the requirement for unidirectional 1:n
protection for P2MP connectivity or at least to put it as a MAY
requirement. 

Regards,

Nurit

----------------------------------------- 
Best regards, 

Nurit Sprecher

Nokia Siemens Networks GmbH & Co. KG 
Industry Environment

Senior Specialist, Carrier Ethernet Transport

3 Hanagar St. Neve Ne'eman B

45241 Hod Hasharon, Israel

Tel. +972 9 7751229

Mobile +972 54 2200954 
Email: [email-masked] <BLOCKED::mailto:[email-masked]> 

------_=_NextPart_001_01C9876A.CC16DD5E
Content-Type: text/html;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

<html xmlns:v="urn:schemas-microsoft-com:vml" xmlns:o="urn:schemas-microsoft-com:office:office" xmlns:w="urn:schemas-microsoft-com:office:word" xmlns:p="urn:schemas-microsoft-com:office:powerpoint" xmlns:oa="urn:schemas-microsoft-com:office:activation" xmlns:st1="urn:schemas-microsoft-com:office:smarttags" xmlns="http://www.w3.org/TR/REC-html40">

<head>
<meta http-equiv=Content-Type content="text/html; charset=us-ascii">
<meta name=Generator content="Microsoft Word 11 (filtered medium)">
<o:SmartTagType namespaceuri="urn:schemas-microsoft-com:office:smarttags"
 name="City"/>
<o:SmartTagType namespaceuri="urn:schemas-microsoft-com:office:smarttags"
 name="country-region"/>
<o:SmartTagType namespaceuri="urn:schemas-microsoft-com:office:smarttags"
 name="place"/>
<!--[if !mso]>
<style>
st1\:*{behavior:url(#default#ieooui) }
</style>
<![endif]-->
<style>
<!--
 /* Style Definitions */
 p.MsoNormal, li.MsoNormal, div.MsoNormal
	{margin:0in;
	margin-bottom:.0001pt;
	font-size:12.0pt;
	font-family:"Times New Roman";}
a:link, span.MsoHyperlink
	{color:blue;
	text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
	{color:purple;
	text-decoration:underline;}
pre
	{margin:0in;
	margin-bottom:.0001pt;
	font-size:10.0pt;
	font-family:"Courier New";}
span.EmailStyle17
	{mso-style-type:personal-compose;
	font-family:Arial;
	color:windowtext;}
p.section1, li.section1, div.section1
	{mso-margin-top-alt:auto;
	margin-right:0in;
	mso-margin-bottom-alt:auto;
	margin-left:0in;
	font-size:12.0pt;
	font-family:"Times New Roman";}
@page Section1
	{size:595.3pt 841.9pt;
	margin:1.0in 1.25in 1.0in 1.25in;}
div.Section1
	{page:Section1;}
-->
</style>

</head>

<body lang=EN-US link=blue vlink=purple>

<div class=Section1 dir=RTL>

<p class=MsoNormal dir=LTR><font size=2 face=Arial><span style='font-size:10.0pt;
font-family:Arial'>Hi Ben,<o:p></o:p></span></font></p>

<pre dir=LTR><font size=2 face="Courier New"><span style='font-size:10.0pt'>In the requirements for protection it is specified that for 1:n that &quot;Unidirectional 1:n protection for P2MP connectivity MUST be supported.&quot;. <o:p></o:p></span></font></pre><pre
dir=LTR><font size=2 face="Courier New"><span style='font-size:10.0pt'>Is it really required or it may be <b><span
style='font-weight:bold'>that the 1+1 is satisfactory to cover this case of unidirectional P2MP</span></b>?<o:p></o:p></span></font></pre><pre
dir=LTR><font size=2 face="Courier New"><span style='font-size:10.0pt'>I ask it basically because of the need in 1:n to notify the source that there is an error which requires the switch over. Then the source needs to communicate this to all leaves. This requires a path back from the leaf to the source. We may assume that there is a path back, out-of-band control channel between source and leaves, but it looks more constrained assumption. <o:p></o:p></span></font></pre>

<p class=MsoNormal dir=LTR><font size=3 face="Times New Roman"><span
style='font-size:12.0pt'>I would propose to remove the requirement for unidirectional
1:n protection for P2MP connectivity or at least to put it as a MAY
requirement. <o:p></o:p></span></font></p>

<p class=MsoNormal dir=LTR><font size=3 face="Times New Roman"><span
style='font-size:12.0pt'>Regards,<o:p></o:p></span></font></p>

<p class=MsoNormal dir=LTR><font size=3 face="Times New Roman"><span
style='font-size:12.0pt'>Nurit<o:p></o:p></span></font></p>

<p class=MsoNormal dir=LTR><font size=2 face=Arial><span style='font-size:10.0pt;
font-family:Arial'><o:p>&nbsp;</o:p></span></font></p>

<p class=MsoNormal dir=LTR><font size=2 face=Arial><span style='font-size:10.0pt;
font-family:Arial'><o:p>&nbsp;</o:p></span></font></p>

<p class=section1 dir=LTR style='margin:0in;margin-bottom:.0001pt'><font
size=2 face=Arial><span style='font-size:10.0pt;font-family:Arial'>-----------------------------------------&nbsp;<br>
Best regards, <o:p></o:p></span></font></p>

<p class=section1 dir=LTR style='margin:0in;margin-bottom:.0001pt'><font
size=2 face=Arial><span style='font-size:10.0pt;font-family:Arial'>Nurit
Sprecher</span></font><o:p></o:p></p>

<p class=section1 dir=LTR style='margin:0in;margin-bottom:.0001pt'><font
size=2 face=Arial><span style='font-size:10.0pt;font-family:Arial'>&nbsp;<o:p></o:p></span></font></p>

<p class=section1 dir=LTR style='margin:0in;margin-bottom:.0001pt'><font
size=2 face=Arial><span style='font-size:10.0pt;font-family:Arial'>Nokia
Siemens Networks GmbH &amp; Co. KG&nbsp;<br>
Industry Environment<o:p></o:p></span></font></p>

<p class=section1 dir=LTR style='margin:0in;margin-bottom:.0001pt'><font
size=2 face=Arial><span style='font-size:10.0pt;font-family:Arial'>Senior
Specialist, Carrier Ethernet Transport<o:p></o:p></span></font></p>

<p class=section1 dir=LTR style='margin:0in;margin-bottom:.0001pt'><font
size=2 face=Arial><span style='font-size:10.0pt;font-family:Arial'>3 Hanagar <u1:place u2:st="on"><st1:place
w:st="on">St.</u1:place></st1:place> Neve Ne'eman B<o:p></o:p></span></font></p>

<p class=section1 dir=LTR style='margin:0in;margin-bottom:.0001pt'><font
size=2 face=Arial><span style='font-size:10.0pt;font-family:Arial'>45241 Hod <u1:place u2:st="on"><u1:City u2:st="on"><st1:place
w:st="on"><st1:City w:st="on">Hasharon</u1:City></st1:City>, <u1:country-region u2:st="on"><st1:country-region
 w:st="on">Israel</u1:country-region></u1:place></st1:country-region></st1:place><o:p></o:p></span></font></p>

<p class=section1 dir=LTR style='margin:0in;margin-bottom:.0001pt'><font
size=2 face=Arial><span style='font-size:10.0pt;font-family:Arial'><br>
Tel. +972 9 7751229<o:p></o:p></span></font></p>

<p class=section1 dir=LTR style='mso-margin-top-alt:0in;margin-right:0in;
margin-bottom:12.0pt;margin-left:0in'><font size=2 face=Arial><span
style='font-size:10.0pt;font-family:Arial'>Mobile +972 54 2200954&nbsp;<br>
Email:&nbsp;<a href="BLOCKED::mailto:[email-masked]"
title="mailto:[email-masked]">[email-masked]</a></span></font><o:p></o:p></p>

<p class=MsoNormal dir=LTR><font size=3 face="Times New Roman"><span
style='font-size:12.0pt'><o:p>&nbsp;</o:p></span></font></p>

</div>

</body>

</html>

------_=_NextPart_001_01C9876A.CC16DD5E--

From: "Adrian Farrel" <[email-masked]>
To: "Sprecher, Nurit \(NSN - IL/Hod HaSharon\)" <[email-masked]>, "ext Ben Niven-Jenkins" <[email-masked]>
Date: Thu, 5 Feb 2009 14:22:51 -0000
Cc: [email-masked], "Weingarten, Yaacov \(NSN - IL/Hod HaSharon\)" <[email-masked]>
Subject: Re: [Mpls-interop] 1:N Protection Switching
Reply-To: Adrian Farrel <[email-masked]>

Hi Nurit,

Just want to be really clear on your question because it looks to me that 
you have mixed
- unidirectional protection (in your first paragraph)
- unidirectional P2MP (in your second paragraph)

Of course, all P2MP LSPs are unidirectional.
Given that, all protection of P2MP LSPs will be unidirectional.

So the question is 1:n or 1+1.

I do not see why 1:1 protection should not be used in a P2MP situation.
1:n might be a little extreme, but is no different from an implementation 
point of view.

You are correct that the solution for 1:1 would be a little more messy than 
1+1, but I am not sure that you are right that it is necessary to tell all 
of the leaves. The leaves could be implemented to bridge, while the source 
is responsible for switching. In this it is no different from P2P 
unidirectional LSPs. Any scaling issues are identical to the scaling issues 
of having multiple leaves.

Adrian

----- Original Message ----- 
From: "Sprecher, Nurit (NSN - IL/Hod HaSharon)" <[email-masked]>
To: "ext Ben Niven-Jenkins" <[email-masked]>
Cc: "Adrian Farrel" <[email-masked]>; <[email-masked]>; 
"Weingarten, Yaacov (NSN - IL/Hod HaSharon)" <[email-masked]>
Sent: Thursday, February 05, 2009 8:21 AM
Subject: 1:N Protection Switching

Hi Ben,

In the requirements for protection it is specified that for 1:n that
"Unidirectional 1:n protection for P2MP connectivity MUST be
supported.".
Is it really required or it may be that the 1+1 is satisfactory to cover
this case of unidirectional P2MP?
I ask it basically because of the need in 1:n to notify the source that
there is an error which requires the switch over. Then the source needs
to communicate this to all leaves. This requires a path back from the
leaf to the source. We may assume that there is a path back, out-of-band
control channel between source and leaves, but it looks more constrained
assumption.

I would propose to remove the requirement for unidirectional 1:n
protection for P2MP connectivity or at least to put it as a MAY
requirement.

Regards,

Nurit

----------------------------------------- 
Best regards,

Nurit Sprecher

Nokia Siemens Networks GmbH & Co. KG
Industry Environment

Senior Specialist, Carrier Ethernet Transport

3 Hanagar St. Neve Ne'eman B

45241 Hod Hasharon, Israel

Tel. +972 9 7751229

Mobile +972 54 2200954
Email: [email-masked] <BLOCKED::mailto:[email-masked]>

Date: Thu, 05 Feb 2009 15:29:12 +0000
From: Ben Niven-Jenkins <[email-masked]>
To: Adrian Farrel <[email-masked]>, "Sprecher, Nurit (NSN - IL/Hod HaSharon)" <[email-masked]>
Cc: [email-masked], "Weingarten, Yaacov \(NSN - IL/Hod HaSharon\)" <[email-masked]>
Subject: Re: [Mpls-interop] 1:N Protection Switching

Indeed.  The issue with 1+1 is the additional bandwidth requirement to
maintain both paths it is not always practical or cost effective to allocate
that bandwidth purely to protecting a P2MP flow.

Ben

On 05/02/2009 14:22, "Adrian Farrel" <[email-masked]> wrote:

> Hi Nurit,
> 
> Just want to be really clear on your question because it looks to me that
> you have mixed
> - unidirectional protection (in your first paragraph)
> - unidirectional P2MP (in your second paragraph)
> 
> Of course, all P2MP LSPs are unidirectional.
> Given that, all protection of P2MP LSPs will be unidirectional.
> 
> So the question is 1:n or 1+1.
> 
> I do not see why 1:1 protection should not be used in a P2MP situation.
> 1:n might be a little extreme, but is no different from an implementation
> point of view.
> 
> You are correct that the solution for 1:1 would be a little more messy than
> 1+1, but I am not sure that you are right that it is necessary to tell all
> of the leaves. The leaves could be implemented to bridge, while the source
> is responsible for switching. In this it is no different from P2P
> unidirectional LSPs. Any scaling issues are identical to the scaling issues
> of having multiple leaves.
> 
> Adrian
> 
> 
> ----- Original Message -----
> From: "Sprecher, Nurit (NSN - IL/Hod HaSharon)" <[email-masked]>
> To: "ext Ben Niven-Jenkins" <[email-masked]>
> Cc: "Adrian Farrel" <[email-masked]>; <[email-masked]>;
> "Weingarten, Yaacov (NSN - IL/Hod HaSharon)" <[email-masked]>
> Sent: Thursday, February 05, 2009 8:21 AM
> Subject: 1:N Protection Switching
> 
> 
> Hi Ben,
> 
> In the requirements for protection it is specified that for 1:n that
> "Unidirectional 1:n protection for P2MP connectivity MUST be
> supported.".
> Is it really required or it may be that the 1+1 is satisfactory to cover
> this case of unidirectional P2MP?
> I ask it basically because of the need in 1:n to notify the source that
> there is an error which requires the switch over. Then the source needs
> to communicate this to all leaves. This requires a path back from the
> leaf to the source. We may assume that there is a path back, out-of-band
> control channel between source and leaves, but it looks more constrained
> assumption.
> 
> I would propose to remove the requirement for unidirectional 1:n
> protection for P2MP connectivity or at least to put it as a MAY
> requirement.
> 
> Regards,
> 
> Nurit
> 
> 
> 
> 
> 
> -----------------------------------------
> Best regards,
> 
> Nurit Sprecher
> 
> 
> 
> Nokia Siemens Networks GmbH & Co. KG
> Industry Environment
> 
> Senior Specialist, Carrier Ethernet Transport
> 
> 3 Hanagar St. Neve Ne'eman B
> 
> 45241 Hod Hasharon, Israel
> 
> 
> Tel. +972 9 7751229
> 
> Mobile +972 54 2200954
> Email: [email-masked] <BLOCKED::mailto:[email-masked]>
> 
> 
> 
> 

Date: Fri, 06 Feb 2009 17:26:41 +0800
From: hejia <[email-masked]>
To: "Sprecher, Nurit (NSN - IL/Hod HaSharon)" <[email-masked]>, ext Ben Niven-Jenkins <[email-masked]>
Cc: [email-masked], "Weingarten, Yaacov \(NSN - IL/Hod HaSharon\)" <[email-masked]>
Subject: Re: [Mpls-interop] 1:N Protection Switching

This is a multi-part message in MIME format.

--Boundary_(ID_+cSBlc6pqe2i6aHfcnctdA)
Content-type: text/plain; charset=ISO-8859-1
Content-transfer-encoding: 7BIT

Hi Nurit,

I guess we can clarify the notification problems in 1:1 unidirectional P2MP protection in the following two directions 

1) leaves-->root
If the leaf detects the fault, it needs a backward path to notify the source to do switching. This applies to each leaf so that there might be a reverse MP2P or m P2Ps to send the notification. 

2) root-->leaves
There might be cases that  the source needs to communicate with other leaves as you indicated. For example, if a leaf detects faults, it sends notification to the source and the source learns the fault and switches but other leaves do not learn the fault so that they may not do the switching and traffic will be lost, supposing no permanent bridge is used in leaves.
In that case, it may require notification from source to leaves for switching and we can reuse the P2MP path. Or the leaf which detects fault sends notification to both root and other leaves (more complicated though)? 

Of course, as indicated by Adrian, if a permanent bridge is used at each leaf and switching is done at source, we do not need notification again from source to leaves  for coordination.

Regards,
Jia
  ----- Original Message ----- 
  From: Sprecher, Nurit (NSN - IL/Hod HaSharon) 
  To: ext Ben Niven-Jenkins 
  Cc: Weingarten, Yaacov (NSN - IL/Hod HaSharon) ; [email-masked] 
  Sent: Thursday, February 05, 2009 4:21 PM
  Subject: [Mpls-interop] 1:N Protection Switching

  Hi Ben,

In the requirements for protection it is specified that for 1:n that "Unidirectional 1:n protection for P2MP connectivity MUST be supported.". Is it really required or it may be that the 1+1 is satisfactory to cover this case of unidirectional P2MP?I ask it basically because of the need in 1:n to notify the source that there is an error which requires the switch over. Then the source needs to communicate this to all leaves. This requires a path back from the leaf to the source. We may assume that there is a path back, out-of-band control channel between source and leaves, but it looks more constrained assumption. I would propose to remove the requirement for unidirectional 1:n protection for P2MP connectivity or at least to put it as a MAY requirement. 

  Regards,

  Nurit

  ----------------------------------------- 
  Best regards, 

  Nurit Sprecher

  Nokia Siemens Networks GmbH & Co. KG 
  Industry Environment

  Senior Specialist, Carrier Ethernet Transport

  3 Hanagar St. Neve Ne'eman B

  45241 Hod Hasharon, Israel

  Tel. +972 9 7751229

  Mobile +972 54 2200954 
  Email: [email-masked]

------------------------------------------------------------------------------

  _______________________________________________
  Mpls-interop mailing list
  [email-masked]
  https://www.ietf.org/mailman/listinfo/mpls-interop

--Boundary_(ID_+cSBlc6pqe2i6aHfcnctdA)
Content-type: text/html; charset=ISO-8859-1
Content-transfer-encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML xmlns="http://www.w3.org/TR/REC-html40" xmlns:v = 
"urn:schemas-microsoft-com:vml" xmlns:o = 
"urn:schemas-microsoft-com:office:office" xmlns:w = 
"urn:schemas-microsoft-com:office:word" xmlns:p = 
"urn:schemas-microsoft-com:office:powerpoint" xmlns:oa = 
"urn:schemas-microsoft-com:office:activation" xmlns:st1 = 
"urn:schemas-microsoft-com:office:smarttags"><HEAD>
<META http-equiv=Content-Type content="text/html; charset=iso-8859-1">
<META content="MSHTML 6.00.6000.16788" name=GENERATOR><o:SmartTagType 
name="City" 
namespaceuri="urn:schemas-microsoft-com:office:smarttags"></o:SmartTagType><o:SmartTagType 
name="country-region" 
namespaceuri="urn:schemas-microsoft-com:office:smarttags"></o:SmartTagType><o:SmartTagType 
name="place" 
namespaceuri="urn:schemas-microsoft-com:office:smarttags"></o:SmartTagType><!--[if !mso]>
<STYLE>st1\:* {
	BEHAVIOR: url(#default#ieooui)
}
</STYLE>
<![endif]-->
<STYLE>
<!--
 /* Style Definitions */
 p.MsoNormal, li.MsoNormal, div.MsoNormal
	{margin:0in;
	margin-bottom:.0001pt;
	font-size:12.0pt;
	font-family:"Times New Roman";}
a:link, span.MsoHyperlink
	{color:blue;
	text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
	{color:purple;
	text-decoration:underline;}
pre
	{margin:0in;
	margin-bottom:.0001pt;
	font-size:10.0pt;
	font-family:"Courier New";}
span.EmailStyle17
	{mso-style-type:personal-compose;
	font-family:Arial;
	color:windowtext;}
p.section1, li.section1, div.section1
	{mso-margin-top-alt:auto;
	margin-right:0in;
	mso-margin-bottom-alt:auto;
	margin-left:0in;
	font-size:12.0pt;
	font-family:"Times New Roman";}
@page Section1
	{size:595.3pt 841.9pt;
	margin:1.0in 1.25in 1.0in 1.25in;}
div.Section1
	{page:Section1;}
-->
</STYLE>
</HEAD>
<BODY lang=EN-US vLink=purple link=blue bgColor=#ffffff>
<DIV>Hi Nurit,</DIV>
<DIV>&nbsp;</DIV>
<DIV>I guess we can&nbsp;clarify the notification problems in 1:1 unidirectional 
P2MP protection&nbsp;in the following two directions 
<DIV>&nbsp;</DIV>
<DIV>1) leaves--&gt;root</DIV>
<DIV>If the leaf detects the fault, it needs a&nbsp;backward path to notify the 
source to&nbsp;do&nbsp;switching. This applies to each leaf so that there might 
be a reverse&nbsp;MP2P or m P2Ps&nbsp;to send the notification. </DIV>
<DIV>&nbsp;</DIV>
<DIV>2) root--&gt;leaves</DIV>
<DIV>There might be cases that&nbsp; the source needs to communicate with other 
leaves as you indicated. For example,&nbsp;if a leaf detects&nbsp;faults, it 
sends notification to&nbsp;the source&nbsp;and the source learns the 
fault&nbsp;and switches but other&nbsp;leaves&nbsp;do not&nbsp;learn the fault 
so that&nbsp;they may not do the switching and traffic will be lost, 
supposing&nbsp;no permanent bridge is used in leaves.</DIV>
<DIV>In that case, it may require&nbsp;notification from source to 
leaves&nbsp;for switching&nbsp;and we&nbsp;can reuse the P2MP path. Or the leaf 
which detects fault sends notification to both&nbsp;root and other leaves (more 
complicated though)?&nbsp;</DIV>
<DIV>&nbsp;</DIV>
<DIV>Of course, as indicated by Adrian, if a&nbsp;permanent&nbsp;bridge is used 
at each leaf and switching is done at source, we do not need notification again 
from&nbsp;source to leaves&nbsp; for coordination.</DIV>
<DIV>&nbsp;</DIV>
<DIV>Regards,</DIV>
<DIV>Jia</DIV></DIV>
<BLOCKQUOTE 
style="PADDING-RIGHT: 0px; PADDING-LEFT: 5px; MARGIN-LEFT: 5px; BORDER-LEFT: #000000 2px solid; MARGIN-RIGHT: 0px">
  <DIV style="FONT: 10pt arial">----- Original Message ----- </DIV>
  <DIV 
  style="BACKGROUND: #e4e4e4; FONT: 10pt arial; font-color: black"><B>From:</B> 
  <A title=[email-masked] href="mailto:[email-masked]">Sprecher, 
  Nurit (NSN - IL/Hod HaSharon)</A> </DIV>
  <DIV style="FONT: 10pt arial"><B>To:</B> <A 
  title=[email-masked] 
  href="mailto:[email-masked]">ext Ben Niven-Jenkins</A> </DIV>
  <DIV style="FONT: 10pt arial"><B>Cc:</B> <A title=[email-masked] 
  href="mailto:[email-masked]">Weingarten, Yaacov (NSN - IL/Hod 
  HaSharon)</A> ; <A title=[email-masked] 
  href="mailto:[email-masked]">[email-masked]</A> </DIV>
  <DIV style="FONT: 10pt arial"><B>Sent:</B> Thursday, February 05, 2009 4:21 
  PM</DIV>
  <DIV style="FONT: 10pt arial"><B>Subject:</B> [Mpls-interop] 1:N Protection 
  Switching</DIV>
  <DIV><BR></DIV>
  <DIV class=Section1 dir=rtl>
  <P class=MsoNormal dir=ltr><FONT face=Arial size=2><SPAN 
  style="FONT-SIZE: 10pt; FONT-FAMILY: Arial">Hi 
  Ben,<o:p></o:p></SPAN></FONT></P><PRE dir=ltr><FONT face="Courier New" size=2><SPAN style="FONT-SIZE: 10pt">In the requirements for protection it is specified that for 1:n that "Unidirectional 1:n protection for P2MP connectivity MUST be supported.". <o:p></o:p></SPAN></FONT></PRE><PRE dir=ltr><FONT face="Courier New" size=2><SPAN style="FONT-SIZE: 10pt">Is it really required or it may be <B><SPAN style="FONT-WEIGHT: bold">that the 1+1 is satisfactory to cover this case of unidirectional P2MP</SPAN></B>?<o:p></o:p></SPAN></FONT></PRE><PRE dir=ltr><FONT face="Courier New" size=2><SPAN style="FONT-SIZE: 10pt">I ask it basically because of the need in 1:n to notify the source that there is an error which requires the switch over. Then the source needs to communicate this to all leaves. This requires a path back from the leaf to the source. We may assume that there is a path back, out-of-band control channel between source and leaves, but it looks more constrained assumption. <o:p></o:p></SPAN></FONT></PRE>
  <P class=MsoNormal dir=ltr><FONT face="Times New Roman" size=3><SPAN 
  style="FONT-SIZE: 12pt">I would propose to remove the requirement for 
  unidirectional 1:n protection for P2MP connectivity or at least to put it as a 
  MAY requirement. <o:p></o:p></SPAN></FONT></P>
  <P class=MsoNormal dir=ltr><FONT face="Times New Roman" size=3><SPAN 
  style="FONT-SIZE: 12pt">Regards,<o:p></o:p></SPAN></FONT></P>
  <P class=MsoNormal dir=ltr><FONT face="Times New Roman" size=3><SPAN 
  style="FONT-SIZE: 12pt">Nurit<o:p></o:p></SPAN></FONT></P>
  <P class=MsoNormal dir=ltr><FONT face=Arial size=2><SPAN 
  style="FONT-SIZE: 10pt; FONT-FAMILY: Arial"><o:p>&nbsp;</o:p></SPAN></FONT></P>
  <P class=MsoNormal dir=ltr><FONT face=Arial size=2><SPAN 
  style="FONT-SIZE: 10pt; FONT-FAMILY: Arial"><o:p>&nbsp;</o:p></SPAN></FONT></P>
  <P class=section1 dir=ltr style="MARGIN: 0in 0in 0pt"><FONT face=Arial 
  size=2><SPAN 
  style="FONT-SIZE: 10pt; FONT-FAMILY: Arial">-----------------------------------------&nbsp;<BR>Best 
  regards, <o:p></o:p></SPAN></FONT></P>
  <P class=section1 dir=ltr style="MARGIN: 0in 0in 0pt"><FONT face=Arial 
  size=2><SPAN style="FONT-SIZE: 10pt; FONT-FAMILY: Arial">Nurit 
  Sprecher</SPAN></FONT><o:p></o:p></P>
  <P class=section1 dir=ltr style="MARGIN: 0in 0in 0pt"><FONT face=Arial 
  size=2><SPAN 
  style="FONT-SIZE: 10pt; FONT-FAMILY: Arial">&nbsp;<o:p></o:p></SPAN></FONT></P>
  <P class=section1 dir=ltr style="MARGIN: 0in 0in 0pt"><FONT face=Arial 
  size=2><SPAN style="FONT-SIZE: 10pt; FONT-FAMILY: Arial">Nokia Siemens 
  Networks GmbH &amp; Co. KG&nbsp;<BR>Industry 
  Environment<o:p></o:p></SPAN></FONT></P>
  <P class=section1 dir=ltr style="MARGIN: 0in 0in 0pt"><FONT face=Arial 
  size=2><SPAN style="FONT-SIZE: 10pt; FONT-FAMILY: Arial">Senior Specialist, 
  Carrier Ethernet Transport<o:p></o:p></SPAN></FONT></P>
  <P class=section1 dir=ltr style="MARGIN: 0in 0in 0pt"><FONT face=Arial 
  size=2><SPAN style="FONT-SIZE: 10pt; FONT-FAMILY: Arial">3 Hanagar <U1:PLACE 
  u2:st="on"><st1:place w:st="on">St.</U1:PLACE></st1:place> Neve Ne'eman 
  B<o:p></o:p></SPAN></FONT></P>
  <P class=section1 dir=ltr style="MARGIN: 0in 0in 0pt"><FONT face=Arial 
  size=2><SPAN style="FONT-SIZE: 10pt; FONT-FAMILY: Arial">45241 Hod <U1:PLACE 
  u2:st="on"><U1:CITY u2:st="on"><st1:place w:st="on"><st1:City 
  w:st="on">Hasharon</U1:CITY></st1:City>, <U1:COUNTRY-REGION 
  u2:st="on"><st1:country-region 
  w:st="on">Israel</U1:COUNTRY-REGION></U1:PLACE></st1:country-region></st1:place><o:p></o:p></SPAN></FONT></P>
  <P class=section1 dir=ltr style="MARGIN: 0in 0in 0pt"><FONT face=Arial 
  size=2><SPAN style="FONT-SIZE: 10pt; FONT-FAMILY: Arial"><BR>Tel. +972 9 
  7751229<o:p></o:p></SPAN></FONT></P>
  <P class=section1 dir=ltr 
  style="MARGIN-BOTTOM: 12pt; MARGIN-LEFT: 0in; MARGIN-RIGHT: 0in; mso-margin-top-alt: 0in"><FONT 
  face=Arial size=2><SPAN style="FONT-SIZE: 10pt; FONT-FAMILY: Arial">Mobile 
  +972 54 2200954&nbsp;<BR>Email:&nbsp;<A title=mailto:[email-masked] 
  href="BLOCKED::mailto:[email-masked]">[email-masked]</A></SPAN></FONT><o:p></o:p></P>
  <P class=MsoNormal dir=ltr><FONT face="Times New Roman" size=3><SPAN 
  style="FONT-SIZE: 12pt"><o:p>&nbsp;</o:p></SPAN></FONT></P></DIV>
  <P>
  <HR>

  <P></P>_______________________________________________<BR>Mpls-interop mailing 
  list<BR>[email-masked]<BR>https://www.ietf.org/mailman/listinfo/mpls-interop<BR></BLOCKQUOTE></BODY></HTML>

--Boundary_(ID_+cSBlc6pqe2i6aHfcnctdA)--

Content-class: urn:content-classes:message
Date: Fri, 6 Feb 2009 08:02:15 -0600
Priority: Urgent
Importance: high
From: "Eric Gray" <[email-masked]>
To: <[email-masked]>, <[email-masked]>, <[email-masked]>
Subject: [Mpls-interop] FW: New Version Notification for draft-gray-mpls-tp-nm-req-03

A new version of this draft has been posted, based on comments 
received and an editing session last month in Ipswich, UK.

As discussed at the Ipswich meeting, we would now like to ask
the WG Chairs, and the WG, to adopt this version as a working
group docment.

Thanks in advance...

-----Original Message-----
From: IETF I-D Submission Tool [mailto:[email-masked]] 
Sent: Friday, February 06, 2009 8:51 AM
To: Eric Gray
Cc: Scott Mansfield; [email-masked]
Subject: New Version Notification for draft-gray-mpls-tp-nm-req-03 
Importance: High

A new version of I-D, draft-gray-mpls-tp-nm-req-03.txt has been
successfuly submitted by Eric Gray and posted to the IETF repository.

Filename:	 draft-gray-mpls-tp-nm-req
Revision:	 03
Title:		 MPLS TP Network Management Requirements
Creation_date:	 2009-02-04
WG ID:		 Independent Submission
Number_of_pages: 20

Abstract:
This document specifies the requirements necessary to manage the 

  elements and networks that support an MPLS Transport Profile 

  (MPLS-TP). This document is a product of a joint International 

  Telecommunications Union - Telecommunications Standardization 

  Sector (ITU-T) and Internet Engineering Task Force (IETF) effort 

  to include a MPLS Transport Profile within the IETF MPLS 

  architecture. The requirements are driven by the management 

  functionality needs defined by ITU-T for packet transport 

  networks. 

  Gray, et al

  Expires August, 2009

  [page 1] 

  Internet-Draft

MPLS-TP NM Requirements

 February, 2009

The IETF Secretariat.

Date: Fri, 06 Feb 2009 16:17:46 +0100
From: Loa Andersson <[email-masked]>
To: Eric Gray <[email-masked]>
Cc: [email-masked], [email-masked], [email-masked], [email-masked]
Subject: [Mpls-interop] Poll for draft-gray-mpls-tp-nm-req-03 to become an mpls wg document

All,

as you can see below the authors of draft-gray-mpls-tp-nm-req-03
has request that we accept the draft as a working group draft.

This is to initiate a two week poll if we want to accept it as
a working group document.

Please send your comments to the mpls-tp list.

/Loa

Eric Gray wrote:
> A new version of this draft has been posted, based on comments 
> received and an editing session last month in Ipswich, UK.
> 
> As discussed at the Ipswich meeting, we would now like to ask
> the WG Chairs, and the WG, to adopt this version as a working
> group docment.
> 
> Thanks in advance...
> 
> -----Original Message-----
> From: IETF I-D Submission Tool [mailto:[email-masked]] 
> Sent: Friday, February 06, 2009 8:51 AM
> To: Eric Gray
> Cc: Scott Mansfield; [email-masked]
> Subject: New Version Notification for draft-gray-mpls-tp-nm-req-03 
> Importance: High
> 
> 
> A new version of I-D, draft-gray-mpls-tp-nm-req-03.txt has been
> successfuly submitted by Eric Gray and posted to the IETF repository.
> 
> Filename:	 draft-gray-mpls-tp-nm-req
> Revision:	 03
> Title:		 MPLS TP Network Management Requirements
> Creation_date:	 2009-02-04
> WG ID:		 Independent Submission
> Number_of_pages: 20
> 
> Abstract:
> This document specifies the requirements necessary to manage the 
> 
>   elements and networks that support an MPLS Transport Profile 
> 
>   (MPLS-TP). This document is a product of a joint International 
> 
>   Telecommunications Union - Telecommunications Standardization 
> 
>   Sector (ITU-T) and Internet Engineering Task Force (IETF) effort 
> 
>   to include a MPLS Transport Profile within the IETF MPLS 
> 
>   architecture. The requirements are driven by the management 
> 
>   functionality needs defined by ITU-T for packet transport 
> 
>   networks. 
> 
> 
> 
> 
> 
> 
> 
>   Gray, et al
> 
> 
> 
>   Expires August, 2009
> 
> 
> 
>   [page 1] 
>  
> 
> 
> 
> 
>   Internet-Draft
> 
> 
> MPLS-TP NM Requirements
> 
>  February, 2009
>  
> 
> 
> 
> The IETF Secretariat.
> 
> 
> _______________________________________________
> Mpls-interop mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/mpls-interop

-- 

Loa Andersson

Sr Strategy and Standards Manager
Ericsson ///                          phone:  +46 8 632 77 14

                                       email:  [email-masked]
                                               [email-masked]
                                               [email-masked]

Content-class: urn:content-classes:message
Date: Fri, 6 Feb 2009 17:11:30 +0100
From: "Annamaria Fulignoli" <[email-masked]>
To: "Loa Andersson" <[email-masked]>, "Eric Gray" <[email-masked]>
Cc: [email-masked], [email-masked], [email-masked], [email-masked]
Subject: Re: [Mpls-interop] Poll for draft-gray-mpls-tp-nm-req-03 to become anmpls wg document

I Support

BR
Annamaria 

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Loa Andersson
Sent: venerdì 6 febbraio 2009 16.18
To: Eric Gray
Cc: [email-masked]; [email-masked]; [email-masked]; [email-masked]
Subject: [Mpls-interop] Poll for draft-gray-mpls-tp-nm-req-03 to become anmpls wg document

All,

as you can see below the authors of draft-gray-mpls-tp-nm-req-03 has request that we accept the draft as a working group draft.

This is to initiate a two week poll if we want to accept it as a working group document.

Please send your comments to the mpls-tp list.

/Loa

Eric Gray wrote:
> A new version of this draft has been posted, based on comments 
> received and an editing session last month in Ipswich, UK.
> 
> As discussed at the Ipswich meeting, we would now like to ask the WG 
> Chairs, and the WG, to adopt this version as a working group docment.
> 
> Thanks in advance...
> 
> -----Original Message-----
> From: IETF I-D Submission Tool [mailto:[email-masked]]
> Sent: Friday, February 06, 2009 8:51 AM
> To: Eric Gray
> Cc: Scott Mansfield; [email-masked]
> Subject: New Version Notification for draft-gray-mpls-tp-nm-req-03
> Importance: High
> 
> 
> A new version of I-D, draft-gray-mpls-tp-nm-req-03.txt has been 
> successfuly submitted by Eric Gray and posted to the IETF repository.
> 
> Filename:	 draft-gray-mpls-tp-nm-req
> Revision:	 03
> Title:		 MPLS TP Network Management Requirements
> Creation_date:	 2009-02-04
> WG ID:		 Independent Submission
> Number_of_pages: 20
> 
> Abstract:
> This document specifies the requirements necessary to manage the
> 
>   elements and networks that support an MPLS Transport Profile
> 
>   (MPLS-TP). This document is a product of a joint International
> 
>   Telecommunications Union - Telecommunications Standardization
> 
>   Sector (ITU-T) and Internet Engineering Task Force (IETF) effort
> 
>   to include a MPLS Transport Profile within the IETF MPLS
> 
>   architecture. The requirements are driven by the management
> 
>   functionality needs defined by ITU-T for packet transport
> 
>   networks. 
> 
> 
> 
> 
> 
> 
> 
>   Gray, et al
> 
> 
> 
>   Expires August, 2009
> 
> 
> 
>   [page 1]
>  
> 
> 
> 
> 
>   Internet-Draft
> 
> 
> MPLS-TP NM Requirements
> 
>  February, 2009
>  
> 
> 
> 
> The IETF Secretariat.
> 
> 
> _______________________________________________
> Mpls-interop mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/mpls-interop

-- 

Loa Andersson

Sr Strategy and Standards Manager
Ericsson ///                          phone:  +46 8 632 77 14

                                       email:  [email-masked]
                                               [email-masked]
                                               [email-masked]

_______________________________________________
Mpls-interop mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/mpls-interop

Content-class: urn:content-classes:message
Date: Fri, 6 Feb 2009 17:09:19 +0100
From: "Annamaria Fulignoli" <[email-masked]>
To: "Loa Andersson" <[email-masked]>, "MEAD team" <[email-masked]>
Subject: Re: [Mpls-interop] moving mpls-tp documents - you are supposed torespond

Hi all,
please, see my comments in line. 
Kind regards,
Annamaria 

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Loa Andersson
Sent: venerdì 23 gennaio 2009 16.57
To: MEAD team
Subject: [Mpls-interop] moving mpls-tp documents - you are supposed torespond

All,

I'll to try push the next round of documents to wg last call, or have them accepted as wg documents asap. The discussions in Ipswich gave a of input that should be captured in several documents.

This also means that we need to to have a couple of documents become wg documents. Here are the steps we need to take:

draft-andersson-mpls-tp-oam-def       (accept as a MEAD team doc?)  
<AF> Support <AF>	

draft-beller-mpls-tp-gach-dcn 	      (accept as a MEAD team doc?)
<AF> Support <AF> 

draft-boutros-mpls-tp-cv              (accept as a MEAD team doc?)
draft-boutros-mpls-tp-fault           (accept as a MEAD team doc?) 	
draft-boutros-mpls-tp-loopback 	      (comments and review need!) 	
draft-boutros-mpls-tp-performance     (accept as a MEAD team doc?)
<AF> I'll send specific comment to the single drafts. In the meantime , about all of them,  I've two general comments:
	1)In all these drafts no MPLS-TP drafts are addressed/referenced; besides they seems to be completely out of MPLS-TP OAM requirement and framework .
	2)ACH encapsulation method ( not IP based ) and LSP Ping extension (IP based) are proposed. I wonder why even the IP based method is proposed in a MPLS-TP OAM tool and I even want to highlight that this approach could lead to a possible confusion and mis-understanding as in MPLS-TP requirement draft is reported (req. 29):
"It MUST be possible to operate and configure the MPLS-TP data(transport) plane without any IP forwarding capability in the MPLS-TP data plane. "

draft-bryant-mpls-tp-ach-tlv          (accept as a MEAD team doc?) 	
<AF> Support <AF>

draft-busi-mpls-tp-oam-framework      (update based on Ipswich discussion!) 
<AF> Support <AF>

draft-gray-mpls-tp-nm-req             (accept as a wg doc!)
<AF> Support <AF>

draft-ietf-mpls-tp-framework          (prepare for a wg last call, after
                                        the tp-requirements are wg last
                                        called)
<AF> Support <AF>

draft-ietf-mpls-tp-oam-requirements   (we need to get existing comments
                                        written down, we will allow until
                                        Friday Jan 30 to do this, after
                                        that we'll prepare the doc for wg
                                        last call)
<AF> Support <AF>

draft-martinotti-mpls-tp-interworking (accept as a MEAD team doc?) 	
<AF> Support. <AF>

draft-sprecher-mpls-tp-oam-analysis   (update as soon as the  oam-requirements are stable)
<AF> Support <AF>
 
draft-sprecher-mpls-tp-survive-fwk    (document has expired and should be republished)
<AF> Support <AF>

draft-yang-mpls-tp-ring-protection-analysis  (accept as a MEAD team doc?)
<AF> It could be a useful material for the draft-sprecher-mpls-tp-survive-fwk <AF>

As a member of the MEAD team you are expected to respond to the "accept as a MEAD team doc"?

As a a MEAD team member you are expected to supply your comments on draft-ietf-mpls-tp-oam-requirements on Fri Jan 30, the latest.

As an editor you are supposed to take the action (when the time is
right) for the other document.

A reminder:

Becoming a MEAD team document means that there a strong element in that draft that the MEAD needs to coordinate, it won't stop us from splitting or merge documents, just that we will do so in a coordinated way.

Becoming wg documents means positive response to three questions.

- does this document address a problem that the wg needs to
   solve
- is this document a good enough start to solve this problem
- is it within wg charter

/Loa

-- 

Loa Andersson

Sr Strategy and Standards Manager
Ericsson ///                          phone:  +46 8 632 77 14

                                       email:  [email-masked]
                                               [email-masked]
                                               [email-masked]

_______________________________________________
Mpls-interop mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/mpls-interop

Date: Sat, 07 Feb 2009 16:31:59 +0100
From: Loa Andersson <[email-masked]>
To: MEAD team <[email-masked]>
Subject: Re: [Mpls-interop] moving mpls-tp documents - you are supposed to respond

Team,

The poll below was obviously a bit multi-dimensional. Thanks for
repsonses. The conclusions I've so far is that we've accepted

- draft-andersson-mpls-tp-oam-def
- draft-beller-mpls-tp-gach-dcn
- draft-bryant-mpls-tp-ach-tlv

as MEAD team documents.

I will send another poll that is more focused.

/Loa

Loa Andersson wrote:
> All,
> 
> I'll to try push the next round of documents to wg last call,
> or have them accepted as wg documents asap. The discussions in
> Ipswich gave a of input that should be captured in several
> documents.
> 
> This also means that we need to to have a couple of documents
> become wg documents. Here are the steps we need to take:
> 
> draft-andersson-mpls-tp-oam-def       (accept as a MEAD team doc?)     
> draft-beller-mpls-tp-gach-dcn           (accept as a MEAD team doc?)
> draft-boutros-mpls-tp-cv              (accept as a MEAD team doc?)
>     
> draft-boutros-mpls-tp-fault           (accept as a MEAD team doc?)    
> draft-boutros-mpls-tp-loopback           (comments and review need!)    
> draft-boutros-mpls-tp-performance     (accept as a MEAD team doc?)
>     
> draft-bryant-mpls-tp-ach-tlv          (accept as a MEAD team doc?)    
> draft-busi-mpls-tp-oam-framework      (update based on Ipswich
>                                        discussion!)    
> draft-gray-mpls-tp-nm-req             (accept as a wg doc!)
> 
> draft-ietf-mpls-tp-framework          (prepare for a wg last call, after
>                                        the tp-requirements are wg last
>                                        called)
> draft-ietf-mpls-tp-oam-requirements   (we need to get existing comments
>                                        written down, we will allow until
>                                        Friday Jan 30 to do this, after
>                                        that we'll prepare the doc for wg
>                                        last call)
> draft-ietf-mpls-tp-requirements       (prepare for wg last call)
> 
> draft-martinotti-mpls-tp-interworking (accept as a MEAD team doc?)    
> draft-sprecher-mpls-tp-oam-analysis   (update as soon as the
>                                        oam-requirements are stable)
> draft-sprecher-mpls-tp-survive-fwk    (document has expired and should
>                                        be republished)
> 
> draft-yang-mpls-tp-ring-protection
> -analysis                             (accept as a MEAD team doc?)
> 
> As a member of the MEAD team you are expected to respond to the
> "accept as a MEAD team doc"?
> 
> As a a MEAD team member you are expected to supply your comments on
> draft-ietf-mpls-tp-oam-requirements on Fri Jan 30, the latest.
> 
> As an editor you are supposed to take the action (when the time is
> right) for the other document.
> 
> A reminder:
> 
> Becoming a MEAD team document means that there a strong element
> in that draft that the MEAD needs to coordinate, it won't stop
> us from splitting or merge documents, just that we will do so
> in a coordinated way.
> 
> Becoming wg documents means positive response to three questions.
> 
> - does this document address a problem that the wg needs to
>   solve
> - is this document a good enough start to solve this problem
> - is it within wg charter
> 
> /Loa
> 
> 

-- 

Loa Andersson

Sr Strategy and Standards Manager
Ericsson ///                          phone:  +46 8 632 77 14

                                       email:  [email-masked]
                                               [email-masked]
                                               [email-masked]

Date: Sat, 07 Feb 2009 15:51:18 +0000
From: Stewart Bryant <[email-masked]>
To: Loa Andersson <[email-masked]>
Cc: MEAD team <[email-masked]>
Subject: Re: [Mpls-interop] moving mpls-tp documents - you are supposed to respond
Reply-To: [email-masked]

Loa
>
> - draft-bryant-mpls-tp-ach-tlv
>
We moved some of the text of this draft to GAL-GACH and
will use draft-bryant-mpls-tp-ach-tlv  as the placeholder
for the TLV registry assignments.

I would suggest that we wait for the next revision of the draft.

Stewart

Date: Sat, 07 Feb 2009 17:26:09 +0100
From: Loa Andersson <[email-masked]>
To: MEAD team <[email-masked]>
Subject: [Mpls-interop] new poll on potential MEAD team documents

Team,

we have the following responses to the poll I tried earlier. This is
a bit more focused. The list contains (only) the potential mead team
documents, I've also registered the opinions from people who responded.

If you are not listed please enter an opinion in the list and send back
to me. Note that undecided covers almost anything other than yes or no,
e.g. "haven't had time read the document", "the info here might be
useful, but I'd like to see it organized in some other way".

People in the list don't need to respond (unless you changed your mind
or I misunderstood), the rest of you SHOULD respond, target date is
Friday Feb 13.

Question is: "Do you want this document accepted as a MEAD team
document?"

draft-boutros-mpls-tp-cv
============

-- yes --
    Lieven
    Ben
    Adrian

-- undecided --
    Nurit
    Annamaria

-- no --

draft-boutros-mpls-tp-fault
=============
-- yes --
    Lieven

-- undecided --
    Nurit
    Ben
    Annamaria

-- no --
    Adrian

draft-boutros-mpls-tp-performance
================
-- yes --
    Lieven
    Ben

-- undecided --
    Nurit

-- no --
    Adrian

draft-martinotti-mpls-tp-interworking
==================
-- yes --
    Annamaria
    Nurit
    Lieven

-- undecided --
    Ben

-- no --
    Adrian

draft-yang-mpls-tp-ring-protection-analysis
=====================
-- yes --
    Lieven
    Igor

-- undecided --
    Ben

-- no --
    Nurit

/Loa

-- 

Loa Andersson

Sr Strategy and Standards Manager
Ericsson ///                          phone:  +46 8 632 77 14

                                       email:  [email-masked]
                                               [email-masked]
                                               [email-masked]

Date: Sat, 07 Feb 2009 19:03:12 +0100
From: Huub van Helvoort <[email-masked]>
To: Loa Andersson <[email-masked]>
Cc: [email-masked], [email-masked], [email-masked], [email-masked]
Subject: Re: [Mpls-interop] [mpls-tp] Poll for draft-gray-mpls-tp-nm-req-03 to become an mpls	wg document
Reply-To: [email-masked]

Hej Loa,

You wrote:

> as you can see below the authors of draft-gray-mpls-tp-nm-req-03
> has request that we accept the draft as a working group draft.

Support.

Cheers, Huub.

-- 
================================
Always remember that you are unique...just like everyone else...

Date: Fri, 06 Feb 2009 17:51:53 +0100
From: Loa Andersson <[email-masked]>
To: Yoichi Maeda <[email-masked]>, Greg Jones <[email-masked]>, Ghani Abbas <[email-masked]>,  Huub Van Helvoort <[email-masked]>, Malcolm Betts <[email-masked]>,  Hing-Kam Lam <[email-masked]>, [email-masked], [email-masked]
Cc: Olaf Kolkman <[email-masked]>, Russ Housley <[email-masked]>, Scott Bradner <[email-masked]>, IETF MEAD team <[email-masked]>
Subject: [Mpls-interop] Liaison on the cooperation between IETF and ITU-T on MPLS-TP

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

All,

please find a liaison on the cooperation between IETF and ITU-T on
MPLS-TP included.

/Loa
-- 

Loa Andersson

Sr Strategy and Standards Manager
Ericsson ///                          phone:  +46 8 632 77 14

                                       email:  [email-masked]
                                               [email-masked]
                                               [email-masked]

--------------050007020007070503060408
Content-Type: application/msword;
 name="liaison-on-cooperation.doc"
Content-Transfer-Encoding: base64
Content-Disposition: inline;
 filename="liaison-on-cooperation.doc"

0M8R4KGxGuEAAAAAAAAAAAAAAAAAAAAAPgADAP7/CQAGAAAAAAAAAAAAAAABAAAAQgAAAAAA
AAAAEAAARQAAAAEAAAD+////AAAAAEEAAAD/////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
AAAAAAAAAAA--------------050007020007070503060408--

Date: Fri, 06 Feb 2009 18:13:06 +0100
From: Loa Andersson <[email-masked]>
To: Yoichi Maeda <[email-masked]>, Greg Jones <[email-masked]>, Ghani Abbas <[email-masked]>,  Huub Van Helvoort <[email-masked]>, Malcolm Betts <[email-masked]>,  Hing-Kam Lam <[email-masked]>, [email-masked], ITU/T ad hoc team on MPLS-TP <[email-masked]>, [email-masked]
Cc: Olaf Kolkman <[email-masked]>, Russ Housley <[email-masked]>, Scott Bradner <[email-masked]>, IETF MEAD team <[email-masked]>
Subject: [Mpls-interop] MPLS-TP requirements wg last call

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

All,

please find a liaison included that announces the start of a working
group last call on the MPLS-TP requirements and poll for support to
make the MPLS-TP network management requirements an MPLS wg draft.

/Loa

-- 

Loa Andersson

Sr Strategy and Standards Manager
Ericsson ///                          phone:  +46 8 632 77 14

                                       email:  [email-masked]
                                               [email-masked]
                                               [email-masked]

--------------020501030205020609060607
Content-Type: application/msword;
 name="liaison-tp-req-and-nm-req.doc"
Content-Transfer-Encoding: base64
Content-Disposition: inline;
 filename="liaison-tp-req-and-nm-req.doc"

0M8R4KGxGuEAAAAAAAAAAAAAAAAAAAAAPgADAP7/CQAGAAAAAAAAAAAAAAABAAAAPAAAAAAA
AAAAEAAAPwAAAAEAAAD+////AAAAADsAAAD/////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
AAAAAAAAAAAAAAAAAAA--------------020501030205020609060607--

From: "Adrian Farrel" <[email-masked]>
To: "Weingarten, Yaacov \(NSN - IL/Hod HaSharon\)" <[email-masked]>, "Sprecher, Nurit \(NSN - IL/Hod HaSharon\)" <[email-masked]>, "ext Ben Niven-Jenkins" <[email-masked]>
Date: Sun, 8 Feb 2009 16:52:59 -0000
Cc: [email-masked]
Subject: Re: [Mpls-interop] 1:N Protection Switching
Reply-To: Adrian Farrel <[email-masked]>

Hello Yaacov,

> I just wanted to ask a question for clarification -
> What you are suggesting (in the paragraph that starts with "You are
> correct...") is this relevant to 1+1 or 1:1 protection architecture?

Well, taking the quote a little further...
| You are correct that the solution for 1:1 would be a little more messy
| than 1+1
So the rest of the paragraph goes on to talk about 1:1.

> The two possibilities that were raised during an internal
> discussion are:
> 1. For 1+1 protection, you are suggesting that the source LSR
> should select to transmit either on the working or the recovery
> path (but not on both) and the sink LSRs (plural for P2MP)
> should read from both paths.  Then there would be no need to
> synchronize for 1+1 P2MP unidirectional protection once the
> root decides to switch, since all leaves will read from both
> paths and receive only on the recovery path.

(Hmm, the problem with my original text may be that I said the leaves 
"bridge" when I should have said "select".)

This sounds for all the world like 1:1.
That is, there is full reservation on both paths, but only one is in use at 
any time.

The point with 1+1 in a signal-based communication is that we do not even 
need to propagate a fault notification, because the receiver is selecting 
the "best" signal. In a packet network, this is a little less obvious, 
because the absence of data packets does not mean that the channel has 
failed. But suitable use of a heartbeat OAM packet can do everything that is 
necessary. (Or we can trigger bridging based on fault notification.)

There is, in general, a risk of packet loss/duplication during 1+1 failover. 
Many solutions have been implemented (usually at the client layer) using 
packet numbering, etc. But it should be noted that it is possible to push 
the problem to be only packet loss through knowledge of relative path delay 
times.

> 2. For 1:1 protection, you are suggesting that only the source
>  LSR should switch, as above.  For 1+1 protection the root
> will continue to bridge to both paths and the leaves will select
> the proper path to read from.

Yes, this is what I meant.

> Incidentally, if we are protecting a P2MP tree, it might happen
> that some leaves could read the traffic from the working path
> while others (who have detected failure conditions on their
> branches) may be reading the traffic from the recovery path.

Absolutely.
This means that 1+1 has higher value than 1:1 in a P2MP environment (IMHO).

> Which of these two explanations was your intention? Are
> both scenarios possible?

Did I answer?

Cheers,
Adrian

> -----Original Message-----
> From: ext Adrian Farrel [mailto:[email-masked]]
> Sent: Thursday, February 05, 2009 16:23
> To: Sprecher, Nurit (NSN - IL/Hod HaSharon); ext Ben Niven-Jenkins
> Cc: [email-masked]; Weingarten, Yaacov (NSN - IL/Hod HaSharon)
> Subject: Re: 1:N Protection Switching
>
> Hi Nurit,
>
> Just want to be really clear on your question because it looks to me
that
> you have mixed
> - unidirectional protection (in your first paragraph)
> - unidirectional P2MP (in your second paragraph)
>
> Of course, all P2MP LSPs are unidirectional.
> Given that, all protection of P2MP LSPs will be unidirectional.
>
> So the question is 1:n or 1+1.
>
> I do not see why 1:1 protection should not be used in a P2MP
situation.
> 1:n might be a little extreme, but is no different from an
implementation
> point of view.
>
> You are correct that the solution for 1:1 would be a little more messy
> than
> 1+1, but I am not sure that you are right that it is necessary to tell
all
> of the leaves. The leaves could be implemented to bridge, while the
source
> is responsible for switching. In this it is no different from P2P
> unidirectional LSPs. Any scaling issues are identical to the scaling
> issues
> of having multiple leaves.
>
> Adrian
>
>
> ----- Original Message -----
> From: "Sprecher, Nurit (NSN - IL/Hod HaSharon)"
<[email-masked]>
> To: "ext Ben Niven-Jenkins" <[email-masked]>
> Cc: "Adrian Farrel" <[email-masked]>; <[email-masked]>;
> "Weingarten, Yaacov (NSN - IL/Hod HaSharon)"
<[email-masked]>
> Sent: Thursday, February 05, 2009 8:21 AM
> Subject: 1:N Protection Switching
>
>
> Hi Ben,
>
> In the requirements for protection it is specified that for 1:n that
> "Unidirectional 1:n protection for P2MP connectivity MUST be
> supported.".
> Is it really required or it may be that the 1+1 is satisfactory to
cover
> this case of unidirectional P2MP?
> I ask it basically because of the need in 1:n to notify the source
that
> there is an error which requires the switch over. Then the source
needs
> to communicate this to all leaves. This requires a path back from the
> leaf to the source. We may assume that there is a path back,
out-of-band
> control channel between source and leaves, but it looks more
constrained
> assumption.
>
> I would propose to remove the requirement for unidirectional 1:n
> protection for P2MP connectivity or at least to put it as a MAY
> requirement.
>
> Regards,
> Nurit
>
> --
> Best regards,
> Nurit Sprecher
>
> Nokia Siemens Networks GmbH & Co. KG
> Industry Environment
> Senior Specialist, Carrier Ethernet Transport
> 3 Hanagar St. Neve Ne'eman B
> 45241 Hod Hasharon, Israel
>
> Tel. +972 9 7751229
> Mobile +972 54 2200954
> Email: [email-masked] <BLOCKED::mailto:[email-masked]>
>
>
>

Date: Thu, 12 Feb 2009 18:52:24 +0100
From: Loa Andersson <[email-masked]>
To: MEAD team <[email-masked]>
Subject: [Mpls-interop] copyrights for the MPLS-TP drafts and RFCs

All,

we will need an acknowledgment from all editors and co-authors of 
MPLS-TP documents that you are able to sign off on the copyrights
for the documents. The editors for each document needs to contact
their contributing authors and verify that this is the case.

Please confirm this to me as soon as possible.

/Loa
-- 

Loa Andersson

Sr Strategy and Standards Manager
Ericsson ///                          phone:  +46 8 632 77 14

                                       email:  [email-masked]
                                               [email-masked]
                                               [email-masked]

Content-class: urn:content-classes:message
Date: Thu, 12 Feb 2009 17:51:22 -0600
From: "Eric Gray" <[email-masked]>
To: "Loa Andersson" <[email-masked]>, "MEAD team" <[email-masked]>
Subject: Re: [Mpls-interop] copyrights for the MPLS-TP drafts and RFCs

Loa,

	I am able to sign off on copyright for any MPLS-TP document I
contribute to that subsequently becomes an RFC.

--
Eric Gray
Ericsson 

-----Original Message-----
From: [email-masked]
[mailto:[email-masked]] On Behalf Of Loa Andersson
Sent: Thursday, February 12, 2009 12:52 PM
To: MEAD team
Subject: [Mpls-interop] copyrights for the MPLS-TP drafts and RFCs

All,

we will need an acknowledgment from all editors and co-authors of 
MPLS-TP documents that you are able to sign off on the copyrights
for the documents. The editors for each document needs to contact
their contributing authors and verify that this is the case.

Please confirm this to me as soon as possible.

/Loa
-- 

Loa Andersson

Sr Strategy and Standards Manager
Ericsson ///                          phone:  +46 8 632 77 14

                                       email:
[email-masked]
                                               [email-masked]
                                               [email-masked]

_______________________________________________
Mpls-interop mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/mpls-interop

Date: Mon, 16 Feb 2009 12:41:08 +0100
From: Loa Andersson <[email-masked]>
To: MEAD team <[email-masked]>
Subject: [Mpls-interop] [Fwd: Meeting invitation: Mead Team Biweekly]

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

All,

we'll have a MEAD team tomorrow, the usual time 6pm (Stockholm),
5pm London, noon (US East Coast) 9am (US West Coast).

Please see the meeting coordinates enclosed, they are different
from what we had before.

This will basically be a Webex test run and we'll use a new
version that Matthew and Stewart are preparing.

/Loa
-- 

Loa Andersson

Sr Strategy and Standards Manager
Ericsson ///                          phone:  +46 8 632 77 14

                                       email:  [email-masked]
                                               [email-masked]
                                               [email-masked]

--------------010208010806070702050603
Content-Type: message/rfc822;
 name="Meeting invitation: Mead Team Biweekly.eml"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline;
 filename="Meeting invitation: Mead Team Biweekly.eml"

Date: Fri, 13 Feb 2009 17:43:45 GMT
From: Stewart Bryant <[email-masked]>
Reply-To: [email-masked]
To: [email-masked]
Subject: Meeting invitation: Mead Team Biweekly
Importance: normal

------=_Part_518_137119966.1234547025197
Content-Type: multipart/Alternative; 
	boundary="----=_Part_519_137120492.1234547025197"

------=_Part_519_137120492.1234547025197
Content-Type: text/plain;charset=iso-8859-1
Content-Transfer-Encoding: base64

------=_Part_519_137120492.1234547025197
Content-Type: text/html;charset=iso-8859-1
Content-Transfer-Encoding: base64

------=_Part_519_137120492.1234547025197--

------=_Part_518_137119966.1234547025197--

--------------010208010806070702050603--

Content-class: urn:content-classes:message
Date: Mon, 16 Feb 2009 13:33:36 +0100
From: "Annamaria Fulignoli" <[email-masked]>
To: <[email-masked]>
Subject: [Mpls-interop] MPLS-TP 1+1 bidirectional protection requirement on " draft-ietf-mpls-tp-requirements-04"

This is a multi-part message in MIME format.

------_=_NextPart_001_01C99032.C9EE3224
Content-Type: text/plain;
	charset="US-ASCII"
Content-Transfer-Encoding: quoted-printable

Hi all,
I'm sorry but I disagree with the Req. 54 of the ID :
"draft-ietf-mpls-tp-requirements-04".

Unidirectional and bidirectional 1+1 protection are the same with
regards to the requirement for simultaneous sending of traffic on both
LSPs and hence 100% traffic duplication.
However 1+1 unidirectional protection is a simpler scheme which doesn't
require a protocol for end-node coordination.

So I ask again that the default for the 1+1 protection is the
unidirectional one while the 1+1 bidirectional is optional ( or even not
required ).

Thank you. 
Best Regards,
Annamaria

------_=_NextPart_001_01C99032.C9EE3224
Content-Type: text/html;
	charset="US-ASCII"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=us-ascii">
<META NAME="Generator" CONTENT="MS Exchange Server version 6.5.7653.38">
<TITLE>MPLS-TP 1+1 bidirectional protection requirement on &quot; draft-ietf-mpls-tp-requirements-04&quot;</TITLE>
</HEAD>
<BODY>
<!-- Converted from text/rtf format -->

<P><FONT SIZE=2 FACE="Arial">Hi all,</FONT>

<BR><FONT SIZE=2 FACE="Arial">I'm sorry but I disagree with the Req. 54 of the ID : &quot;<SPAN LANG="en">draft-ietf-mpls-tp-requirements-04&quot;.</SPAN></FONT>
</P>

<P><SPAN LANG="it"><FONT COLOR="#000000" SIZE=2 FACE="Arial">Unidirectional and bidirectional 1+1 protection are the same with regards to the requirement for simultaneous sending of traffic on both LSPs and hence 100% traffic duplication.</FONT></SPAN></P>

<P><SPAN LANG="it"><FONT COLOR="#000000" SIZE=2 FACE="Arial">However 1+1 unidirectional protection is a simpler scheme which doesn't require a protocol for end-node coordination.</FONT></SPAN>
</P>

<P><SPAN LANG="it"><FONT SIZE=2 FACE="Arial">So I ask again that the default for the 1+1 protection is the unidirectional one while the 1+1 bidirectional is optional ( or even not required ).</FONT></SPAN></P>

<P><SPAN LANG="it"><FONT SIZE=2 FACE="Arial">Thank you. </FONT></SPAN>

<BR><SPAN LANG="it"><FONT SIZE=2 FACE="Arial">Best Regards,</FONT></SPAN>

<BR><SPAN LANG="it"><FONT SIZE=2 FACE="Arial">Annamaria</FONT></SPAN>
</P>
<BR>

</BODY>
</HTML>
------_=_NextPart_001_01C99032.C9EE3224--

Date: Mon, 16 Feb 2009 13:49:39 +0000
From: Ben Niven-Jenkins <[email-masked]>
To: Annamaria Fulignoli <[email-masked]>, <[email-masked]>
Subject: Re: [Mpls-interop] MPLS-TP 1+1 bidirectional protection requirement on " draft-ietf-mpls-tp-requirements-04"

Annamaria,

Your e-mail raises two separate questions:

1) Do we need to state a requirement for unidirectional P2P 1+1 protection
(current draft says it is not required)

2) Which should be the default mode, unidirectional 1+1 or bidirectional
1+1.

I would like to seek the opinion of others before changing, so does anyone
have a strong view one way or another to making

1) a requirement to support unidriectional P2P 1+1 protection
2) making it the default option instead of the current bidirectional 1+1
support?

Ben

On 16/02/2009 12:33, "Annamaria Fulignoli"
<[email-masked]> wrote:

> Hi all,
> I'm sorry but I disagree with the Req. 54 of the ID :
> "draft-ietf-mpls-tp-requirements-04".
> 
> Unidirectional and bidirectional 1+1 protection are the same with
> regards to the requirement for simultaneous sending of traffic on both
> LSPs and hence 100% traffic duplication.
> However 1+1 unidirectional protection is a simpler scheme which doesn't
> require a protocol for end-node coordination.
> 
> So I ask again that the default for the 1+1 protection is the
> unidirectional one while the 1+1 bidirectional is optional ( or even not
> required ).
> 
> Thank you. 
> Best Regards,
> Annamaria
> 
> 
> _______________________________________________
> Mpls-interop mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/mpls-interop

Content-class: urn:content-classes:message
Date: Tue, 17 Feb 2009 16:32:20 +0100
From: "BUSI ITALO" <[email-masked]>
To: "Ben Niven-Jenkins" <[email-masked]>, "Annamaria Fulignoli" <[email-masked]>, <[email-masked]>
Subject: Re: [Mpls-interop] MPLS-TP 1+1 bidirectional protection requirement on " draft-ietf-mpls-tp-requirements-04"

Ben,

I do not like 1+1 protection switching mechanisms in packet networks,
however it is true that 1+1 unidirectional protection switching is very
simple and allows trivial multi-vendor interoperability because it does
not rely upon any protocol to coordinate protection switching actions.

As a consequence, my opinion is that:

A) 1+1 unidirectional protection switching is required (for both p2p and
p2mp transport paths)

B) 1+1 bidirectional protection switching is not required (for neither
p2p nor p2mp transport paths)

If there are other requirements to support 1+1 bidirectional protection
switching, I would then support having the unidirectional mode as the
default for 1+1 protection switching.

Italo

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Ben Niven-Jenkins
> Sent: Monday, February 16, 2009 2:50 PM
> To: Annamaria Fulignoli; [email-masked]
> Subject: Re: [Mpls-interop] MPLS-TP 1+1 bidirectional 
> protection requirement on " draft-ietf-mpls-tp-requirements-04"
> 
> Annamaria,
> 
> Your e-mail raises two separate questions:
> 
> 1) Do we need to state a requirement for unidirectional P2P 
> 1+1 protection
> (current draft says it is not required)
> 
> 2) Which should be the default mode, unidirectional 1+1 or 
> bidirectional
> 1+1.
> 
> I would like to seek the opinion of others before changing, 
> so does anyone
> have a strong view one way or another to making
> 
> 1) a requirement to support unidriectional P2P 1+1 protection
> 2) making it the default option instead of the current 
> bidirectional 1+1
> support?
> 
> Ben
> 
> 
> On 16/02/2009 12:33, "Annamaria Fulignoli"
> <[email-masked]> wrote:
> 
> > Hi all,
> > I'm sorry but I disagree with the Req. 54 of the ID :
> > "draft-ietf-mpls-tp-requirements-04".
> > 
> > Unidirectional and bidirectional 1+1 protection are the same with
> > regards to the requirement for simultaneous sending of 
> traffic on both
> > LSPs and hence 100% traffic duplication.
> > However 1+1 unidirectional protection is a simpler scheme 
> which doesn't
> > require a protocol for end-node coordination.
> > 
> > So I ask again that the default for the 1+1 protection is the
> > unidirectional one while the 1+1 bidirectional is optional 
> ( or even not
> > required ).
> > 
> > Thank you. 
> > Best Regards,
> > Annamaria
> > 
> > 
> > _______________________________________________
> > Mpls-interop mailing list
> > [email-masked]
> > https://www.ietf.org/mailman/listinfo/mpls-interop
> 
> _______________________________________________
> Mpls-interop mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/mpls-interop
> 

Date: Wed, 11 Feb 2009 17:52:35 +0100
From: Loa Andersson <[email-masked]>
To: Yoichi Maeda <[email-masked]>, Greg Jones <[email-masked]>, Malcolm Betts <[email-masked]>,  Hing-Kam Lam <[email-masked]>, [email-masked], [email-masked]
Cc: Scott Bradner <[email-masked]>, IETF MEAD team <[email-masked]>
Subject: [Mpls-interop] Response to Liaison on MCC SCC for MPLS-TP

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

Mr Maeda, Mr Betts and Mr Lam,

please find a response to your liaison "Generic Associated
Channel (G-ACH) Requirement to Provide a Signalling Communication
Channel (SCC) and a Management Communication Channel (MCC) for
MPLS-TP".

/Loa
-- 

Loa Andersson

Sr Strategy and Standards Manager
Ericsson ///                          phone:  +46 8 632 77 14

                                       email:  [email-masked]
                                               [email-masked]
                                               [email-masked]

--------------020200030802030008020501
Content-Type: application/msword;
 name="scc-and-mcc-liaison.doc"
Content-Transfer-Encoding: base64
Content-Disposition: inline;
 filename="scc-and-mcc-liaison.doc"

0M8R4KGxGuEAAAAAAAAAAAAAAAAAAAAAPgADAP7/CQAGAAAAAAAAAAAAAAABAAAANgAAAAAA
AAAAEAAAOAAAAAEAAAD+////AAAAADUAAAD/////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
--------------020200030802030008020501--

Date: Tue, 17 Feb 2009 16:59:33 -0500
To: "Ben Niven-Jenkins" <[email-masked]>
From: Lou Berger <[email-masked]>
Cc: [email-masked]
Subject: [Mpls-interop] control plane interoperability requirement

Ben,
	It looks like we have a bit of disconnect between some of the 
existing documents regarding control plane interoperability 
requirements. We think the following change to the requirements draft 
will fix the issue:

Old text:
    3   Mechanisms and capabilities MUST be able to interoperate, without
        a gateway function, with existing IETF MPLS [RFC3031] and IETF
        PWE3 [RFC3985] control and data planes where appropriate.

New text:
    3   Mechanisms and capabilities MUST be able to interoperate with
        existing IETF MPLS [RFC3031] and IETF PWE3 [RFC3985] control and
        data planes where appropriate.

        a. data plane interoperability MUST NOT require a gateway function.

This will align the requirements with the current TP framework 
document which states: "GMPLS based MPLS-TP LSPs must be able to 
interoperate with RSVP-TE based MPLS-TE LSPs, as per [RFC 5146]"

Much thanks,
Lou (and Loa & Luyan)

Date: Wed, 18 Feb 2009 00:27:17 +0100
From: Huub van Helvoort <[email-masked]>
To: Annamaria Fulignoli <[email-masked]>
Cc: [email-masked]
Subject: Re: [Mpls-interop] MPLS-TP 1+1 bidirectional protection requirement on	" draft-ietf-mpls-tp-requirements-04"
Reply-To: [email-masked]

Ciao Annamaria,

You wrote:

> I'm sorry but I disagree with the Req. 54 of the ID : 
> "draft-ietf-mpls-tp-requirements-04".
> 
> Unidirectional and bidirectional 1+1 protection are the same with 
> regards to the requirement for simultaneous sending of traffic on both 
> LSPs and hence 100% traffic duplication.

Traffic is indeed sent on both LSPs, however the LSPs can have
different propagation delays.

> However 1+1 unidirectional protection is a simpler scheme which doesn't 
> require a protocol for end-node coordination.

I agree. However if both LSPs are bi-directional LSPs then a
unidirectional protection switch may result in a different
propagation delay in forward and backward direction.
There may be services that are sensitive to this latency.

Indeed bidirectional 1+1 protection switching requires
synchronisation of both ends selectors.

> So I ask again that the default for the 1+1 protection is the 
> unidirectional one while the 1+1 bidirectional is optional ( or even not 
> required ).

I think there is still a requirement for 1+1 bidirectional.

Kind regards, Huub.

-- 
================================
Always remember that you are unique...just like everyone else...

Content-class: urn:content-classes:message
Date: Wed, 18 Feb 2009 14:58:14 +0100
From: "BOCCI Matthew" <[email-masked]>
To: "MEAD team" <[email-masked]>
Subject: [Mpls-interop] Updated version of GACH-GAL draft

This is a multi-part message in MIME format.

------_=_NextPart_001_01C991D1.927F7A35
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_002_01C991D1.927F7A35"

------_=_NextPart_002_01C991D1.927F7A35
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

Please find attached an updated version of
draft-ietf-mpls-tp-gach-gal-02.txt, updated as per the discussion on the
MEAD team call yesterday.

Please can you let me know if you have any comments by the end of this
week. I would like to upload the new version to the IETF by Monday so
that Loa can initiate a second last call on this draft.

Best regards

Matthew
 <<draft-ietf-mpls-tp-gach-gal-02.txt>> 

------_=_NextPart_002_01C991D1.927F7A35
Content-Type: text/html;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=us-ascii">
<META NAME="Generator" CONTENT="MS Exchange Server version 6.5.7652.24">
<TITLE>Updated version of GACH-GAL draft</TITLE>
</HEAD>
<BODY>
<!-- Converted from text/rtf format -->

<P><FONT SIZE=2 FACE="Arial">Please find attached an updated version of draft-ietf-mpls-tp-gach-gal-02.txt, updated as per the discussion on the MEAD team call yesterday.</FONT></P>

<P><FONT SIZE=2 FACE="Arial">Please can you let me know if you have any comments by the end of this week. I would like to upload the new version to the IETF by Monday so that Loa can initiate a second last call on this draft.</FONT></P>

<P><FONT SIZE=2 FACE="Arial">Best regards</FONT>
</P>

<P><FONT SIZE=2 FACE="Arial">Matthew</FONT>

<BR><FONT FACE="Arial" SIZE=2 COLOR="#000000"> &lt;&lt;draft-ietf-mpls-tp-gach-gal-02.txt&gt;&gt; </FONT>
</P>

</BODY>
</HTML>
------_=_NextPart_002_01C991D1.927F7A35--

------_=_NextPart_001_01C991D1.927F7A35
Content-Type: text/plain;
	name="draft-ietf-mpls-tp-gach-gal-02.txt"
Content-Transfer-Encoding: base64
Content-Description: draft-ietf-mpls-tp-gach-gal-02.txt
Content-Disposition: attachment;
	filename="draft-ietf-mpls-tp-gach-gal-02.txt"

------_=_NextPart_001_01C991D1.927F7A35--

Content-class: urn:content-classes:message
Date: Fri, 20 Feb 2009 11:59:12 +0100
From: "BUSI ITALO" <[email-masked]>
To: "BOCCI Matthew" <[email-masked]>
Cc: MEAD team <[email-masked]>
Subject: Re: [Mpls-interop] Updated version of GACH-GAL draft

This is a multi-part message in MIME format.

------_=_NextPart_001_01C9934A.4476D0E7
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_002_01C9934A.4476D0E7"

------_=_NextPart_002_01C9934A.4476D0E7
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

Matthew,
 
see in attachment my comments on the draft.
 
Italo

________________________________

	From: [email-masked]
[mailto:[email-masked]] On Behalf Of BOCCI Matthew
	Sent: Wednesday, February 18, 2009 2:58 PM
	To: MEAD team
	Subject: [Mpls-interop] Updated version of GACH-GAL draft

	Please find attached an updated version of
draft-ietf-mpls-tp-gach-gal-02.txt, updated as per the discussion on the
MEAD team call yesterday.

	Please can you let me know if you have any comments by the end
of this week. I would like to upload the new version to the IETF by
Monday so that Loa can initiate a second last call on this draft.

	Best regards 

	Matthew 
	<<draft-ietf-mpls-tp-gach-gal-02.txt>> 

------_=_NextPart_002_01C9934A.4476D0E7
Content-Type: text/html;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD><TITLE>Updated version of GACH-GAL draft</TITLE>
<META http-equiv=Content-Type content="text/html; charset=us-ascii">
<META content="MSHTML 6.00.6000.16809" name=GENERATOR></HEAD>
<BODY>
<DIV dir=ltr align=left><FONT face="Courier New" size=2><SPAN 
class=201114610-20022009>Matthew,</SPAN></FONT></DIV>
<DIV dir=ltr align=left><FONT face="Courier New" size=2><SPAN 
class=201114610-20022009></SPAN></FONT>&nbsp;</DIV>
<DIV dir=ltr align=left><FONT face="Courier New" size=2><SPAN 
class=201114610-20022009>see in attachment my comments on the 
draft.</SPAN></FONT></DIV>
<DIV dir=ltr align=left><FONT face="Courier New" size=2><SPAN 
class=201114610-20022009></SPAN></FONT>&nbsp;</DIV>
<DIV dir=ltr align=left><FONT face="Courier New" size=2><SPAN 
class=201114610-20022009>Italo</SPAN></FONT></DIV><FONT face="Courier New" 
size=2></FONT><BR>
<BLOCKQUOTE dir=ltr 
style="PADDING-LEFT: 5px; MARGIN-LEFT: 5px; BORDER-LEFT: #000000 2px solid; MARGIN-RIGHT: 0px">
  <DIV class=OutlookMessageHeader lang=en-us dir=ltr align=left>
  <HR tabIndex=-1>
  <FONT face=Tahoma size=2><B>From:</B> [email-masked] 
  [mailto:[email-masked]] <B>On Behalf Of </B>BOCCI 
  Matthew<BR><B>Sent:</B> Wednesday, February 18, 2009 2:58 PM<BR><B>To:</B> 
  MEAD team<BR><B>Subject:</B> [Mpls-interop] Updated version of GACH-GAL 
  draft<BR></FONT><BR></DIV>
  <DIV></DIV><!-- Converted from text/rtf format -->
  <P><FONT face=Arial size=2>Please find attached an updated version of 
  draft-ietf-mpls-tp-gach-gal-02.txt, updated as per the discussion on the MEAD 
  team call yesterday.</FONT></P>
  <P><FONT face=Arial size=2>Please can you let me know if you have any comments 
  by the end of this week. I would like to upload the new version to the IETF by 
  Monday so that Loa can initiate a second last call on this draft.</FONT></P>
  <P><FONT face=Arial size=2>Best regards</FONT> </P>
  <P><FONT face=Arial size=2>Matthew</FONT> <BR><FONT face=Arial 
  size=2>&lt;&lt;draft-ietf-mpls-tp-gach-gal-02.txt&gt;&gt; 
</FONT></P></BLOCKQUOTE></BODY></HTML>

------_=_NextPart_002_01C9934A.4476D0E7--

------_=_NextPart_001_01C9934A.4476D0E7
Content-Type: text/plain;
	name="draft-ietf-mpls-tp-gach-gal-02-mead-ib.txt"
Content-Transfer-Encoding: base64
Content-Description: draft-ietf-mpls-tp-gach-gal-02-mead-ib.txt
Content-Disposition: attachment;
	filename="draft-ietf-mpls-tp-gach-gal-02-mead-ib.txt"

------_=_NextPart_001_01C9934A.4476D0E7--

Content-class: urn:content-classes:message
Date: Fri, 20 Feb 2009 12:08:26 +0100
From: "Sprecher, Nurit (NSN - IL/Hod HaSharon)" <[email-masked]>
To: "ext BOCCI Matthew" <[email-masked]>, "MEAD team" <[email-masked]>
Cc: "Weingarten, Yaacov \(NSN - IL/Hod HaSharon\)" <[email-masked]>
Subject: Re: [Mpls-interop] Updated version of GACH-GAL draft

This is a multi-part message in MIME format.

------_=_NextPart_001_01C9934B.918B9EB0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

Hi Matthew,

Thanks for the updated document. I am glad to see the SCH TLVs included
in this version.

I have an editorial comment to the entire document. I would propose to
change the name "Maintenance Message" to "Control Message" or Control
Message payload". The channels are used for control messages, and I
prefer the name to reflect it better. We do not say maintenance plane
but control plane, although it is used also for maintenance. 

Best regards,

Nurit

________________________________

From: [email-masked]
[mailto:[email-masked]] On Behalf Of ext BOCCI Matthew
Sent: Wednesday, February 18, 2009 15:58
To: MEAD team
Subject: [Mpls-interop] Updated version of GACH-GAL draft

Please find attached an updated version of
draft-ietf-mpls-tp-gach-gal-02.txt, updated as per the discussion on the
MEAD team call yesterday.

Please can you let me know if you have any comments by the end of this
week. I would like to upload the new version to the IETF by Monday so
that Loa can initiate a second last call on this draft.

Best regards 

Matthew 
<<draft-ietf-mpls-tp-gach-gal-02.txt>> 

------_=_NextPart_001_01C9934B.918B9EB0
Content-Type: text/html;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

<html xmlns:v="urn:schemas-microsoft-com:vml" xmlns:o="urn:schemas-microsoft-com:office:office" xmlns:w="urn:schemas-microsoft-com:office:word" xmlns="http://www.w3.org/TR/REC-html40">

<head>
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=us-ascii">
<meta name=Generator content="Microsoft Word 11 (filtered medium)">
<!--[if !mso]>
<style>
v\:* {behavior:url(#default#VML);}
o\:* {behavior:url(#default#VML);}
w\:* {behavior:url(#default#VML);}
.shape {behavior:url(#default#VML);}
</style>
<![endif]-->
<title>Updated version of GACH-GAL draft</title>
<style>
<!--
 /* Font Definitions */
 @font-face
	{font-family:Tahoma;
	panose-1:2 11 6 4 3 5 4 4 2 4;}
 /* Style Definitions */
 p.MsoNormal, li.MsoNormal, div.MsoNormal
	{margin:0in;
	margin-bottom:.0001pt;
	font-size:12.0pt;
	font-family:"Times New Roman";}
a:link, span.MsoHyperlink
	{color:blue;
	text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
	{color:purple;
	text-decoration:underline;}
p
	{mso-margin-top-alt:auto;
	margin-right:0in;
	mso-margin-bottom-alt:auto;
	margin-left:0in;
	font-size:12.0pt;
	font-family:"Times New Roman";}
span.EmailStyle18
	{mso-style-type:personal-reply;
	font-family:Arial;
	color:navy;}
@page Section1
	{size:595.3pt 841.9pt;
	margin:1.0in 1.25in 1.0in 1.25in;}
div.Section1
	{page:Section1;}
-->
</style>
<!--[if gte mso 9]><xml>
 <o:shapedefaults v:ext="edit" spidmax="1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
 <o:shapelayout v:ext="edit">
  <o:idmap v:ext="edit" data="1" />
 </o:shapelayout></xml><![endif]-->
</head>

<body lang=EN-US link=blue vlink=purple>

<div class=Section1 dir=RTL>

<p class=MsoNormal dir=LTR><font size=2 color=navy face=Arial><span
style='font-size:10.0pt;font-family:Arial;color:navy'>Hi Matthew,<o:p></o:p></span></font></p>

<p class=MsoNormal dir=LTR><font size=2 color=navy face=Arial><span
style='font-size:10.0pt;font-family:Arial;color:navy'>Thanks for the updated
document. I am glad to see the SCH TLVs included in this version.<o:p></o:p></span></font></p>

<p class=MsoNormal dir=LTR><font size=2 color=navy face=Arial><span
style='font-size:10.0pt;font-family:Arial;color:navy'><br>
I have an editorial comment to the entire document. I would propose to change
the name &quot;Maintenance Message&quot; to &quot;Control Message&quot; or
Control Message payload&quot;. The channels are used for control messages, and
I prefer the name to reflect it better. We do not say maintenance plane but
control plane, although it is used also for maintenance. <o:p></o:p></span></font></p>

<p class=MsoNormal dir=LTR><font size=2 color=navy face=Arial><span
style='font-size:10.0pt;font-family:Arial;color:navy'>Best regards,<o:p></o:p></span></font></p>

<p class=MsoNormal dir=LTR><font size=2 color=navy face=Arial><span
style='font-size:10.0pt;font-family:Arial;color:navy'>Nurit<o:p></o:p></span></font></p>

<p class=MsoNormal dir=LTR><font size=2 color=navy face=Arial><span
style='font-size:10.0pt;font-family:Arial;color:navy'><o:p>&nbsp;</o:p></span></font></p>

<p class=MsoNormal dir=LTR><font size=2 color=navy face=Arial><span
style='font-size:10.0pt;font-family:Arial;color:navy'><o:p>&nbsp;</o:p></span></font></p>

<div>

<div class=MsoNormal align=center dir=LTR style='text-align:center'><font
size=3 face="Times New Roman"><span style='font-size:12.0pt'>

<hr size=2 width="100%" align=center tabindex=-1>

</span></font></div>

<p class=MsoNormal dir=LTR><b><font size=2 face=Tahoma><span style='font-size:
10.0pt;font-family:Tahoma;font-weight:bold'>From:</span></font></b><font
size=2 face=Tahoma><span style='font-size:10.0pt;font-family:Tahoma'>
[email-masked] [mailto:[email-masked]] <b><span
style='font-weight:bold'>On Behalf Of </span></b>ext BOCCI Matthew<br>
<b><span style='font-weight:bold'>Sent:</span></b> Wednesday, February 18, 2009
15:58<br>
<b><span style='font-weight:bold'>To:</span></b> MEAD team<br>
<b><span style='font-weight:bold'>Subject:</span></b> [Mpls-interop] Updated
version of GACH-GAL draft</span></font><o:p></o:p></p>

</div>

<p class=MsoNormal dir=LTR><font size=3 face="Times New Roman"><span
style='font-size:12.0pt'><o:p>&nbsp;</o:p></span></font></p>

<p dir=LTR><font size=2 face=Arial><span style='font-size:10.0pt;font-family:
Arial'>Please find attached an updated version of
draft-ietf-mpls-tp-gach-gal-02.txt, updated as per the discussion on the MEAD
team call yesterday.</span></font><o:p></o:p></p>

<p dir=LTR><font size=2 face=Arial><span style='font-size:10.0pt;font-family:
Arial'>Please can you let me know if you have any comments by the end of this
week. I would like to upload the new version to the IETF by Monday so that Loa
can initiate a second last call on this draft.</span></font><o:p></o:p></p>

<p dir=LTR><font size=2 face=Arial><span style='font-size:10.0pt;font-family:
Arial'>Best regards</span></font> <o:p></o:p></p>

<p dir=LTR><font size=2 face=Arial><span style='font-size:10.0pt;font-family:
Arial'>Matthew</span></font> <br>
<font size=2 color=black face=Arial><span style='font-size:10.0pt;font-family:
Arial;color:black'>&lt;&lt;draft-ietf-mpls-tp-gach-gal-02.txt&gt;&gt; </span></font><o:p></o:p></p>

</div>

</body>

</html>

------_=_NextPart_001_01C9934B.918B9EB0--

Content-class: urn:content-classes:message
Date: Fri, 20 Feb 2009 12:31:32 +0100
From: "BOCCI Matthew" <[email-masked]>
To: "Sprecher, Nurit (NSN - IL/Hod HaSharon)" <[email-masked]>, "MEAD team" <[email-masked]>
Cc: "Weingarten, Yaacov \(NSN - IL/Hod HaSharon\)" <[email-masked]>
Subject: Re: [Mpls-interop] Updated version of GACH-GAL draft

This is a multi-part message in MIME format.

------_=_NextPart_001_01C9934E.C8D24CC9
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

Hi Nurit,
 
Thanks very much for your comments. The use of the term 'maintenance' is
not intended to exclude control functions, and we do include the
following statement in the draft:
 
"Note that, in this document, maintenance functions and packets should
be understood in the broad sense. That is, a set of maintenance and
management mechanisms that include OAM, Automatic Protection Switching
(APS), Signalling Communication Channel (SCC) and Management
Communication Channel (MCC) messages."
 
I don't have a strong opinion on this, but I do want to make sure that
it is absolutely clear that we are not precluding non-OAM messages, so
I'd appreciate some further feedback from the list before changing the
current text. I fear that if we do change the text we might get a
similar comment for "control" ;-)
 
Regards
 
Matthew

________________________________

	From: Sprecher, Nurit (NSN - IL/Hod HaSharon)
[mailto:[email-masked]] 
	Sent: 20 February 2009 11:08
	To: BOCCI Matthew; MEAD team
	Cc: Weingarten, Yaacov (NSN - IL/Hod HaSharon); Sprecher, Nurit
(NSN - IL/Hod HaSharon)
	Subject: RE: [Mpls-interop] Updated version of GACH-GAL draft

	Hi Matthew,

	Thanks for the updated document. I am glad to see the SCH TLVs
included in this version.

	I have an editorial comment to the entire document. I would
propose to change the name "Maintenance Message" to "Control Message" or
Control Message payload". The channels are used for control messages,
and I prefer the name to reflect it better. We do not say maintenance
plane but control plane, although it is used also for maintenance. 

	Best regards,

	Nurit

________________________________

	From: [email-masked]
[mailto:[email-masked]] On Behalf Of ext BOCCI Matthew
	Sent: Wednesday, February 18, 2009 15:58
	To: MEAD team
	Subject: [Mpls-interop] Updated version of GACH-GAL draft

	Please find attached an updated version of
draft-ietf-mpls-tp-gach-gal-02.txt, updated as per the discussion on the
MEAD team call yesterday.

	Please can you let me know if you have any comments by the end
of this week. I would like to upload the new version to the IETF by
Monday so that Loa can initiate a second last call on this draft.

	Best regards 

	Matthew 
	<<draft-ietf-mpls-tp-gach-gal-02.txt>> 

------_=_NextPart_001_01C9934E.C8D24CC9
Content-Type: text/html;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML xmlns="http://www.w3.org/TR/REC-html40" xmlns:v = 
"urn:schemas-microsoft-com:vml" xmlns:o = 
"urn:schemas-microsoft-com:office:office" xmlns:w = 
"urn:schemas-microsoft-com:office:word"><HEAD><TITLE>Updated version of GACH-GAL draft</TITLE>
<META http-equiv=Content-Type content="text/html; charset=us-ascii">
<META content="MSHTML 6.00.2900.5726" name=GENERATOR><!--[if !mso]>
<STYLE>v\:* {
	BEHAVIOR: url(#default#VML)
}
o\:* {
	BEHAVIOR: url(#default#VML)
}
w\:* {
	BEHAVIOR: url(#default#VML)
}
.shape {
	BEHAVIOR: url(#default#VML)
}
</STYLE>
<![endif]-->
<STYLE>@font-face {
	font-family: Tahoma;
}
@page Section1 {size: 595.3pt 841.9pt; margin: 1.0in 1.25in 1.0in 1.25in; }
P.MsoNormal {
	FONT-SIZE: 12pt; MARGIN: 0in 0in 0pt; FONT-FAMILY: "Times New Roman"
}
LI.MsoNormal {
	FONT-SIZE: 12pt; MARGIN: 0in 0in 0pt; FONT-FAMILY: "Times New Roman"
}
DIV.MsoNormal {
	FONT-SIZE: 12pt; MARGIN: 0in 0in 0pt; FONT-FAMILY: "Times New Roman"
}
A:link {
	COLOR: blue; TEXT-DECORATION: underline
}
SPAN.MsoHyperlink {
	COLOR: blue; TEXT-DECORATION: underline
}
A:visited {
	COLOR: purple; TEXT-DECORATION: underline
}
SPAN.MsoHyperlinkFollowed {
	COLOR: purple; TEXT-DECORATION: underline
}
P {
	FONT-SIZE: 12pt; MARGIN-LEFT: 0in; MARGIN-RIGHT: 0in; FONT-FAMILY: "Times New Roman"; mso-margin-top-alt: auto; mso-margin-bottom-alt: auto
}
SPAN.EmailStyle18 {
	COLOR: navy; FONT-FAMILY: Arial; mso-style-type: personal-reply
}
DIV.Section1 {
	page: Section1
}
</STYLE>
<!--[if gte mso 9]><xml>
 <o:shapedefaults v:ext="edit" spidmax="1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
 <o:shapelayout v:ext="edit">
  <o:idmap v:ext="edit" data="1" />
 </o:shapelayout></xml><![endif]--></HEAD>
<BODY lang=EN-US vLink=purple link=blue>
<DIV dir=ltr align=left><SPAN class=140412611-20022009><FONT face=Arial 
color=#0000ff size=2>Hi Nurit,</FONT></SPAN></DIV>
<DIV dir=ltr align=left><SPAN class=140412611-20022009><FONT face=Arial 
color=#0000ff size=2></FONT></SPAN>&nbsp;</DIV>
<DIV dir=ltr align=left><SPAN class=140412611-20022009><FONT face=Arial 
color=#0000ff size=2>Thanks very much for your comments. The use of the term 
'maintenance' is not intended to exclude control functions, and we do include 
the following statement in the draft:</FONT></SPAN></DIV>
<DIV dir=ltr align=left><SPAN class=140412611-20022009><FONT face=Arial 
color=#0000ff size=2></FONT></SPAN>&nbsp;</DIV>
<DIV dir=ltr align=left><SPAN class=140412611-20022009><FONT face=Arial 
color=#0000ff size=2>"Note that, in this document, maintenance functions and 
packets should be understood in the broad sense. That is, a set of maintenance 
and management mechanisms that include OAM, Automatic Protection Switching 
(APS), Signalling Communication Channel (SCC) and Management Communication 
Channel (MCC) messages."</FONT></SPAN></DIV>
<DIV dir=ltr align=left><SPAN class=140412611-20022009><FONT face=Arial 
color=#0000ff size=2></FONT></SPAN>&nbsp;</DIV>
<DIV dir=ltr align=left><SPAN class=140412611-20022009><FONT face=Arial 
color=#0000ff size=2>I don't have a strong opinion on this, but I do want to 
make sure that it is absolutely clear that we are not precluding non-OAM 
messages, so I'd appreciate some further feedback from the list before changing 
the current text. I fear that if we do change the text we might get a similar 
comment for "control" ;-)</FONT></SPAN></DIV>
<DIV dir=ltr align=left><SPAN class=140412611-20022009><FONT face=Arial 
color=#0000ff size=2></FONT></SPAN>&nbsp;</DIV>
<DIV dir=ltr align=left><SPAN class=140412611-20022009><FONT face=Arial 
color=#0000ff size=2>Regards</FONT></SPAN></DIV>
<DIV dir=ltr align=left><SPAN class=140412611-20022009><FONT face=Arial 
color=#0000ff size=2></FONT></SPAN>&nbsp;</DIV>
<DIV dir=ltr align=left><SPAN class=140412611-20022009><FONT face=Arial 
color=#0000ff size=2>Matthew</FONT></SPAN></DIV><BR>
<BLOCKQUOTE 
style="PADDING-LEFT: 5px; MARGIN-LEFT: 5px; BORDER-LEFT: #0000ff 2px solid; MARGIN-RIGHT: 0px">
  <DIV class=OutlookMessageHeader lang=en-us dir=ltr align=left>
  <HR tabIndex=-1>
  <FONT face=Tahoma size=2><B>From:</B> Sprecher, Nurit (NSN - IL/Hod HaSharon) 
  [mailto:[email-masked]] <BR><B>Sent:</B> 20 February 2009 
  11:08<BR><B>To:</B> BOCCI Matthew; MEAD team<BR><B>Cc:</B> Weingarten, Yaacov 
  (NSN - IL/Hod HaSharon); Sprecher, Nurit (NSN - IL/Hod 
  HaSharon)<BR><B>Subject:</B> RE: [Mpls-interop] Updated version of GACH-GAL 
  draft<BR></FONT><BR></DIV>
  <DIV></DIV>
  <DIV class=Section1 dir=rtl>
  <P class=MsoNormal dir=ltr><FONT face=Arial color=navy size=2><SPAN 
  style="FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: Arial">Hi 
  Matthew,<o:p></o:p></SPAN></FONT></P>
  <P class=MsoNormal dir=ltr><FONT face=Arial color=navy size=2><SPAN 
  style="FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: Arial">Thanks for the 
  updated document. I am glad to see the SCH TLVs included in this 
  version.<o:p></o:p></SPAN></FONT></P>
  <P class=MsoNormal dir=ltr><FONT face=Arial color=navy size=2><SPAN 
  style="FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: Arial"><BR>I have an 
  editorial comment to the entire document. I would propose to change the name 
  "Maintenance Message" to "Control Message" or Control Message payload". The 
  channels are used for control messages, and I prefer the name to reflect it 
  better. We do not say maintenance plane but control plane, although it is used 
  also for maintenance. <o:p></o:p></SPAN></FONT></P>
  <P class=MsoNormal dir=ltr><FONT face=Arial color=navy size=2><SPAN 
  style="FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: Arial">Best 
  regards,<o:p></o:p></SPAN></FONT></P>
  <P class=MsoNormal dir=ltr><FONT face=Arial color=navy size=2><SPAN 
  style="FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: Arial">Nurit<o:p></o:p></SPAN></FONT></P>
  <P class=MsoNormal dir=ltr><FONT face=Arial color=navy size=2><SPAN 
  style="FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: Arial"><o:p>&nbsp;</o:p></SPAN></FONT></P>
  <P class=MsoNormal dir=ltr><FONT face=Arial color=navy size=2><SPAN 
  style="FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: Arial"><o:p>&nbsp;</o:p></SPAN></FONT></P>
  <DIV>
  <DIV class=MsoNormal dir=ltr style="TEXT-ALIGN: center" align=center><FONT 
  face="Times New Roman" size=3><SPAN style="FONT-SIZE: 12pt">
  <HR tabIndex=-1 align=center width="100%" SIZE=2>
  </SPAN></FONT></DIV>
  <P class=MsoNormal dir=ltr><B><FONT face=Tahoma size=2><SPAN 
  style="FONT-WEIGHT: bold; FONT-SIZE: 10pt; FONT-FAMILY: Tahoma">From:</SPAN></FONT></B><FONT 
  face=Tahoma size=2><SPAN style="FONT-SIZE: 10pt; FONT-FAMILY: Tahoma"> 
  [email-masked] [mailto:[email-masked]] <B><SPAN 
  style="FONT-WEIGHT: bold">On Behalf Of </SPAN></B>ext BOCCI 
  Matthew<BR><B><SPAN style="FONT-WEIGHT: bold">Sent:</SPAN></B> Wednesday, 
  February 18, 2009 15:58<BR><B><SPAN style="FONT-WEIGHT: bold">To:</SPAN></B> 
  MEAD team<BR><B><SPAN style="FONT-WEIGHT: bold">Subject:</SPAN></B> 
  [Mpls-interop] Updated version of GACH-GAL 
  draft</SPAN></FONT><o:p></o:p></P></DIV>
  <P class=MsoNormal dir=ltr><FONT face="Times New Roman" size=3><SPAN 
  style="FONT-SIZE: 12pt"><o:p>&nbsp;</o:p></SPAN></FONT></P>
  <P dir=ltr><FONT face=Arial size=2><SPAN 
  style="FONT-SIZE: 10pt; FONT-FAMILY: Arial">Please find attached an updated 
  version of draft-ietf-mpls-tp-gach-gal-02.txt, updated as per the discussion 
  on the MEAD team call yesterday.</SPAN></FONT><o:p></o:p></P>
  <P dir=ltr><FONT face=Arial size=2><SPAN 
  style="FONT-SIZE: 10pt; FONT-FAMILY: Arial">Please can you let me know if you 
  have any comments by the end of this week. I would like to upload the new 
  version to the IETF by Monday so that Loa can initiate a second last call on 
  this draft.</SPAN></FONT><o:p></o:p></P>
  <P dir=ltr><FONT face=Arial size=2><SPAN 
  style="FONT-SIZE: 10pt; FONT-FAMILY: Arial">Best regards</SPAN></FONT> 
  <o:p></o:p></P>
  <P dir=ltr><FONT face=Arial size=2><SPAN 
  style="FONT-SIZE: 10pt; FONT-FAMILY: Arial">Matthew</SPAN></FONT> <BR><FONT 
  face=Arial color=black size=2><SPAN 
  style="FONT-SIZE: 10pt; COLOR: black; FONT-FAMILY: Arial">&lt;&lt;draft-ietf-mpls-tp-gach-gal-02.txt&gt;&gt; 
  </SPAN></FONT><o:p></o:p></P></DIV></BLOCKQUOTE></BODY></HTML>

------_=_NextPart_001_01C9934E.C8D24CC9--

Content-class: urn:content-classes:message
Date: Fri, 20 Feb 2009 12:52:52 +0100
From: "BOCCI Matthew" <[email-masked]>
To: "BUSI ITALO" <[email-masked]>
Cc: MEAD team <[email-masked]>
Subject: Re: [Mpls-interop] Updated version of GACH-GAL draft

This is a multi-part message in MIME format.

------_=_NextPart_001_01C99351.C47CC435
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

Italo,
 
Thanks for your comments.
 
Please see below for responses.
 
Matthew

MPLS Working Group                                         M. Bocci, Ed.
Internet-Draft                                         M. Vigoureux, Ed.
Updates: 3032, 4385, 5085                                 Alcatel-Lucent
 
<<Comment: I think it also updates RFC 4446>>
 
(if approved)                                                 G. Swallow
Intended status: Standards Track                                 D. Ward
Expires: August 15, 2009                                           Cisco
                                                             R. Aggarwal
                                                        Juniper Networks
                                                               S. Bryant
                                                                   Cisco
                                                       February 11, 2009

                 MPLS Generic Associated Channel Header
                     draft-ietf-mpls-tp-gach-gal-02
 
Status of this Memo
 
   By submitting this Internet-Draft, each author represents that any
   applicable patent or other IPR claims of which he or she is aware
   have been or will be disclosed, and any of which he or she becomes
   aware will be disclosed, in accordance with Section 6 of BCP 79.
 
   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF), its areas, and its working groups.  Note that
   other groups may also distribute working documents as Internet-
   Drafts.
 
   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."
 
   The list of current Internet-Drafts can be accessed at
   http://www.ietf.org/ietf/1id-abstracts.txt
<http://www.ietf.org/ietf/1id-abstracts.txt> .
 
   The list of Internet-Draft Shadow Directories can be accessed at
   http://www.ietf.org/shadow.html <http://www.ietf.org/shadow.html> .
 
   This Internet-Draft will expire on August 15, 2009.
 
Abstract
 
   This document generalises the applicability of the pseudowire (PW)
   Associated Channel Header (ACH), enabling the realization of a
   control channel associated to MPLS Label Switched Paths (LSPs) and
   MPLS Sections in addition to MPLS pseudowires.  In order to identify
   the presence of this ACH in the label stack, this document also

Bocci, et al.            Expires August 15, 2009                [Page 1]

Internet-Draft                G-ACH and GAL                February 2009

   assigns one of the reserved MPLS label values to the Generic
   Associated Channel Header Label (GAL), to be used as a label based
   exception mechanism.
 
Requirements Language
 
   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 RFC 2119 [1].

Table of Contents
 
   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
     1.1.  Contributing Authors . . . . . . . . . . . . . . . . . . .  4
     1.2.  Objectives . . . . . . . . . . . . . . . . . . . . . . . .  4
     1.3.  Scope  . . . . . . . . . . . . . . . . . . . . . . . . . .  4
     1.4.  Terminology  . . . . . . . . . . . . . . . . . . . . . . .  5
   2.  Generic Associated Channel Header  . . . . . . . . . . . . . .  5
     2.1.  Definition . . . . . . . . . . . . . . . . . . . . . . . .  5
     2.2.  Allocation of Channel Types  . . . . . . . . . . . . . . .  6
   3.  ACH TLVs . . . . . . . . . . . . . . . . . . . . . . . . . . .  6
     3.1.  ACH TLV Payload Structure  . . . . . . . . . . . . . . . .  7
     3.2.  ACH TLV Header . . . . . . . . . . . . . . . . . . . . . .  7
     3.3.  ACH TLV Object . . . . . . . . . . . . . . . . . . . . . .  8
   4.  Generalised Exception Mechanism  . . . . . . . . . . . . . . .  8
     4.1.  Relationship with Existing MPLS OAM Alert Mechanisms . . .  9
     4.2.  GAL Applicability and Usage  . . . . . . . . . . . . . . .  9
       4.2.1.  GAL Processing . . . . . . . . . . . . . . . . . . . .  9
     4.3.  Relationship wth RFC 3429  . . . . . . . . . . . . . . . . 12
   5.  Compatability  . . . . . . . . . . . . . . . . . . . . . . . . 12
   6.  Congestion Considerations  . . . . . . . . . . . . . . . . . . 13
   7.  Security Considerations  . . . . . . . . . . . . . . . . . . . 13
   8.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 13
   9.  Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 15
   10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 15
     10.1. Normative References . . . . . . . . . . . . . . . . . . . 15
     10.2. Informative References . . . . . . . . . . . . . . . . . . 16
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 16
   Intellectual Property and Copyright Statements . . . . . . . . . . 18

 

Bocci, et al.            Expires August 15, 2009                [Page 2]

Internet-Draft                G-ACH and GAL                February 2009

1.  Introduction
 
   There is a need for Operations, Administration and Maintenance (OAM)
   mechanisms that can be used for fault detection, diagnostics,
   maintenance and other functions on a PW and a LSP.  These functions
   can be used between any two Label Edge Routers (LERs) / Label
   Switching Router (LSRs) or Terminating Provider Edge routers (T-PEs)
   / Switching Provider Edge routers (S-PEs) along the path of an LSP or
   PW respectively [16].  Some of these functions can be supported using
   existing tools such as Virtual Circuit Connectivity Verification
   (VCCV) [2], Bidirectional Forwarding Detection for MPLS LSPs (BFD-
   MPLS)[3], LSP-Ping [4], or BFD-VCCV [5].  However, a requirement has
   been indicated to augment this set of maintenance functions, in
   particular when MPLS networks are used for packet transport services
   and transport network operations [17].  Examples of these functions
   include performance monitoring, automatic protection switching, and
   support for management and signaling communication channels.  These
 
<<Comment>>
 
Is it worth to capitalize the must"?
 
OLD
 
   tools must be applicable to, and function in essentially the same
 
NEW
 
   tools MUST be applicable to, and function in essentially the same
 
<<End Comment>>
 
   manner (from an operational point of view) on MPLS PWs, MPLS LSPs and
 
<<Comment>>
 
Is it worth to capitalize the must"?
 
MB> Yes. The RFC-ed will also make this comment. I agree with you on
these capitalisation points throughout.

OLD
 
   MPLS Sections.  They must also operate in-band on the PW or LSP such
 
NEW
 
   MPLS Sections.  They MUST also operate in-band on the PW or LSP such
 
<<End Comment>>
 
   that they do not depend on Packet Switched Network (PSN) routing or
 
<<Comment>>
 
Is it worth to capitalize the must"?
 
OLD
 
   on user data traffic, and must also not depend on dynamic control
 
NEW
 
   on user data traffic, and MUST also not depend on dynamic control
 
<<End Comment>>
 
   plane functions.
 
   VCCV can use an Associated Channel Header (ACH) to provide a PW-
   associated control channel between a PW's end points, over which OAM
   and other control messages can be exchanged.  This document
   generalises the use of the ACH to enable the same associated control
   channel mechanism to be used for Sections, LSPs and PWs.  The
   associated channel thus generalized is known as the Generic
   Associated Channel (G-ACh).  The ACH, specified in RFC 4385 [6], may
   be used with additional code points to support additional MPLS
   maintenance functions on the G-ACh.
 
   Generalizing the associated channel mechanism to LSPs and Sections
   also requires a method to identify that a packet contains an ACH
   followed by a non-service payload.  Therefore, this document also
   defines a label based exception mechanism that serves to inform an
   LSR (or LER) that a packet it receives on an LSP or Section belongs
   to an associated control channel for that LSP or Section.
 
   RFC 4379 [4] and BFD-MPLS [3] define alert mechanisms that enable an
   MPLS LSR to identify and process MPLS OAM packets when these are
   encapsulated in an IP header.  These alert mechanisms are based on
   MPLS or PW label Time to Live (TTL) expiration and/or on the use of
   an IP destination address in the range 127/8.  These mechanisms are
   the default mechanisms for identifying MPLS OAM packets when
   encapsulated in an IP header.  However it may not always be possible

Bocci, et al.            Expires August 15, 2009                [Page 3]

Internet-Draft                G-ACH and GAL                February 2009

   to use these mechanisms in some MPLS applications, e.g.  MPLS
   Transport Profile (MPLS-TP) [16], particularly when IP based
   demultiplexing cannot be used.  This document defines a mechanism
   that is RECOMMENDED for identifying and encapsulating MPLS OAM and
   other maintenance messages when IP based mechanisms such as those in
   [4] and [3] are not available.  This mechanism MAY be used in
   addition to IP-based mechanisms.
 
   The GAL mechanism is defined to work together with the ACH for LSPs
   and MPLS Sections.
 
   Note that, in this document, maintenance functions and packets should
   be understood in the broad sense.  That is, a set of FCAPS mechanisms
   that include OAM, Automatic Protection Switching (APS), Signalling
   Communication Channel (SCC) and Management Communication Channel
   (MCC) messages.
 
   Also note that the GAL and ACH are applicable to MPLS in general.
   Their applicability to specific applications of MPLS is outside the
   scope of this document.  For example, the applicability of the GAL
   and ACH to MPLS-TP is described in [16] and [18].
 
1.1.  Contributing Authors
 
   The editors gratefully acknowledge the contributions of Sami Boutros,
   Marc Lasserre, Lieven Levrau and Siva Sivabalan
 
1.2.  Objectives
 
   This document defines a mechanism that provides a solution to the
   extended maintenance needs of emerging applications for MPLS.  It
   creates a generic control channel mechanism that may be applied to
   MPLS LSPs and Sections, while maintaining compatibility with the PW
   associated channel.  It also normalises the use of the G-ACH for PWs
   in a transport context, and defines a label based exception mechanism
   to alert LERs/LSRs of the presence of an ACH after the bottom of the
   stack.
 
1.3.  Scope
 
   This document defines the encapsulation header for LSP, MPLS Section
   and PW associated channel messages.
 
   It does not define how associated control channel capabilities are
   signaled or negotiated between LERs/LSRs or PEs, or the operation of
   various OAM functions.
 
   This document does not deprecate existing MPLS and PW OAM mechanisms.

Bocci, et al.            Expires August 15, 2009                [Page 4]

Internet-Draft                G-ACH and GAL                February 2009

1.4.  Terminology
 
   ACH: Associated Channel Header
 
   G-ACh: Generic Associated Channel
 
<<Comment>>
 
If I understand correctly, this document calls G-ACh the Generic
Associate Channel and G-ACH the Generic Associated Channel Header.
 
ADD
 
   G-ACH: Generic Associated Channel Header
 
<<End Comment>>

MB> No, the associated channel header is just an ACH. There is no
difference from the existing ACH, so we do not need to call it a G-ACH.
However, the channel it creates is generic, becuase it applies to PWs,
LSPs and Sections, so it is a G-ACh. However, the title of the draft is
now confusing. The title should probably be changed to either
"Generalising the associated channel header for MPLS", or "MPLS Generic
Associated Channel". But that is probably a significant enough change to
be worth repeating as a last call comment.
 
   GAL: G-ACh Label
 
   Maintenance packet: Any packet containing a message belonging to a
   maintenance protocol that is carried on a PW, LSP or MPLS Section
   associated control channel.  Examples of such maintenance protocols
   include OAM functions, signaling communications or management
   communications.
 
   The terms 'Section' and 'Concatenated Segment' are defined in [19].

2.  Generic Associated Channel Header
 
   VCCV [2] defines three MPLS Control Channel (CC) Types that may be
   used to multiplex OAM messages onto a PW: CC Type 1 uses an ACH and
   is referred to as "In-band VCCV"; CC Type 2 uses the MPLS Router
   Alert Label to indicate VCCV packets and is referred to as "Out of
   Band VCCV"; CC Type 3 uses the TTL to force the packet to be
   processed by the targeted router control plane and is referred to as
   "MPLS PW Label with TTL == 1".
 
2.1.  Definition
 
   The use of the CC Type 1, previously limited to PWs, is extended to
   also apply to LSPs and to Sections.  This header that identifies the
   associated control channel is called the Generic Associated Channel
   Header (G-ACH).  Note that for PWs, the PWE3 control word [6]MUST be
   present in the encapsulation of user packets when the ACH is used to
   realize the associated control channel.
 
   The CC Type 1 channel header is depicted in figure below:
 
    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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |0 0 0 1|Version|   Reserved    |         Channel Type          |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 
                    Figure 1: Associated Channel Header
 
   In the above figure, the first nibble is set to 0001b to indicate a
   control channel associated with a PW, an LSP or a Section.  The

Bocci, et al.            Expires August 15, 2009                [Page 5]

Internet-Draft                G-ACH and GAL                February 2009

   Version field is set to 0, as specified in RFC 4385 [6].  Bits 8 to
   14 of the G-ACH are reserved and MUST be set to 0 and ignored on
   reception.
 
   Note that VCCV also includes mechanisms for negotiating the Control
   Channel and Connectivity Verification (i.e.  OAM functions) Types
   between PEs.  It is anticipated that similar mechanisms will be
   applied to LSPs.  Such application will require further
   specification.  However, such specification is beyond the scope of
   this document.
 
2.2.  Allocation of Channel Types
 
   The Channel Type field indicates the type of message carried on the
   associated control channel e.g.  IPv4 or IPv6 if IP demultiplexing is
   used for messages sent on the associated channel, or OAM or other
   FCAPS function if IP demultiplexing is not used.  For associated
   channel packets where IP is not used as the multiplexer, the Channel
   Type SHOULD indicate the specific maintenance protocol carried in the
   associated control channel.
 
   Values for the Channel Type field currently used for VCCV are
   specified elsewhere, e.g. in RFC 4446 and RFC 4385. [7].  Additional
   Channel Type values and the associated maintenance functionality will
   be defined in other documents.  Each document specifying a protocol
   solution relying on the ACH MUST also specify the applicable Channel
   Type field value.
 
   Note that these values are allocated from the PW Associated Channel
   Type registry, but this document modifies the existing policy to
   accommodate a level of experimentation.  See Section 8 for further
   details.

3.  ACH TLVs
 
   In some applications of the associated channel it is necessary to
   include one or more ACH TLVs to provide additional context
   information to the maintenance packet.  One use of these ACH TLVs
   might be to identify the source and/or intended destination of the
   associated channel maintenance message.  However, the use of this
   construct is not limited to providing addressing information nor is
   the applicability restricted to transport network applications.
 
   If the maintenance message MAY be preceded by one or more ACH TLVs,
   then this MUST be explicitly specified in the definition of a ACH
   Channel Type.  If the ACH Channel Type definition does state that one
   or more ACH TLVs MAY precede the maintenance message, an ACH TLV

Bocci, et al.            Expires August 15, 2009                [Page 6]

Internet-Draft                G-ACH and GAL                February 2009

   Header MUST follow the ACH.  If no ACH TLVs are required in a specifc
   associated channel packet, but the channel type nevertheless defines
   that ACH TLVs MAY be used, an ACH TLV Header MUST be present but with
   a length field set to zero to indicate that no ACH TLVs follow.
 
   If a channel type specification does not explicitly specify that ACH
   TLVs MAY be used, then an ACH TLV MUST NOT be used.
 
3.1.  ACH TLV Payload Structure
 
   This section defines and describes the structure of the set of ACH
   TLVs that MAY follow an ACH.  It then defines and describes the
   structure of an ACH TLV object.
 
   The following figure (Figure 2) shows the structure of a G-ACh packet
   payload.
 
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                              ACH                              |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                         ACH TLV Header                        |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                                                               ~
   ~                     zero or more ACH TLVs                     ~
   ~                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                                                               ~
   ~                      Maintenance Message                      ~
   ~                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 
                    Figure 2: ACH TLV Payload Structure
 
3.2.  ACH TLV Header
 
   The ACH TLV Header defines the length of the set of ACH TLVs that
   follow.
 
    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                 |          Reserved           |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 
                         Figure 3: ACH TLV Header
 
   The length field specifies the length in octets of the complete set
<<Comment>>
 
Please rephrase:
 
OLD
 
   of TLVs including TLVs that follow the ACH TLV header.  A length of
 
NEW
 
   of TLVs that follow the ACH TLV header.  A length of
 
<<End Comment>>
 
MB> OK

Bocci, et al.            Expires August 15, 2009                [Page 7]

Internet-Draft                G-ACH and GAL                February 2009

   zero indicates that no ACH TLVs follow this header.
 
   The reserved field is for future use and must be set to zero on
   transmission and ignored on reception.
 
3.3.  ACH TLV Object
 
   An ACH TLV consists of a 16-bit Type field, followed by a 16-bit
   Length field which specifies the number of octets of the Value field
   which follows the Length field.  This 32-bit word is followed by zero
   or more octets of Value information.  The format and semantics of the
   value information are defined by the TLV Type as recorded in the TLV
 
<<Comment>>
 
The sentence "Note that ACH TLVs may be sub-TLVs of other ACH TLVs." is
not fully clear (at least to me).
 
My understanding is that sub-TLVs are TLVs within the Value field of a
"parent" TLV object.
 
If my understanding is correct please rephrase:
 
OLD
 
   Type registry.  See Section 8 for further details.  Note that ACH
   TLVs may be sub-TLVs of other ACH TLVs.
 
NEW
 
   Type registry.  See Section 8 for further details.  Note that the
Value field of
   ACH TLVs MAY contain sub-TLVs objects.
 
<<End Comment>>

MB> OK with me.

    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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |           TLV Type            |          Length               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                                                               ~
   ~                             Value                             ~
   ~                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 
                         Figure 4: ACH TLV Format

4.  Generalised Exception Mechanism
 
   Generalizing the associated channel mechanism to LSPs and Sections
   also requires a method to identify that a packet contains an ACH
   followed by a non-service payload.  This document specifies that a
   label is used for that purpose and calls this special label the G-ACh
   Label (GAL).  One of the reserved label values defined in RFC 3032
   [8] is assigned for this purpose.  The value of the label is to be
   allocated by IANA; this document suggests the value 13.
 
   The GAL provides an alert based exception mechanism to:
 
   o  differentiate specific packets (e.g. maintenance messages) from
      others, such as normal user-plane ones,
 
   o  indicate that the ACH appears immediately after the bottom of the
      label stack.
 
   The GAL MUST only be used where both of these purposes apply.

Bocci, et al.            Expires August 15, 2009                [Page 8]

Internet-Draft                G-ACH and GAL                February 2009

4.1.  Relationship with Existing MPLS OAM Alert Mechanisms
 
   RFC 4379 [4] and BFD-MPLS [3] have defined alert mechanisms that
   enable a MPLS LSR to identify and process MPLS OAM packets when the
   OAM packets are encapsulated in an IP header.  These alert mechanisms
   are based on TTL expiration and/or use an IP destination address in
   the range 127/8.
 
   These alert mechanisms SHOULD be used in non MPLS-TP environments,
   although the mechanism defined in this document MAY also be used.
 
4.2.  GAL Applicability and Usage
 
   The GAL MUST only be used with LSPs, concatenated segments of LSPs,
   and with Sections.
 
   In MPLS-TP, the GAL MUST always be at the bottom of the label stack
   (i.e.  S bit set to 1).  However, in other MPLS environments, this
   document places no restrictions on where the GAL may appear within
   the label stack.
 
   The GAL MUST NOT appear in the label stack when transporting normal
   user-plane packets.  Furthermore, when present, the GAL MUST only
   appear once in the label stack.
 
4.2.1.  GAL Processing
 
   The Traffic Class (TC) field (formerly known as the EXP field) of the
   label stack entry containing the GAL follows the definition and
   processing rules specified and referenced in [9].
 
   The Time-To-Live (TTL) field of the label stack entry that contains
   the GAL follows the definition and processing rules specified in
   [10].
 
4.2.1.1.  MPLS Label Switched Paths and Segments
 
   The following figure (Figure 5) depicts two LERs (A and D) and two
   LSRs (B and C) for a given LSP which is established from A to D and
   switched in B and C.
 
        +---+             +---+             +---+             +---+
        | A |-------------| B |-------------| C |-------------| D |
        +---+             +---+             +---+             +---+
 
                 Figure 5: MPLS-TP maintenance over a LSP
 
   In this example, a G-ACh exists on an LSP that extends between LERs A

Bocci, et al.            Expires August 15, 2009                [Page 9]

Internet-Draft                G-ACH and GAL                February 2009

   and D, via LSRs B and C. Only these nodes may insert, extract or
   process packets on the G-ACh.
 
   The following figure (Figure 6) depicts the format of a MPLS-TP
   maintenance message when used for a LSP.
 
    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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |               LSP Label               |  TC |S|       TTL     |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                  GAL                  |  TC |S|       TTL     |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                              ACH                              |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                  ACH TLV Header (if present)                  |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                                                               ~
   ~                     Zero or more ACH TLVs                     ~
   ~                           (if present)                        |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                                                               ~
   ~                      Maintenance Message                      ~
   ~                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 
          Figure 6: MPLS-TP maintenance message format for a LSP
 
   Note that it is possible that the LSP may be tunnelled in another LSP
   (e.g. if a MPLS Tunnel exists between B and C), and as such other
   labels may be present in the label stack.
 
   To send a maintenance message on the LSP associated control channel,
   the LER (A) generates a maintenance message, to which it MAY
   prepended an ACH TLV header and appropriate ACH TLVs, and with a ACH
   to which it pushes a GAL and finally the LSP label.
 
   o  The TTL field of the GAL MUST be set to at least 1.  The exact
      value of the TTL is application specific.
 
   o  The S bit of the GAL MUST be set according to its position in the
      label stack.
 
   o  The setting of the TC field is application specific.
 
   The maintenance message, the ACH or the GAL SHOULD NOT be modified
   towards the targeted destination.  Upon reception of the labelled
   packet, the targeted destination, after having checked both the LSP

Bocci, et al.            Expires August 15, 2009               [Page 10]

Internet-Draft                G-ACH and GAL                February 2009

   label and GAL fields, SHOULD pass the whole maintenance message to
   the appropriate processing entity.
 
4.2.1.2.  MPLS Section
 
   The following figure (Figure 7) depicts an example of a MPLS Section.
 
                          +---+             +---+
                          | A |-------------| Z |
                          +---+             +---+
 
                Figure 7: Maintenance over an MPLS Section
 
   With regard to the MPLS Section, a G-ACh exists between A and Z. Only
   A and Z can insert, extract or process packets on the G-ACh.
 
   The following figure (Figure 8) depicts the format of a maintenance
   message when used for a MPLS Section.  The GAL MAY provide the
   exception mechanism for a control channel in its own right without
   being associated with a specific LSP, thus providing maintenance
   related communications across a specific link interconnecting two
   LSRs.  In this case, the GAL is the only label in the stack.
 
    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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                  GAL                  |  TC |S|       TTL     |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                             ACH                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                  ACH TLV Header (if present)                  |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                                                               ~
   ~                     Zero or more ACH TLVs                     ~
   ~                         (if present)                          |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                                                               ~
   ~                      Maintenance Message                      ~
   ~                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 
          Figure 8: Maintenance message format for a MPLS Section
 
   To send a maintenance message on a control channel associated to the
   Section, the head-end LSR (A) of the Section generates a maintenance
   message, to which it MAY prepend an ACH TLV Header and appropriate
   ACH TLVs, and with a ACH to which it pushes a GAL.

Bocci, et al.            Expires August 15, 2009               [Page 11]

Internet-Draft                G-ACH and GAL                February 2009

   o  The TTL field of the GAL MUST be set to at least 1.  The exact
      value of the TTL is application specific.
 
   o  The S bit of the GAL MUST be set according to its position in the
      label stack.  For MPLS Sections, the S bit MUST be set to 1.
 
<<Comment>>
 
While a fully agree that for MPLS-TP Sections the S bit MUST be set to
1, I am not 100% sure that this is true also for MPLS Sections.
 
<<End Comment>>
 
MB> If an MPLS section turns out to be another MPLS LSP on which a hash
label or something is used, then I guess you are right. Maybe we should
make the same statement as for LSPs. However, this is significant
enought that we should proably raise this during the second LC.
 
   o  The setting of the TC field is application specific.
 
   The maintenance message, the ACH and the GAL SHOULD NOT be modified
   towards the tail-end LSR (Z).  Upon reception of the labelled packet,
   the tail-end LSR (Z), after having checked the GAL fields, SHOULD
   pass the whole packet to the appropriate processing entity.
 
4.3.  Relationship wth RFC 3429
 
   RFC 3429 [20] describes the assignment of one of the reserved label
   values, defined in RFC 3032 [8], to the 'OAM Alert Label' that is
   used by user-plane MPLS OAM functions for the identification of MPLS
   OAM packets.  The value of 14 is used for that purpose.
 
   Both this document and RFC 3429 [20] therefore describe the
   assignment of reserved label values for similar purposes.  The
   rationale for the assignment of a new reserved label can be
   summarized as follows:
 
   o  Unlike the mechanisms described and referenced in RFC 3429 [20],
      MPLS-TP maintenance messages will not reside immediately after the
      GAL but instead behind the G-ACH, which itself resides after the
      bottom of the label stack.  This ensures that OAM, using the
      G-ACh, complies with RFC 4928 [11].
 
   o  The set of maintenance functions potentially operated in the
      context of the G-ACh is wider than the set of OAM functions
      referenced in RFC 3429 [20].
 
   o  It has been reported that there are existing implementations and
      running deployments using the 'OAM Alert Label' as described in
      RFC 3429 [20].  It is therefore not possible to modify the 'OAM
      Alert Label' allocation, purpose or usage.  Nevertheless, it is
      RECOMMENDED by this document that no further OAM extensions based
      on 'OAM Alert Label' (Label 14) usage be specified or developed.

5.  Compatability
 
   Procedures for handling a packet received with an invalid incoming
   label are specified in RFC 3031[12].

Bocci, et al.            Expires August 15, 2009               [Page 12]

Internet-Draft                G-ACH and GAL                February 2009

   An LER, LSR or PE MUST discard received associated channel packets on
   which all of the MPLS or PW labels have been popped if any one of the
   following conditions is true:
 
   o  It is not capable of processing packets on the Channel Type
      indicated by the ACH of the received packet.
 
   o  It has not, through means outside the scope of this document,
      indicated to the sending LSR, LER or PE that it will process
      associated channel packets on the Channel Type indicated by the
      ACH of the received packet.
 
   o  If the ACH was indicated by the presence of a GAL, and the first
      nibble of the ACH of the received packet is not 0b0001.
 
   o  The ACH version is not recognised.
 
   In addition, it MAY increment an error counter and MAY also
   optionally issue a system and/or SNMP notification.

6.  Congestion Considerations
 
   The congestion considerations detailed in RFC 5085 [2] apply.

7.  Security Considerations
 
   The security considerations for the associated control channel are
   descrbed in RFC 4385[6].  Further security considerations must be
   described in the relevant associated chanel type specification.
 
   RFC 5085 [2] provides data plane related security considerations.
   These also apply to a G-ACh, whether the alert mechanism uses a GAL
   or only an ACH.

8.  IANA Considerations
 
   This document requests that IANA allocates a label value, to the GAL,
   from the pool of reserved labels, and suggests this value to be 13.
 
   Channel Types for the Generic Associated Channel Header are allocated
   from the IANA PW Associated Channel Type registry [7].  The PW
   Associated Channel Type registry is currently allocated based on the
   IETF consensus process, described in [13].  This allocation process
   was chosen based on the consensus reached in the PWE3 working group
   that pseudowire associated channel mechanisms should be reviewed by

Bocci, et al.            Expires August 15, 2009               [Page 13]

Internet-Draft                G-ACH and GAL                February 2009

   the IETF and only those that are consistent with the PWE3
   architecture and requirements should be allocated a code point.
 
   However, a requirement has emerged (see [17]) to allow for
   optimizations or extensions to OAM and other control protocols
 
<<Comment>>
 
Please rephrase:
 
OLD
 
   running in an associated channel to be experimented with without
 
NEW
 
   running in an associated channel to be experimented without
 
<<End Comment>>
 
MB> OK thanks.
 
   resorting to the IETF standards process, by supporting experimental
   code points.  This would prevent code points used for such functions
   from being used from the range allocated through the IETF standards
   and thus protects an installed base of equipment from potential
   inadvertent overloading of code points.  In order to support this
   requirement, this document requests that the code point allocation
   scheme for the PW Associated Channel Type be changed as follows:
 
   0 - 32751 : IETF Consensus
 
   32752 - 32767 : Experimental
 
   Code points in the experimental range MUST be used according to the
   guidelines of RFC 3692 [14].  Experimental OAM functions MUST be
   disabled by default.  The channel type value used for a given
   experimental OAM function MUST be configurable, and care MUST be
   taken to ensure that different OAM functions that are not inter-
   operable are configured to use different channel type values.
 
   The PW Associated Channel Type registry needs to be updated to
   include a column indicating whether the ACH is followed by a TLV
   header (Yes/No).  There are two ACH Channel Type code-points
   currently assigned and in both cases no TLV header is used.  Thus the
   new format of the PW Channel Type registry is:
 
   Registry:
   Value  Description                   TLV Follows  Reference
   -----  ----------------------------  -----------  ---------
   0x21   ACH carries an IPv4 packet    No           [RFC4385]
   0x57   ACH carries an IPv6 packet    No           [RFC4385]
 
                    Figure 9: PW Channel Type registry
 
   IANA is requested create a new registry called the Associated Channel
   TLV Registry.  The allocation policy for this registry is IETF
   consensus.  This registry must record the following information.
   There are no initial entries.
 
   Name       Type  Length   Description                  Reference
                   (octets)
 
                      Figure 10: PW ACH TLV registry
 
<<Comment>>
 
I wonder whether it would be useful to allocate at least one TLV for
experimental use.
 
<<End Comment>>
 
MB> Do we really need this if we use an experimental channel type? In
any case, I am not sure we are being inconsistent with the above text if
we specficy one code point in the ACH TLV draft that is experimental.

Bocci, et al.            Expires August 15, 2009               [Page 14]

Internet-Draft                G-ACH and GAL                February 2009

9.  Acknowledgements
 
   The authors would like to thank all members of the teams (the Joint
   Working Team, the MPLS Interoperability Design Team in IETF and the
   MPLS-TP Ad-Hoc Team in ITU-T) involved in the definition and
   specification of MPLS Transport Profile.

10.  References
 
10.1.  Normative References
 
   [1]   Bradner, S., "Key words for use in RFCs to Indicate Requirement
         Levels", BCP 14, RFC 2119, March 1997.
 
   [2]   Nadeau, T. and C. Pignataro, "Pseudowire Virtual Circuit
         Connectivity Verification (VCCV): A Control Channel for
         Pseudowires", RFC 5085, December 2007.
 
   [3]   Aggarwal, R., Kompella, K., Nadeau, T., and G. Swallow, "BFD
         For MPLS LSPs", draft-ietf-bfd-mpls-07 (work in progress),
         June 2008.
 
   [4]   Kompella, K. and G. Swallow, "Detecting Multi-Protocol Label
         Switched (MPLS) Data Plane Failures", RFC 4379, February 2006.
 
   [5]   Nadeau, T. and C. Pignataro, "Bidirectional Forwarding
         Detection (BFD) for the Pseudowire Virtual Circuit
         Connectivity Verification (VCCV)", draft-ietf-pwe3-vccv-bfd-02
         (work in progress), June 2008.
 
   [6]   Bryant, S., Swallow, G., Martini, L., and D. McPherson,
         "Pseudowire Emulation Edge-to-Edge (PWE3) Control Word for Use
         over an MPLS PSN", RFC 4385, February 2006.
 
   [7]   Martini, L., "IANA Allocations for Pseudowire Edge to Edge
         Emulation (PWE3)", BCP 116, RFC 4446, April 2006.
 
   [8]   Rosen, E., Tappan, D., Fedorkow, G., Rekhter, Y., Farinacci,
         D., Li, T., and A. Conta, "MPLS Label Stack Encoding",
         RFC 3032, January 2001.
 
   [9]   Andersson, L. and R. Asati, "Multi-Protocol Label Switching
         (MPLS) label stack entry: "EXP" field renamed  to "Traffic
         Class" field", draft-ietf-mpls-cosfield-def-08 (work in
         progress), December 2008.
 
   [10]  Agarwal, P. and B. Akyol, "Time To Live (TTL) Processing in

Bocci, et al.            Expires August 15, 2009               [Page 15]

Internet-Draft                G-ACH and GAL                February 2009

         Multi-Protocol Label Switching (MPLS) Networks", RFC 3443,
         January 2003.
 
   [11]  Swallow, G., Bryant, S., and L. Andersson, "Avoiding Equal Cost
         Multipath Treatment in MPLS Networks", BCP 128, RFC 4928,
         June 2007.
 
   [12]  Rosen, E., Viswanathan, A., and R. Callon, "Multiprotocol Label
         Switching Architecture", RFC 3031, January 2001.
 
   [13]  Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA
         Considerations Section in RFCs", BCP 26, RFC 2434,
         October 1998.
 
   [14]  Narten, T., "Assigning Experimental and Testing Numbers
         Considered Useful", BCP 82, RFC 3692, January 2004.
 
   [15]  Bryant, S. and P. Pate, "Pseudo Wire Emulation Edge-to-Edge
         (PWE3) Architecture", RFC 3985, March 2005.
 
10.2.  Informative References
 
   [16]  Bocci, M., Bryant, S., and L. Levrau, "A Framework for MPLS in
         Transport Networks", draft-ietf-mpls-tp-framework-00 (work in
         progress), November 2008.
 
   [17]  Vigoureux, M., Ward, D., and M. Betts, "Requirements for OAM in
         MPLS Transport Networks",
         draft-ietf-mpls-tp-oam-requirements-00 (work in progress),
         December 2008.
 
   [18]  Busi, I. and B. Niven-Jenkins, "MPLS-TP OAM Framework and
         Overview", draft-busi-mpls-tp-oam-framework-00 (work in
         progress), October 2008.
 
   [19]  Niven-Jenkins, B., Brungard, D., Betts, M., Sprecher, N., and
         S. Ueno, "MPLS-TP Requirements",
         draft-ietf-mpls-tp-requirements-04 (work in progress),
         February 2009.
 
   [20]  Ohta, H., "Assignment of the 'OAM Alert Label' for
         Multiprotocol Label Switching Architecture (MPLS) Operation and
         Maintenance (OAM) Functions", RFC 3429, November 2002.

 

Bocci, et al.            Expires August 15, 2009               [Page 16]

Internet-Draft                G-ACH and GAL                February 2009

Authors' Addresses
 
   Matthew Bocci (editor)
   Alcatel-Lucent

   Email: [email-masked]
<mailto:[email-masked]> 

   Martin Vigoureux (editor)
   Alcatel-Lucent
   Route de Villejust
   Nozay,   91620
   France
 
   Email: [email-masked]
<mailto:[email-masked]> 

   George Swallow
   Cisco

   Email: [email-masked] <mailto:[email-masked]> 

   David Ward
   Cisco
 
   Email: [email-masked] <mailto:[email-masked]> 

   Rahul Aggarwal
   Juniper Networks

   Email: [email-masked] <mailto:[email-masked]> 

   Stewart Bryant
   Cisco

   Phone:
   Fax:
   Email: [email-masked] <mailto:[email-masked]> 
   URI:

Bocci, et al.            Expires August 15, 2009               [Page 17]

Internet-Draft                G-ACH and GAL                February 2009

Full Copyright Statement
 
   Copyright (C) The IETF Trust (2009).
 
   This document is subject to the rights, licenses and restrictions
   contained in BCP 78, and except as set forth therein, the authors
   retain all their rights.
 
   This document and the information contained herein are provided on an
   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
   THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
   OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
   THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

Intellectual Property
 
   The IETF takes no position regarding the validity or scope of any
   Intellectual Property Rights or other rights that might be claimed to
   pertain to the implementation or use of the technology described in
   this document or the extent to which any license under such rights
   might or might not be available; nor does it represent that it has
   made any independent effort to identify any such rights.  Information
   on the procedures with respect to rights in RFC documents can be
   found in BCP 78 and BCP 79.
 
   Copies of IPR disclosures made to the IETF Secretariat and any
   assurances of licenses to be made available, or the result of an
   attempt made to obtain a general license or permission for the use of
   such proprietary rights by implementers or users of this
   specification can be obtained from the IETF on-line IPR repository at
   http://www.ietf.org/ipr <http://www.ietf.org/ipr> .
 
   The IETF invites any interested party to bring to its attention any
   copyrights, patents or patent applications, or other proprietary
   rights that may cover technology that may be required to implement
   this standard.  Please address the information to the IETF at
   [email-masked] <mailto:[email-masked]> .

 

Bocci, et al.            Expires August 15, 2009               [Page 18]


------_=_NextPart_001_01C99351.C47CC435
Content-Type: text/html;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD><TITLE>Updated version of GACH-GAL draft</TITLE>
<META http-equiv=Content-Type content="text/html; charset=us-ascii">
<META content="MSHTML 6.00.2900.5726" name=GENERATOR></HEAD>
<BODY>
<DIV dir=ltr align=left><SPAN class=094303211-20022009><FONT face="Courier New" 
color=#0000ff size=2>Italo,</FONT></SPAN></DIV>
<DIV dir=ltr align=left><SPAN class=094303211-20022009><FONT face="Courier New" 
color=#0000ff size=2></FONT></SPAN>&nbsp;</DIV>
<DIV dir=ltr align=left><SPAN class=094303211-20022009><FONT face="Courier New" 
color=#0000ff size=2>Thanks for your comments.</FONT></SPAN></DIV>
<DIV dir=ltr align=left><SPAN class=094303211-20022009><FONT face="Courier New" 
color=#0000ff size=2></FONT></SPAN>&nbsp;</DIV>
<DIV dir=ltr align=left><SPAN class=094303211-20022009><FONT face="Courier New" 
color=#0000ff size=2>Please see below for responses.</FONT></SPAN></DIV>
<DIV dir=ltr align=left><SPAN class=094303211-20022009><FONT face="Courier New" 
color=#0000ff size=2></FONT></SPAN>&nbsp;</DIV>
<DIV dir=ltr align=left><SPAN class=094303211-20022009><FONT face="Courier New" 
color=#0000ff size=2>Matthew</FONT></SPAN></DIV>
<DIV dir=ltr align=left><SPAN class=094303211-20022009><FONT face="Courier New" 
color=#0000ff size=2></FONT></SPAN>&nbsp;</DIV>
<DIV dir=ltr align=left><FONT face="Courier New" color=#0000ff size=2><SPAN 
class=094303211-20022009></SPAN></FONT>&nbsp;</DIV>
<DIV dir=ltr align=left><FONT face="Courier New" color=#0000ff size=2><SPAN 
class=094303211-20022009></SPAN></FONT>&nbsp;</DIV>
<DIV dir=ltr align=left><FONT face="Courier New" color=#0000ff size=2><SPAN 
class=094303211-20022009></SPAN></FONT>&nbsp;</DIV>
<DIV><FONT face="Courier New"></FONT>&nbsp;</DIV><SPAN class=094303211-20022009>
<DIV dir=ltr align=left><BR><FONT face="Courier New" color=#0000ff size=2>MPLS 
Working 
Group&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
M. Bocci, 
Ed.<BR>Internet-Draft&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
M. Vigoureux, Ed.<BR>Updates: 3032, 4385, 
5085&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
Alcatel-Lucent</FONT></DIV>
<DIV><FONT face="Courier New" color=#0000ff size=2></FONT>&nbsp;</DIV>
<DIV dir=ltr align=left><FONT face="Courier New" color=#0000ff 
size=2>&lt;&lt;Comment: I think it also updates RFC 4446&gt;&gt;</FONT></DIV>
<DIV><FONT face="Courier New" color=#0000ff size=2></FONT>&nbsp;</DIV>
<DIV dir=ltr align=left><FONT face="Courier New" color=#0000ff size=2>(if 
approved)&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
G. Swallow<BR>Intended status: Standards 
Track&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
D. Ward<BR>Expires: August 15, 
2009&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
Cisco<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
R. 
Aggarwal<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
Juniper 
Networks<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
S. 
Bryant<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
Cisco<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
February 11, 2009</FONT></DIV>
<DIV><FONT face="Courier New" color=#0000ff size=2></FONT>&nbsp;</DIV>
<DIV dir=ltr align=left><BR><FONT face="Courier New" color=#0000ff 
size=2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
MPLS Generic Associated Channel 
Header<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
draft-ietf-mpls-tp-gach-gal-02</FONT></DIV>
<DIV><FONT face="Courier New" color=#0000ff size=2></FONT>&nbsp;</DIV>
<DIV dir=ltr align=left><FONT face="Courier New" color=#0000ff size=2>Status of 
this Memo</FONT></DIV>
<DIV><FONT face="Courier New" color=#0000ff size=2></FONT>&nbsp;</DIV>
<DIV dir=ltr align=left><FONT face="Courier New" color=#0000ff 
size=2>&nbsp;&nbsp; By submitting this Internet-Draft, each author represents 
that any<BR>&nbsp;&nbsp; applicable patent or other IPR claims of which he or 
she is aware<BR>&nbsp;&nbsp; have been or will be disclosed, and any of which he 
or she becomes<BR>&nbsp;&nbsp; aware will be disclosed, in accordance with 
Section 6 of BCP 79.</FONT></DIV>
<DIV><FONT face="Courier New" color=#0000ff size=2></FONT>&nbsp;</DIV>
<DIV dir=ltr align=left><FONT face="Courier New" color=#0000ff 
size=2>&nbsp;&nbsp; Internet-Drafts are working documents of the Internet 
Engineering<BR>&nbsp;&nbsp; Task Force (IETF), its areas, and its working 
groups.&nbsp; Note that<BR>&nbsp;&nbsp; other groups may also distribute working 
documents as Internet-<BR>&nbsp;&nbsp; Drafts.</FONT></DIV>
<DIV><FONT face="Courier New" color=#0000ff size=2></FONT>&nbsp;</DIV>
<DIV dir=ltr align=left><FONT face="Courier New" color=#0000ff 
size=2>&nbsp;&nbsp; Internet-Drafts are draft documents valid for a maximum of 
six months<BR>&nbsp;&nbsp; and may be updated, replaced, or obsoleted by other 
documents at any<BR>&nbsp;&nbsp; time.&nbsp; It is inappropriate to use 
Internet-Drafts as reference<BR>&nbsp;&nbsp; material or to cite them other than 
as "work in progress."</FONT></DIV>
<DIV><FONT face="Courier New" color=#0000ff size=2></FONT>&nbsp;</DIV>
<DIV dir=ltr align=left><FONT face="Courier New" color=#0000ff 
size=2>&nbsp;&nbsp; The list of current Internet-Drafts can be accessed 
at<BR>&nbsp;&nbsp; </FONT><A 
href="http://www.ietf.org/ietf/1id-abstracts.txt"><FONT face="Courier New" 
size=2>http://www.ietf.org/ietf/1id-abstracts.txt</FONT></A><FONT 
face="Courier New" color=#0000ff size=2>.</FONT></DIV>
<DIV><FONT face="Courier New" color=#0000ff size=2></FONT>&nbsp;</DIV>
<DIV dir=ltr align=left><FONT face="Courier New" color=#0000ff 
size=2>&nbsp;&nbsp; The list of Internet-Draft Shadow Directories can be 
accessed at<BR>&nbsp;&nbsp; </FONT><A 
href="http://www.ietf.org/shadow.html"><FONT face="Courier New" 
size=2>http://www.ietf.org/shadow.html</FONT></A><FONT face="Courier New" 
color=#0000ff size=2>.</FONT></DIV>
<DIV><FONT face="Courier New" color=#0000ff size=2></FONT>&nbsp;</DIV>
<DIV dir=ltr align=left><FONT face="Courier New" color=#0000ff 
size=2>&nbsp;&nbsp; This Internet-Draft will expire on August 15, 
2009.</FONT></DIV>
<DIV><FONT face="Courier New" color=#0000ff size=2></FONT>&nbsp;</DIV>
<DIV dir=ltr align=left><FONT face="Courier New" color=#0000ff 
size=2>Abstract</FONT></DIV>
<DIV><FONT face="Courier New" color=#0000ff size=2></FONT>&nbsp;</DIV>
<DIV dir=ltr align=left><FONT face="Courier New" color=#0000ff 
size=2>&nbsp;&nbsp; This document generalises the applicability of the 
pseudowire (PW)<BR>&nbsp;&nbsp; Associated Channel Header (ACH), enabling the 
realization of a<BR>&nbsp;&nbsp; control channel associated to MPLS Label 
Switched Paths (LSPs) and<BR>&nbsp;&nbsp; MPLS Sections in addition to MPLS 
pseudowires.&nbsp; In order to identify<BR>&nbsp;&nbsp; the presence of this ACH 
in the label stack, this document also</FONT></DIV>
<DIV><FONT face="Courier New" color=#0000ff size=2></FONT>&nbsp;</DIV>
<DIV dir=ltr align=left><FONT face="Courier New" color=#0000ff 
size=2></FONT>&nbsp;</DIV>
<DIV><FONT face="Courier New" color=#0000ff size=2></FONT>&nbsp;</DIV>
<DIV dir=ltr align=left><FONT face="Courier New" color=#0000ff size=2>Bocci, et 
al.&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Expires 
August 15, 
2009&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
[Page 
1]<BR><BR>Internet-Draft&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
G-ACH and 
GAL&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
February 2009</FONT></DIV>
<DIV><FONT face="Courier New" color=#0000ff size=2></FONT>&nbsp;</DIV>
<DIV dir=ltr align=left><BR><FONT face="Courier New" color=#0000ff 
size=2>&nbsp;&nbsp; assigns one of the reserved MPLS label values to the 
Generic<BR>&nbsp;&nbsp; Associated Channel Header Label (GAL), to be used as a 
label based<BR>&nbsp;&nbsp; exception mechanism.</FONT></DIV>
<DIV><FONT face="Courier New" color=#0000ff size=2></FONT>&nbsp;</DIV>
<DIV dir=ltr align=left><FONT face="Courier New" color=#0000ff 
size=2>Requirements Language</FONT></DIV>
<DIV><FONT face="Courier New" color=#0000ff size=2></FONT>&nbsp;</DIV>
<DIV dir=ltr align=left><FONT face="Courier New" color=#0000ff 
size=2>&nbsp;&nbsp; The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", 
"SHALL NOT",<BR>&nbsp;&nbsp; "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and 
"OPTIONAL" in this<BR>&nbsp;&nbsp; document are to be interpreted as described 
in RFC 2119 [1].</FONT></DIV>
<DIV><FONT face="Courier New" color=#0000ff size=2></FONT>&nbsp;</DIV>
<DIV dir=ltr align=left><BR><FONT face="Courier New" color=#0000ff size=2>Table 
of Contents</FONT></DIV>
<DIV><FONT face="Courier New" color=#0000ff size=2></FONT>&nbsp;</DIV>
<DIV dir=ltr align=left><FONT face="Courier New" color=#0000ff 
size=2>&nbsp;&nbsp; 1.&nbsp; Introduction . . . . . . . . . . . . . . . . . . . 
. . . . . .&nbsp; 3<BR>&nbsp;&nbsp;&nbsp;&nbsp; 1.1.&nbsp; Contributing Authors 
. . . . . . . . . . . . . . . . . . .&nbsp; 4<BR>&nbsp;&nbsp;&nbsp;&nbsp; 
1.2.&nbsp; Objectives . . . . . . . . . . . . . . . . . . . . . . . .&nbsp; 
4<BR>&nbsp;&nbsp;&nbsp;&nbsp; 1.3.&nbsp; Scope&nbsp; . . . . . . . . . . . . . . 
. . . . . . . . . . . .&nbsp; 4<BR>&nbsp;&nbsp;&nbsp;&nbsp; 1.4.&nbsp; 
Terminology&nbsp; . . . . . . . . . . . . . . . . . . . . . . .&nbsp; 
5<BR>&nbsp;&nbsp; 2.&nbsp; Generic Associated Channel Header&nbsp; . . . . . . . 
. . . . . . .&nbsp; 5<BR>&nbsp;&nbsp;&nbsp;&nbsp; 2.1.&nbsp; Definition . . . . 
. . . . . . . . . . . . . . . . . . . .&nbsp; 5<BR>&nbsp;&nbsp;&nbsp;&nbsp; 
2.2.&nbsp; Allocation of Channel Types&nbsp; . . . . . . . . . . . . . . .&nbsp; 
6<BR>&nbsp;&nbsp; 3.&nbsp; ACH TLVs . . . . . . . . . . . . . . . . . . . . . . 
. . . . .&nbsp; 6<BR>&nbsp;&nbsp;&nbsp;&nbsp; 3.1.&nbsp; ACH TLV Payload 
Structure&nbsp; . . . . . . . . . . . . . . . .&nbsp; 
7<BR>&nbsp;&nbsp;&nbsp;&nbsp; 3.2.&nbsp; ACH TLV Header . . . . . . . . . . . . 
. . . . . . . . . .&nbsp; 7<BR>&nbsp;&nbsp;&nbsp;&nbsp; 3.3.&nbsp; ACH TLV 
Object . . . . . . . . . . . . . . . . . . . . . .&nbsp; 8<BR>&nbsp;&nbsp; 
4.&nbsp; Generalised Exception Mechanism&nbsp; . . . . . . . . . . . . . . 
.&nbsp; 8<BR>&nbsp;&nbsp;&nbsp;&nbsp; 4.1.&nbsp; Relationship with Existing MPLS 
OAM Alert Mechanisms . . .&nbsp; 9<BR>&nbsp;&nbsp;&nbsp;&nbsp; 4.2.&nbsp; GAL 
Applicability and Usage&nbsp; . . . . . . . . . . . . . . .&nbsp; 
9<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 4.2.1.&nbsp; GAL Processing . . . . . 
. . . . . . . . . . . . . . .&nbsp; 9<BR>&nbsp;&nbsp;&nbsp;&nbsp; 4.3.&nbsp; 
Relationship wth RFC 3429&nbsp; . . . . . . . . . . . . . . . . 
12<BR>&nbsp;&nbsp; 5.&nbsp; Compatability&nbsp; . . . . . . . . . . . . . . . . 
. . . . . . . . 12<BR>&nbsp;&nbsp; 6.&nbsp; Congestion Considerations&nbsp; . . 
. . . . . . . . . . . . . . . . 13<BR>&nbsp;&nbsp; 7.&nbsp; Security 
Considerations&nbsp; . . . . . . . . . . . . . . . . . . . 13<BR>&nbsp;&nbsp; 
8.&nbsp; IANA Considerations&nbsp; . . . . . . . . . . . . . . . . . . . . . 
13<BR>&nbsp;&nbsp; 9.&nbsp; Acknowledgements . . . . . . . . . . . . . . . . . . 
. . . . . 15<BR>&nbsp;&nbsp; 10. References . . . . . . . . . . . . . . . . . . 
. . . . . . . . 15<BR>&nbsp;&nbsp;&nbsp;&nbsp; 10.1. Normative References . . . 
. . . . . . . . . . . . . . . . 15<BR>&nbsp;&nbsp;&nbsp;&nbsp; 10.2. Informative 
References . . . . . . . . . . . . . . . . . . 16<BR>&nbsp;&nbsp; Authors' 
Addresses . . . . . . . . . . . . . . . . . . . . . . . . 16<BR>&nbsp;&nbsp; 
Intellectual Property and Copyright Statements . . . . . . . . . . 
18</FONT></DIV>
<DIV><FONT face="Courier New" color=#0000ff size=2></FONT>&nbsp;</DIV>
<DIV dir=ltr align=left><FONT face="Courier New" color=#0000ff 
size=2></FONT>&nbsp;</DIV>
<DIV><FONT face="Courier New" color=#0000ff size=2></FONT>&nbsp;</DIV>
<DIV dir=ltr align=left><FONT face="Courier New" color=#0000ff 
size=2></FONT>&nbsp;</DIV>
<DIV><FONT face="Courier New" color=#0000ff size=2></FONT>&nbsp;</DIV>
<DIV dir=ltr align=left><FONT face="Courier New" color=#0000ff 
size=2></FONT>&nbsp;</DIV>
<DIV><FONT face="Courier New" color=#0000ff size=2></FONT>&nbsp;</DIV>
<DIV dir=ltr align=left><FONT face="Courier New" color=#0000ff 
size=2></FONT>&nbsp;</DIV>
<DIV><FONT face="Courier New" color=#0000ff size=2></FONT>&nbsp;</DIV>
<DIV dir=ltr align=left><FONT face="Courier New" color=#0000ff 
size=2></FONT>&nbsp;</DIV>
<DIV><FONT face="Courier New" color=#0000ff size=2></FONT>&nbsp;</DIV>
<DIV dir=ltr align=left><FONT face="Courier New" color=#0000ff size=2>Bocci, et 
al.&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Expires 
August 15, 
2009&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
[Page 
2]<BR><BR>Internet-Draft&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
G-ACH and 
GAL&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
February 2009</FONT></DIV>
<DIV><FONT face="Courier New" color=#0000ff size=2></FONT>&nbsp;</DIV>
<DIV dir=ltr align=left><BR><FONT face="Courier New" color=#0000ff 
size=2>1.&nbsp; Introduction</FONT></DIV>
<DIV><FONT face="Courier New" color=#0000ff size=2></FONT>&nbsp;</DIV>
<DIV dir=ltr align=left><FONT face="Courier New" color=#0000ff 
size=2>&nbsp;&nbsp; There is a need for Operations, Administration and 
Maintenance (OAM)<BR>&nbsp;&nbsp; mechanisms that can be used for fault 
detection, diagnostics,<BR>&nbsp;&nbsp; maintenance and other functions on a PW 
and a LSP.&nbsp; These functions<BR>&nbsp;&nbsp; can be used between any two 
Label Edge Routers (LERs) / Label<BR>&nbsp;&nbsp; Switching Router (LSRs) or 
Terminating Provider Edge routers (T-PEs)<BR>&nbsp;&nbsp; / Switching Provider 
Edge routers (S-PEs) along the path of an LSP or<BR>&nbsp;&nbsp; PW respectively 
[16].&nbsp; Some of these functions can be supported using<BR>&nbsp;&nbsp; 
existing tools such as Virtual Circuit Connectivity Verification<BR>&nbsp;&nbsp; 
(VCCV) [2], Bidirectional Forwarding Detection for MPLS LSPs 
(BFD-<BR>&nbsp;&nbsp; MPLS)[3], LSP-Ping [4], or BFD-VCCV [5].&nbsp; However, a 
requirement has<BR>&nbsp;&nbsp; been indicated to augment this set of 
maintenance functions, in<BR>&nbsp;&nbsp; particular when MPLS networks are used 
for packet transport services<BR>&nbsp;&nbsp; and transport network operations 
[17].&nbsp; Examples of these functions<BR>&nbsp;&nbsp; include performance 
monitoring, automatic protection switching, and<BR>&nbsp;&nbsp; support for 
management and signaling communication channels.&nbsp; These</FONT></DIV>
<DIV><FONT face="Courier New" color=#0000ff size=2></FONT>&nbsp;</DIV>
<DIV dir=ltr align=left><FONT face="Courier New" color=#0000ff 
size=2>&lt;&lt;Comment&gt;&gt;</FONT></DIV>
<DIV><FONT face="Courier New" color=#0000ff size=2></FONT>&nbsp;</DIV>
<DIV dir=ltr align=left><FONT face="Courier New" color=#0000ff size=2>Is it 
worth to capitalize the must"?</FONT></DIV>
<DIV><FONT face="Courier New" color=#0000ff size=2></FONT>&nbsp;</DIV>
<DIV dir=ltr align=left><FONT face="Courier New" color=#0000ff 
size=2>OLD</FONT></DIV>
<DIV><FONT face="Courier New" color=#0000ff size=2></FONT>&nbsp;</DIV>
<DIV dir=ltr align=left><FONT face="Courier New" color=#0000ff 
size=2>&nbsp;&nbsp; tools must be applicable to, and function in essentially the 
same</FONT></DIV>
<DIV><FONT face="Courier New" color=#0000ff size=2></FONT>&nbsp;</DIV>
<DIV dir=ltr align=left><FONT face="Courier New" color=#0000ff 
size=2>NEW</FONT></DIV>
<DIV><FONT face="Courier New" color=#0000ff size=2></FONT>&nbsp;</DIV>
<DIV dir=ltr align=left><FONT face="Courier New" color=#0000ff 
size=2>&nbsp;&nbsp; tools MUST be applicable to, and function in essentially the 
same</FONT></DIV>
<DIV><FONT face="Courier New" color=#0000ff size=2></FONT>&nbsp;</DIV>
<DIV dir=ltr align=left><FONT face="Courier New" color=#0000ff 
size=2>&lt;&lt;End Comment&gt;&gt;</FONT></DIV>
<DIV><FONT face="Courier New" color=#0000ff size=2></FONT>&nbsp;</DIV>
<DIV dir=ltr align=left><FONT face="Courier New" color=#0000ff 
size=2>&nbsp;&nbsp; manner (from an operational point of view) on MPLS PWs, MPLS 
LSPs and</FONT></DIV>
<DIV><FONT face="Courier New" color=#0000ff size=2></FONT>&nbsp;</DIV>
<DIV dir=ltr align=left><FONT face="Courier New" color=#0000ff 
size=2>&lt;&lt;Comment&gt;&gt;</FONT></DIV>
<DIV><FONT face="Courier New" color=#0000ff size=2></FONT>&nbsp;</DIV>
<DIV dir=ltr align=left><FONT face="Courier New" color=#0000ff size=2>Is it 
worth to capitalize the must"?</FONT></DIV>
<DIV dir=ltr align=left><FONT face="Courier New" color=#0000ff 
size=2></FONT>&nbsp;</DIV>
<DIV dir=ltr align=left><SPAN class=094303211-20022009><FONT face="Courier New" 
color=#0000ff size=2>MB&gt; Yes. The RFC-ed will also make this comment. I agree 
with you on these capitalisation points throughout.</FONT></SPAN></DIV>
<DIV dir=ltr align=left><SPAN class=094303211-20022009><FONT face="Courier New" 
color=#0000ff size=2></FONT></SPAN>&nbsp;</DIV>
<DIV><FONT face="Courier New" color=#0000ff size=2></FONT>&nbsp;</DIV>
<DIV dir=ltr align=left><FONT face="Courier New" color=#0000ff 
size=2>OLD</FONT></DIV>
<DIV><FONT face="Courier New" color=#0000ff size=2></FONT>&nbsp;</DIV>
<DIV dir=ltr align=left><FONT face="Courier New" color=#0000ff 
size=2>&nbsp;&nbsp; MPLS Sections.&nbsp; They must also operate in-band on the 
PW or LSP such</FONT></DIV>
<DIV><FONT face="Courier New" color=#0000ff size=2></FONT>&nbsp;</DIV>
<DIV dir=ltr align=left><FONT face="Courier New" color=#0000ff 
size=2>NEW</FONT></DIV>
<DIV><FONT face="Courier New" color=#0000ff size=2></FONT>&nbsp;</DIV>
<DIV dir=ltr align=left><FONT face="Courier New" color=#0000ff 
size=2>&nbsp;&nbsp; MPLS Sections.&nbsp; They MUST also operate in-band on the 
PW or LSP such</FONT></DIV>
<DIV><FONT face="Courier New" color=#0000ff size=2></FONT>&nbsp;</DIV>
<DIV dir=ltr align=left><FONT face="Courier New" color=#0000ff 
size=2>&lt;&lt;End Comment&gt;&gt;</FONT></DIV>
<DIV><FONT face="Courier New" color=#0000ff size=2></FONT>&nbsp;</DIV>
<DIV dir=ltr align=left><FONT face="Courier New" color=#0000ff 
size=2>&nbsp;&nbsp; that they do not depend on Packet Switched Network (PSN) 
routing or</FONT></DIV>
<DIV><FONT face="Courier New" color=#0000ff size=2></FONT>&nbsp;</DIV>
<DIV dir=ltr align=left><FONT face="Courier New" color=#0000ff 
size=2>&lt;&lt;Comment&gt;&gt;</FONT></DIV>
<DIV><FONT face="Courier New" color=#0000ff size=2></FONT>&nbsp;</DIV>
<DIV dir=ltr align=left><FONT face="Courier New" color=#0000ff size=2>Is it 
worth to capitalize the must"?</FONT></DIV>
<DIV><FONT face="Courier New" color=#0000ff size=2></FONT>&nbsp;</DIV>
<DIV dir=ltr align=left><FONT face="Courier New" color=#0000ff 
size=2>OLD</FONT></DIV>
<DIV><FONT face="Courier New" color=#0000ff size=2></FONT>&nbsp;</DIV>
<DIV dir=ltr align=left><FONT face="Courier New" color=#0000ff 
size=2>&nbsp;&nbsp; on user data traffic, and must also not depend on dynamic 
control</FONT></DIV>
<DIV><FONT face="Courier New" color=#0000ff size=2></FONT>&nbsp;</DIV>
<DIV dir=ltr align=left><FONT face="Courier New" color=#0000ff 
size=2>NEW</FONT></DIV>
<DIV><FONT face="Courier New" color=#0000ff size=2></FONT>&nbsp;</DIV>
<DIV dir=ltr align=left><FONT face="Courier New" color=#0000ff 
size=2>&nbsp;&nbsp; on user data traffic, and MUST also not depend on dynamic 
control</FONT></DIV>
<DIV><FONT face="Courier New" color=#0000ff size=2></FONT>&nbsp;</DIV>
<DIV dir=ltr align=left><FONT face="Courier New" color=#0000ff 
size=2>&lt;&lt;End Comment&gt;&gt;</FONT></DIV>
<DIV><FONT face="Courier New" color=#0000ff size=2></FONT>&nbsp;</DIV>
<DIV dir=ltr align=left><FONT face="Courier New" color=#0000ff 
size=2>&nbsp;&nbsp; plane functions.</FONT></DIV>
<DIV><FONT face="Courier New" color=#0000ff size=2></FONT>&nbsp;</DIV>
<DIV dir=ltr align=left><FONT face="Courier New" color=#0000ff 
size=2>&nbsp;&nbsp; VCCV can use an Associated Channel Header (ACH) to provide a 
PW-<BR>&nbsp;&nbsp; associated control channel between a PW's end points, over 
which OAM<BR>&nbsp;&nbsp; and other control messages can be exchanged.&nbsp; 
This document<BR>&nbsp;&nbsp; generalises the use of the ACH to enable the same 
associated control<BR>&nbsp;&nbsp; channel mechanism to be used for Sections, 
LSPs and PWs.&nbsp; The<BR>&nbsp;&nbsp; associated channel thus generalized is 
known as the Generic<BR>&nbsp;&nbsp; Associated Channel (G-ACh).&nbsp; The ACH, 
specified in RFC 4385 [6], may<BR>&nbsp;&nbsp; be used with additional code 
points to support additional MPLS<BR>&nbsp;&nbsp; maintenance functions on the 
G-ACh.</FONT></DIV>
<DIV><FONT face="Courier New" color=#0000ff size=2></FONT>&nbsp;</DIV>
<DIV dir=ltr align=left><FONT face="Courier New" color=#0000ff 
size=2>&nbsp;&nbsp; Generalizing the associated channel mechanism to LSPs and 
Sections<BR>&nbsp;&nbsp; also requires a method to identify that a packet 
contains an ACH<BR>&nbsp;&nbsp; followed by a non-service payload.&nbsp; 
Therefore, this document also<BR>&nbsp;&nbsp; defines a label based exception 
mechanism that serves to inform an<BR>&nbsp;&nbsp; LSR (or LER) that a packet it 
receives on an LSP or Section belongs<BR>&nbsp;&nbsp; to an associated control 
channel for that LSP or Section.</FONT></DIV>
<DIV><FONT face="Courier New" color=#0000ff size=2></FONT>&nbsp;</DIV>
<DIV dir=ltr align=left><FONT face="Courier New" color=#0000ff 
size=2>&nbsp;&nbsp; RFC 4379 [4] and BFD-MPLS [3] define alert mechanisms that 
enable an<BR>&nbsp;&nbsp; MPLS LSR to identify and process MPLS OAM packets when 
these are<BR>&nbsp;&nbsp; encapsulated in an IP header.&nbsp; These alert 
mechanisms are based on<BR>&nbsp;&nbsp; MPLS or PW label Time to Live (TTL) 
expiration and/or on the use of<BR>&nbsp;&nbsp; an IP destination address in the 
range 127/8.&nbsp; These mechanisms are<BR>&nbsp;&nbsp; the default mechanisms 
for identifying MPLS OAM packets when<BR>&nbsp;&nbsp; encapsulated in an IP 
header.&nbsp; However it may not always be possible</FONT></DIV>
<DIV><FONT face="Courier New" color=#0000ff size=2></FONT>&nbsp;</DIV>
<DIV dir=ltr align=left><FONT face="Courier New" color=#0000ff 
size=2></FONT>&nbsp;</DIV>
<DIV><FONT face="Courier New" color=#0000ff size=2></FONT>&nbsp;</DIV>
<DIV dir=ltr align=left><FONT face="Courier New" color=#0000ff size=2>Bocci, et 
al.&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Expires 
August 15, 
2009&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
[Page 
3]<BR><BR>Internet-Draft&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
G-ACH and 
GAL&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
February 2009</FONT></DIV>
<DIV><FONT face="Courier New" color=#0000ff size=2></FONT>&nbsp;</DIV>
<DIV dir=ltr align=left><BR><FONT face="Courier New" color=#0000ff 
size=2>&nbsp;&nbsp; to use these mechanisms in some MPLS applications, 
e.g.&nbsp; MPLS<BR>&nbsp;&nbsp; Transport Profile (MPLS-TP) [16], particularly 
when IP based<BR>&nbsp;&nbsp; demultiplexing cannot be used.&nbsp; This document 
defines a mechanism<BR>&nbsp;&nbsp; that is RECOMMENDED for identifying and 
encapsulating MPLS OAM and<BR>&nbsp;&nbsp; other maintenance messages when IP 
based mechanisms such as those in<BR>&nbsp;&nbsp; [4] and [3] are not 
available.&nbsp; This mechanism MAY be used in<BR>&nbsp;&nbsp; addition to 
IP-based mechanisms.</FONT></DIV>
<DIV><FONT face="Courier New" color=#0000ff size=2></FONT>&nbsp;</DIV>
<DIV dir=ltr align=left><FONT face="Courier New" color=#0000ff 
size=2>&nbsp;&nbsp; The GAL mechanism is defined to work together with the ACH 
for LSPs<BR>&nbsp;&nbsp; and MPLS Sections.</FONT></DIV>
<DIV><FONT face="Courier New" color=#0000ff size=2></FONT>&nbsp;</DIV>
<DIV dir=ltr align=left><FONT face="Courier New" color=#0000ff 
size=2>&nbsp;&nbsp; Note that, in this document, maintenance functions and 
packets should<BR>&nbsp;&nbsp; be understood in the broad sense.&nbsp; That is, 
a set of FCAPS mechanisms<BR>&nbsp;&nbsp; that include OAM, Automatic Protection 
Switching (APS), Signalling<BR>&nbsp;&nbsp; Communication Channel (SCC) and 
Management Communication Channel<BR>&nbsp;&nbsp; (MCC) messages.</FONT></DIV>
<DIV><FONT face="Courier New" color=#0000ff size=2></FONT>&nbsp;</DIV>
<DIV dir=ltr align=left><FONT face="Courier New" color=#0000ff 
size=2>&nbsp;&nbsp; Also note that the GAL and ACH are applicable to MPLS in 
general.<BR>&nbsp;&nbsp; Their applicability to specific applications of MPLS is 
outside the<BR>&nbsp;&nbsp; scope of this document.&nbsp; For example, the 
applicability of the GAL<BR>&nbsp;&nbsp; and ACH to MPLS-TP is described in [16] 
and [18].</FONT></DIV>
<DIV><FONT face="Courier New" color=#0000ff size=2></FONT>&nbsp;</DIV>
<DIV dir=ltr align=left><FONT face="Courier New" color=#0000ff size=2>1.1.&nbsp; 
Contributing Authors</FONT></DIV>
<DIV><FONT face="Courier New" color=#0000ff size=2></FONT>&nbsp;</DIV>
<DIV dir=ltr align=left><FONT face="Courier New" color=#0000ff 
size=2>&nbsp;&nbsp; The editors gratefully acknowledge the contributions of Sami 
Boutros,<BR>&nbsp;&nbsp; Marc Lasserre, Lieven Levrau and Siva 
Sivabalan</FONT></DIV>
<DIV><FONT face="Courier New" color=#0000ff size=2></FONT>&nbsp;</DIV>
<DIV dir=ltr align=left><FONT face="Courier New" color=#0000ff size=2>1.2.&nbsp; 
Objectives</FONT></DIV>
<DIV><FONT face="Courier New" color=#0000ff size=2></FONT>&nbsp;</DIV>
<DIV dir=ltr align=left><FONT face="Courier New" color=#0000ff 
size=2>&nbsp;&nbsp; This document defines a mechanism that provides a solution 
to the<BR>&nbsp;&nbsp; extended maintenance needs of emerging applications for 
MPLS.&nbsp; It<BR>&nbsp;&nbsp; creates a generic control channel mechanism that 
may be applied to<BR>&nbsp;&nbsp; MPLS LSPs and Sections, while maintaining 
compatibility with the PW<BR>&nbsp;&nbsp; associated channel.&nbsp; It also 
normalises the use of the G-ACH for PWs<BR>&nbsp;&nbsp; in a transport context, 
and defines a label based exception mechanism<BR>&nbsp;&nbsp; to alert LERs/LSRs 
of the presence of an ACH after the bottom of the<BR>&nbsp;&nbsp; 
stack.</FONT></DIV>
<DIV><FONT face="Courier New" color=#0000ff size=2></FONT>&nbsp;</DIV>
<DIV dir=ltr align=left><FONT face="Courier New" color=#0000ff size=2>1.3.&nbsp; 
Scope</FONT></DIV>
<DIV><FONT face="Courier New" color=#0000ff size=2></FONT>&nbsp;</DIV>
<DIV dir=ltr align=left><FONT face="Courier New" color=#0000ff 
size=2>&nbsp;&nbsp; This document defines the encapsulation header for LSP, MPLS 
Section<BR>&nbsp;&nbsp; and PW associated channel messages.</FONT></DIV>
<DIV><FONT face="Courier New" color=#0000ff size=2></FONT>&nbsp;</DIV>
<DIV dir=ltr align=left><FONT face="Courier New" color=#0000ff 
size=2>&nbsp;&nbsp; It does not define how associated control channel 
capabilities are<BR>&nbsp;&nbsp; signaled or negotiated between LERs/LSRs or 
PEs, or the operation of<BR>&nbsp;&nbsp; various OAM functions.</FONT></DIV>
<DIV><FONT face="Courier New" color=#0000ff size=2></FONT>&nbsp;</DIV>
<DIV dir=ltr align=left><FONT face="Courier New" color=#0000ff 
size=2>&nbsp;&nbsp; This document does not deprecate existing MPLS and PW OAM 
mechanisms.</FONT></DIV>
<DIV><FONT face="Courier New" color=#0000ff size=2></FONT>&nbsp;</DIV>
<DIV dir=ltr align=left><FONT face="Courier New" color=#0000ff 
size=2></FONT>&nbsp;</DIV>
<DIV><FONT face="Courier New" color=#0000ff size=2></FONT>&nbsp;</DIV>
<DIV dir=ltr align=left><FONT face="Courier New" color=#0000ff size=2>Bocci, et 
al.&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Expires 
August 15, 
2009&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
[Page 
4]<BR><BR>Internet-Draft&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
G-ACH and 
GAL&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
February 2009</FONT></DIV>
<DIV><FONT face="Courier New" color=#0000ff size=2></FONT>&nbsp;</DIV>
<DIV dir=ltr align=left><BR><FONT face="Courier New" color=#0000ff 
size=2>1.4.&nbsp; Terminology</FONT></DIV>
<DIV><FONT face="Courier New" color=#0000ff size=2></FONT>&nbsp;</DIV>
<DIV dir=ltr align=left><FONT face="Courier New" color=#0000ff 
size=2>&nbsp;&nbsp; ACH: Associated Channel Header</FONT></DIV>
<DIV><FONT face="Courier New" color=#0000ff size=2></FONT>&nbsp;</DIV>
<DIV dir=ltr align=left><FONT face="Courier New" color=#0000ff 
size=2>&nbsp;&nbsp; G-ACh: Generic Associated Channel</FONT></DIV>
<DIV><FONT face="Courier New" color=#0000ff size=2></FONT>&nbsp;</DIV>
<DIV dir=ltr align=left><FONT face="Courier New" color=#0000ff 
size=2>&lt;&lt;Comment&gt;&gt;</FONT></DIV>
<DIV><FONT face="Courier New" color=#0000ff size=2></FONT>&nbsp;</DIV>
<DIV dir=ltr align=left><FONT face="Courier New" color=#0000ff size=2>If I 
understand correctly, this document calls G-ACh the Generic Associate Channel 
and G-ACH the Generic Associated Channel Header.</FONT></DIV>
<DIV><FONT face="Courier New" color=#0000ff size=2></FONT>&nbsp;</DIV>
<DIV dir=ltr align=left><FONT face="Courier New" color=#0000ff 
size=2>ADD</FONT></DIV>
<DIV><FONT face="Courier New" color=#0000ff size=2></FONT>&nbsp;</DIV>
<DIV dir=ltr align=left><FONT face="Courier New" color=#0000ff 
size=2>&nbsp;&nbsp; G-ACH: Generic Associated Channel Header</FONT></DIV>
<DIV><FONT face="Courier New" color=#0000ff size=2></FONT>&nbsp;</DIV>
<DIV dir=ltr align=left><FONT face="Courier New" color=#0000ff 
size=2>&lt;&lt;End Comment&gt;&gt;</FONT></DIV>
<DIV dir=ltr align=left><FONT face="Courier New" color=#0000ff 
size=2></FONT>&nbsp;</DIV>
<DIV dir=ltr align=left><FONT face="Courier New" color=#0000ff 
size=2></FONT>&nbsp;</DIV>
<DIV dir=ltr align=left><SPAN class=094303211-20022009><FONT face="Courier New" 
color=#0000ff size=2>MB&gt; No, the associated channel header is just an ACH. 
There is no difference from the existing ACH, so we do not need to call it a 
G-ACH. However, the channel it creates is generic, becuase it applies to PWs, 
LSPs and Sections, so it is a G-ACh. However, the title of the draft is now 
confusing. The title should probably be changed to either "Generalising the 
associated channel header for MPLS", or "MPLS Generic Associated Channel". But 
that is probably a significant enough change to be worth repeating as&nbsp;a 
last call&nbsp;comment.</FONT></SPAN></DIV>
<DIV dir=ltr align=left><SPAN class=094303211-20022009><FONT face="Courier New" 
color=#0000ff size=2></FONT></SPAN><FONT face="Courier New" color=#0000ff 
size=2></FONT>&nbsp;</DIV>
<DIV dir=ltr align=left><FONT face="Courier New" color=#0000ff 
size=2>&nbsp;&nbsp; GAL: G-ACh Label</FONT></DIV>
<DIV><FONT face="Courier New" color=#0000ff size=2></FONT>&nbsp;</DIV>
<DIV dir=ltr align=left><FONT face="Courier New" color=#0000ff 
size=2>&nbsp;&nbsp; Maintenance packet: Any packet containing a message 
belonging to a<BR>&nbsp;&nbsp; maintenance protocol that is carried on a PW, LSP 
or MPLS Section<BR>&nbsp;&nbsp; associated control channel.&nbsp; Examples of 
such maintenance protocols<BR>&nbsp;&nbsp; include OAM functions, signaling 
communications or management<BR>&nbsp;&nbsp; communications.</FONT></DIV>
<DIV><FONT face="Courier New" color=#0000ff size=2></FONT>&nbsp;</DIV>
<DIV dir=ltr align=left><FONT face="Courier New" color=#0000ff 
size=2>&nbsp;&nbsp; The terms 'Section' and 'Concatenated Segment' are defined 
in [19].</FONT></DIV>
<DIV><FONT face="Courier New" color=#0000ff size=2></FONT>&nbsp;</DIV>
<DIV dir=ltr align=left><BR><FONT face="Courier New" color=#0000ff 
size=2>2.&nbsp; Generic Associated Channel Header</FONT></DIV>
<DIV><FONT face="Courier New" color=#0000ff size=2></FONT>&nbsp;</DIV>
<DIV dir=ltr align=left><FONT face="Courier New" color=#0000ff 
size=2>&nbsp;&nbsp; VCCV [2] defines three MPLS Control Channel (CC) Types that 
may be<BR>&nbsp;&nbsp; used to multiplex OAM messages onto a PW: CC Type 1 uses 
an ACH and<BR>&nbsp;&nbsp; is referred to as "In-band VCCV"; CC Type 2 uses the 
MPLS Router<BR>&nbsp;&nbsp; Alert Label to indicate VCCV packets and is referred 
to as "Out of<BR>&nbsp;&nbsp; Band VCCV"; CC Type 3 uses the TTL to force the 
packet to be<BR>&nbsp;&nbsp; processed by the targeted router control plane and 
is referred to as<BR>&nbsp;&nbsp; "MPLS PW Label with TTL == 1".</FONT></DIV>
<DIV><FONT face="Courier New" color=#0000ff size=2></FONT>&nbsp;</DIV>
<DIV dir=ltr align=left><FONT face="Courier New" color=#0000ff size=2>2.1.&nbsp; 
Definition</FONT></DIV>
<DIV><FONT face="Courier New" color=#0000ff size=2></FONT>&nbsp;</DIV>
<DIV dir=ltr align=left><FONT face="Courier New" color=#0000ff 
size=2>&nbsp;&nbsp; The use of the CC Type 1, previously limited to PWs, is 
extended to<BR>&nbsp;&nbsp; also apply to LSPs and to Sections.&nbsp; This 
header that identifies the<BR>&nbsp;&nbsp; associated control channel is called 
the Generic Associated Channel<BR>&nbsp;&nbsp; Header (G-ACH).&nbsp; Note that 
for PWs, the PWE3 control word [6]MUST be<BR>&nbsp;&nbsp; present in the 
encapsulation of user packets when the ACH is used to<BR>&nbsp;&nbsp; realize 
the associated control channel.</FONT></DIV>
<DIV><FONT face="Courier New" color=#0000ff size=2></FONT>&nbsp;</DIV>
<DIV dir=ltr align=left><FONT face="Courier New" color=#0000ff 
size=2>&nbsp;&nbsp; The CC Type 1 channel header is depicted in figure 
below:</FONT></DIV>
<DIV><FONT face="Courier New" color=#0000ff size=2></FONT>&nbsp;</DIV>
<DIV dir=ltr align=left><FONT face="Courier New" color=#0000ff 
size=2>&nbsp;&nbsp;&nbsp; 
0&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
1&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
2&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
3<BR>&nbsp;&nbsp;&nbsp; 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<BR>&nbsp;&nbsp; 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+<BR>&nbsp;&nbsp; 
|0 0 0 1|Version|&nbsp;&nbsp; Reserved&nbsp;&nbsp;&nbsp; 
|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Channel 
Type&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; |<BR>&nbsp;&nbsp; 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+</FONT></DIV>
<DIV><FONT face="Courier New" color=#0000ff size=2></FONT>&nbsp;</DIV>
<DIV dir=ltr align=left><FONT face="Courier New" color=#0000ff 
size=2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
Figure 1: Associated Channel Header</FONT></DIV>
<DIV><FONT face="Courier New" color=#0000ff size=2></FONT>&nbsp;</DIV>
<DIV dir=ltr align=left><FONT face="Courier New" color=#0000ff 
size=2>&nbsp;&nbsp; In the above figure, the first nibble is set to 0001b to 
indicate a<BR>&nbsp;&nbsp; control channel associated with a PW, an LSP or a 
Section.&nbsp; The</FONT></DIV>
<DIV><FONT face="Courier New" color=#0000ff size=2></FONT>&nbsp;</DIV>
<DIV dir=ltr align=left><FONT face="Courier New" color=#0000ff 
size=2></FONT>&nbsp;</DIV>
<DIV><FONT face="Courier New" color=#0000ff size=2></FONT>&nbsp;</DIV>
<DIV dir=ltr align=left><FONT face="Courier New" color=#0000ff size=2>Bocci, et 
al.&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Expires 
August 15, 
2009&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
[Page 
5]<BR><BR>Internet-Draft&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
G-ACH and 
GAL&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
February 2009</FONT></DIV>
<DIV><FONT face="Courier New" color=#0000ff size=2></FONT>&nbsp;</DIV>
<DIV dir=ltr align=left><BR><FONT face="Courier New" color=#0000ff 
size=2>&nbsp;&nbsp; Version field is set to 0, as specified in RFC 4385 
[6].&nbsp; Bits 8 to<BR>&nbsp;&nbsp; 14 of the G-ACH are reserved and MUST be 
set to 0 and ignored on<BR>&nbsp;&nbsp; reception.</FONT></DIV>
<DIV><FONT face="Courier New" color=#0000ff size=2></FONT>&nbsp;</DIV>
<DIV dir=ltr align=left><FONT face="Courier New" color=#0000ff 
size=2>&nbsp;&nbsp; Note that VCCV also includes mechanisms for negotiating the 
Control<BR>&nbsp;&nbsp; Channel and Connectivity Verification (i.e.&nbsp; OAM 
functions) Types<BR>&nbsp;&nbsp; between PEs.&nbsp; It is anticipated that 
similar mechanisms will be<BR>&nbsp;&nbsp; applied to LSPs.&nbsp; Such 
application will require further<BR>&nbsp;&nbsp; specification.&nbsp; However, 
such specification is beyond the scope of<BR>&nbsp;&nbsp; this 
document.</FONT></DIV>
<DIV><FONT face="Courier New" color=#0000ff size=2></FONT>&nbsp;</DIV>
<DIV dir=ltr align=left><FONT face="Courier New" color=#0000ff size=2>2.2.&nbsp; 
Allocation of Channel Types</FONT></DIV>
<DIV><FONT face="Courier New" color=#0000ff size=2></FONT>&nbsp;</DIV>
<DIV dir=ltr align=left><FONT face="Courier New" color=#0000ff 
size=2>&nbsp;&nbsp; The Channel Type field indicates the type of message carried 
on the<BR>&nbsp;&nbsp; associated control channel e.g.&nbsp; IPv4 or IPv6 if IP 
demultiplexing is<BR>&nbsp;&nbsp; used for messages sent on the associated 
channel, or OAM or other<BR>&nbsp;&nbsp; FCAPS function if IP demultiplexing is 
not used.&nbsp; For associated<BR>&nbsp;&nbsp; channel packets where IP is not 
used as the multiplexer, the Channel<BR>&nbsp;&nbsp; Type SHOULD indicate the 
specific maintenance protocol carried in the<BR>&nbsp;&nbsp; associated control 
channel.</FONT></DIV>
<DIV><FONT face="Courier New" color=#0000ff size=2></FONT>&nbsp;</DIV>
<DIV dir=ltr align=left><FONT face="Courier New" color=#0000ff 
size=2>&nbsp;&nbsp; Values for the Channel Type field currently used for VCCV 
are<BR>&nbsp;&nbsp; specified elsewhere, e.g. in RFC 4446 and RFC 4385. 
[7].&nbsp; Additional<BR>&nbsp;&nbsp; Channel Type values and the associated 
maintenance functionality will<BR>&nbsp;&nbsp; be defined in other 
documents.&nbsp; Each document specifying a protocol<BR>&nbsp;&nbsp; solution 
relying on the ACH MUST also specify the applicable Channel<BR>&nbsp;&nbsp; Type 
field value.</FONT></DIV>
<DIV><FONT face="Courier New" color=#0000ff size=2></FONT>&nbsp;</DIV>
<DIV dir=ltr align=left><FONT face="Courier New" color=#0000ff 
size=2>&nbsp;&nbsp; Note that these values are allocated from the PW Associated 
Channel<BR>&nbsp;&nbsp; Type registry, but this document modifies the existing 
policy to<BR>&nbsp;&nbsp; accommodate a level of experimentation.&nbsp; See 
Section 8 for further<BR>&nbsp;&nbsp; details.</FONT></DIV>
<DIV><FONT face="Courier New" color=#0000ff size=2></FONT>&nbsp;</DIV>
<DIV dir=ltr align=left><BR><FONT face="Courier New" color=#0000ff 
size=2>3.&nbsp; ACH TLVs</FONT></DIV>
<DIV><FONT face="Courier New" color=#0000ff size=2></FONT>&nbsp;</DIV>
<DIV dir=ltr align=left><FONT face="Courier New" color=#0000ff 
size=2>&nbsp;&nbsp; In some applications of the associated channel it is 
necessary to<BR>&nbsp;&nbsp; include one or more ACH TLVs to provide additional 
context<BR>&nbsp;&nbsp; information to the maintenance packet.&nbsp; One use of 
these ACH TLVs<BR>&nbsp;&nbsp; might be to identify the source and/or intended 
destination of the<BR>&nbsp;&nbsp; associated channel maintenance message.&nbsp; 
However, the use of this<BR>&nbsp;&nbsp; construct is not limited to providing 
addressing information nor is<BR>&nbsp;&nbsp; the applicability restricted to 
transport network applications.</FONT></DIV>
<DIV><FONT face="Courier New" color=#0000ff size=2></FONT>&nbsp;</DIV>
<DIV dir=ltr align=left><FONT face="Courier New" color=#0000ff 
size=2>&nbsp;&nbsp; If the maintenance message MAY be preceded by one or more 
ACH TLVs,<BR>&nbsp;&nbsp; then this MUST be explicitly specified in the 
definition of a ACH<BR>&nbsp;&nbsp; Channel Type.&nbsp; If the ACH Channel Type 
definition does state that one<BR>&nbsp;&nbsp; or more ACH TLVs MAY precede the 
maintenance message, an ACH TLV</FONT></DIV>
<DIV><FONT face="Courier New" color=#0000ff size=2></FONT>&nbsp;</DIV>
<DIV dir=ltr align=left><FONT face="Courier New" color=#0000ff 
size=2></FONT>&nbsp;</DIV>
<DIV><FONT face="Courier New" color=#0000ff size=2></FONT>&nbsp;</DIV>
<DIV dir=ltr align=left><FONT face="Courier New" color=#0000ff size=2>Bocci, et 
al.&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Expires 
August 15, 
2009&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
[Page 
6]<BR><BR>Internet-Draft&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
G-ACH and 
GAL&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
February 2009</FONT></DIV>
<DIV><FONT face="Courier New" color=#0000ff size=2></FONT>&nbsp;</DIV>
<DIV dir=ltr align=left><BR><FONT face="Courier New" color=#0000ff 
size=2>&nbsp;&nbsp; Header MUST follow the ACH.&nbsp; If no ACH TLVs are 
required in a specifc<BR>&nbsp;&nbsp; associated channel packet, but the channel 
type nevertheless defines<BR>&nbsp;&nbsp; that ACH TLVs MAY be used, an ACH TLV 
Header MUST be present but with<BR>&nbsp;&nbsp; a length field set to zero to 
indicate that no ACH TLVs follow.</FONT></DIV>
<DIV><FONT face="Courier New" color=#0000ff size=2></FONT>&nbsp;</DIV>
<DIV dir=ltr align=left><FONT face="Courier New" color=#0000ff 
size=2>&nbsp;&nbsp; If a channel type specification does not explicitly specify 
that ACH<BR>&nbsp;&nbsp; TLVs MAY be used, then an ACH TLV MUST NOT be 
used.</FONT></DIV>
<DIV><FONT face="Courier New" color=#0000ff size=2></FONT>&nbsp;</DIV>
<DIV dir=ltr align=left><FONT face="Courier New" color=#0000ff size=2>3.1.&nbsp; 
ACH TLV Payload Structure</FONT></DIV>
<DIV><FONT face="Courier New" color=#0000ff size=2></FONT>&nbsp;</DIV>
<DIV dir=ltr align=left><FONT face="Courier New" color=#0000ff 
size=2>&nbsp;&nbsp; This section defines and describes the structure of the set 
of ACH<BR>&nbsp;&nbsp; TLVs that MAY follow an ACH.&nbsp; It then defines and 
describes the<BR>&nbsp;&nbsp; structure of an ACH TLV object.</FONT></DIV>
<DIV><FONT face="Courier New" color=#0000ff size=2></FONT>&nbsp;</DIV>
<DIV dir=ltr align=left><FONT face="Courier New" color=#0000ff 
size=2>&nbsp;&nbsp; The following figure (Figure 2) shows the structure of a 
G-ACh packet<BR>&nbsp;&nbsp; payload.</FONT></DIV>
<DIV><FONT face="Courier New" color=#0000ff size=2></FONT>&nbsp;</DIV>
<DIV dir=ltr align=left><FONT face="Courier New" color=#0000ff 
size=2>&nbsp;&nbsp; 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+<BR>&nbsp;&nbsp; 
|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
ACH&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
|<BR>&nbsp;&nbsp; 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+<BR>&nbsp;&nbsp; 
|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
ACH TLV 
Header&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
|<BR>&nbsp;&nbsp; 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+<BR>&nbsp;&nbsp; 
|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
~<BR>&nbsp;&nbsp; 
~&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
zero or more ACH 
TLVs&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
~<BR>&nbsp;&nbsp; 
~&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
|<BR>&nbsp;&nbsp; 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+<BR>&nbsp;&nbsp; 
|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
~<BR>&nbsp;&nbsp; 
~&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
Maintenance 
Message&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
~<BR>&nbsp;&nbsp; 
~&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
|<BR>&nbsp;&nbsp; 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+</FONT></DIV>
<DIV><FONT face="Courier New" color=#0000ff size=2></FONT>&nbsp;</DIV>
<DIV dir=ltr align=left><FONT face="Courier New" color=#0000ff 
size=2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
Figure 2: ACH TLV Payload Structure</FONT></DIV>
<DIV><FONT face="Courier New" color=#0000ff size=2></FONT>&nbsp;</DIV>
<DIV dir=ltr align=left><FONT face="Courier New" color=#0000ff size=2>3.2.&nbsp; 
ACH TLV Header</FONT></DIV>
<DIV><FONT face="Courier New" color=#0000ff size=2></FONT>&nbsp;</DIV>
<DIV dir=ltr align=left><FONT face="Courier New" color=#0000ff 
size=2>&nbsp;&nbsp; The ACH TLV Header defines the length of the set of ACH TLVs 
that<BR>&nbsp;&nbsp; follow.</FONT></DIV>
<DIV><FONT face="Courier New" color=#0000ff size=2></FONT>&nbsp;</DIV>
<DIV dir=ltr align=left><FONT face="Courier New" color=#0000ff 
size=2>&nbsp;&nbsp;&nbsp; 
0&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
1&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
2&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
3<BR>&nbsp;&nbsp;&nbsp; 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<BR>&nbsp;&nbsp; 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+<BR>&nbsp;&nbsp; 
|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
Length&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
Reserved&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
|<BR>&nbsp;&nbsp; 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+</FONT></DIV>
<DIV><FONT face="Courier New" color=#0000ff size=2></FONT>&nbsp;</DIV>
<DIV dir=ltr align=left><FONT face="Courier New" color=#0000ff 
size=2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
Figure 3: ACH TLV Header</FONT></DIV>
<DIV><FONT face="Courier New" color=#0000ff size=2></FONT>&nbsp;</DIV>
<DIV dir=ltr align=left><FONT face="Courier New" color=#0000ff 
size=2>&nbsp;&nbsp; The length field specifies the length in octets of the 
complete set<BR>&lt;&lt;Comment&gt;&gt;</FONT></DIV>
<DIV><FONT face="Courier New" color=#0000ff size=2></FONT>&nbsp;</DIV>
<DIV dir=ltr align=left><FONT face="Courier New" color=#0000ff size=2>Please 
rephrase:</FONT></DIV>
<DIV><FONT face="Courier New" color=#0000ff size=2></FONT>&nbsp;</DIV>
<DIV dir=ltr align=left><FONT face="Courier New" color=#0000ff 
size=2>OLD</FONT></DIV>
<DIV><FONT face="Courier New" color=#0000ff size=2></FONT>&nbsp;</DIV>
<DIV dir=ltr align=left><FONT face="Courier New" color=#0000ff 
size=2>&nbsp;&nbsp; of TLVs including TLVs that follow the ACH TLV header.&nbsp; 
A length of</FONT></DIV>
<DIV><FONT face="Courier New" color=#0000ff size=2></FONT>&nbsp;</DIV>
<DIV dir=ltr align=left><FONT face="Courier New" color=#0000ff 
size=2>NEW</FONT></DIV>
<DIV><FONT face="Courier New" color=#0000ff size=2></FONT>&nbsp;</DIV>
<DIV dir=ltr align=left><FONT face="Courier New" color=#0000ff 
size=2>&nbsp;&nbsp; of TLVs that follow the ACH TLV header.&nbsp; A length 
of</FONT></DIV>
<DIV><FONT face="Courier New" color=#0000ff size=2></FONT>&nbsp;</DIV>
<DIV dir=ltr align=left><FONT face="Courier New" color=#0000ff 
size=2>&lt;&lt;End Comment&gt;&gt;</FONT></DIV>
<DIV><FONT face="Courier New" color=#0000ff size=2></FONT>&nbsp;</DIV>
<DIV dir=ltr align=left><SPAN class=094303211-20022009></SPAN><FONT 
face=Arial><FONT color=#0000ff><FONT size=2>M<SPAN 
class=094303211-20022009>B&gt; OK</SPAN></FONT></FONT></FONT></DIV>
<DIV dir=ltr align=left><FONT face=Arial><FONT color=#0000ff><FONT size=2><SPAN 
class=094303211-20022009></SPAN></FONT></FONT></FONT><BR><FONT 
face="Courier New" color=#0000ff size=2>Bocci, et 
al.&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Expires 
August 15, 
2009&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
[Page 
7]<BR><BR>Internet-Draft&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
G-ACH and 
GAL&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
February 2009</FONT></DIV>
<DIV><FONT face="Courier New" color=#0000ff size=2></FONT>&nbsp;</DIV>
<DIV dir=ltr align=left><BR><FONT face="Courier New" color=#0000ff 
size=2>&nbsp;&nbsp; zero indicates that no ACH TLVs follow this 
header.</FONT></DIV>
<DIV><FONT face="Courier New" color=#0000ff size=2></FONT>&nbsp;</DIV>
<DIV dir=ltr align=left><FONT face="Courier New" color=#0000ff 
size=2>&nbsp;&nbsp; The reserved field is for future use and must be set to zero 
on<BR>&nbsp;&nbsp; transmission and ignored on reception.</FONT></DIV>
<DIV><FONT face="Courier New" color=#0000ff size=2></FONT>&nbsp;</DIV>
<DIV dir=ltr align=left><FONT face="Courier New" color=#0000ff size=2>3.3.&nbsp; 
ACH TLV Object</FONT></DIV>
<DIV><FONT face="Courier New" color=#0000ff size=2></FONT>&nbsp;</DIV>
<DIV dir=ltr align=left><FONT face="Courier New" color=#0000ff 
size=2>&nbsp;&nbsp; An ACH TLV consists of a 16-bit Type field, followed by a 
16-bit<BR>&nbsp;&nbsp; Length field which specifies the number of octets of the 
Value field<BR>&nbsp;&nbsp; which follows the Length field.&nbsp; This 32-bit 
word is followed by zero<BR>&nbsp;&nbsp; or more octets of Value 
information.&nbsp; The format and semantics of the<BR>&nbsp;&nbsp; value 
information are defined by the TLV Type as recorded in the TLV</FONT></DIV>
<DIV><FONT face="Courier New" color=#0000ff size=2></FONT>&nbsp;</DIV>
<DIV dir=ltr align=left><FONT face="Courier New" color=#0000ff 
size=2>&lt;&lt;Comment&gt;&gt;</FONT></DIV>
<DIV><FONT face="Courier New" color=#0000ff size=2></FONT>&nbsp;</DIV>
<DIV dir=ltr align=left><FONT face="Courier New" color=#0000ff size=2>The 
sentence "Note that ACH TLVs may be sub-TLVs of other ACH TLVs." is not fully 
clear (at least to me).</FONT></DIV>
<DIV><FONT face="Courier New" color=#0000ff size=2></FONT>&nbsp;</DIV>
<DIV dir=ltr align=left><FONT face="Courier New" color=#0000ff size=2>My 
understanding is that sub-TLVs are TLVs within the Value field of a "parent" TLV 
object.</FONT></DIV>
<DIV><FONT face="Courier New" color=#0000ff size=2></FONT>&nbsp;</DIV>
<DIV dir=ltr align=left><FONT face="Courier New" color=#0000ff size=2>If my 
understanding is correct please rephrase:</FONT></DIV>
<DIV><FONT face="Courier New" color=#0000ff size=2></FONT>&nbsp;</DIV>
<DIV dir=ltr align=left><FONT face="Courier New" color=#0000ff 
size=2>OLD</FONT></DIV>
<DIV><FONT face="Courier New" color=#0000ff size=2></FONT>&nbsp;</DIV>
<DIV dir=ltr align=left><FONT face="Courier New" color=#0000ff 
size=2>&nbsp;&nbsp; Type registry.&nbsp; See Section 8 for further 
details.&nbsp; Note that ACH<BR>&nbsp;&nbsp; TLVs may be sub-TLVs of other ACH 
TLVs.</FONT></DIV>
<DIV><FONT face="Courier New" color=#0000ff size=2></FONT>&nbsp;</DIV>
<DIV dir=ltr align=left><FONT face="Courier New" color=#0000ff 
size=2>NEW</FONT></DIV>
<DIV><FONT face="Courier New" color=#0000ff size=2></FONT>&nbsp;</DIV>
<DIV dir=ltr align=left><FONT face="Courier New" color=#0000ff 
size=2>&nbsp;&nbsp; Type registry.&nbsp; See Section 8 for further 
details.&nbsp; Note that the Value field of<BR>&nbsp;&nbsp; ACH TLVs MAY contain 
sub-TLVs objects.</FONT></DIV>
<DIV><FONT face="Courier New" color=#0000ff size=2></FONT>&nbsp;</DIV>
<DIV dir=ltr align=left><FONT face="Courier New" color=#0000ff 
size=2>&lt;&lt;End Comment&gt;&gt;</FONT></DIV>
<DIV dir=ltr align=left><FONT face="Courier New" color=#0000ff 
size=2></FONT>&nbsp;</DIV>
<DIV dir=ltr align=left><FONT face="Courier New" color=#0000ff 
size=2></FONT>&nbsp;</DIV>
<DIV dir=ltr align=left><SPAN class=094303211-20022009><FONT face="Courier New" 
color=#0000ff size=2>MB&gt; OK with me.</FONT></SPAN></DIV>
<DIV dir=ltr align=left><SPAN class=094303211-20022009><FONT face="Courier New" 
color=#0000ff size=2></FONT></SPAN>&nbsp;</DIV>
<DIV><FONT face="Courier New" color=#0000ff size=2></FONT>&nbsp;</DIV>
<DIV dir=ltr align=left><FONT face="Courier New" color=#0000ff 
size=2>&nbsp;&nbsp;&nbsp; 
0&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
1&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
2&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
3<BR>&nbsp;&nbsp;&nbsp; 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<BR>&nbsp;&nbsp; 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+<BR>&nbsp;&nbsp; 
|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; TLV 
Type&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
Length&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
|<BR>&nbsp;&nbsp; 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+<BR>&nbsp;&nbsp; 
|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
~<BR>&nbsp;&nbsp; 
~&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
Value&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
~<BR>&nbsp;&nbsp; 
~&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
|<BR>&nbsp;&nbsp; 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+</FONT></DIV>
<DIV><FONT face="Courier New" color=#0000ff size=2></FONT>&nbsp;</DIV>
<DIV dir=ltr align=left><FONT face="Courier New" color=#0000ff 
size=2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
Figure 4: ACH TLV Format</FONT></DIV>
<DIV><FONT face="Courier New" color=#0000ff size=2></FONT>&nbsp;</DIV>
<DIV dir=ltr align=left><BR><FONT face="Courier New" color=#0000ff 
size=2>4.&nbsp; Generalised Exception Mechanism</FONT></DIV>
<DIV><FONT face="Courier New" color=#0000ff size=2></FONT>&nbsp;</DIV>
<DIV dir=ltr align=left><FONT face="Courier New" color=#0000ff 
size=2>&nbsp;&nbsp; Generalizing the associated channel mechanism to LSPs and 
Sections<BR>&nbsp;&nbsp; also requires a method to identify that a packet 
contains an ACH<BR>&nbsp;&nbsp; followed by a non-service payload.&nbsp; This 
document specifies that a<BR>&nbsp;&nbsp; label is used for that purpose and 
calls this special label the G-ACh<BR>&nbsp;&nbsp; Label (GAL).&nbsp; One of the 
reserved label values defined in RFC 3032<BR>&nbsp;&nbsp; [8] is assigned for 
this purpose.&nbsp; The value of the label is to be<BR>&nbsp;&nbsp; allocated by 
IANA; this document suggests the value 13.</FONT></DIV>
<DIV><FONT face="Courier New" color=#0000ff size=2></FONT>&nbsp;</DIV>
<DIV dir=ltr align=left><FONT face="Courier New" color=#0000ff 
size=2>&nbsp;&nbsp; The GAL provides an alert based exception mechanism 
to:</FONT></DIV>
<DIV><FONT face="Courier New" color=#0000ff size=2></FONT>&nbsp;</DIV>
<DIV dir=ltr align=left><FONT face="Courier New" color=#0000ff 
size=2>&nbsp;&nbsp; o&nbsp; differentiate specific packets (e.g. maintenance 
messages) from<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; others, such as normal 
user-plane ones,</FONT></DIV>
<DIV><FONT face="Courier New" color=#0000ff size=2></FONT>&nbsp;</DIV>
<DIV dir=ltr align=left><FONT face="Courier New" color=#0000ff 
size=2>&nbsp;&nbsp; o&nbsp; indicate that the ACH appears immediately after the 
bottom of the<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; label stack.</FONT></DIV>
<DIV><FONT face="Courier New" color=#0000ff size=2></FONT>&nbsp;</DIV>
<DIV dir=ltr align=left><FONT face="Courier New" color=#0000ff 
size=2>&nbsp;&nbsp; The GAL MUST only be used where both of these purposes 
apply.</FONT></DIV>
<DIV><FONT face="Courier New" color=#0000ff size=2></FONT>&nbsp;</DIV>
<DIV dir=ltr align=left><FONT face="Courier New" color=#0000ff 
size=2></FONT>&nbsp;</DIV>
<DIV><FONT face="Courier New" color=#0000ff size=2></FONT>&nbsp;</DIV>
<DIV dir=ltr align=left><BR><FONT face="Courier New" color=#0000ff size=2>Bocci, 
et al.&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Expires 
August 15, 
2009&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
[Page 
8]<BR><BR>Internet-Draft&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
G-ACH and 
GAL&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
February 2009</FONT></DIV>
<DIV><FONT face="Courier New" color=#0000ff size=2></FONT>&nbsp;</DIV>
<DIV dir=ltr align=left><BR><FONT face="Courier New" color=#0000ff 
size=2>4.1.&nbsp; Relationship with Existing MPLS OAM Alert 
Mechanisms</FONT></DIV>
<DIV><FONT face="Courier New" color=#0000ff size=2></FONT>&nbsp;</DIV>
<DIV dir=ltr align=left><FONT face="Courier New" color=#0000ff 
size=2>&nbsp;&nbsp; RFC 4379 [4] and BFD-MPLS [3] have defined alert mechanisms 
that<BR>&nbsp;&nbsp; enable a MPLS LSR to identify and process MPLS OAM packets 
when the<BR>&nbsp;&nbsp; OAM packets are encapsulated in an IP header.&nbsp; 
These alert mechanisms<BR>&nbsp;&nbsp; are based on TTL expiration and/or use an 
IP destination address in<BR>&nbsp;&nbsp; the range 127/8.</FONT></DIV>
<DIV><FONT face="Courier New" color=#0000ff size=2></FONT>&nbsp;</DIV>
<DIV dir=ltr align=left><FONT face="Courier New" color=#0000ff 
size=2>&nbsp;&nbsp; These alert mechanisms SHOULD be used in non MPLS-TP 
environments,<BR>&nbsp;&nbsp; although the mechanism defined in this document 
MAY also be used.</FONT></DIV>
<DIV><FONT face="Courier New" color=#0000ff size=2></FONT>&nbsp;</DIV>
<DIV dir=ltr align=left><FONT face="Courier New" color=#0000ff size=2>4.2.&nbsp; 
GAL Applicability and Usage</FONT></DIV>
<DIV><FONT face="Courier New" color=#0000ff size=2></FONT>&nbsp;</DIV>
<DIV dir=ltr align=left><FONT face="Courier New" color=#0000ff 
size=2>&nbsp;&nbsp; The GAL MUST only be used with LSPs, concatenated segments 
of LSPs,<BR>&nbsp;&nbsp; and with Sections.</FONT></DIV>
<DIV><FONT face="Courier New" color=#0000ff size=2></FONT>&nbsp;</DIV>
<DIV dir=ltr align=left><FONT face="Courier New" color=#0000ff 
size=2>&nbsp;&nbsp; In MPLS-TP, the GAL MUST always be at the bottom of the 
label stack<BR>&nbsp;&nbsp; (i.e.&nbsp; S bit set to 1).&nbsp; However, in other 
MPLS environments, this<BR>&nbsp;&nbsp; document places no restrictions on where 
the GAL may appear within<BR>&nbsp;&nbsp; the label stack.</FONT></DIV>
<DIV><FONT face="Courier New" color=#0000ff size=2></FONT>&nbsp;</DIV>
<DIV dir=ltr align=left><FONT face="Courier New" color=#0000ff 
size=2>&nbsp;&nbsp; The GAL MUST NOT appear in the label stack when transporting 
normal<BR>&nbsp;&nbsp; user-plane packets.&nbsp; Furthermore, when present, the 
GAL MUST only<BR>&nbsp;&nbsp; appear once in the label stack.</FONT></DIV>
<DIV><FONT face="Courier New" color=#0000ff size=2></FONT>&nbsp;</DIV>
<DIV dir=ltr align=left><FONT face="Courier New" color=#0000ff 
size=2>4.2.1.&nbsp; GAL Processing</FONT></DIV>
<DIV><FONT face="Courier New" color=#0000ff size=2></FONT>&nbsp;</DIV>
<DIV dir=ltr align=left><FONT face="Courier New" color=#0000ff 
size=2>&nbsp;&nbsp; The Traffic Class (TC) field (formerly known as the EXP 
field) of the<BR>&nbsp;&nbsp; label stack entry containing the GAL follows the 
definition and<BR>&nbsp;&nbsp; processing rules specified and referenced in 
[9].</FONT></DIV>
<DIV><FONT face="Courier New" color=#0000ff size=2></FONT>&nbsp;</DIV>
<DIV dir=ltr align=left><FONT face="Courier New" color=#0000ff 
size=2>&nbsp;&nbsp; The Time-To-Live (TTL) field of the label stack entry that 
contains<BR>&nbsp;&nbsp; the GAL follows the definition and processing rules 
specified in<BR>&nbsp;&nbsp; [10].</FONT></DIV>
<DIV><FONT face="Courier New" color=#0000ff size=2></FONT>&nbsp;</DIV>
<DIV dir=ltr align=left><FONT face="Courier New" color=#0000ff 
size=2>4.2.1.1.&nbsp; MPLS Label Switched Paths and Segments</FONT></DIV>
<DIV><FONT face="Courier New" color=#0000ff size=2></FONT>&nbsp;</DIV>
<DIV dir=ltr align=left><FONT face="Courier New" color=#0000ff 
size=2>&nbsp;&nbsp; The following figure (Figure 5) depicts two LERs (A and D) 
and two<BR>&nbsp;&nbsp; LSRs (B and C) for a given LSP which is established from 
A to D and<BR>&nbsp;&nbsp; switched in B and C.</FONT></DIV>
<DIV><FONT face="Courier New" color=#0000ff size=2></FONT>&nbsp;</DIV>
<DIV dir=ltr align=left><FONT face="Courier New" color=#0000ff 
size=2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
+---+&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
+---+&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
+---+&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
+---+<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; | A |-------------| B 
|-------------| C |-------------| D 
|<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
+---+&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
+---+&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
+---+&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
+---+</FONT></DIV>
<DIV><FONT face="Courier New" color=#0000ff size=2></FONT>&nbsp;</DIV>
<DIV dir=ltr align=left><FONT face="Courier New" color=#0000ff 
size=2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
Figure 5: MPLS-TP maintenance over a LSP</FONT></DIV>
<DIV><FONT face="Courier New" color=#0000ff size=2></FONT>&nbsp;</DIV>
<DIV dir=ltr align=left><FONT face="Courier New" color=#0000ff 
size=2>&nbsp;&nbsp; In this example, a G-ACh exists on an LSP that extends 
between LERs A</FONT></DIV>
<DIV><FONT face="Courier New" color=#0000ff size=2></FONT>&nbsp;</DIV>
<DIV dir=ltr align=left><FONT face="Courier New" color=#0000ff 
size=2></FONT>&nbsp;</DIV>
<DIV><FONT face="Courier New" color=#0000ff size=2></FONT>&nbsp;</DIV>
<DIV dir=ltr align=left><FONT face="Courier New" color=#0000ff size=2>Bocci, et 
al.&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Expires 
August 15, 
2009&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
[Page 
9]<BR><BR>Internet-Draft&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
G-ACH and 
GAL&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
February 2009</FONT></DIV>
<DIV><FONT face="Courier New" color=#0000ff size=2></FONT>&nbsp;</DIV>
<DIV dir=ltr align=left><BR><FONT face="Courier New" color=#0000ff 
size=2>&nbsp;&nbsp; and D, via LSRs B and C. Only these nodes may insert, 
extract or<BR>&nbsp;&nbsp; process packets on the G-ACh.</FONT></DIV>
<DIV><FONT face="Courier New" color=#0000ff size=2></FONT>&nbsp;</DIV>
<DIV dir=ltr align=left><FONT face="Courier New" color=#0000ff 
size=2>&nbsp;&nbsp; The following figure (Figure 6) depicts the format of a 
MPLS-TP<BR>&nbsp;&nbsp; maintenance message when used for a LSP.</FONT></DIV>
<DIV><FONT face="Courier New" color=#0000ff size=2></FONT>&nbsp;</DIV>
<DIV dir=ltr align=left><FONT face="Courier New" color=#0000ff 
size=2>&nbsp;&nbsp;&nbsp; 
0&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
1&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
2&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
3<BR>&nbsp;&nbsp;&nbsp; 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<BR>&nbsp;&nbsp; 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+<BR>&nbsp;&nbsp; 
|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
LSP 
Label&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
|&nbsp; TC |S|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; TTL&nbsp;&nbsp;&nbsp;&nbsp; 
|<BR>&nbsp;&nbsp; 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+<BR>&nbsp;&nbsp; 
|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
GAL&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
|&nbsp; TC |S|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; TTL&nbsp;&nbsp;&nbsp;&nbsp; 
|<BR>&nbsp;&nbsp; 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+<BR>&nbsp;&nbsp; 
|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
ACH&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
|<BR>&nbsp;&nbsp; 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+<BR>&nbsp;&nbsp; 
|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
ACH TLV Header (if 
present)&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
|<BR>&nbsp;&nbsp; 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+<BR>&nbsp;&nbsp; 
|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
~<BR>&nbsp;&nbsp; 
~&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
Zero or more ACH 
TLVs&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
~<BR>&nbsp;&nbsp; 
~&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
(if 
present)&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
|<BR>&nbsp;&nbsp; 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+<BR>&nbsp;&nbsp; 
|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
~<BR>&nbsp;&nbsp; 
~&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
Maintenance 
Message&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
~<BR>&nbsp;&nbsp; 
~&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
|<BR>&nbsp;&nbsp; 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+</FONT></DIV>
<DIV><FONT face="Courier New" color=#0000ff size=2></FONT>&nbsp;</DIV>
<DIV dir=ltr align=left><FONT face="Courier New" color=#0000ff 
size=2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Figure 6: MPLS-TP 
maintenance message format for a LSP</FONT></DIV>
<DIV><FONT face="Courier New" color=#0000ff size=2></FONT>&nbsp;</DIV>
<DIV dir=ltr align=left><FONT face="Courier New" color=#0000ff 
size=2>&nbsp;&nbsp; Note that it is possible that the LSP may be tunnelled in 
another LSP<BR>&nbsp;&nbsp; (e.g. if a MPLS Tunnel exists between B and C), and 
as such other<BR>&nbsp;&nbsp; labels may be present in the label 
stack.</FONT></DIV>
<DIV><FONT face="Courier New" color=#0000ff size=2></FONT>&nbsp;</DIV>
<DIV dir=ltr align=left><FONT face="Courier New" color=#0000ff 
size=2>&nbsp;&nbsp; To send a maintenance message on the LSP associated control 
channel,<BR>&nbsp;&nbsp; the LER (A) generates a maintenance message, to which 
it MAY<BR>&nbsp;&nbsp; prepended an ACH TLV header and appropriate ACH TLVs, and 
with a ACH<BR>&nbsp;&nbsp; to which it pushes a GAL and finally the LSP 
label.</FONT></DIV>
<DIV><FONT face="Courier New" color=#0000ff size=2></FONT>&nbsp;</DIV>
<DIV dir=ltr align=left><FONT face="Courier New" color=#0000ff 
size=2>&nbsp;&nbsp; o&nbsp; The TTL field of the GAL MUST be set to at least 
1.&nbsp; The exact<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; value of the TTL is 
application specific.</FONT></DIV>
<DIV><FONT face="Courier New" color=#0000ff size=2></FONT>&nbsp;</DIV>
<DIV dir=ltr align=left><FONT face="Courier New" color=#0000ff 
size=2>&nbsp;&nbsp; o&nbsp; The S bit of the GAL MUST be set according to its 
position in the<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; label stack.</FONT></DIV>
<DIV><FONT face="Courier New" color=#0000ff size=2></FONT>&nbsp;</DIV>
<DIV dir=ltr align=left><FONT face="Courier New" color=#0000ff 
size=2>&nbsp;&nbsp; o&nbsp; The setting of the TC field is application 
specific.</FONT></DIV>
<DIV><FONT face="Courier New" color=#0000ff size=2></FONT>&nbsp;</DIV>
<DIV dir=ltr align=left><FONT face="Courier New" color=#0000ff 
size=2>&nbsp;&nbsp; The maintenance message, the ACH or the GAL SHOULD NOT be 
modified<BR>&nbsp;&nbsp; towards the targeted destination.&nbsp; Upon reception 
of the labelled<BR>&nbsp;&nbsp; packet, the targeted destination, after having 
checked both the LSP</FONT></DIV>
<DIV><FONT face="Courier New" color=#0000ff size=2></FONT>&nbsp;</DIV>
<DIV dir=ltr align=left><FONT face="Courier New" color=#0000ff 
size=2></FONT>&nbsp;</DIV>
<DIV><FONT face="Courier New" color=#0000ff size=2></FONT>&nbsp;</DIV>
<DIV dir=ltr align=left><FONT face="Courier New" color=#0000ff size=2>Bocci, et 
al.&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Expires 
August 15, 
2009&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
[Page 
10]<BR><BR>Internet-Draft&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
G-ACH and 
GAL&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
February 2009</FONT></DIV>
<DIV><FONT face="Courier New" color=#0000ff size=2></FONT>&nbsp;</DIV>
<DIV dir=ltr align=left><BR><FONT face="Courier New" color=#0000ff 
size=2>&nbsp;&nbsp; label and GAL fields, SHOULD pass the whole maintenance 
message to<BR>&nbsp;&nbsp; the appropriate processing entity.</FONT></DIV>
<DIV><FONT face="Courier New" color=#0000ff size=2></FONT>&nbsp;</DIV>
<DIV dir=ltr align=left><FONT face="Courier New" color=#0000ff 
size=2>4.2.1.2.&nbsp; MPLS Section</FONT></DIV>
<DIV><FONT face="Courier New" color=#0000ff size=2></FONT>&nbsp;</DIV>
<DIV dir=ltr align=left><FONT face="Courier New" color=#0000ff 
size=2>&nbsp;&nbsp; The following figure (Figure 7) depicts an example of a MPLS 
Section.</FONT></DIV>
<DIV><FONT face="Courier New" color=#0000ff size=2></FONT>&nbsp;</DIV>
<DIV dir=ltr align=left><FONT face="Courier New" color=#0000ff 
size=2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
+---+&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
+---+<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
| A |-------------| Z 
|<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
+---+&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
+---+</FONT></DIV>
<DIV><FONT face="Courier New" color=#0000ff size=2></FONT>&nbsp;</DIV>
<DIV dir=ltr align=left><FONT face="Courier New" color=#0000ff 
size=2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
Figure 7: Maintenance over an MPLS Section</FONT></DIV>
<DIV><FONT face="Courier New" color=#0000ff size=2></FONT>&nbsp;</DIV>
<DIV dir=ltr align=left><FONT face="Courier New" color=#0000ff 
size=2>&nbsp;&nbsp; With regard to the MPLS Section, a G-ACh exists between A 
and Z. Only<BR>&nbsp;&nbsp; A and Z can insert, extract or process packets on 
the G-ACh.</FONT></DIV>
<DIV><FONT face="Courier New" color=#0000ff size=2></FONT>&nbsp;</DIV>
<DIV dir=ltr align=left><FONT face="Courier New" color=#0000ff 
size=2>&nbsp;&nbsp; The following figure (Figure 8) depicts the format of a 
maintenance<BR>&nbsp;&nbsp; message when used for a MPLS Section.&nbsp; The GAL 
MAY provide the<BR>&nbsp;&nbsp; exception mechanism for a control channel in its 
own right without<BR>&nbsp;&nbsp; being associated with a specific LSP, thus 
providing maintenance<BR>&nbsp;&nbsp; related communications across a specific 
link interconnecting two<BR>&nbsp;&nbsp; LSRs.&nbsp; In this case, the GAL is 
the only label in the stack.</FONT></DIV>
<DIV><FONT face="Courier New" color=#0000ff size=2></FONT>&nbsp;</DIV>
<DIV dir=ltr align=left><FONT face="Courier New" color=#0000ff 
size=2>&nbsp;&nbsp;&nbsp; 
0&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
1&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
2&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
3<BR>&nbsp;&nbsp;&nbsp; 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<BR>&nbsp;&nbsp; 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+<BR>&nbsp;&nbsp; 
|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
GAL&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
|&nbsp; TC |S|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; TTL&nbsp;&nbsp;&nbsp;&nbsp; 
|<BR>&nbsp;&nbsp; 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+<BR>&nbsp;&nbsp; 
|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
ACH&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
|<BR>&nbsp;&nbsp; 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+<BR>&nbsp;&nbsp; 
|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
ACH TLV Header (if 
present)&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
|<BR>&nbsp;&nbsp; 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+<BR>&nbsp;&nbsp; 
|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
~<BR>&nbsp;&nbsp; 
~&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
Zero or more ACH 
TLVs&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
~<BR>&nbsp;&nbsp; 
~&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
(if 
present)&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
|<BR>&nbsp;&nbsp; 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+<BR>&nbsp;&nbsp; 
|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
~<BR>&nbsp;&nbsp; 
~&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
Maintenance 
Message&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
~<BR>&nbsp;&nbsp; 
~&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
|<BR>&nbsp;&nbsp; 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+</FONT></DIV>
<DIV><FONT face="Courier New" color=#0000ff size=2></FONT>&nbsp;</DIV>
<DIV dir=ltr align=left><FONT face="Courier New" color=#0000ff 
size=2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Figure 8: 
Maintenance message format for a MPLS Section</FONT></DIV>
<DIV><FONT face="Courier New" color=#0000ff size=2></FONT>&nbsp;</DIV>
<DIV dir=ltr align=left><FONT face="Courier New" color=#0000ff 
size=2>&nbsp;&nbsp; To send a maintenance message on a control channel 
associated to the<BR>&nbsp;&nbsp; Section, the head-end LSR (A) of the Section 
generates a maintenance<BR>&nbsp;&nbsp; message, to which it MAY prepend an ACH 
TLV Header and appropriate<BR>&nbsp;&nbsp; ACH TLVs, and with a ACH to which it 
pushes a GAL.</FONT></DIV>
<DIV><FONT face="Courier New" color=#0000ff size=2></FONT>&nbsp;</DIV>
<DIV dir=ltr align=left><FONT face="Courier New" color=#0000ff 
size=2></FONT>&nbsp;</DIV>
<DIV><FONT face="Courier New" color=#0000ff size=2></FONT>&nbsp;</DIV>
<DIV dir=ltr align=left><BR><FONT face="Courier New" color=#0000ff size=2>Bocci, 
et al.&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Expires 
August 15, 
2009&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
[Page 
11]<BR><BR>Internet-Draft&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
G-ACH and 
GAL&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
February 2009</FONT></DIV>
<DIV><FONT face="Courier New" color=#0000ff size=2></FONT>&nbsp;</DIV>
<DIV dir=ltr align=left><BR><FONT face="Courier New" color=#0000ff 
size=2>&nbsp;&nbsp; o&nbsp; The TTL field of the GAL MUST be set to at least 
1.&nbsp; The exact<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; value of the TTL is 
application specific.</FONT></DIV>
<DIV><FONT face="Courier New" color=#0000ff size=2></FONT>&nbsp;</DIV>
<DIV dir=ltr align=left><FONT face="Courier New" color=#0000ff 
size=2>&nbsp;&nbsp; o&nbsp; The S bit of the GAL MUST be set according to its 
position in the<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; label stack.&nbsp; For MPLS 
Sections, the S bit MUST be set to 1.</FONT></DIV>
<DIV><FONT face="Courier New" color=#0000ff size=2></FONT>&nbsp;</DIV>
<DIV dir=ltr align=left><FONT face="Courier New" color=#0000ff 
size=2>&lt;&lt;Comment&gt;&gt;</FONT></DIV>
<DIV><FONT face="Courier New" color=#0000ff size=2></FONT>&nbsp;</DIV>
<DIV dir=ltr align=left><FONT face="Courier New" color=#0000ff size=2>While a 
fully agree that for MPLS-TP Sections the S bit MUST be set to 1, I am not 100% 
sure that this is true also for MPLS Sections.</FONT></DIV>
<DIV><FONT face="Courier New" color=#0000ff size=2></FONT>&nbsp;</DIV>
<DIV dir=ltr align=left><FONT face="Courier New" color=#0000ff 
size=2>&lt;&lt;End Comment&gt;&gt;</FONT></DIV>
<DIV dir=ltr align=left><FONT face="Courier New" color=#0000ff 
size=2></FONT>&nbsp;</DIV>
<DIV dir=ltr align=left><SPAN class=094303211-20022009><FONT face="Courier New" 
color=#0000ff size=2>MB&gt; If an MPLS section turns out to be another MPLS LSP 
on which a hash label or something is used, then I guess you are right. Maybe we 
should make the same statement as for LSPs. However, this is significant enought 
that we should proably raise this during the second&nbsp;LC.</FONT></SPAN></DIV>
<DIV><FONT face="Courier New" color=#0000ff size=2></FONT>&nbsp;</DIV>
<DIV dir=ltr align=left><FONT face="Courier New" color=#0000ff 
size=2>&nbsp;&nbsp; o&nbsp; The setting of the TC field is application 
specific.</FONT></DIV>
<DIV><FONT face="Courier New" color=#0000ff size=2></FONT>&nbsp;</DIV>
<DIV dir=ltr align=left><FONT face="Courier New" color=#0000ff 
size=2>&nbsp;&nbsp; The maintenance message, the ACH and the GAL SHOULD NOT be 
modified<BR>&nbsp;&nbsp; towards the tail-end LSR (Z).&nbsp; Upon reception of 
the labelled packet,<BR>&nbsp;&nbsp; the tail-end LSR (Z), after having checked 
the GAL fields, SHOULD<BR>&nbsp;&nbsp; pass the whole packet to the appropriate 
processing entity.</FONT></DIV>
<DIV><FONT face="Courier New" color=#0000ff size=2></FONT>&nbsp;</DIV>
<DIV dir=ltr align=left><FONT face="Courier New" color=#0000ff size=2>4.3.&nbsp; 
Relationship wth RFC 3429</FONT></DIV>
<DIV><FONT face="Courier New" color=#0000ff size=2></FONT>&nbsp;</DIV>
<DIV dir=ltr align=left><FONT face="Courier New" color=#0000ff 
size=2>&nbsp;&nbsp; RFC 3429 [20] describes the assignment of one of the 
reserved label<BR>&nbsp;&nbsp; values, defined in RFC 3032 [8], to the 'OAM 
Alert Label' that is<BR>&nbsp;&nbsp; used by user-plane MPLS OAM functions for 
the identification of MPLS<BR>&nbsp;&nbsp; OAM packets.&nbsp; The value of 14 is 
used for that purpose.</FONT></DIV>
<DIV><FONT face="Courier New" color=#0000ff size=2></FONT>&nbsp;</DIV>
<DIV dir=ltr align=left><FONT face="Courier New" color=#0000ff 
size=2>&nbsp;&nbsp; Both this document and RFC 3429 [20] therefore describe 
the<BR>&nbsp;&nbsp; assignment of reserved label values for similar 
purposes.&nbsp; The<BR>&nbsp;&nbsp; rationale for the assignment of a new 
reserved label can be<BR>&nbsp;&nbsp; summarized as follows:</FONT></DIV>
<DIV><FONT face="Courier New" color=#0000ff size=2></FONT>&nbsp;</DIV>
<DIV dir=ltr align=left><FONT face="Courier New" color=#0000ff 
size=2>&nbsp;&nbsp; o&nbsp; Unlike the mechanisms described and referenced in 
RFC 3429 [20],<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; MPLS-TP maintenance messages 
will not reside immediately after the<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; GAL but 
instead behind the G-ACH, which itself resides after 
the<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; bottom of the label stack.&nbsp; This 
ensures that OAM, using the<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; G-ACh, complies 
with RFC 4928 [11].</FONT></DIV>
<DIV><FONT face="Courier New" color=#0000ff size=2></FONT>&nbsp;</DIV>
<DIV dir=ltr align=left><FONT face="Courier New" color=#0000ff 
size=2>&nbsp;&nbsp; o&nbsp; The set of maintenance functions potentially 
operated in the<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; context of the G-ACh is wider 
than the set of OAM functions<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; referenced in 
RFC 3429 [20].</FONT></DIV>
<DIV><FONT face="Courier New" color=#0000ff size=2></FONT>&nbsp;</DIV>
<DIV dir=ltr align=left><FONT face="Courier New" color=#0000ff 
size=2>&nbsp;&nbsp; o&nbsp; It has been reported that there are existing 
implementations and<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; running deployments using 
the 'OAM Alert Label' as described in<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; RFC 3429 
[20].&nbsp; It is therefore not possible to modify the 
'OAM<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Alert Label' allocation, purpose or 
usage.&nbsp; Nevertheless, it is<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; RECOMMENDED 
by this document that no further OAM extensions 
based<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; on 'OAM Alert Label' (Label 14) usage be 
specified or developed.</FONT></DIV>
<DIV><FONT face="Courier New" color=#0000ff size=2></FONT>&nbsp;</DIV>
<DIV dir=ltr align=left><BR><FONT face="Courier New" color=#0000ff 
size=2>5.&nbsp; Compatability</FONT></DIV>
<DIV><FONT face="Courier New" color=#0000ff size=2></FONT>&nbsp;</DIV>
<DIV dir=ltr align=left><FONT face="Courier New" color=#0000ff 
size=2>&nbsp;&nbsp; Procedures for handling a packet received with an invalid 
incoming<BR>&nbsp;&nbsp; label are specified in RFC 3031[12].</FONT></DIV>
<DIV><FONT face="Courier New" color=#0000ff size=2></FONT>&nbsp;</DIV>
<DIV dir=ltr align=left><FONT face="Courier New" color=#0000ff 
size=2></FONT>&nbsp;</DIV>
<DIV><FONT face="Courier New" color=#0000ff size=2></FONT>&nbsp;</DIV>
<DIV dir=ltr align=left><BR><FONT face="Courier New" color=#0000ff size=2>Bocci, 
et al.&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Expires 
August 15, 
2009&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
[Page 
12]<BR><BR>Internet-Draft&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
G-ACH and 
GAL&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
February 2009</FONT></DIV>
<DIV><FONT face="Courier New" color=#0000ff size=2></FONT>&nbsp;</DIV>
<DIV dir=ltr align=left><BR><FONT face="Courier New" color=#0000ff 
size=2>&nbsp;&nbsp; An LER, LSR or PE MUST discard received associated channel 
packets on<BR>&nbsp;&nbsp; which all of the MPLS or PW labels have been popped 
if any one of the<BR>&nbsp;&nbsp; following conditions is true:</FONT></DIV>
<DIV><FONT face="Courier New" color=#0000ff size=2></FONT>&nbsp;</DIV>
<DIV dir=ltr align=left><FONT face="Courier New" color=#0000ff 
size=2>&nbsp;&nbsp; o&nbsp; It is not capable of processing packets on the 
Channel Type<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; indicated by the ACH of the 
received packet.</FONT></DIV>
<DIV><FONT face="Courier New" color=#0000ff size=2></FONT>&nbsp;</DIV>
<DIV dir=ltr align=left><FONT face="Courier New" color=#0000ff 
size=2>&nbsp;&nbsp; o&nbsp; It has not, through means outside the scope of this 
document,<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; indicated to the sending LSR, LER or 
PE that it will process<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; associated channel 
packets on the Channel Type indicated by the<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
ACH of the received packet.</FONT></DIV>
<DIV><FONT face="Courier New" color=#0000ff size=2></FONT>&nbsp;</DIV>
<DIV dir=ltr align=left><FONT face="Courier New" color=#0000ff 
size=2>&nbsp;&nbsp; o&nbsp; If the ACH was indicated by the presence of a GAL, 
and the first<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; nibble of the ACH of the 
received packet is not 0b0001.</FONT></DIV>
<DIV><FONT face="Courier New" color=#0000ff size=2></FONT>&nbsp;</DIV>
<DIV dir=ltr align=left><FONT face="Courier New" color=#0000ff 
size=2>&nbsp;&nbsp; o&nbsp; The ACH version is not recognised.</FONT></DIV>
<DIV><FONT face="Courier New" color=#0000ff size=2></FONT>&nbsp;</DIV>
<DIV dir=ltr align=left><FONT face="Courier New" color=#0000ff 
size=2>&nbsp;&nbsp; In addition, it MAY increment an error counter and MAY 
also<BR>&nbsp;&nbsp; optionally issue a system and/or SNMP 
notification.</FONT></DIV>
<DIV><FONT face="Courier New" color=#0000ff size=2></FONT>&nbsp;</DIV>
<DIV dir=ltr align=left><BR><FONT face="Courier New" color=#0000ff 
size=2>6.&nbsp; Congestion Considerations</FONT></DIV>
<DIV><FONT face="Courier New" color=#0000ff size=2></FONT>&nbsp;</DIV>
<DIV dir=ltr align=left><FONT face="Courier New" color=#0000ff 
size=2>&nbsp;&nbsp; The congestion considerations detailed in RFC 5085 [2] 
apply.</FONT></DIV>
<DIV><FONT face="Courier New" color=#0000ff size=2></FONT>&nbsp;</DIV>
<DIV dir=ltr align=left><BR><FONT face="Courier New" color=#0000ff 
size=2>7.&nbsp; Security Considerations</FONT></DIV>
<DIV><FONT face="Courier New" color=#0000ff size=2></FONT>&nbsp;</DIV>
<DIV dir=ltr align=left><FONT face="Courier New" color=#0000ff 
size=2>&nbsp;&nbsp; The security considerations for the associated control 
channel are<BR>&nbsp;&nbsp; descrbed in RFC 4385[6].&nbsp; Further security 
considerations must be<BR>&nbsp;&nbsp; described in the relevant associated 
chanel type specification.</FONT></DIV>
<DIV><FONT face="Courier New" color=#0000ff size=2></FONT>&nbsp;</DIV>
<DIV dir=ltr align=left><FONT face="Courier New" color=#0000ff 
size=2>&nbsp;&nbsp; RFC 5085 [2] provides data plane related security 
considerations.<BR>&nbsp;&nbsp; These also apply to a G-ACh, whether the alert 
mechanism uses a GAL<BR>&nbsp;&nbsp; or only an ACH.</FONT></DIV>
<DIV><FONT face="Courier New" color=#0000ff size=2></FONT>&nbsp;</DIV>
<DIV dir=ltr align=left><BR><FONT face="Courier New" color=#0000ff 
size=2>8.&nbsp; IANA Considerations</FONT></DIV>
<DIV><FONT face="Courier New" color=#0000ff size=2></FONT>&nbsp;</DIV>
<DIV dir=ltr align=left><FONT face="Courier New" color=#0000ff 
size=2>&nbsp;&nbsp; This document requests that IANA allocates a label value, to 
the GAL,<BR>&nbsp;&nbsp; from the pool of reserved labels, and suggests this 
value to be 13.</FONT></DIV>
<DIV><FONT face="Courier New" color=#0000ff size=2></FONT>&nbsp;</DIV>
<DIV dir=ltr align=left><FONT face="Courier New" color=#0000ff 
size=2>&nbsp;&nbsp; Channel Types for the Generic Associated Channel Header are 
allocated<BR>&nbsp;&nbsp; from the IANA PW Associated Channel Type registry 
[7].&nbsp; The PW<BR>&nbsp;&nbsp; Associated Channel Type registry is currently 
allocated based on the<BR>&nbsp;&nbsp; IETF consensus process, described in 
[13].&nbsp; This allocation process<BR>&nbsp;&nbsp; was chosen based on the 
consensus reached in the PWE3 working group<BR>&nbsp;&nbsp; that pseudowire 
associated channel mechanisms should be reviewed by</FONT></DIV>
<DIV><FONT face="Courier New" color=#0000ff size=2></FONT>&nbsp;</DIV>
<DIV dir=ltr align=left><FONT face="Courier New" color=#0000ff 
size=2></FONT>&nbsp;</DIV>
<DIV><FONT face="Courier New" color=#0000ff size=2></FONT>&nbsp;</DIV>
<DIV dir=ltr align=left><FONT face="Courier New" color=#0000ff size=2>Bocci, et 
al.&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Expires 
August 15, 
2009&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
[Page 
13]<BR><BR>Internet-Draft&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
G-ACH and 
GAL&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
February 2009</FONT></DIV>
<DIV><FONT face="Courier New" color=#0000ff size=2></FONT>&nbsp;</DIV>
<DIV dir=ltr align=left><BR><FONT face="Courier New" color=#0000ff 
size=2>&nbsp;&nbsp; the IETF and only those that are consistent with the 
PWE3<BR>&nbsp;&nbsp; architecture and requirements should be allocated a code 
point.</FONT></DIV>
<DIV><FONT face="Courier New" color=#0000ff size=2></FONT>&nbsp;</DIV>
<DIV dir=ltr align=left><FONT face="Courier New" color=#0000ff 
size=2>&nbsp;&nbsp; However, a requirement has emerged (see [17]) to allow 
for<BR>&nbsp;&nbsp; optimizations or extensions to OAM and other control 
protocols</FONT></DIV>
<DIV><FONT face="Courier New" color=#0000ff size=2></FONT>&nbsp;</DIV>
<DIV dir=ltr align=left><FONT face="Courier New" color=#0000ff 
size=2>&lt;&lt;Comment&gt;&gt;</FONT></DIV>
<DIV><FONT face="Courier New" color=#0000ff size=2></FONT>&nbsp;</DIV>
<DIV dir=ltr align=left><FONT face="Courier New" color=#0000ff size=2>Please 
rephrase:</FONT></DIV>
<DIV><FONT face="Courier New" color=#0000ff size=2></FONT>&nbsp;</DIV>
<DIV dir=ltr align=left><FONT face="Courier New" color=#0000ff 
size=2>OLD</FONT></DIV>
<DIV><FONT face="Courier New" color=#0000ff size=2></FONT>&nbsp;</DIV>
<DIV dir=ltr align=left><FONT face="Courier New" color=#0000ff 
size=2>&nbsp;&nbsp; running in an associated channel to be experimented with 
without</FONT></DIV>
<DIV><FONT face="Courier New" color=#0000ff size=2></FONT>&nbsp;</DIV>
<DIV dir=ltr align=left><FONT face="Courier New" color=#0000ff 
size=2>NEW</FONT></DIV>
<DIV><FONT face="Courier New" color=#0000ff size=2></FONT>&nbsp;</DIV>
<DIV dir=ltr align=left><FONT face="Courier New" color=#0000ff 
size=2>&nbsp;&nbsp; running in an associated channel to be experimented 
without</FONT></DIV>
<DIV><FONT face="Courier New" color=#0000ff size=2></FONT>&nbsp;</DIV>
<DIV dir=ltr align=left><FONT face="Courier New" color=#0000ff 
size=2>&lt;&lt;End Comment&gt;&gt;</FONT></DIV>
<DIV dir=ltr align=left><FONT face="Courier New" color=#0000ff 
size=2></FONT>&nbsp;</DIV>
<DIV dir=ltr align=left><SPAN class=094303211-20022009><FONT face="Courier New" 
color=#0000ff size=2>MB&gt; OK thanks.</FONT></SPAN></DIV>
<DIV><FONT face="Courier New" color=#0000ff size=2></FONT>&nbsp;</DIV>
<DIV dir=ltr align=left><FONT face="Courier New" color=#0000ff 
size=2>&nbsp;&nbsp; resorting to the IETF standards process, by supporting 
experimental<BR>&nbsp;&nbsp; code points.&nbsp; This would prevent code points 
used for such functions<BR>&nbsp;&nbsp; from being used from the range allocated 
through the IETF standards<BR>&nbsp;&nbsp; and thus protects an installed base 
of equipment from potential<BR>&nbsp;&nbsp; inadvertent overloading of code 
points.&nbsp; In order to support this<BR>&nbsp;&nbsp; requirement, this 
document requests that the code point allocation<BR>&nbsp;&nbsp; scheme for the 
PW Associated Channel Type be changed as follows:</FONT></DIV>
<DIV><FONT face="Courier New" color=#0000ff size=2></FONT>&nbsp;</DIV>
<DIV dir=ltr align=left><FONT face="Courier New" color=#0000ff 
size=2>&nbsp;&nbsp; 0 - 32751 : IETF Consensus</FONT></DIV>
<DIV><FONT face="Courier New" color=#0000ff size=2></FONT>&nbsp;</DIV>
<DIV dir=ltr align=left><FONT face="Courier New" color=#0000ff 
size=2>&nbsp;&nbsp; 32752 - 32767 : Experimental</FONT></DIV>
<DIV><FONT face="Courier New" color=#0000ff size=2></FONT>&nbsp;</DIV>
<DIV dir=ltr align=left><FONT face="Courier New" color=#0000ff 
size=2>&nbsp;&nbsp; Code points in the experimental range MUST be used according 
to the<BR>&nbsp;&nbsp; guidelines of RFC 3692 [14].&nbsp; Experimental OAM 
functions MUST be<BR>&nbsp;&nbsp; disabled by default.&nbsp; The channel type 
value used for a given<BR>&nbsp;&nbsp; experimental OAM function MUST be 
configurable, and care MUST be<BR>&nbsp;&nbsp; taken to ensure that different 
OAM functions that are not inter-<BR>&nbsp;&nbsp; operable are configured to use 
different channel type values.</FONT></DIV>
<DIV><FONT face="Courier New" color=#0000ff size=2></FONT>&nbsp;</DIV>
<DIV dir=ltr align=left><FONT face="Courier New" color=#0000ff 
size=2>&nbsp;&nbsp; The PW Associated Channel Type registry needs to be updated 
to<BR>&nbsp;&nbsp; include a column indicating whether the ACH is followed by a 
TLV<BR>&nbsp;&nbsp; header (Yes/No).&nbsp; There are two ACH Channel Type 
code-points<BR>&nbsp;&nbsp; currently assigned and in both cases no TLV header 
is used.&nbsp; Thus the<BR>&nbsp;&nbsp; new format of the PW Channel Type 
registry is:</FONT></DIV>
<DIV><FONT face="Courier New" color=#0000ff size=2></FONT>&nbsp;</DIV>
<DIV dir=ltr align=left><FONT face="Courier New" color=#0000ff 
size=2>&nbsp;&nbsp; Registry:<BR>&nbsp;&nbsp; Value&nbsp; 
Description&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
TLV Follows&nbsp; Reference<BR>&nbsp;&nbsp; -----&nbsp; 
----------------------------&nbsp; -----------&nbsp; ---------<BR>&nbsp;&nbsp; 
0x21&nbsp;&nbsp; ACH carries an IPv4 packet&nbsp;&nbsp;&nbsp; 
No&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
[RFC4385]<BR>&nbsp;&nbsp; 0x57&nbsp;&nbsp; ACH carries an IPv6 
packet&nbsp;&nbsp;&nbsp; 
No&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
[RFC4385]</FONT></DIV>
<DIV><FONT face="Courier New" color=#0000ff size=2></FONT>&nbsp;</DIV>
<DIV dir=ltr align=left><FONT face="Courier New" color=#0000ff 
size=2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
Figure 9: PW Channel Type registry</FONT></DIV>
<DIV><FONT face="Courier New" color=#0000ff size=2></FONT>&nbsp;</DIV>
<DIV dir=ltr align=left><FONT face="Courier New" color=#0000ff 
size=2>&nbsp;&nbsp; IANA is requested create a new registry called the 
Associated Channel<BR>&nbsp;&nbsp; TLV Registry.&nbsp; The allocation policy for 
this registry is IETF<BR>&nbsp;&nbsp; consensus.&nbsp; This registry must record 
the following information.<BR>&nbsp;&nbsp; There are no initial 
entries.</FONT></DIV>
<DIV><FONT face="Courier New" color=#0000ff size=2></FONT>&nbsp;</DIV>
<DIV dir=ltr align=left><FONT face="Courier New" color=#0000ff 
size=2>&nbsp;&nbsp; Name&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Type&nbsp; 
Length&nbsp;&nbsp; 
Description&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
Reference<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
(octets)</FONT></DIV>
<DIV><FONT face="Courier New" color=#0000ff size=2></FONT>&nbsp;</DIV>
<DIV dir=ltr align=left><FONT face="Courier New" color=#0000ff 
size=2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
Figure 10: PW ACH TLV registry</FONT></DIV>
<DIV><FONT face="Courier New" color=#0000ff size=2></FONT>&nbsp;</DIV>
<DIV dir=ltr align=left><FONT face="Courier New" color=#0000ff 
size=2>&lt;&lt;Comment&gt;&gt;</FONT></DIV>
<DIV><FONT face="Courier New" color=#0000ff size=2></FONT>&nbsp;</DIV>
<DIV dir=ltr align=left><FONT face="Courier New" color=#0000ff size=2>I wonder 
whether it would be useful to allocate at least one TLV for experimental 
use.</FONT></DIV>
<DIV><FONT face="Courier New" color=#0000ff size=2></FONT>&nbsp;</DIV>
<DIV dir=ltr align=left><FONT face="Courier New" color=#0000ff 
size=2>&lt;&lt;End Comment&gt;&gt;</FONT></DIV>
<DIV dir=ltr align=left><FONT face="Courier New" color=#0000ff 
size=2></FONT>&nbsp;</DIV>
<DIV dir=ltr align=left><SPAN class=094303211-20022009><FONT face="Courier New" 
color=#0000ff size=2>MB&gt; Do we really need this if we use an experimental 
channel type? In any case, I am not sure we are being inconsistent with the 
above text&nbsp;if we specficy one code point in the ACH TLV draft that is 
experimental.</FONT></SPAN></DIV>
<DIV dir=ltr align=left><SPAN class=094303211-20022009><FONT face="Courier New" 
color=#0000ff size=2></FONT></SPAN>&nbsp;</DIV>
<DIV dir=ltr align=left><SPAN class=094303211-20022009>&nbsp;</SPAN></DIV>
<DIV dir=ltr align=left><FONT face="Courier New" color=#0000ff size=2>Bocci, et 
al.&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Expires 
August 15, 
2009&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
[Page 
14]<BR><BR>Internet-Draft&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
G-ACH and 
GAL&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
February 2009</FONT></DIV>
<DIV><FONT face="Courier New" color=#0000ff size=2></FONT>&nbsp;</DIV>
<DIV dir=ltr align=left><BR><FONT face="Courier New" color=#0000ff 
size=2>9.&nbsp; Acknowledgements</FONT></DIV>
<DIV><FONT face="Courier New" color=#0000ff size=2></FONT>&nbsp;</DIV>
<DIV dir=ltr align=left><FONT face="Courier New" color=#0000ff 
size=2>&nbsp;&nbsp; The authors would like to thank all members of the teams 
(the Joint<BR>&nbsp;&nbsp; Working Team, the MPLS Interoperability Design Team 
in IETF and the<BR>&nbsp;&nbsp; MPLS-TP Ad-Hoc Team in ITU-T) involved in the 
definition and<BR>&nbsp;&nbsp; specification of MPLS Transport 
Profile.</FONT></DIV>
<DIV><FONT face="Courier New" color=#0000ff size=2></FONT>&nbsp;</DIV>
<DIV dir=ltr align=left><BR><FONT face="Courier New" color=#0000ff 
size=2>10.&nbsp; References</FONT></DIV>
<DIV><FONT face="Courier New" color=#0000ff size=2></FONT>&nbsp;</DIV>
<DIV dir=ltr align=left><FONT face="Courier New" color=#0000ff 
size=2>10.1.&nbsp; Normative References</FONT></DIV>
<DIV><FONT face="Courier New" color=#0000ff size=2></FONT>&nbsp;</DIV>
<DIV dir=ltr align=left><FONT face="Courier New" color=#0000ff 
size=2>&nbsp;&nbsp; [1]&nbsp;&nbsp; Bradner, S., "Key words for use in RFCs to 
Indicate Requirement<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
Levels", BCP 14, RFC 2119, March 1997.</FONT></DIV>
<DIV><FONT face="Courier New" color=#0000ff size=2></FONT>&nbsp;</DIV>
<DIV dir=ltr align=left><FONT face="Courier New" color=#0000ff 
size=2>&nbsp;&nbsp; [2]&nbsp;&nbsp; Nadeau, T. and C. Pignataro, "Pseudowire 
Virtual Circuit<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Connectivity 
Verification (VCCV): A Control Channel 
for<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Pseudowires", RFC 5085, 
December 2007.</FONT></DIV>
<DIV><FONT face="Courier New" color=#0000ff size=2></FONT>&nbsp;</DIV>
<DIV dir=ltr align=left><FONT face="Courier New" color=#0000ff 
size=2>&nbsp;&nbsp; [3]&nbsp;&nbsp; Aggarwal, R., Kompella, K., Nadeau, T., and 
G. Swallow, "BFD<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; For MPLS 
LSPs", draft-ietf-bfd-mpls-07 (work in 
progress),<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; June 
2008.</FONT></DIV>
<DIV><FONT face="Courier New" color=#0000ff size=2></FONT>&nbsp;</DIV>
<DIV dir=ltr align=left><FONT face="Courier New" color=#0000ff 
size=2>&nbsp;&nbsp; [4]&nbsp;&nbsp; Kompella, K. and G. Swallow, "Detecting 
Multi-Protocol Label<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
Switched (MPLS) Data Plane Failures", RFC 4379, February 2006.</FONT></DIV>
<DIV><FONT face="Courier New" color=#0000ff size=2></FONT>&nbsp;</DIV>
<DIV dir=ltr align=left><FONT face="Courier New" color=#0000ff 
size=2>&nbsp;&nbsp; [5]&nbsp;&nbsp; Nadeau, T. and C. Pignataro, "Bidirectional 
Forwarding<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Detection (BFD) 
for the Pseudowire Virtual 
Circuit<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Connectivity 
Verification (VCCV)", 
draft-ietf-pwe3-vccv-bfd-02<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
(work in progress), June 2008.</FONT></DIV>
<DIV><FONT face="Courier New" color=#0000ff size=2></FONT>&nbsp;</DIV>
<DIV dir=ltr align=left><FONT face="Courier New" color=#0000ff 
size=2>&nbsp;&nbsp; [6]&nbsp;&nbsp; Bryant, S., Swallow, G., Martini, L., and D. 
McPherson,<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; "Pseudowire 
Emulation Edge-to-Edge (PWE3) Control Word for 
Use<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; over an MPLS PSN", RFC 
4385, February 2006.</FONT></DIV>
<DIV><FONT face="Courier New" color=#0000ff size=2></FONT>&nbsp;</DIV>
<DIV dir=ltr align=left><FONT face="Courier New" color=#0000ff 
size=2>&nbsp;&nbsp; [7]&nbsp;&nbsp; Martini, L., "IANA Allocations for 
Pseudowire Edge to Edge<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
Emulation (PWE3)", BCP 116, RFC 4446, April 2006.</FONT></DIV>
<DIV><FONT face="Courier New" color=#0000ff size=2></FONT>&nbsp;</DIV>
<DIV dir=ltr align=left><FONT face="Courier New" color=#0000ff 
size=2>&nbsp;&nbsp; [8]&nbsp;&nbsp; Rosen, E., Tappan, D., Fedorkow, G., 
Rekhter, Y., Farinacci,<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; D., 
Li, T., and A. Conta, "MPLS Label Stack 
Encoding",<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; RFC 3032, January 
2001.</FONT></DIV>
<DIV><FONT face="Courier New" color=#0000ff size=2></FONT>&nbsp;</DIV>
<DIV dir=ltr align=left><FONT face="Courier New" color=#0000ff 
size=2>&nbsp;&nbsp; [9]&nbsp;&nbsp; Andersson, L. and R. Asati, "Multi-Protocol 
Label Switching<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; (MPLS) label 
stack entry: "EXP" field renamed&nbsp; to 
"Traffic<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Class" field", 
draft-ietf-mpls-cosfield-def-08 (work 
in<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; progress), December 
2008.</FONT></DIV>
<DIV><FONT face="Courier New" color=#0000ff size=2></FONT>&nbsp;</DIV>
<DIV dir=ltr align=left><FONT face="Courier New" color=#0000ff 
size=2>&nbsp;&nbsp; [10]&nbsp; Agarwal, P. and B. Akyol, "Time To Live (TTL) 
Processing in</FONT></DIV>
<DIV><FONT face="Courier New" color=#0000ff size=2></FONT>&nbsp;</DIV>
<DIV dir=ltr align=left><FONT face="Courier New" color=#0000ff 
size=2></FONT>&nbsp;</DIV>
<DIV><FONT face="Courier New" color=#0000ff size=2></FONT>&nbsp;</DIV>
<DIV dir=ltr align=left><FONT face="Courier New" color=#0000ff size=2>Bocci, et 
al.&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Expires 
August 15, 
2009&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
[Page 
15]<BR><BR>Internet-Draft&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
G-ACH and 
GAL&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
February 2009</FONT></DIV>
<DIV><FONT face="Courier New" color=#0000ff size=2></FONT>&nbsp;</DIV>
<DIV dir=ltr align=left><BR><FONT face="Courier New" color=#0000ff 
size=2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Multi-Protocol Label 
Switching (MPLS) Networks", RFC 
3443,<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; January 
2003.</FONT></DIV>
<DIV><FONT face="Courier New" color=#0000ff size=2></FONT>&nbsp;</DIV>
<DIV dir=ltr align=left><FONT face="Courier New" color=#0000ff 
size=2>&nbsp;&nbsp; [11]&nbsp; Swallow, G., Bryant, S., and L. Andersson, 
"Avoiding Equal Cost<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
Multipath Treatment in MPLS Networks", BCP 128, RFC 
4928,<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; June 
2007.</FONT></DIV>
<DIV><FONT face="Courier New" color=#0000ff size=2></FONT>&nbsp;</DIV>
<DIV dir=ltr align=left><FONT face="Courier New" color=#0000ff 
size=2>&nbsp;&nbsp; [12]&nbsp; Rosen, E., Viswanathan, A., and R. Callon, 
"Multiprotocol Label<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
Switching Architecture", RFC 3031, January 2001.</FONT></DIV>
<DIV><FONT face="Courier New" color=#0000ff size=2></FONT>&nbsp;</DIV>
<DIV dir=ltr align=left><FONT face="Courier New" color=#0000ff 
size=2>&nbsp;&nbsp; [13]&nbsp; Narten, T. and H. Alvestrand, "Guidelines for 
Writing an IANA<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
Considerations Section in RFCs", BCP 26, RFC 
2434,<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; October 
1998.</FONT></DIV>
<DIV><FONT face="Courier New" color=#0000ff size=2></FONT>&nbsp;</DIV>
<DIV dir=ltr align=left><FONT face="Courier New" color=#0000ff 
size=2>&nbsp;&nbsp; [14]&nbsp; Narten, T., "Assigning Experimental and Testing 
Numbers<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Considered Useful", 
BCP 82, RFC 3692, January 2004.</FONT></DIV>
<DIV><FONT face="Courier New" color=#0000ff size=2></FONT>&nbsp;</DIV>
<DIV dir=ltr align=left><FONT face="Courier New" color=#0000ff 
size=2>&nbsp;&nbsp; [15]&nbsp; Bryant, S. and P. Pate, "Pseudo Wire Emulation 
Edge-to-Edge<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; (PWE3) 
Architecture", RFC 3985, March 2005.</FONT></DIV>
<DIV><FONT face="Courier New" color=#0000ff size=2></FONT>&nbsp;</DIV>
<DIV dir=ltr align=left><FONT face="Courier New" color=#0000ff 
size=2>10.2.&nbsp; Informative References</FONT></DIV>
<DIV><FONT face="Courier New" color=#0000ff size=2></FONT>&nbsp;</DIV>
<DIV dir=ltr align=left><FONT face="Courier New" color=#0000ff 
size=2>&nbsp;&nbsp; [16]&nbsp; Bocci, M., Bryant, S., and L. Levrau, "A 
Framework for MPLS in<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
Transport Networks", draft-ietf-mpls-tp-framework-00 (work 
in<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; progress), November 
2008.</FONT></DIV>
<DIV><FONT face="Courier New" color=#0000ff size=2></FONT>&nbsp;</DIV>
<DIV dir=ltr align=left><FONT face="Courier New" color=#0000ff 
size=2>&nbsp;&nbsp; [17]&nbsp; Vigoureux, M., Ward, D., and M. Betts, 
"Requirements for OAM in<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
MPLS Transport Networks",<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
draft-ietf-mpls-tp-oam-requirements-00 (work in 
progress),<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; December 
2008.</FONT></DIV>
<DIV><FONT face="Courier New" color=#0000ff size=2></FONT>&nbsp;</DIV>
<DIV dir=ltr align=left><FONT face="Courier New" color=#0000ff 
size=2>&nbsp;&nbsp; [18]&nbsp; Busi, I. and B. Niven-Jenkins, "MPLS-TP OAM 
Framework and<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Overview", 
draft-busi-mpls-tp-oam-framework-00 (work 
in<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; progress), October 
2008.</FONT></DIV>
<DIV><FONT face="Courier New" color=#0000ff size=2></FONT>&nbsp;</DIV>
<DIV dir=ltr align=left><FONT face="Courier New" color=#0000ff 
size=2>&nbsp;&nbsp; [19]&nbsp; Niven-Jenkins, B., Brungard, D., Betts, M., 
Sprecher, N., and<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; S. Ueno, 
"MPLS-TP Requirements",<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
draft-ietf-mpls-tp-requirements-04 (work in 
progress),<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; February 
2009.</FONT></DIV>
<DIV><FONT face="Courier New" color=#0000ff size=2></FONT>&nbsp;</DIV>
<DIV dir=ltr align=left><FONT face="Courier New" color=#0000ff 
size=2>&nbsp;&nbsp; [20]&nbsp; Ohta, H., "Assignment of the 'OAM Alert Label' 
for<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Multiprotocol Label 
Switching Architecture (MPLS) Operation 
and<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Maintenance (OAM) 
Functions", RFC 3429, November 2002.</FONT></DIV>
<DIV><FONT face="Courier New" color=#0000ff size=2></FONT>&nbsp;</DIV>
<DIV dir=ltr align=left><FONT face="Courier New" color=#0000ff 
size=2></FONT>&nbsp;</DIV>
<DIV><FONT face="Courier New" color=#0000ff size=2></FONT>&nbsp;</DIV>
<DIV dir=ltr align=left><FONT face="Courier New" color=#0000ff 
size=2></FONT>&nbsp;</DIV>
<DIV><FONT face="Courier New" color=#0000ff size=2></FONT>&nbsp;</DIV>
<DIV dir=ltr align=left><FONT face="Courier New" color=#0000ff 
size=2></FONT>&nbsp;</DIV>
<DIV><FONT face="Courier New" color=#0000ff size=2></FONT>&nbsp;</DIV>
<DIV dir=ltr align=left><BR><FONT face="Courier New" color=#0000ff size=2>Bocci, 
et al.&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Expires 
August 15, 
2009&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
[Page 
16]<BR><BR>Internet-Draft&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
G-ACH and 
GAL&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
February 2009</FONT></DIV>
<DIV><FONT face="Courier New" color=#0000ff size=2></FONT>&nbsp;</DIV>
<DIV dir=ltr align=left><BR><FONT face="Courier New" color=#0000ff 
size=2>Authors' Addresses</FONT></DIV>
<DIV><FONT face="Courier New" color=#0000ff size=2></FONT>&nbsp;</DIV>
<DIV dir=ltr align=left><FONT face="Courier New" color=#0000ff 
size=2>&nbsp;&nbsp; Matthew Bocci (editor)<BR>&nbsp;&nbsp; 
Alcatel-Lucent</FONT></DIV>
<DIV><FONT face="Courier New" color=#0000ff size=2></FONT>&nbsp;</DIV>
<DIV dir=ltr align=left><BR><FONT face="Courier New" color=#0000ff 
size=2>&nbsp;&nbsp; Email: </FONT><A 
href="mailto:[email-masked]"><FONT face="Courier New" 
size=2>[email-masked]</FONT></A></DIV>
<DIV><FONT face="Courier New" color=#0000ff size=2></FONT>&nbsp;</DIV>
<DIV dir=ltr align=left><BR><FONT face="Courier New" color=#0000ff 
size=2>&nbsp;&nbsp; Martin Vigoureux (editor)<BR>&nbsp;&nbsp; 
Alcatel-Lucent<BR>&nbsp;&nbsp; Route de Villejust<BR>&nbsp;&nbsp; 
Nozay,&nbsp;&nbsp; 91620<BR>&nbsp;&nbsp; France</FONT></DIV>
<DIV><FONT face="Courier New" color=#0000ff size=2></FONT>&nbsp;</DIV>
<DIV dir=ltr align=left><FONT face="Courier New" color=#0000ff 
size=2>&nbsp;&nbsp; Email: </FONT><A 
href="mailto:[email-masked]"><FONT face="Courier New" 
size=2>[email-masked]</FONT></A></DIV>
<DIV><FONT face="Courier New" color=#0000ff size=2></FONT>&nbsp;</DIV>
<DIV dir=ltr align=left><BR><FONT face="Courier New" color=#0000ff 
size=2>&nbsp;&nbsp; George Swallow<BR>&nbsp;&nbsp; Cisco</FONT></DIV>
<DIV><FONT face="Courier New" color=#0000ff size=2></FONT>&nbsp;</DIV>
<DIV dir=ltr align=left><BR><FONT face="Courier New" color=#0000ff 
size=2>&nbsp;&nbsp; Email: </FONT><A href="mailto:[email-masked]"><FONT 
face="Courier New" size=2>[email-masked]</FONT></A></DIV>
<DIV><FONT face="Courier New" color=#0000ff size=2></FONT>&nbsp;</DIV>
<DIV dir=ltr align=left><BR><FONT face="Courier New" color=#0000ff 
size=2>&nbsp;&nbsp; David Ward<BR>&nbsp;&nbsp; Cisco</FONT></DIV>
<DIV><FONT face="Courier New" color=#0000ff size=2></FONT>&nbsp;</DIV>
<DIV dir=ltr align=left><FONT face="Courier New" color=#0000ff 
size=2>&nbsp;&nbsp; Email: </FONT><A href="mailto:[email-masked]"><FONT 
face="Courier New" size=2>[email-masked]</FONT></A></DIV>
<DIV><FONT face="Courier New" color=#0000ff size=2></FONT>&nbsp;</DIV>
<DIV dir=ltr align=left><BR><FONT face="Courier New" color=#0000ff 
size=2>&nbsp;&nbsp; Rahul Aggarwal<BR>&nbsp;&nbsp; Juniper Networks</FONT></DIV>
<DIV><FONT face="Courier New" color=#0000ff size=2></FONT>&nbsp;</DIV>
<DIV dir=ltr align=left><BR><FONT face="Courier New" color=#0000ff 
size=2>&nbsp;&nbsp; Email: </FONT><A href="mailto:[email-masked]"><FONT 
face="Courier New" size=2>[email-masked]</FONT></A></DIV>
<DIV><FONT face="Courier New" color=#0000ff size=2></FONT>&nbsp;</DIV>
<DIV dir=ltr align=left><BR><FONT face="Courier New" color=#0000ff 
size=2>&nbsp;&nbsp; Stewart Bryant<BR>&nbsp;&nbsp; Cisco</FONT></DIV>
<DIV><FONT face="Courier New" color=#0000ff size=2></FONT>&nbsp;</DIV>
<DIV dir=ltr align=left><BR><FONT face="Courier New" color=#0000ff 
size=2>&nbsp;&nbsp; Phone:<BR>&nbsp;&nbsp; Fax:<BR>&nbsp;&nbsp; Email: </FONT><A 
href="mailto:[email-masked]"><FONT face="Courier New" 
size=2>[email-masked]</FONT></A><BR><FONT face="Courier New" color=#0000ff 
size=2>&nbsp;&nbsp; URI:</FONT></DIV>
<DIV><FONT face="Courier New" color=#0000ff size=2></FONT>&nbsp;</DIV>
<DIV dir=ltr align=left><FONT face="Courier New" color=#0000ff 
size=2></FONT>&nbsp;</DIV>
<DIV><FONT face="Courier New" color=#0000ff size=2></FONT>&nbsp;</DIV>
<DIV dir=ltr align=left><FONT face="Courier New" color=#0000ff 
size=2></FONT>&nbsp;</DIV>
<DIV><FONT face="Courier New" color=#0000ff size=2></FONT>&nbsp;</DIV>
<DIV dir=ltr align=left><FONT face="Courier New" color=#0000ff size=2>Bocci, et 
al.&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Expires 
August 15, 
2009&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
[Page 
17]<BR><BR>Internet-Draft&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
G-ACH and 
GAL&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
February 2009</FONT></DIV>
<DIV><FONT face="Courier New" color=#0000ff size=2></FONT>&nbsp;</DIV>
<DIV dir=ltr align=left><BR><FONT face="Courier New" color=#0000ff size=2>Full 
Copyright Statement</FONT></DIV>
<DIV><FONT face="Courier New" color=#0000ff size=2></FONT>&nbsp;</DIV>
<DIV dir=ltr align=left><FONT face="Courier New" color=#0000ff 
size=2>&nbsp;&nbsp; Copyright (C) The IETF Trust (2009).</FONT></DIV>
<DIV><FONT face="Courier New" color=#0000ff size=2></FONT>&nbsp;</DIV>
<DIV dir=ltr align=left><FONT face="Courier New" color=#0000ff 
size=2>&nbsp;&nbsp; This document is subject to the rights, licenses and 
restrictions<BR>&nbsp;&nbsp; contained in BCP 78, and except as set forth 
therein, the authors<BR>&nbsp;&nbsp; retain all their rights.</FONT></DIV>
<DIV><FONT face="Courier New" color=#0000ff size=2></FONT>&nbsp;</DIV>
<DIV dir=ltr align=left><FONT face="Courier New" color=#0000ff 
size=2>&nbsp;&nbsp; This document and the information contained herein are 
provided on an<BR>&nbsp;&nbsp; "AS IS" basis and THE CONTRIBUTOR, THE 
ORGANIZATION HE/SHE REPRESENTS<BR>&nbsp;&nbsp; OR IS SPONSORED BY (IF ANY), THE 
INTERNET SOCIETY, THE IETF TRUST AND<BR>&nbsp;&nbsp; THE INTERNET ENGINEERING 
TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS<BR>&nbsp;&nbsp; OR IMPLIED, 
INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF<BR>&nbsp;&nbsp; THE 
INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED<BR>&nbsp;&nbsp; 
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.</FONT></DIV>
<DIV><FONT face="Courier New" color=#0000ff size=2></FONT>&nbsp;</DIV>
<DIV dir=ltr align=left><BR><FONT face="Courier New" color=#0000ff 
size=2>Intellectual Property</FONT></DIV>
<DIV><FONT face="Courier New" color=#0000ff size=2></FONT>&nbsp;</DIV>
<DIV dir=ltr align=left><FONT face="Courier New" color=#0000ff 
size=2>&nbsp;&nbsp; The IETF takes no position regarding the validity or scope 
of any<BR>&nbsp;&nbsp; Intellectual Property Rights or other rights that might 
be claimed to<BR>&nbsp;&nbsp; pertain to the implementation or use of the 
technology described in<BR>&nbsp;&nbsp; this document or the extent to which any 
license under such rights<BR>&nbsp;&nbsp; might or might not be available; nor 
does it represent that it has<BR>&nbsp;&nbsp; made any independent effort to 
identify any such rights.&nbsp; Information<BR>&nbsp;&nbsp; on the procedures 
with respect to rights in RFC documents can be<BR>&nbsp;&nbsp; found in BCP 78 
and BCP 79.</FONT></DIV>
<DIV><FONT face="Courier New" color=#0000ff size=2></FONT>&nbsp;</DIV>
<DIV dir=ltr align=left><FONT face="Courier New" color=#0000ff 
size=2>&nbsp;&nbsp; Copies of IPR disclosures made to the IETF Secretariat and 
any<BR>&nbsp;&nbsp; assurances of licenses to be made available, or the result 
of an<BR>&nbsp;&nbsp; attempt made to obtain a general license or permission for 
the use of<BR>&nbsp;&nbsp; such proprietary rights by implementers or users of 
this<BR>&nbsp;&nbsp; specification can be obtained from the IETF on-line IPR 
repository at<BR>&nbsp;&nbsp; </FONT><A href="http://www.ietf.org/ipr"><FONT 
face="Courier New" size=2>http://www.ietf.org/ipr</FONT></A><FONT 
face="Courier New" color=#0000ff size=2>.</FONT></DIV>
<DIV><FONT face="Courier New" color=#0000ff size=2></FONT>&nbsp;</DIV>
<DIV dir=ltr align=left><FONT face="Courier New" color=#0000ff 
size=2>&nbsp;&nbsp; The IETF invites any interested party to bring to its 
attention any<BR>&nbsp;&nbsp; copyrights, patents or patent applications, or 
other proprietary<BR>&nbsp;&nbsp; rights that may cover technology that may be 
required to implement<BR>&nbsp;&nbsp; this standard.&nbsp; Please address the 
information to the IETF at<BR>&nbsp;&nbsp; </FONT><A 
href="mailto:[email-masked]"><FONT face="Courier New" 
size=2>[email-masked]</FONT></A><FONT face="Courier New" color=#0000ff 
size=2>.</FONT></DIV>
<DIV><FONT face="Courier New" color=#0000ff size=2></FONT>&nbsp;</DIV>
<DIV dir=ltr align=left><FONT face="Courier New" color=#0000ff 
size=2></FONT>&nbsp;</DIV>
<DIV><FONT face="Courier New" color=#0000ff size=2></FONT>&nbsp;</DIV>
<DIV dir=ltr align=left><FONT face="Courier New" color=#0000ff 
size=2></FONT>&nbsp;</DIV>
<DIV><FONT face="Courier New" color=#0000ff size=2></FONT>&nbsp;</DIV>
<DIV dir=ltr align=left><FONT face="Courier New" color=#0000ff 
size=2></FONT>&nbsp;</DIV>
<DIV><FONT face="Courier New" color=#0000ff size=2></FONT>&nbsp;</DIV>
<DIV dir=ltr align=left><FONT face="Courier New" color=#0000ff 
size=2></FONT>&nbsp;</DIV>
<DIV><FONT face="Courier New" color=#0000ff size=2></FONT>&nbsp;</DIV>
<DIV dir=ltr align=left><FONT face="Courier New" color=#0000ff 
size=2></FONT>&nbsp;</DIV>
<DIV><FONT face="Courier New" color=#0000ff size=2></FONT>&nbsp;</DIV>
<DIV dir=ltr align=left><FONT face="Courier New" color=#0000ff size=2>Bocci, et 
al.&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Expires 
August 15, 
2009&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
[Page 18]<BR></FONT></DIV>
<DIV><FONT face="Courier New" color=#0000ff size=2></FONT>&nbsp;</DIV>
<DIV dir=ltr align=left><FONT 
face="Courier New"></FONT></SPAN>&nbsp;</DIV></BODY></HTML>

------_=_NextPart_001_01C99351.C47CC435--

Content-class: urn:content-classes:message
Date: Fri, 20 Feb 2009 14:26:45 +0100
From: "BUSI ITALO" <[email-masked]>
To: "BOCCI Matthew" <[email-masked]>
Cc: MEAD team <[email-masked]>
Subject: Re: [Mpls-interop] Updated version of GACH-GAL draft

Matthew,
 
see in line marked with [ib]

I have removed text that is not relevant

Thanks, Italo

________________________________

	From: BOCCI Matthew 
	Sent: Friday, February 20, 2009 12:53 PM
	To: BUSI ITALO
	Cc: 'MEAD team'
	Subject: RE: [Mpls-interop] Updated version of GACH-GAL draft

	Italo,
	 
	Thanks for your comments.
	 
	Please see below for responses.
	 
	Matthew

	
	MPLS Working Group                                         M.
Bocci, Ed.
	Internet-Draft                                         M.
Vigoureux, Ed.
	Updates: 3032, 4385, 5085
Alcatel-Lucent
	 
	<<Comment: I think it also updates RFC 4446>>

[ib] I am not sure you agree or have missed this comment.

	(if approved)                                                 G.
Swallow

<...>

	<<Comment>>
	 
	Is it worth to capitalize the must"?
	 
	OLD
	 
	   tools must be applicable to, and function in essentially the
same
	 
	NEW
	 
	   tools MUST be applicable to, and function in essentially the
same
	 
	<<End Comment>>
	 
	   manner (from an operational point of view) on MPLS PWs, MPLS
LSPs and
	 
	<<Comment>>
	 
	Is it worth to capitalize the must"?
	 
	MB> Yes. The RFC-ed will also make this comment. I agree with
you on these capitalisation points throughout.

[ib] Ok

	OLD
	 
	   MPLS Sections.  They must also operate in-band on the PW or
LSP such
	 
	NEW
	 
	   MPLS Sections.  They MUST also operate in-band on the PW or
LSP such
	 
	<<End Comment>>
	 
	   that they do not depend on Packet Switched Network (PSN)
routing or
	 
	<<Comment>>
	 
	Is it worth to capitalize the must"?
	 
	OLD
	 
	   on user data traffic, and must also not depend on dynamic
control
	 
	NEW
	 
	   on user data traffic, and MUST also not depend on dynamic
control
	 
	<<End Comment>>

<...>
	 
	<<Comment>>
	 
	If I understand correctly, this document calls G-ACh the Generic
Associate Channel and G-ACH the Generic Associated Channel Header.
	 
	ADD
	 
	   G-ACH: Generic Associated Channel Header
	 
	<<End Comment>>

	MB> No, the associated channel header is just an ACH. There is
no difference from the existing ACH, so we do not need to call it a
G-ACH. However, the channel it creates is generic, becuase it applies to
PWs, LSPs and Sections, so it is a G-ACh. However, the title of the
draft is now confusing. The title should probably be changed to either
"Generalising the associated channel header for MPLS", or "MPLS Generic
Associated Channel". But that is probably a significant enough change to
be worth repeating as a last call comment.
	 
[ib] If I understand correctly, I have to raise a LC comment on the name
after the draft goes in LC.

That is fine for me. Just note that there are few occurences in the
draft where G-ACH is used to indicate "Generic Associated Channel
Header".

<...>

	<<Comment>>
	 
	While a fully agree that for MPLS-TP Sections the S bit MUST be
set to 1, I am not 100% sure that this is true also for MPLS Sections.
	 
	<<End Comment>>
	 
	MB> If an MPLS section turns out to be another MPLS LSP on which
a hash label or something is used, then I guess you are right. Maybe we
should make the same statement as for LSPs. However, this is significant
enought that we should proably raise this during the second LC.

[ib] If I understand correctly, I have to raise a LC comment on the name
after the draft goes in LC.

That is fine for me. Just note that in draft-ietf-mpls-tp-gach-gal-01 is
was stated that the S bit of the GAL is set to 1 for MPLS-TP (and not
for MPLS).

<...>

	<<Comment>>
	 
	I wonder whether it would be useful to allocate at least one TLV
for experimental use.
	 
	<<End Comment>>
	 
	MB> Do we really need this if we use an experimental channel
type? In any case, I am not sure we are being inconsistent with the
above text if we specficy one code point in the ACH TLV draft that is
experimental.

[ib] That's fine for me.

<...>

Content-class: urn:content-classes:message
Date: Fri, 20 Feb 2009 15:21:35 +0100
From: "BUSI ITALO" <[email-masked]>
To: "BOCCI Matthew" <[email-masked]>, "Sprecher, Nurit (NSN - IL/Hod HaSharon)" <[email-masked]>, "MEAD team" <[email-masked]>
Cc: "Weingarten, Yaacov \(NSN - IL/Hod HaSharon\)" <[email-masked]>
Subject: Re: [Mpls-interop] Updated version of GACH-GAL draft

This is a multi-part message in MIME format.

------_=_NextPart_001_01C99366.89B2854F
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

Matthew,
 
I have not strong opinion either.
 
I think the note is clear enough but I noticed people do not tend to
read it with the same attention they look at the figures.
 
In the past I have proposed "Associated Channel Message/Packet" to be
generic enough and to avoid defining new terms.

Just my 2 cents ;-)
 
Italo

________________________________

	From: [email-masked]
[mailto:[email-masked]] On Behalf Of BOCCI Matthew
	Sent: Friday, February 20, 2009 12:32 PM
	To: Sprecher, Nurit (NSN - IL/Hod HaSharon); MEAD team
	Cc: Weingarten, Yaacov (NSN - IL/Hod HaSharon)
	Subject: Re: [Mpls-interop] Updated version of GACH-GAL draft

	Hi Nurit,
	 
	Thanks very much for your comments. The use of the term
'maintenance' is not intended to exclude control functions, and we do
include the following statement in the draft:
	 
	"Note that, in this document, maintenance functions and packets
should be understood in the broad sense. That is, a set of maintenance
and management mechanisms that include OAM, Automatic Protection
Switching (APS), Signalling Communication Channel (SCC) and Management
Communication Channel (MCC) messages."
	 
	I don't have a strong opinion on this, but I do want to make
sure that it is absolutely clear that we are not precluding non-OAM
messages, so I'd appreciate some further feedback from the list before
changing the current text. I fear that if we do change the text we might
get a similar comment for "control" ;-)
	 
	Regards
	 
	Matthew

________________________________

		From: Sprecher, Nurit (NSN - IL/Hod HaSharon)
[mailto:[email-masked]] 
		Sent: 20 February 2009 11:08
		To: BOCCI Matthew; MEAD team
		Cc: Weingarten, Yaacov (NSN - IL/Hod HaSharon);
Sprecher, Nurit (NSN - IL/Hod HaSharon)
		Subject: RE: [Mpls-interop] Updated version of GACH-GAL
draft

		Hi Matthew,

		Thanks for the updated document. I am glad to see the
SCH TLVs included in this version.

		I have an editorial comment to the entire document. I
would propose to change the name "Maintenance Message" to "Control
Message" or Control Message payload". The channels are used for control
messages, and I prefer the name to reflect it better. We do not say
maintenance plane but control plane, although it is used also for
maintenance. 

		Best regards,

		Nurit

________________________________

		From: [email-masked]
[mailto:[email-masked]] On Behalf Of ext BOCCI Matthew
		Sent: Wednesday, February 18, 2009 15:58
		To: MEAD team
		Subject: [Mpls-interop] Updated version of GACH-GAL
draft

		Please find attached an updated version of
draft-ietf-mpls-tp-gach-gal-02.txt, updated as per the discussion on the
MEAD team call yesterday.

		Please can you let me know if you have any comments by
the end of this week. I would like to upload the new version to the IETF
by Monday so that Loa can initiate a second last call on this draft.

		Best regards 

		Matthew 
		<<draft-ietf-mpls-tp-gach-gal-02.txt>> 

------_=_NextPart_001_01C99366.89B2854F
Content-Type: text/html;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML xmlns="http://www.w3.org/TR/REC-html40" xmlns:v = 
"urn:schemas-microsoft-com:vml" xmlns:o = 
"urn:schemas-microsoft-com:office:office" xmlns:w = 
"urn:schemas-microsoft-com:office:word"><HEAD><TITLE>Updated version of GACH-GAL draft</TITLE>
<META http-equiv=Content-Type content="text/html; charset=us-ascii">
<META content="MSHTML 6.00.6000.16809" name=GENERATOR><!--[if !mso]>
<STYLE>v\:* {
	BEHAVIOR: url(#default#VML)
}
o\:* {
	BEHAVIOR: url(#default#VML)
}
w\:* {
	BEHAVIOR: url(#default#VML)
}
.shape {
	BEHAVIOR: url(#default#VML)
}
</STYLE>
<![endif]-->
<STYLE>@font-face {
	font-family: Tahoma;
}
@page Section1 {size: 595.3pt 841.9pt; margin: 1.0in 1.25in 1.0in 1.25in; }
P.MsoNormal {
	FONT-SIZE: 12pt; MARGIN: 0in 0in 0pt; FONT-FAMILY: "Times New Roman"
}
LI.MsoNormal {
	FONT-SIZE: 12pt; MARGIN: 0in 0in 0pt; FONT-FAMILY: "Times New Roman"
}
DIV.MsoNormal {
	FONT-SIZE: 12pt; MARGIN: 0in 0in 0pt; FONT-FAMILY: "Times New Roman"
}
A:link {
	COLOR: blue; TEXT-DECORATION: underline
}
SPAN.MsoHyperlink {
	COLOR: blue; TEXT-DECORATION: underline
}
A:visited {
	COLOR: purple; TEXT-DECORATION: underline
}
SPAN.MsoHyperlinkFollowed {
	COLOR: purple; TEXT-DECORATION: underline
}
P {
	FONT-SIZE: 12pt; MARGIN-LEFT: 0in; MARGIN-RIGHT: 0in; FONT-FAMILY: "Times New Roman"; mso-margin-top-alt: auto; mso-margin-bottom-alt: auto
}
SPAN.EmailStyle18 {
	COLOR: navy; FONT-FAMILY: Arial; mso-style-type: personal-reply
}
DIV.Section1 {
	page: Section1
}
</STYLE>
<!--[if gte mso 9]><xml>
 <o:shapedefaults v:ext="edit" spidmax="1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
 <o:shapelayout v:ext="edit">
  <o:idmap v:ext="edit" data="1" />
 </o:shapelayout></xml><![endif]--></HEAD>
<BODY lang=EN-US vLink=purple link=blue>
<DIV dir=ltr align=left><SPAN class=686591814-20022009><FONT face="Courier New" 
size=2>Matthew,</FONT></SPAN></DIV>
<DIV dir=ltr align=left><SPAN class=686591814-20022009><FONT face="Courier New" 
size=2></FONT></SPAN>&nbsp;</DIV>
<DIV dir=ltr align=left><SPAN class=686591814-20022009><FONT face="Courier New" 
size=2>I have not strong opinion either.</FONT></SPAN></DIV>
<DIV dir=ltr align=left><SPAN class=686591814-20022009><FONT face="Courier New" 
size=2></FONT></SPAN>&nbsp;</DIV>
<DIV dir=ltr align=left><SPAN class=686591814-20022009><FONT face="Courier New" 
size=2>I think the note is clear enough but I noticed people do not tend to read 
it with the same attention they look at the figures.</FONT></SPAN></DIV>
<DIV dir=ltr align=left><SPAN class=686591814-20022009><FONT face="Courier New" 
size=2></FONT></SPAN>&nbsp;</DIV>
<DIV dir=ltr align=left><SPAN class=686591814-20022009><FONT face="Courier New" 
size=2>In the past I have proposed "<FONT size=2>Associated Channel 
Message/Packet" to be generic enough and to avoid defining new 
terms.</FONT></FONT></SPAN><BR></DIV>
<DIV dir=ltr align=left><FONT face="Courier New" size=2><SPAN 
class=686591814-20022009>Just my 2 cents ;-)</SPAN></FONT></DIV>
<DIV dir=ltr align=left><FONT face="Courier New" size=2></FONT>&nbsp;</DIV>
<DIV dir=ltr align=left><SPAN class=686591814-20022009><FONT face="Courier New" 
size=2>Italo</FONT></SPAN></DIV>
<BLOCKQUOTE dir=ltr 
style="PADDING-LEFT: 5px; MARGIN-LEFT: 5px; BORDER-LEFT: #000000 2px solid; MARGIN-RIGHT: 0px">
  <DIV class=OutlookMessageHeader lang=en-us dir=ltr align=left>
  <HR tabIndex=-1>
  <FONT face=Tahoma size=2><B>From:</B> [email-masked] 
  [mailto:[email-masked]] <B>On Behalf Of </B>BOCCI 
  Matthew<BR><B>Sent:</B> Friday, February 20, 2009 12:32 PM<BR><B>To:</B> 
  Sprecher, Nurit (NSN - IL/Hod HaSharon); MEAD team<BR><B>Cc:</B> Weingarten, 
  Yaacov (NSN - IL/Hod HaSharon)<BR><B>Subject:</B> Re: [Mpls-interop] Updated 
  version of GACH-GAL draft<BR></FONT><BR></DIV>
  <DIV></DIV>
  <DIV dir=ltr align=left><SPAN class=140412611-20022009><FONT face=Arial 
  color=#0000ff size=2>Hi Nurit,</FONT></SPAN></DIV>
  <DIV dir=ltr align=left><SPAN class=140412611-20022009><FONT face=Arial 
  color=#0000ff size=2></FONT></SPAN>&nbsp;</DIV>
  <DIV dir=ltr align=left><SPAN class=140412611-20022009><FONT face=Arial 
  color=#0000ff size=2>Thanks very much for your comments. The use of the term 
  'maintenance' is not intended to exclude control functions, and we do include 
  the following statement in the draft:</FONT></SPAN></DIV>
  <DIV dir=ltr align=left><SPAN class=140412611-20022009><FONT face=Arial 
  color=#0000ff size=2></FONT></SPAN>&nbsp;</DIV>
  <DIV dir=ltr align=left><SPAN class=140412611-20022009><FONT face=Arial 
  color=#0000ff size=2>"Note that, in this document, maintenance functions and 
  packets should be understood in the broad sense. That is, a set of maintenance 
  and management mechanisms that include OAM, Automatic Protection Switching 
  (APS), Signalling Communication Channel (SCC) and Management Communication 
  Channel (MCC) messages."</FONT></SPAN></DIV>
  <DIV dir=ltr align=left><SPAN class=140412611-20022009><FONT face=Arial 
  color=#0000ff size=2></FONT></SPAN>&nbsp;</DIV>
  <DIV dir=ltr align=left><SPAN class=140412611-20022009><FONT face=Arial 
  color=#0000ff size=2>I don't have a strong opinion on this, but I do want to 
  make sure that it is absolutely clear that we are not precluding non-OAM 
  messages, so I'd appreciate some further feedback from the list before 
  changing the current text. I fear that if we do change the text we might get a 
  similar comment for "control" ;-)</FONT></SPAN></DIV>
  <DIV dir=ltr align=left><SPAN class=140412611-20022009><FONT face=Arial 
  color=#0000ff size=2></FONT></SPAN>&nbsp;</DIV>
  <DIV dir=ltr align=left><SPAN class=140412611-20022009><FONT face=Arial 
  color=#0000ff size=2>Regards</FONT></SPAN></DIV>
  <DIV dir=ltr align=left><SPAN class=140412611-20022009><FONT face=Arial 
  color=#0000ff size=2></FONT></SPAN>&nbsp;</DIV>
  <DIV dir=ltr align=left><SPAN class=140412611-20022009><FONT face=Arial 
  color=#0000ff size=2>Matthew</FONT></SPAN></DIV><BR>
  <BLOCKQUOTE 
  style="PADDING-LEFT: 5px; MARGIN-LEFT: 5px; BORDER-LEFT: #0000ff 2px solid; MARGIN-RIGHT: 0px">
    <DIV class=OutlookMessageHeader lang=en-us dir=ltr align=left>
    <HR tabIndex=-1>
    <FONT face=Tahoma size=2><B>From:</B> Sprecher, Nurit (NSN - IL/Hod 
    HaSharon) [mailto:[email-masked]] <BR><B>Sent:</B> 20 February 2009 
    11:08<BR><B>To:</B> BOCCI Matthew; MEAD team<BR><B>Cc:</B> Weingarten, 
    Yaacov (NSN - IL/Hod HaSharon); Sprecher, Nurit (NSN - IL/Hod 
    HaSharon)<BR><B>Subject:</B> RE: [Mpls-interop] Updated version of GACH-GAL 
    draft<BR></FONT><BR></DIV>
    <DIV></DIV>
    <DIV class=Section1 dir=rtl>
    <P class=MsoNormal dir=ltr><FONT face=Arial color=navy size=2><SPAN 
    style="FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: Arial">Hi 
    Matthew,<o:p></o:p></SPAN></FONT></P>
    <P class=MsoNormal dir=ltr><FONT face=Arial color=navy size=2><SPAN 
    style="FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: Arial">Thanks for the 
    updated document. I am glad to see the SCH TLVs included in this 
    version.<o:p></o:p></SPAN></FONT></P>
    <P class=MsoNormal dir=ltr><FONT face=Arial color=navy size=2><SPAN 
    style="FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: Arial"><BR>I have an 
    editorial comment to the entire document. I would propose to change the name 
    "Maintenance Message" to "Control Message" or Control Message payload". The 
    channels are used for control messages, and I prefer the name to reflect it 
    better. We do not say maintenance plane but control plane, although it is 
    used also for maintenance. <o:p></o:p></SPAN></FONT></P>
    <P class=MsoNormal dir=ltr><FONT face=Arial color=navy size=2><SPAN 
    style="FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: Arial">Best 
    regards,<o:p></o:p></SPAN></FONT></P>
    <P class=MsoNormal dir=ltr><FONT face=Arial color=navy size=2><SPAN 
    style="FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: Arial">Nurit<o:p></o:p></SPAN></FONT></P>
    <P class=MsoNormal dir=ltr><FONT face=Arial color=navy size=2><SPAN 
    style="FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: Arial"><o:p>&nbsp;</o:p></SPAN></FONT></P>
    <P class=MsoNormal dir=ltr><FONT face=Arial color=navy size=2><SPAN 
    style="FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: Arial"><o:p>&nbsp;</o:p></SPAN></FONT></P>
    <DIV>
    <DIV class=MsoNormal dir=ltr style="TEXT-ALIGN: center" align=center><FONT 
    face="Times New Roman" size=3><SPAN style="FONT-SIZE: 12pt">
    <HR tabIndex=-1 align=center width="100%" SIZE=2>
    </SPAN></FONT></DIV>
    <P class=MsoNormal dir=ltr><B><FONT face=Tahoma size=2><SPAN 
    style="FONT-WEIGHT: bold; FONT-SIZE: 10pt; FONT-FAMILY: Tahoma">From:</SPAN></FONT></B><FONT 
    face=Tahoma size=2><SPAN style="FONT-SIZE: 10pt; FONT-FAMILY: Tahoma"> 
    [email-masked] [mailto:[email-masked]] 
    <B><SPAN style="FONT-WEIGHT: bold">On Behalf Of </SPAN></B>ext BOCCI 
    Matthew<BR><B><SPAN style="FONT-WEIGHT: bold">Sent:</SPAN></B> Wednesday, 
    February 18, 2009 15:58<BR><B><SPAN style="FONT-WEIGHT: bold">To:</SPAN></B> 
    MEAD team<BR><B><SPAN style="FONT-WEIGHT: bold">Subject:</SPAN></B> 
    [Mpls-interop] Updated version of GACH-GAL 
    draft</SPAN></FONT><o:p></o:p></P></DIV>
    <P class=MsoNormal dir=ltr><FONT face="Times New Roman" size=3><SPAN 
    style="FONT-SIZE: 12pt"><o:p>&nbsp;</o:p></SPAN></FONT></P>
    <P dir=ltr><FONT face=Arial size=2><SPAN 
    style="FONT-SIZE: 10pt; FONT-FAMILY: Arial">Please find attached an updated 
    version of draft-ietf-mpls-tp-gach-gal-02.txt, updated as per the discussion 
    on the MEAD team call yesterday.</SPAN></FONT><o:p></o:p></P>
    <P dir=ltr><FONT face=Arial size=2><SPAN 
    style="FONT-SIZE: 10pt; FONT-FAMILY: Arial">Please can you let me know if 
    you have any comments by the end of this week. I would like to upload the 
    new version to the IETF by Monday so that Loa can initiate a second last 
    call on this draft.</SPAN></FONT><o:p></o:p></P>
    <P dir=ltr><FONT face=Arial size=2><SPAN 
    style="FONT-SIZE: 10pt; FONT-FAMILY: Arial">Best regards</SPAN></FONT> 
    <o:p></o:p></P>
    <P dir=ltr><FONT face=Arial size=2><SPAN 
    style="FONT-SIZE: 10pt; FONT-FAMILY: Arial">Matthew</SPAN></FONT> <BR><FONT 
    face=Arial color=black size=2><SPAN 
    style="FONT-SIZE: 10pt; COLOR: black; FONT-FAMILY: Arial">&lt;&lt;draft-ietf-mpls-tp-gach-gal-02.txt&gt;&gt; 
    </SPAN></FONT><o:p></o:p></P></DIV></BLOCKQUOTE></BLOCKQUOTE></BODY></HTML>

------_=_NextPart_001_01C99366.89B2854F--

Date: Sun, 22 Feb 2009 17:41:30 +0000
From: Ben Niven-Jenkins <[email-masked]>
To: Annamaria Fulignoli <[email-masked]>, <[email-masked]>
Subject: Re: [Mpls-interop] MPLS-TP 1+1 bidirectional protection requirement on " draft-ietf-mpls-tp-requirements-04"

Annamaria,

Following discussion with other operators we decided that a requirement
exists for
Both uni & bi directional 1+1 for P2P
Uni directional 1+1 for P2MP
But that the requirement draft should not state a default behaviour.

I have therefore changed requirement 54 to read as follows
"
MPLS-TP MUST support 1+1 protection.
 A Bidirectional 1+1 protection for P2P connectivity MUST be supported.
 B Unidirectional 1+1 protection for P2P connectivity MUST be supported.
 C Unidirectional 1+1 protection for P2MP connectivity MUST be supported.
"

It does raise in my mind a similar question for requirement 55 on 1:n
protection. Should we do the same and not state a default behaviour?

Thans
Ben

On 16/02/2009 12:33, "Annamaria Fulignoli"
<[email-masked]> wrote:

> Hi all,
> I'm sorry but I disagree with the Req. 54 of the ID :
> "draft-ietf-mpls-tp-requirements-04".
> 
> Unidirectional and bidirectional 1+1 protection are the same with
> regards to the requirement for simultaneous sending of traffic on both
> LSPs and hence 100% traffic duplication.
> However 1+1 unidirectional protection is a simpler scheme which doesn't
> require a protocol for end-node coordination.
> 
> So I ask again that the default for the 1+1 protection is the
> unidirectional one while the 1+1 bidirectional is optional ( or even not
> required ).
> 
> Thank you. 
> Best Regards,
> Annamaria
> 
> 
> _______________________________________________
> Mpls-interop mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/mpls-interop

Date: Sun, 22 Feb 2009 17:45:17 +0000
From: Ben Niven-Jenkins <[email-masked]>
To: Lou Berger <[email-masked]>
Cc: [email-masked]
Subject: Re: [Mpls-interop] control plane interoperability requirement

Done. Ben

On 17/02/2009 21:59, "Lou Berger" <[email-masked]> wrote:

> Ben,
> It looks like we have a bit of disconnect between some of the
> existing documents regarding control plane interoperability
> requirements. We think the following change to the requirements draft
> will fix the issue:
> 
> Old text:
>     3   Mechanisms and capabilities MUST be able to interoperate, without
>         a gateway function, with existing IETF MPLS [RFC3031] and IETF
>         PWE3 [RFC3985] control and data planes where appropriate.
> 
> New text:
>     3   Mechanisms and capabilities MUST be able to interoperate with
>         existing IETF MPLS [RFC3031] and IETF PWE3 [RFC3985] control and
>         data planes where appropriate.
> 
>         a. data plane interoperability MUST NOT require a gateway function.
> 
> This will align the requirements with the current TP framework
> document which states: "GMPLS based MPLS-TP LSPs must be able to
> interoperate with RSVP-TE based MPLS-TE LSPs, as per [RFC 5146]"
> 
> Much thanks,
> Lou (and Loa & Luyan)
> 

Sensitivity: Normal
Importance: Normal
To: "Ben Niven-Jenkins" <[email-masked]>, "Lou Berger" <[email-masked]>
From: "Lou Berger" <[email-masked]>
Date: Sun, 22 Feb 2009 21:06:14 +0000
Cc: [email-masked]
Subject: Re: [Mpls-interop] control plane interoperability requirement
Reply-To: [email-masked]

Content-class: urn:content-classes:message
Date: Mon, 23 Feb 2009 10:13:59 +0100
From: "Sprecher, Nurit (NSN - IL/Hod HaSharon)" <[email-masked]>
To: "ext Lou Berger" <[email-masked]>, "Loa Andersson" <[email-masked]>, "Bitar, Nabil N." <[email-masked]>, <[email-masked]>
Cc: MEAD team <[email-masked]>, "Weingarten, Yaacov \(NSN - IL/Hod HaSharon\)" <[email-masked]>
Subject: [Mpls-interop] Copy of draft-abfb-mpls-tp-control-plane-framework-00.doc

This is a multi-part message in MIME format.

------_=_NextPart_001_01C99597.1311D364
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_002_01C99597.1311D364"

------_=_NextPart_002_01C99597.1311D364
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

Hi,
Thanks for the document.
Please some comments in the attached.
In addition, I think H-LSP is the implementation we are using for PST
(Path Segment Tunnel) which is used to monitor and manage segments of
transport paths (e.g. for purposes like OAM, PSC, etc.). This is the
existing construct to do it. Still, I propose to define the PST
architectural element in one of the documents........the most
appropriate place would be the MPLS-TP framework document. 
BEst regards,
NUrit

------_=_NextPart_002_01C99597.1311D364
Content-Type: text/html;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META http-equiv=Content-Type content="text/html; charset=us-ascii">
<META content="MSHTML 6.00.2900.3492" name=GENERATOR></HEAD>
<BODY>
<DIV><SPAN class=163500909-23022009><FONT face=Arial 
size=2>Hi,</FONT></SPAN></DIV>
<DIV><SPAN class=163500909-23022009><FONT face=Arial size=2>Thanks for the 
document.</FONT></SPAN></DIV>
<DIV><SPAN class=163500909-23022009><FONT face=Arial size=2>Please some comments 
in the attached.</FONT></SPAN></DIV>
<DIV><SPAN class=163500909-23022009><FONT face=Arial size=2>In addition, I think 
H-LSP is the implementation we are using for PST (Path Segment Tunnel) which is 
used to monitor and manage segments of transport paths (e.g. for purposes like 
OAM, PSC, etc.). This is the existing construct to do it. Still, I propose to 
define the PST architectural element in one of the documents........the most 
appropriate place would be the MPLS-TP framework document. </FONT></SPAN></DIV>
<DIV><SPAN class=163500909-23022009><FONT face=Arial size=2>BEst 
regards,</FONT></SPAN></DIV>
<DIV><SPAN class=163500909-23022009><FONT face=Arial 
size=2>NUrit</FONT></SPAN></DIV></BODY></HTML>

------_=_NextPart_002_01C99597.1311D364--

------_=_NextPart_001_01C99597.1311D364
Content-Type: application/msword;
	name="Copy of draft-abfb-mpls-tp-control-plane-framework-00.doc"
Content-Transfer-Encoding: base64
Content-Description: Copy of draft-abfb-mpls-tp-control-plane-framework-00.doc
Content-Disposition: attachment;
	filename="Copy of draft-abfb-mpls-tp-control-plane-framework-00.doc"

0M8R4KGxGuEAAAAAAAAAAAAAAAAAAAAAPgADAP7/CQAGAAAAAAAAAAAAAAAEAAAAmAEAAAAAAAAA
EAAAmgEAAAEAAAD+////AAAAAJABAACRAQAAkgEAAJkBAAD/////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////AQAAAP7///8DAAAA
BAAAAAUAAAAGAAAABwAAAP7/////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
AAACAAAAsAQAABMAAAAJBAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA

------_=_NextPart_001_01C99597.1311D364--

Date: Mon, 23 Feb 2009 14:46:40 +0100
From: Loa Andersson <[email-masked]>
To: MEAD team <[email-masked]>
Subject: [Mpls-interop] MEAD team meeting tomorrow Feb 24 cancelled - new date Mar 03

All,

I've decided to cancel the MEAD team meeting tomorrow, the next meeting
will be Mar 03. Same time as usual.

The plan is to use WebEx to discuss the 
draft-busi-mpls-tp-oam-framework-00 and if possible to get in shape to
tart a poll on becoming a working document.

/Loa

-- 

Loa Andersson

Sr Strategy and Standards Manager
Ericsson ///                          phone:  +46 8 632 77 14

                                       email:  [email-masked]
                                               [email-masked]
                                               [email-masked]

Date: Mon, 23 Feb 2009 15:50:23 -0500
From: Lou Berger <[email-masked]>
To: "Sprecher, Nurit (NSN - IL/Hod HaSharon)" <[email-masked]>
Cc: "Weingarten, Yaacov \(NSN - IL/Hod HaSharon\)" <[email-masked]>, MEAD team <[email-masked]>
Subject: Re: [Mpls-interop] Copy of draft-abfb-mpls-tp-control-plane-framework-00.doc

Nurit,

I agree that defining PST in only place is optimal.

WRT your in-document comments.  If you'd like to discuss any of the 
comments on the list, could you extract them from the document and send 
the question/comment to the list?

Much thanks,
Lou

On 2/23/2009 4:13 AM, Sprecher, Nurit (NSN - IL/Hod HaSharon) wrote:
> Hi,
> Thanks for the document.
> Please some comments in the attached.
> In addition, I think H-LSP is the implementation we are using for PST
> (Path Segment Tunnel) which is used to monitor and manage segments of
> transport paths (e.g. for purposes like OAM, PSC, etc.). This is the
> existing construct to do it. Still, I propose to define the PST
> architectural element in one of the documents........the most
> appropriate place would be the MPLS-TP framework document.
> BEst regards,
> NUrit

Date: Mon, 23 Feb 2009 22:08:37 +0000
From: Ben Niven-Jenkins <[email-masked]>
To: Lou Berger <[email-masked]>, "Sprecher, Nurit (NSN - IL/Hod HaSharon)" <[email-masked]>
Cc: MEAD team <[email-masked]>, "Weingarten, Yaacov \(NSN - IL/Hod HaSharon\)" <[email-masked]>
Subject: Re: [Mpls-interop] Copy of draft-abfb-mpls-tp-control-plane-framework-00.doc

Whoa there cowboys, what's a PST? How does it relate to a
segment/concatenated segment? Is it just a "proposed IETF term" for Tandem
Connection?

Thanks
Ben

On 23/02/2009 20:50, "Lou Berger" <[email-masked]> wrote:

> 
> Nurit,
> 
> I agree that defining PST in only place is optimal.
> 
> WRT your in-document comments.  If you'd like to discuss any of the
> comments on the list, could you extract them from the document and send
> the question/comment to the list?
> 
> Much thanks,
> Lou
> 
> On 2/23/2009 4:13 AM, Sprecher, Nurit (NSN - IL/Hod HaSharon) wrote:
>> Hi,
>> Thanks for the document.
>> Please some comments in the attached.
>> In addition, I think H-LSP is the implementation we are using for PST
>> (Path Segment Tunnel) which is used to monitor and manage segments of
>> transport paths (e.g. for purposes like OAM, PSC, etc.). This is the
>> existing construct to do it. Still, I propose to define the PST
>> architectural element in one of the documents........the most
>> appropriate place would be the MPLS-TP framework document.
>> BEst regards,
>> NUrit
> _______________________________________________
> Mpls-interop mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/mpls-interop

Date: Mon, 23 Feb 2009 17:20:40 -0500
From: Lou Berger <[email-masked]>
To: Ben Niven-Jenkins <[email-masked]>
Cc: MEAD team <[email-masked]>, "Weingarten, Yaacov \(NSN - IL/Hod HaSharon\)" <[email-masked]>
Subject: Re: [Mpls-interop] Copy of draft-abfb-mpls-tp-control-plane-framework-00.doc

The point I was agreeing to is that the CP document isn't the right 
place to be defining the *data plane* constructs used to support 
protection.  In "classic" IETF speak, a hierarchical LSP is used. 
Nurit's assertion is that PST is the MPLS-TP term for the construct. 
(Please feel free to argue with her ;-) I really don't care which term 
we use, but the control plane document shouldn't be the place the 
defines the architectural construct...

Lou

On 2/23/2009 5:08 PM, Ben Niven-Jenkins wrote:
> Whoa there cowboys, what's a PST? How does it relate to a
> segment/concatenated segment? Is it just a "proposed IETF term" for Tandem
> Connection?
>
> Thanks
> Ben
>
>
>
> On 23/02/2009 20:50, "Lou Berger"<[email-masked]>  wrote:
>
>> Nurit,
>>
>> I agree that defining PST in only place is optimal.
>>
>> WRT your in-document comments.  If you'd like to discuss any of the
>> comments on the list, could you extract them from the document and send
>> the question/comment to the list?
>>
>> Much thanks,
>> Lou
>>
>> On 2/23/2009 4:13 AM, Sprecher, Nurit (NSN - IL/Hod HaSharon) wrote:
>>> Hi,
>>> Thanks for the document.
>>> Please some comments in the attached.
>>> In addition, I think H-LSP is the implementation we are using for PST
>>> (Path Segment Tunnel) which is used to monitor and manage segments of
>>> transport paths (e.g. for purposes like OAM, PSC, etc.). This is the
>>> existing construct to do it. Still, I propose to define the PST
>>> architectural element in one of the documents........the most
>>> appropriate place would be the MPLS-TP framework document.
>>> BEst regards,
>>> NUrit
>> _______________________________________________
>> Mpls-interop mailing list
>> [email-masked]
>> https://www.ietf.org/mailman/listinfo/mpls-interop
>
>
>
>

Date: Mon, 23 Feb 2009 23:57:17 +0000
From: Ben Niven-Jenkins <[email-masked]>
To: Lou Berger <[email-masked]>
Cc: MEAD team <[email-masked]>, "Weingarten, Yaacov \(NSN - IL/Hod HaSharon\)" <[email-masked]>
Subject: Re: [Mpls-interop] Copy of draft-abfb-mpls-tp-control-plane-framework-00.doc

Lou,

I agree on where the definition shouldn't be :-)

I'm also not that bothered which term we use just want to make sure we don't
already have a suitable term.

Ben

On 23/02/2009 22:20, "Lou Berger" <[email-masked]> wrote:

> The point I was agreeing to is that the CP document isn't the right
> place to be defining the *data plane* constructs used to support
> protection.  In "classic" IETF speak, a hierarchical LSP is used.
> Nurit's assertion is that PST is the MPLS-TP term for the construct.
> (Please feel free to argue with her ;-) I really don't care which term
> we use, but the control plane document shouldn't be the place the
> defines the architectural construct...
> 
> Lou
> 
> On 2/23/2009 5:08 PM, Ben Niven-Jenkins wrote:
>> Whoa there cowboys, what's a PST? How does it relate to a
>> segment/concatenated segment? Is it just a "proposed IETF term" for Tandem
>> Connection?
>> 
>> Thanks
>> Ben
>> 
>> 
>> 
>> On 23/02/2009 20:50, "Lou Berger"<[email-masked]>  wrote:
>> 
>>> Nurit,
>>> 
>>> I agree that defining PST in only place is optimal.
>>> 
>>> WRT your in-document comments.  If you'd like to discuss any of the
>>> comments on the list, could you extract them from the document and send
>>> the question/comment to the list?
>>> 
>>> Much thanks,
>>> Lou
>>> 
>>> On 2/23/2009 4:13 AM, Sprecher, Nurit (NSN - IL/Hod HaSharon) wrote:
>>>> Hi,
>>>> Thanks for the document.
>>>> Please some comments in the attached.
>>>> In addition, I think H-LSP is the implementation we are using for PST
>>>> (Path Segment Tunnel) which is used to monitor and manage segments of
>>>> transport paths (e.g. for purposes like OAM, PSC, etc.). This is the
>>>> existing construct to do it. Still, I propose to define the PST
>>>> architectural element in one of the documents........the most
>>>> appropriate place would be the MPLS-TP framework document.
>>>> BEst regards,
>>>> NUrit
>>> _______________________________________________
>>> Mpls-interop mailing list
>>> [email-masked]
>>> https://www.ietf.org/mailman/listinfo/mpls-interop
>> 
>> 
>> 
>> 

Date: Tue, 24 Feb 2009 00:09:47 +0000
From: Ben Niven-Jenkins <[email-masked]>
To: BOCCI Matthew <[email-masked]>, BUSI ITALO <[email-masked]>
Cc: MEAD team <[email-masked]>
Subject: Re: [Mpls-interop] Updated version of GACH-GAL draft

On 20/02/2009 11:52, "BOCCI Matthew" <[email-masked]>
wrote:
>    o  The TTL field of the GAL MUST be set to at least 1.  The exact
>       value of the TTL is application specific.
>  
>    o  The S bit of the GAL MUST be set according to its position in the
>       label stack.  For MPLS Sections, the S bit MUST be set to 1.
>  
> <<Comment>>
>  
> While a fully agree that for MPLS-TP Sections the S bit MUST be set to
> 1, I am not 100% sure that this is true also for MPLS Sections.
>  
> <<End Comment>>
>  
> MB> If an MPLS section turns out to be another MPLS LSP on which a hash
> label or something is used, then I guess you are right. Maybe we should
> make the same statement as for LSPs. However, this is significant
> enought that we should proably raise this during the second LC.

Text in 4.2.1.2 above contradicts text in section 4.2 which states

"In MPLS-TP, the GAL MUST always be at the bottom of the label stack (i.e.
S bit set to 1).  However, in other MPLS environments, this document places
no restrictions on where the GAL may appear within the label stack."

So I guess above is just a typo and just need to s/MPLS/MPLS-TP/

Ben

Date: Tue, 24 Feb 2009 00:36:32 +0000
From: Ben Niven-Jenkins <[email-masked]>
To: BOCCI Matthew <[email-masked]>, MEAD team <[email-masked]>
Subject: Re: [Mpls-interop] Updated version of GACH-GAL draft

Matthew,

Some comments a bit late.

1) Section 1

s/Label Switching Router (LSRs)/Label Switching Routers (LSRs)/

You state:

   This document defines a mechanism
   that is RECOMMENDED for identifying and encapsulating MPLS OAM and
   other maintenance messages when IP based mechanisms such as those in
   [4] and [3] are not available.  This mechanism MAY be used in
   addition to IP-based mechanisms.

   The GAL mechanism is defined to work together with the ACH for LSPs
   and MPLS Sections.

You just seem to jump straight in with GAL without introducing it as a term,
maybe reword an earlier sentence in section 1 from

   Therefore, this document also
   defines a label based exception mechanism that serves to inform an
   LSR (or LER) that a packet it receives on an LSP or Section belongs
   to an associated control channel for that LSP or Section.

To:

   Therefore, this document also
   defines a label based exception mechanism (the Generic Associated Channel
Label (GAL)) that serves to inform an
   LSR (or LER) that a packet it receives on an LSP or Section belongs
   to an associated control channel for that LSP or Section.

2) Section 4.2.1.1 after Figure 5

You state:

   In this example, a G-ACh exists on an LSP that extends between LERs A
   and D, via LSRs B and C. Only these nodes may insert, extract or
   process packets on the G-ACh.

It is not clear to me which nodes the last sentence refers to - is it only A
& D that may insert/extract/process packets on the G-Ach? Or is it B & C you
refer to. Maybe worth explicitly stating which nodes it is similar to what
you do after Figure 7.

3) Section 4.2.1.1 after Figure 6

You state:

   To send a maintenance message on the LSP associated control channel,
   the LER (A) generates a maintenance message, to which it MAY
   prepended an ACH TLV header and appropriate ACH TLVs, and with a ACH
   to which it pushes a GAL and finally the LSP label.

s/prepended/prepend/

"and with a ACH" confuses me, is this superfluous and just "it MAY prepend
an ACH TLV header and appropriate ACH TLVs, to which it pushes a GAL and
finally the LSP label." be sufficient?

4) Section 4.1.1.2 after Figure 8

Same comment as 3) above.

5) Section 7

s/descrbed/described/

Ben

On 18/02/2009 13:58, "BOCCI Matthew" <[email-masked]>
wrote:

> Please find attached an updated version of
> draft-ietf-mpls-tp-gach-gal-02.txt, updated as per the discussion on the
> MEAD team call yesterday.
> 
> Please can you let me know if you have any comments by the end of this
> week. I would like to upload the new version to the IETF by Monday so
> that Loa can initiate a second last call on this draft.
> 
> Best regards
> 
> Matthew
>  <<draft-ietf-mpls-tp-gach-gal-02.txt>>
> _______________________________________________
> Mpls-interop mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/mpls-interop

Content-class: urn:content-classes:message
Date: Tue, 24 Feb 2009 08:53:59 +0100
From: "Sprecher, Nurit (NSN - IL/Hod HaSharon)" <[email-masked]>
To: "ext Lou Berger" <[email-masked]>, "Ben Niven-Jenkins" <[email-masked]>
Cc: MEAD team <[email-masked]>, "Weingarten, Yaacov \(NSN - IL/Hod HaSharon\)" <[email-masked]>
Subject: Re: [Mpls-interop] Copy of draft-abfb-mpls-tp-control-plane-framework-00.doc

TC is interpreted as 1:1 mapping between the LSP and the segment. In
Geneva we proposed to use the term PST (which is 1:n mapping) and I
think we got the agreement on the mailing list. TC would be a specific
case of the PST. 

-----Original Message-----
From: ext Lou Berger [mailto:[email-masked]] 
Sent: Tuesday, February 24, 2009 00:21
To: Ben Niven-Jenkins
Cc: Sprecher, Nurit (NSN - IL/Hod HaSharon); Weingarten, Yaacov (NSN -
IL/Hod HaSharon); MEAD team
Subject: Re: [Mpls-interop] Copy of
draft-abfb-mpls-tp-control-plane-framework-00.doc

The point I was agreeing to is that the CP document isn't the right 
place to be defining the *data plane* constructs used to support 
protection.  In "classic" IETF speak, a hierarchical LSP is used. 
Nurit's assertion is that PST is the MPLS-TP term for the construct. 
(Please feel free to argue with her ;-) I really don't care which term 
we use, but the control plane document shouldn't be the place the 
defines the architectural construct...

Lou

On 2/23/2009 5:08 PM, Ben Niven-Jenkins wrote:
> Whoa there cowboys, what's a PST? How does it relate to a
> segment/concatenated segment? Is it just a "proposed IETF term" for
Tandem
> Connection?
>
> Thanks
> Ben
>
>
>
> On 23/02/2009 20:50, "Lou Berger"<[email-masked]>  wrote:
>
>> Nurit,
>>
>> I agree that defining PST in only place is optimal.
>>
>> WRT your in-document comments.  If you'd like to discuss any of the
>> comments on the list, could you extract them from the document and
send
>> the question/comment to the list?
>>
>> Much thanks,
>> Lou
>>
>> On 2/23/2009 4:13 AM, Sprecher, Nurit (NSN - IL/Hod HaSharon) wrote:
>>> Hi,
>>> Thanks for the document.
>>> Please some comments in the attached.
>>> In addition, I think H-LSP is the implementation we are using for
PST
>>> (Path Segment Tunnel) which is used to monitor and manage segments
of
>>> transport paths (e.g. for purposes like OAM, PSC, etc.). This is the
>>> existing construct to do it. Still, I propose to define the PST
>>> architectural element in one of the documents........the most
>>> appropriate place would be the MPLS-TP framework document.
>>> BEst regards,
>>> NUrit
>> _______________________________________________
>> Mpls-interop mailing list
>> [email-masked]
>> https://www.ietf.org/mailman/listinfo/mpls-interop
>
>
>
>

Date: Tue, 24 Feb 2009 10:42:20 +0100
From: Loa Andersson <[email-masked]>
To: "Sprecher, Nurit (NSN - IL/Hod HaSharon)" <[email-masked]>
Cc: "Weingarten, Yaacov \(NSN - IL/Hod HaSharon\)" <[email-masked]>, MEAD team <[email-masked]>
Subject: Re: [Mpls-interop] Copy of	draft-abfb-mpls-tp-control-plane-framework-00.doc

Nurit,

the term PST was proposed by Adrian in the discussion around the
MEAD team participants of the SG15 meeting in Geneva, I don't
think we ever actually agreed on the term, not on the mpls-tp list
or in the MEAD team.

Proposed action: Write down the definition, agree in the MEAD team
that it is useful and should be used, find the proper place to put
the definition, discuss on the mpls-tp list as tht document gets
progressed.

Any one who can commit to the action?

/Loa

Sprecher, Nurit (NSN - IL/Hod HaSharon) wrote:
> TC is interpreted as 1:1 mapping between the LSP and the segment. In
> Geneva we proposed to use the term PST (which is 1:n mapping) and I
> think we got the agreement on the mailing list. TC would be a specific
> case of the PST. 
> 
> -----Original Message-----
> From: ext Lou Berger [mailto:[email-masked]] 
> Sent: Tuesday, February 24, 2009 00:21
> To: Ben Niven-Jenkins
> Cc: Sprecher, Nurit (NSN - IL/Hod HaSharon); Weingarten, Yaacov (NSN -
> IL/Hod HaSharon); MEAD team
> Subject: Re: [Mpls-interop] Copy of
> draft-abfb-mpls-tp-control-plane-framework-00.doc
> 
> The point I was agreeing to is that the CP document isn't the right 
> place to be defining the *data plane* constructs used to support 
> protection.  In "classic" IETF speak, a hierarchical LSP is used. 
> Nurit's assertion is that PST is the MPLS-TP term for the construct. 
> (Please feel free to argue with her ;-) I really don't care which term 
> we use, but the control plane document shouldn't be the place the 
> defines the architectural construct...
> 
> Lou
> 
> On 2/23/2009 5:08 PM, Ben Niven-Jenkins wrote:
>> Whoa there cowboys, what's a PST? How does it relate to a
>> segment/concatenated segment? Is it just a "proposed IETF term" for
> Tandem
>> Connection?
>>
>> Thanks
>> Ben
>>
>>
>>
>> On 23/02/2009 20:50, "Lou Berger"<[email-masked]>  wrote:
>>
>>> Nurit,
>>>
>>> I agree that defining PST in only place is optimal.
>>>
>>> WRT your in-document comments.  If you'd like to discuss any of the
>>> comments on the list, could you extract them from the document and
> send
>>> the question/comment to the list?
>>>
>>> Much thanks,
>>> Lou
>>>
>>> On 2/23/2009 4:13 AM, Sprecher, Nurit (NSN - IL/Hod HaSharon) wrote:
>>>> Hi,
>>>> Thanks for the document.
>>>> Please some comments in the attached.
>>>> In addition, I think H-LSP is the implementation we are using for
> PST
>>>> (Path Segment Tunnel) which is used to monitor and manage segments
> of
>>>> transport paths (e.g. for purposes like OAM, PSC, etc.). This is the
>>>> existing construct to do it. Still, I propose to define the PST
>>>> architectural element in one of the documents........the most
>>>> appropriate place would be the MPLS-TP framework document.
>>>> BEst regards,
>>>> NUrit
>>> _______________________________________________
>>> Mpls-interop mailing list
>>> [email-masked]
>>> https://www.ietf.org/mailman/listinfo/mpls-interop
>>
>>
>>
> _______________________________________________
> Mpls-interop mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/mpls-interop

-- 

Loa Andersson

Sr Strategy and Standards Manager
Ericsson ///                          phone:  +46 8 632 77 14

                                       email:  [email-masked]
                                               [email-masked]
                                               [email-masked]

Content-class: urn:content-classes:message
Date: Tue, 24 Feb 2009 11:38:26 +0100
From: "Sprecher, Nurit (NSN - IL/Hod HaSharon)" <[email-masked]>
To: "ext Loa Andersson" <[email-masked]>
Cc: "Weingarten, Yaacov \(NSN - IL/Hod HaSharon\)" <[email-masked]>, MEAD team <[email-masked]>
Subject: Re: [Mpls-interop] Copy of	draft-abfb-mpls-tp-control-plane-framework-00.doc

If it is ok with Martin, I'll be glad to work with him on this. 

-----Original Message-----
From: ext Loa Andersson [mailto:[email-masked]] 
Sent: Tuesday, February 24, 2009 11:42
To: Sprecher, Nurit (NSN - IL/Hod HaSharon)
Cc: ext Lou Berger; Ben Niven-Jenkins; MEAD team; Weingarten, Yaacov
(NSN - IL/Hod HaSharon)
Subject: Re: [Mpls-interop] Copy of
draft-abfb-mpls-tp-control-plane-framework-00.doc

Nurit,

the term PST was proposed by Adrian in the discussion around the MEAD
team participants of the SG15 meeting in Geneva, I don't think we ever
actually agreed on the term, not on the mpls-tp list or in the MEAD
team.

Proposed action: Write down the definition, agree in the MEAD team that
it is useful and should be used, find the proper place to put the
definition, discuss on the mpls-tp list as tht document gets progressed.

Any one who can commit to the action?

/Loa

Sprecher, Nurit (NSN - IL/Hod HaSharon) wrote:
> TC is interpreted as 1:1 mapping between the LSP and the segment. In 
> Geneva we proposed to use the term PST (which is 1:n mapping) and I 
> think we got the agreement on the mailing list. TC would be a specific

> case of the PST.
> 
> -----Original Message-----
> From: ext Lou Berger [mailto:[email-masked]]
> Sent: Tuesday, February 24, 2009 00:21
> To: Ben Niven-Jenkins
> Cc: Sprecher, Nurit (NSN - IL/Hod HaSharon); Weingarten, Yaacov (NSN -

> IL/Hod HaSharon); MEAD team
> Subject: Re: [Mpls-interop] Copy of
> draft-abfb-mpls-tp-control-plane-framework-00.doc
> 
> The point I was agreeing to is that the CP document isn't the right 
> place to be defining the *data plane* constructs used to support 
> protection.  In "classic" IETF speak, a hierarchical LSP is used.
> Nurit's assertion is that PST is the MPLS-TP term for the construct. 
> (Please feel free to argue with her ;-) I really don't care which term

> we use, but the control plane document shouldn't be the place the 
> defines the architectural construct...
> 
> Lou
> 
> On 2/23/2009 5:08 PM, Ben Niven-Jenkins wrote:
>> Whoa there cowboys, what's a PST? How does it relate to a 
>> segment/concatenated segment? Is it just a "proposed IETF term" for
> Tandem
>> Connection?
>>
>> Thanks
>> Ben
>>
>>
>>
>> On 23/02/2009 20:50, "Lou Berger"<[email-masked]>  wrote:
>>
>>> Nurit,
>>>
>>> I agree that defining PST in only place is optimal.
>>>
>>> WRT your in-document comments.  If you'd like to discuss any of the 
>>> comments on the list, could you extract them from the document and
> send
>>> the question/comment to the list?
>>>
>>> Much thanks,
>>> Lou
>>>
>>> On 2/23/2009 4:13 AM, Sprecher, Nurit (NSN - IL/Hod HaSharon) wrote:
>>>> Hi,
>>>> Thanks for the document.
>>>> Please some comments in the attached.
>>>> In addition, I think H-LSP is the implementation we are using for
> PST
>>>> (Path Segment Tunnel) which is used to monitor and manage segments
> of
>>>> transport paths (e.g. for purposes like OAM, PSC, etc.). This is 
>>>> the existing construct to do it. Still, I propose to define the PST

>>>> architectural element in one of the documents........the most 
>>>> appropriate place would be the MPLS-TP framework document.
>>>> BEst regards,
>>>> NUrit
>>> _______________________________________________
>>> Mpls-interop mailing list
>>> [email-masked]
>>> https://www.ietf.org/mailman/listinfo/mpls-interop
>>
>>
>>
> _______________________________________________
> Mpls-interop mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/mpls-interop

-- 

Loa Andersson

Sr Strategy and Standards Manager
Ericsson ///                          phone:  +46 8 632 77 14

                                       email:
[email-masked]
                                               [email-masked]
                                               [email-masked]

Content-class: urn:content-classes:message
Date: Tue, 24 Feb 2009 16:32:49 +0100
From: "Annamaria Fulignoli" <[email-masked]>
To: "Ben Niven-Jenkins" <[email-masked]>, <[email-masked]>
Subject: Re: [Mpls-interop] MPLS-TP 1+1 bidirectional protection requirement on " draft-ietf-mpls-tp-requirements-04"

Hi Ben,
thank you for your answer.

About requirement 54, following the operators requirements as you've
described , I agree with the changes you've proposed.

About requirement 55 I think that:
-  for p2p only the bidirectional protection switching MUST be
supported.
-  for p2p I do not see needs for unidirectional protection as yet
reported in C ( my interpretation is that it is not supported in
MPLS-TP)
-  I can understand that for p2mp the 1:n (unidirectional) protection is
required; however please note that it needs a return path from leaf to
root to signal the failure; 

Maybe we could change the requirement 55 with the following:

MPLS-TP MUST support 1:n protection (including 1:1 protection)
 A) Bidirectional  1:n protection for P2P connectivity MUST be
supported.
 B) Unidirectional 1:n protection for P2MP connectivity MAY be
supported.
 C) Unidirectional 1:n protection for P2P connectivity is not required. 

BR
Annamaria

-----Original Message-----
From: Ben Niven-Jenkins [mailto:[email-masked]] 
Sent: domenica 22 febbraio 2009 18.42
To: Annamaria Fulignoli; [email-masked]
Subject: Re: [Mpls-interop] MPLS-TP 1+1 bidirectional protection
requirement on " draft-ietf-mpls-tp-requirements-04"

Annamaria,

Following discussion with other operators we decided that a requirement
exists for Both uni & bi directional 1+1 for P2P Uni directional 1+1 for
P2MP But that the requirement draft should not state a default
behaviour.

I have therefore changed requirement 54 to read as follows "
MPLS-TP MUST support 1+1 protection.
 A Bidirectional 1+1 protection for P2P connectivity MUST be supported.
 B Unidirectional 1+1 protection for P2P connectivity MUST be supported.
 C Unidirectional 1+1 protection for P2MP connectivity MUST be
supported.
"

It does raise in my mind a similar question for requirement 55 on 1:n
protection. Should we do the same and not state a default behaviour?

Thans
Ben

On 16/02/2009 12:33, "Annamaria Fulignoli"
<[email-masked]> wrote:

> Hi all,
> I'm sorry but I disagree with the Req. 54 of the ID :
> "draft-ietf-mpls-tp-requirements-04".
> 
> Unidirectional and bidirectional 1+1 protection are the same with 
> regards to the requirement for simultaneous sending of traffic on both

> LSPs and hence 100% traffic duplication.
> However 1+1 unidirectional protection is a simpler scheme which 
> doesn't require a protocol for end-node coordination.
> 
> So I ask again that the default for the 1+1 protection is the 
> unidirectional one while the 1+1 bidirectional is optional ( or even 
> not required ).
> 
> Thank you. 
> Best Regards,
> Annamaria
> 
> 
> _______________________________________________
> Mpls-interop mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/mpls-interop

Date: Tue, 24 Feb 2009 16:47:33 +0100
From: Loa Andersson <[email-masked]>
To: Yoichi Maeda <[email-masked]>, Greg Jones <[email-masked]>, Ghani Abbas <[email-masked]>,  Huub Van Helvoort <[email-masked]>, Malcolm Betts <[email-masked]>,  Hing-Kam Lam <[email-masked]>, [email-masked], [email-masked], David Ward <[email-masked]>,  Ross Callon <[email-masked]>, Mark Townsley <[email-masked]>, Jari Arkko <[email-masked]>,  Scott Bradner <[email-masked]>, IETF MEAD team <[email-masked]>
Subject: [Mpls-interop] Liaison on working group last call on draft-ietf-mpls-tp-gach-gal-02

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

Dear All,

please find a liaison on the 2nd wg last call for:

http://tools.ietf.org/html/draft-ietf-mpls-tp-gach-gal-02

/Loa
-- 

Loa Andersson

Sr Strategy and Standards Manager
Ericsson ///                          phone:  +46 8 632 77 14

                                       email:  [email-masked]
                                               [email-masked]
                                               [email-masked]

--------------020109040800050906050305
Content-Type: application/msword;
 name="Liaison-LC-GACH-2.doc"
Content-Transfer-Encoding: base64
Content-Disposition: inline;
 filename="Liaison-LC-GACH-2.doc"

0M8R4KGxGuEAAAAAAAAAAAAAAAAAAAAAPgADAP7/CQAGAAAAAAAAAAAAAAABAAAAOQAAAAAA
AAAAEAAAPAAAAAEAAAD+////AAAAADgAAAD/////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA--------------020109040800050906050305--

Date: Thu, 26 Feb 2009 01:18:33 +0000
From: Ben Niven-Jenkins <[email-masked]>
To: Annamaria Fulignoli <[email-masked]>, <[email-masked]>
Subject: Re: [Mpls-interop] MPLS-TP 1+1 bidirectional protection requirement on " draft-ietf-mpls-tp-requirements-04"

Annamaria,

Thanks, please see below.

On 24/02/2009 15:32, "Annamaria Fulignoli"
<[email-masked]> wrote:

> Hi Ben,
> thank you for your answer.
> 
> About requirement 54, following the operators requirements as you've
> described , I agree with the changes you've proposed.
> 
> About requirement 55 I think that:
> -  for p2p only the bidirectional protection switching MUST be
> supported.
> -  for p2p I do not see needs for unidirectional protection as yet
> reported in C ( my interpretation is that it is not supported in
> MPLS-TP)
> -  I can understand that for p2mp the 1:n (unidirectional) protection is
> required; however please note that it needs a return path from leaf to
> root to signal the failure;
> 
> Maybe we could change the requirement 55 with the following:
> 
> MPLS-TP MUST support 1:n protection (including 1:1 protection)
>  A) Bidirectional  1:n protection for P2P connectivity MUST be
> supported.
>  B) Unidirectional 1:n protection for P2MP connectivity MAY be
> supported.

If 1:n for P2MP is required (your earlier statement) then why do you suggest
a MAY and not a MUST? Remember the MPLS-TP requirements draft does not place
requirements of what specific implementations may choose to support as
emphasised in the following paragraph of the Introduction

   The requirements are for the the behavior of the protocol
   mechanisms and procedures that constitute building blocks out of
   which the MPLS transport profile is constructed.  That is, the
   requirements indicate what features are to be available in the MPLS
   toolkit for use by MPLS-TP.  The requirements in this document do not
   describe what functions an MPLS-TP implementation supports.  The
   purpose of this document is to identify the toolkit and any new
   protocol work that is required.

As such I think the toolkit MUST support 1:n for P2MP but individual
implementations are free to choose whether or not they will support it.

Therefore I would conclude that requirement 55 is OK as it is currently
recorded in -04.

Ben