Subject: Re: [Status] Updated charter - version 3 and maybe 4
From: Loa Andersson <[email-masked]>
To: [email-masked], [email-masked]
Cc: "[email-masked]" <[email-masked]>
Date: Tue, 01 Oct 2013 09:45:16 +0800
List-Id: "Stacked Tunnels for Source Routing \(STATUS\)." <status.ietf.org>

Adrian and Stewart,

what is the value of "conjuntion"? If one group develops a spec
and sends it to the owner of the technology for wglc is that
"in conjunction"?

/Loa

On 2013-10-01 03:24, Adrian Farrel wrote:
> And Stewart wanted to say...
>
> http://datatracker.ietf.org/wg/spring/charter/
>
> *From:[email-masked] [mailto:[email-masked]] *On
> Behalf Of *Stewart Bryant
> *Sent:* 30 September 2013 16:52
> *To:* [email-masked]
> *Subject:* [Status] Updated charter - version 3 and maybe 4
>
> Adrian and I took a close look the SPRING charter
>
> and have edited it to get text that we think is more
>
> likely to get through the review cycles.
>
>
>
> The intent of the changes is not change the work
>
> programme, the deliverables or the networks. The
>
> purpose of the changes is to generate what we think
>
> is a viable charter that matches the intent of
>
> this list.
>
>
>
> First we added a summary of what spring is and
>
> why it is needed - that is covered by the first
>
> paragraph, the list of *example* and the following
>
> paragraph.
>
>
>
> We then note that we need bot strict and loose
>
> path specification.
>
>
>
> We then discuss the trust model
>
>
>
> We then say we start with single AS but must be
>
> able to multi-AS
>
>
>
> We call out centralized and distributed path comp.
>
>
>
> We then call out SPRING as an OAM and the need
>
> to manage SPRING.
>
>
>
> Then for data plane, control plane and management
>
> we say, try to use existing, but if that does
>
> not work we specify the process for change.
>
> Note that we talk about data planes in the plural.
>
>
>
> We then provide the deliverable as an edited
>
> version of the delivery plan.
>
>
>
> We do not explicitly call out either MPLS or
>
> IPv6 (or any other data plane), because,
>
>
>
> 1) That emerges from the use cases.
>
> 2) The charter says use the dataplanes (note the
>
> plural) and protocols that are derived from
>
> the use cases.
>
>
>
> The charter therefore set a strong expectation
>
> that whatever dataplanes need to to be used
>
> to satisfy the network need is in scope.
>
>
>
> Comments please
>
>
>
> Stewart
>
>
>
> PS you may see -04 with some cosmetic/layout changes.
>
>
>
>
>
>
>
>
>
> _______________________________________________
> status mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/status
>

-- 

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

From: "Adrian Farrel" <[email-masked]>
To: <[email-masked]>, <[email-masked]>
Date: Mon, 30 Sep 2013 20:24:44 +0100
Subject: Re: [Status] Updated charter - version 3 and maybe 4
Reply-To: [email-masked]

This is a multipart message in MIME format.

------=_NextPart_000_07C5_01CEBE1B.1A22DD50
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit

And Stewart wanted to say...
 
http://datatracker.ietf.org/wg/spring/charter/
 
From: [email-masked] [mailto:[email-masked]] On Behalf Of
Stewart Bryant
Sent: 30 September 2013 16:52
To: [email-masked]
Subject: [Status] Updated charter - version 3 and maybe 4
 
Adrian and I took a close look the SPRING charter
and have edited it to get text that we think is more
likely to get through the review cycles.
 
The intent of the changes is not change the work 
programme, the deliverables or the networks. The
purpose of the changes is to generate what we think
is a viable charter that matches the intent of
this list.
 
First we added a summary of what spring is and 
why it is needed - that is covered by the first
paragraph, the list of *example* and the following
paragraph.
 
We then note that we need bot strict and loose
path specification.
 
We then discuss the trust model
 
We then say we start with single AS but must be
able to multi-AS
 
We call out centralized and distributed path comp.
 
We then call out SPRING as an OAM and the need
to manage SPRING.
 
Then for data plane, control plane and management
we say, try to use existing, but if that does
not work we specify the process for change.
Note that we talk about data planes in the plural.
 
We then provide the deliverable as an edited
version of the delivery plan.
 
We do not explicitly call out either MPLS or
IPv6 (or any other data plane), because, 
 
1) That emerges from the use cases.
2) The charter says use the dataplanes (note the 
plural) and protocols that are derived from
the use cases.
 
The charter therefore set a strong expectation
that whatever dataplanes need to to be used 
to satisfy the network need is in scope.
 
Comments please 
 
Stewart
 
PS you may see -04 with some cosmetic/layout changes.

 

------=_NextPart_000_07C5_01CEBE1B.1A22DD50
Content-Type: text/html;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

<html xmlns:v=3D"urn:schemas-microsoft-com:vml" =
xmlns:o=3D"urn:schemas-microsoft-com:office:office" =
xmlns:w=3D"urn:schemas-microsoft-com:office:word" =
xmlns:m=3D"http://schemas.microsoft.com/office/2004/12/omml" =
xmlns=3D"http://www.w3.org/TR/REC-html40"><head><meta =
http-equiv=3DContent-Type content=3D"text/html; =
charset=3Dus-ascii"><meta name=3DProgId content=3DWord.Document><meta =
name=3DGenerator content=3D"Microsoft Word 14"><meta name=3DOriginator =
content=3D"Microsoft Word 14"><link rel=3DFile-List =
href=3D"cid:[email-masked]"><!--[if gte mso 9]><xml>
<o:OfficeDocumentSettings>
<o:AllowPNG/>
</o:OfficeDocumentSettings>
</xml><![endif]--><!--[if gte mso 9]><xml>
<w:WordDocument>
<w:SpellingState>Clean</w:SpellingState>
<w:TrackMoves/>
<w:TrackFormatting/>
<w:EnvelopeVis/>
<w:ValidateAgainstSchemas/>
<w:SaveIfXMLInvalid>false</w:SaveIfXMLInvalid>
<w:IgnoreMixedContent>false</w:IgnoreMixedContent>
<w:AlwaysShowPlaceholderText>false</w:AlwaysShowPlaceholderText>
<w:DoNotPromoteQF/>
<w:LidThemeOther>EN-GB</w:LidThemeOther>
<w:LidThemeAsian>X-NONE</w:LidThemeAsian>
<w:LidThemeComplexScript>X-NONE</w:LidThemeComplexScript>
<w:Compatibility>
<w:DoNotExpandShiftReturn/>
<w:BreakWrappedTables/>
<w:SplitPgBreakAndParaMark/>
<w:EnableOpenTypeKerning/>
</w:Compatibility>
<m:mathPr>
<m:mathFont m:val=3D"Cambria Math"/>
<m:brkBin m:val=3D"before"/>
<m:brkBinSub m:val=3D"&#45;-"/>
<m:smallFrac m:val=3D"off"/>
<m:dispDef/>
<m:lMargin m:val=3D"0"/>
<m:rMargin m:val=3D"0"/>
<m:defJc m:val=3D"centerGroup"/>
<m:wrapIndent m:val=3D"1440"/>
<m:intLim m:val=3D"subSup"/>
<m:naryLim m:val=3D"undOvr"/>
</m:mathPr></w:WordDocument>
</xml><![endif]--><!--[if gte mso 9]><xml>
<w:LatentStyles DefLockedState=3D"false" DefUnhideWhenUsed=3D"true" =
DefSemiHidden=3D"true" DefQFormat=3D"false" DefPriority=3D"99" =
LatentStyleCount=3D"267">
<w:LsdException Locked=3D"false" Priority=3D"0" SemiHidden=3D"false" =
UnhideWhenUsed=3D"false" QFormat=3D"true" Name=3D"Normal"/>
<w:LsdException Locked=3D"false" Priority=3D"9" SemiHidden=3D"false" =
UnhideWhenUsed=3D"false" QFormat=3D"true" Name=3D"heading 1"/>
<w:LsdException Locked=3D"false" Priority=3D"9" QFormat=3D"true" =
Name=3D"heading 2"/>
<w:LsdException Locked=3D"false" Priority=3D"9" QFormat=3D"true" =
Name=3D"heading 3"/>
<w:LsdException Locked=3D"false" Priority=3D"9" QFormat=3D"true" =
Name=3D"heading 4"/>
<w:LsdException Locked=3D"false" Priority=3D"9" QFormat=3D"true" =
Name=3D"heading 5"/>
<w:LsdException Locked=3D"false" Priority=3D"9" QFormat=3D"true" =
Name=3D"heading 6"/>
<w:LsdException Locked=3D"false" Priority=3D"9" QFormat=3D"true" =
Name=3D"heading 7"/>
<w:LsdException Locked=3D"false" Priority=3D"9" QFormat=3D"true" =
Name=3D"heading 8"/>
<w:LsdException Locked=3D"false" Priority=3D"9" QFormat=3D"true" =
Name=3D"heading 9"/>
<w:LsdException Locked=3D"false" Priority=3D"39" Name=3D"toc 1"/>
<w:LsdException Locked=3D"false" Priority=3D"39" Name=3D"toc 2"/>
<w:LsdException Locked=3D"false" Priority=3D"39" Name=3D"toc 3"/>
<w:LsdException Locked=3D"false" Priority=3D"39" Name=3D"toc 4"/>
<w:LsdException Locked=3D"false" Priority=3D"39" Name=3D"toc 5"/>
<w:LsdException Locked=3D"false" Priority=3D"39" Name=3D"toc 6"/>
<w:LsdException Locked=3D"false" Priority=3D"39" Name=3D"toc 7"/>
<w:LsdException Locked=3D"false" Priority=3D"39" Name=3D"toc 8"/>
<w:LsdException Locked=3D"false" Priority=3D"39" Name=3D"toc 9"/>
<w:LsdException Locked=3D"false" Priority=3D"35" QFormat=3D"true" =
Name=3D"caption"/>
<w:LsdException Locked=3D"false" Priority=3D"10" SemiHidden=3D"false" =
UnhideWhenUsed=3D"false" QFormat=3D"true" Name=3D"Title"/>
<w:LsdException Locked=3D"false" Priority=3D"1" Name=3D"Default =
Paragraph Font"/>
<w:LsdException Locked=3D"false" Priority=3D"11" SemiHidden=3D"false" =
UnhideWhenUsed=3D"false" QFormat=3D"true" Name=3D"Subtitle"/>
<w:LsdException Locked=3D"false" Priority=3D"22" SemiHidden=3D"false" =
UnhideWhenUsed=3D"false" QFormat=3D"true" Name=3D"Strong"/>
<w:LsdException Locked=3D"false" Priority=3D"20" SemiHidden=3D"false" =
UnhideWhenUsed=3D"false" QFormat=3D"true" Name=3D"Emphasis"/>
<w:LsdException Locked=3D"false" Priority=3D"59" SemiHidden=3D"false" =
UnhideWhenUsed=3D"false" Name=3D"Table Grid"/>
<w:LsdException Locked=3D"false" UnhideWhenUsed=3D"false" =
Name=3D"Placeholder Text"/>
<w:LsdException Locked=3D"false" Priority=3D"1" SemiHidden=3D"false" =
UnhideWhenUsed=3D"false" QFormat=3D"true" Name=3D"No Spacing"/>
<w:LsdException Locked=3D"false" Priority=3D"60" SemiHidden=3D"false" =
UnhideWhenUsed=3D"false" Name=3D"Light Shading"/>
<w:LsdException Locked=3D"false" Priority=3D"61" SemiHidden=3D"false" =
UnhideWhenUsed=3D"false" Name=3D"Light List"/>
<w:LsdException Locked=3D"false" Priority=3D"62" SemiHidden=3D"false" =
UnhideWhenUsed=3D"false" Name=3D"Light Grid"/>
<w:LsdException Locked=3D"false" Priority=3D"63" SemiHidden=3D"false" =
UnhideWhenUsed=3D"false" Name=3D"Medium Shading 1"/>
<w:LsdException Locked=3D"false" Priority=3D"64" SemiHidden=3D"false" =
UnhideWhenUsed=3D"false" Name=3D"Medium Shading 2"/>
<w:LsdException Locked=3D"false" Priority=3D"65" SemiHidden=3D"false" =
UnhideWhenUsed=3D"false" Name=3D"Medium List 1"/>
<w:LsdException Locked=3D"false" Priority=3D"66" SemiHidden=3D"false" =
UnhideWhenUsed=3D"false" Name=3D"Medium List 2"/>
<w:LsdException Locked=3D"false" Priority=3D"67" SemiHidden=3D"false" =
UnhideWhenUsed=3D"false" Name=3D"Medium Grid 1"/>
<w:LsdException Locked=3D"false" Priority=3D"68" SemiHidden=3D"false" =
UnhideWhenUsed=3D"false" Name=3D"Medium Grid 2"/>
<w:LsdException Locked=3D"false" Priority=3D"69" SemiHidden=3D"false" =
UnhideWhenUsed=3D"false" Name=3D"Medium Grid 3"/>
<w:LsdException Locked=3D"false" Priority=3D"70" SemiHidden=3D"false" =
UnhideWhenUsed=3D"false" Name=3D"Dark List"/>
<w:LsdException Locked=3D"false" Priority=3D"71" SemiHidden=3D"false" =
UnhideWhenUsed=3D"false" Name=3D"Colorful Shading"/>
<w:LsdException Locked=3D"false" Priority=3D"72" SemiHidden=3D"false" =
UnhideWhenUsed=3D"false" Name=3D"Colorful List"/>
<w:LsdException Locked=3D"false" Priority=3D"73" SemiHidden=3D"false" =
UnhideWhenUsed=3D"false" Name=3D"Colorful Grid"/>
<w:LsdException Locked=3D"false" Priority=3D"60" SemiHidden=3D"false" =
UnhideWhenUsed=3D"false" Name=3D"Light Shading Accent 1"/>
<w:LsdException Locked=3D"false" Priority=3D"61" SemiHidden=3D"false" =
UnhideWhenUsed=3D"false" Name=3D"Light List Accent 1"/>
<w:LsdException Locked=3D"false" Priority=3D"62" SemiHidden=3D"false" =
UnhideWhenUsed=3D"false" Name=3D"Light Grid Accent 1"/>
<w:LsdException Locked=3D"false" Priority=3D"63" SemiHidden=3D"false" =
UnhideWhenUsed=3D"false" Name=3D"Medium Shading 1 Accent 1"/>
<w:LsdException Locked=3D"false" Priority=3D"64" SemiHidden=3D"false" =
UnhideWhenUsed=3D"false" Name=3D"Medium Shading 2 Accent 1"/>
<w:LsdException Locked=3D"false" Priority=3D"65" SemiHidden=3D"false" =
UnhideWhenUsed=3D"false" Name=3D"Medium List 1 Accent 1"/>
<w:LsdException Locked=3D"false" UnhideWhenUsed=3D"false" =
Name=3D"Revision"/>
<w:LsdException Locked=3D"false" Priority=3D"34" SemiHidden=3D"false" =
UnhideWhenUsed=3D"false" QFormat=3D"true" Name=3D"List Paragraph"/>
<w:LsdException Locked=3D"false" Priority=3D"29" SemiHidden=3D"false" =
UnhideWhenUsed=3D"false" QFormat=3D"true" Name=3D"Quote"/>
<w:LsdException Locked=3D"false" Priority=3D"30" SemiHidden=3D"false" =
UnhideWhenUsed=3D"false" QFormat=3D"true" Name=3D"Intense Quote"/>
<w:LsdException Locked=3D"false" Priority=3D"66" SemiHidden=3D"false" =
UnhideWhenUsed=3D"false" Name=3D"Medium List 2 Accent 1"/>
<w:LsdException Locked=3D"false" Priority=3D"67" SemiHidden=3D"false" =
UnhideWhenUsed=3D"false" Name=3D"Medium Grid 1 Accent 1"/>
<w:LsdException Locked=3D"false" Priority=3D"68" SemiHidden=3D"false" =
UnhideWhenUsed=3D"false" Name=3D"Medium Grid 2 Accent 1"/>
<w:LsdException Locked=3D"false" Priority=3D"69" SemiHidden=3D"false" =
UnhideWhenUsed=3D"false" Name=3D"Medium Grid 3 Accent 1"/>
<w:LsdException Locked=3D"false" Priority=3D"70" SemiHidden=3D"false" =
UnhideWhenUsed=3D"false" Name=3D"Dark List Accent 1"/>
<w:LsdException Locked=3D"false" Priority=3D"71" SemiHidden=3D"false" =
UnhideWhenUsed=3D"false" Name=3D"Colorful Shading Accent 1"/>
<w:LsdException Locked=3D"false" Priority=3D"72" SemiHidden=3D"false" =
UnhideWhenUsed=3D"false" Name=3D"Colorful List Accent 1"/>
<w:LsdException Locked=3D"false" Priority=3D"73" SemiHidden=3D"false" =
UnhideWhenUsed=3D"false" Name=3D"Colorful Grid Accent 1"/>
<w:LsdException Locked=3D"false" Priority=3D"60" SemiHidden=3D"false" =
UnhideWhenUsed=3D"false" Name=3D"Light Shading Accent 2"/>
<w:LsdException Locked=3D"false" Priority=3D"61" SemiHidden=3D"false" =
UnhideWhenUsed=3D"false" Name=3D"Light List Accent 2"/>
<w:LsdException Locked=3D"false" Priority=3D"62" SemiHidden=3D"false" =
UnhideWhenUsed=3D"false" Name=3D"Light Grid Accent 2"/>
<w:LsdException Locked=3D"false" Priority=3D"63" SemiHidden=3D"false" =
UnhideWhenUsed=3D"false" Name=3D"Medium Shading 1 Accent 2"/>
<w:LsdException Locked=3D"false" Priority=3D"64" SemiHidden=3D"false" =
UnhideWhenUsed=3D"false" Name=3D"Medium Shading 2 Accent 2"/>
<w:LsdException Locked=3D"false" Priority=3D"65" SemiHidden=3D"false" =
UnhideWhenUsed=3D"false" Name=3D"Medium List 1 Accent 2"/>
<w:LsdException Locked=3D"false" Priority=3D"66" SemiHidden=3D"false" =
UnhideWhenUsed=3D"false" Name=3D"Medium List 2 Accent 2"/>
<w:LsdException Locked=3D"false" Priority=3D"67" SemiHidden=3D"false" =
UnhideWhenUsed=3D"false" Name=3D"Medium Grid 1 Accent 2"/>
<w:LsdException Locked=3D"false" Priority=3D"68" SemiHidden=3D"false" =
UnhideWhenUsed=3D"false" Name=3D"Medium Grid 2 Accent 2"/>
<w:LsdException Locked=3D"false" Priority=3D"69" SemiHidden=3D"false" =
UnhideWhenUsed=3D"false" Name=3D"Medium Grid 3 Accent 2"/>
<w:LsdException Locked=3D"false" Priority=3D"70" SemiHidden=3D"false" =
UnhideWhenUsed=3D"false" Name=3D"Dark List Accent 2"/>
<w:LsdException Locked=3D"false" Priority=3D"71" SemiHidden=3D"false" =
UnhideWhenUsed=3D"false" Name=3D"Colorful Shading Accent 2"/>
<w:LsdException Locked=3D"false" Priority=3D"72" SemiHidden=3D"false" =
UnhideWhenUsed=3D"false" Name=3D"Colorful List Accent 2"/>
<w:LsdException Locked=3D"false" Priority=3D"73" SemiHidden=3D"false" =
UnhideWhenUsed=3D"false" Name=3D"Colorful Grid Accent 2"/>
<w:LsdException Locked=3D"false" Priority=3D"60" SemiHidden=3D"false" =
UnhideWhenUsed=3D"false" Name=3D"Light Shading Accent 3"/>
<w:LsdException Locked=3D"false" Priority=3D"61" SemiHidden=3D"false" =
UnhideWhenUsed=3D"false" Name=3D"Light List Accent 3"/>
<w:LsdException Locked=3D"false" Priority=3D"62" SemiHidden=3D"false" =
UnhideWhenUsed=3D"false" Name=3D"Light Grid Accent 3"/>
<w:LsdException Locked=3D"false" Priority=3D"63" SemiHidden=3D"false" =
UnhideWhenUsed=3D"false" Name=3D"Medium Shading 1 Accent 3"/>
<w:LsdException Locked=3D"false" Priority=3D"64" SemiHidden=3D"false" =
UnhideWhenUsed=3D"false" Name=3D"Medium Shading 2 Accent 3"/>
<w:LsdException Locked=3D"false" Priority=3D"65" SemiHidden=3D"false" =
UnhideWhenUsed=3D"false" Name=3D"Medium List 1 Accent 3"/>
<w:LsdException Locked=3D"false" Priority=3D"66" SemiHidden=3D"false" =
UnhideWhenUsed=3D"false" Name=3D"Medium List 2 Accent 3"/>
<w:LsdException Locked=3D"false" Priority=3D"67" SemiHidden=3D"false" =
UnhideWhenUsed=3D"false" Name=3D"Medium Grid 1 Accent 3"/>
<w:LsdException Locked=3D"false" Priority=3D"68" SemiHidden=3D"false" =
UnhideWhenUsed=3D"false" Name=3D"Medium Grid 2 Accent 3"/>
<w:LsdException Locked=3D"false" Priority=3D"69" SemiHidden=3D"false" =
UnhideWhenUsed=3D"false" Name=3D"Medium Grid 3 Accent 3"/>
<w:LsdException Locked=3D"false" Priority=3D"70" SemiHidden=3D"false" =
UnhideWhenUsed=3D"false" Name=3D"Dark List Accent 3"/>
<w:LsdException Locked=3D"false" Priority=3D"71" SemiHidden=3D"false" =
UnhideWhenUsed=3D"false" Name=3D"Colorful Shading Accent 3"/>
<w:LsdException Locked=3D"false" Priority=3D"72" SemiHidden=3D"false" =
UnhideWhenUsed=3D"false" Name=3D"Colorful List Accent 3"/>
<w:LsdException Locked=3D"false" Priority=3D"73" SemiHidden=3D"false" =
UnhideWhenUsed=3D"false" Name=3D"Colorful Grid Accent 3"/>
<w:LsdException Locked=3D"false" Priority=3D"60" SemiHidden=3D"false" =
UnhideWhenUsed=3D"false" Name=3D"Light Shading Accent 4"/>
<w:LsdException Locked=3D"false" Priority=3D"61" SemiHidden=3D"false" =
UnhideWhenUsed=3D"false" Name=3D"Light List Accent 4"/>
<w:LsdException Locked=3D"false" Priority=3D"62" SemiHidden=3D"false" =
UnhideWhenUsed=3D"false" Name=3D"Light Grid Accent 4"/>
<w:LsdException Locked=3D"false" Priority=3D"63" SemiHidden=3D"false" =
UnhideWhenUsed=3D"false" Name=3D"Medium Shading 1 Accent 4"/>
<w:LsdException Locked=3D"false" Priority=3D"64" SemiHidden=3D"false" =
UnhideWhenUsed=3D"false" Name=3D"Medium Shading 2 Accent 4"/>
<w:LsdException Locked=3D"false" Priority=3D"65" SemiHidden=3D"false" =
UnhideWhenUsed=3D"false" Name=3D"Medium List 1 Accent 4"/>
<w:LsdException Locked=3D"false" Priority=3D"66" SemiHidden=3D"false" =
UnhideWhenUsed=3D"false" Name=3D"Medium List 2 Accent 4"/>
<w:LsdException Locked=3D"false" Priority=3D"67" SemiHidden=3D"false" =
UnhideWhenUsed=3D"false" Name=3D"Medium Grid 1 Accent 4"/>
<w:LsdException Locked=3D"false" Priority=3D"68" SemiHidden=3D"false" =
UnhideWhenUsed=3D"false" Name=3D"Medium Grid 2 Accent 4"/>
<w:LsdException Locked=3D"false" Priority=3D"69" SemiHidden=3D"false" =
UnhideWhenUsed=3D"false" Name=3D"Medium Grid 3 Accent 4"/>
<w:LsdException Locked=3D"false" Priority=3D"70" SemiHidden=3D"false" =
UnhideWhenUsed=3D"false" Name=3D"Dark List Accent 4"/>
<w:LsdException Locked=3D"false" Priority=3D"71" SemiHidden=3D"false" =
UnhideWhenUsed=3D"false" Name=3D"Colorful Shading Accent 4"/>
<w:LsdException Locked=3D"false" Priority=3D"72" SemiHidden=3D"false" =
UnhideWhenUsed=3D"false" Name=3D"Colorful List Accent 4"/>
<w:LsdException Locked=3D"false" Priority=3D"73" SemiHidden=3D"false" =
UnhideWhenUsed=3D"false" Name=3D"Colorful Grid Accent 4"/>
<w:LsdException Locked=3D"false" Priority=3D"60" SemiHidden=3D"false" =
UnhideWhenUsed=3D"false" Name=3D"Light Shading Accent 5"/>
<w:LsdException Locked=3D"false" Priority=3D"61" SemiHidden=3D"false" =
UnhideWhenUsed=3D"false" Name=3D"Light List Accent 5"/>
<w:LsdException Locked=3D"false" Priority=3D"62" SemiHidden=3D"false" =
UnhideWhenUsed=3D"false" Name=3D"Light Grid Accent 5"/>
<w:LsdException Locked=3D"false" Priority=3D"63" SemiHidden=3D"false" =
UnhideWhenUsed=3D"false" Name=3D"Medium Shading 1 Accent 5"/>
<w:LsdException Locked=3D"false" Priority=3D"64" SemiHidden=3D"false" =
UnhideWhenUsed=3D"false" Name=3D"Medium Shading 2 Accent 5"/>
<w:LsdException Locked=3D"false" Priority=3D"65" SemiHidden=3D"false" =
UnhideWhenUsed=3D"false" Name=3D"Medium List 1 Accent 5"/>
<w:LsdException Locked=3D"false" Priority=3D"66" SemiHidden=3D"false" =
UnhideWhenUsed=3D"false" Name=3D"Medium List 2 Accent 5"/>
<w:LsdException Locked=3D"false" Priority=3D"67" SemiHidden=3D"false" =
UnhideWhenUsed=3D"false" Name=3D"Medium Grid 1 Accent 5"/>
<w:LsdException Locked=3D"false" Priority=3D"68" SemiHidden=3D"false" =
UnhideWhenUsed=3D"false" Name=3D"Medium Grid 2 Accent 5"/>
<w:LsdException Locked=3D"false" Priority=3D"69" SemiHidden=3D"false" =
UnhideWhenUsed=3D"false" Name=3D"Medium Grid 3 Accent 5"/>
<w:LsdException Locked=3D"false" Priority=3D"70" SemiHidden=3D"false" =
UnhideWhenUsed=3D"false" Name=3D"Dark List Accent 5"/>
<w:LsdException Locked=3D"false" Priority=3D"71" SemiHidden=3D"false" =
UnhideWhenUsed=3D"false" Name=3D"Colorful Shading Accent 5"/>
<w:LsdException Locked=3D"false" Priority=3D"72" SemiHidden=3D"false" =
UnhideWhenUsed=3D"false" Name=3D"Colorful List Accent 5"/>
<w:LsdException Locked=3D"false" Priority=3D"73" SemiHidden=3D"false" =
UnhideWhenUsed=3D"false" Name=3D"Colorful Grid Accent 5"/>
<w:LsdException Locked=3D"false" Priority=3D"60" SemiHidden=3D"false" =
UnhideWhenUsed=3D"false" Name=3D"Light Shading Accent 6"/>
<w:LsdException Locked=3D"false" Priority=3D"61" SemiHidden=3D"false" =
UnhideWhenUsed=3D"false" Name=3D"Light List Accent 6"/>
<w:LsdException Locked=3D"false" Priority=3D"62" SemiHidden=3D"false" =
UnhideWhenUsed=3D"false" Name=3D"Light Grid Accent 6"/>
<w:LsdException Locked=3D"false" Priority=3D"63" SemiHidden=3D"false" =
UnhideWhenUsed=3D"false" Name=3D"Medium Shading 1 Accent 6"/>
<w:LsdException Locked=3D"false" Priority=3D"64" SemiHidden=3D"false" =
UnhideWhenUsed=3D"false" Name=3D"Medium Shading 2 Accent 6"/>
<w:LsdException Locked=3D"false" Priority=3D"65" SemiHidden=3D"false" =
UnhideWhenUsed=3D"false" Name=3D"Medium List 1 Accent 6"/>
<w:LsdException Locked=3D"false" Priority=3D"66" SemiHidden=3D"false" =
UnhideWhenUsed=3D"false" Name=3D"Medium List 2 Accent 6"/>
<w:LsdException Locked=3D"false" Priority=3D"67" SemiHidden=3D"false" =
UnhideWhenUsed=3D"false" Name=3D"Medium Grid 1 Accent 6"/>
<w:LsdException Locked=3D"false" Priority=3D"68" SemiHidden=3D"false" =
UnhideWhenUsed=3D"false" Name=3D"Medium Grid 2 Accent 6"/>
<w:LsdException Locked=3D"false" Priority=3D"69" SemiHidden=3D"false" =
UnhideWhenUsed=3D"false" Name=3D"Medium Grid 3 Accent 6"/>
<w:LsdException Locked=3D"false" Priority=3D"70" SemiHidden=3D"false" =
UnhideWhenUsed=3D"false" Name=3D"Dark List Accent 6"/>
<w:LsdException Locked=3D"false" Priority=3D"71" SemiHidden=3D"false" =
UnhideWhenUsed=3D"false" Name=3D"Colorful Shading Accent 6"/>
<w:LsdException Locked=3D"false" Priority=3D"72" SemiHidden=3D"false" =
UnhideWhenUsed=3D"false" Name=3D"Colorful List Accent 6"/>
<w:LsdException Locked=3D"false" Priority=3D"73" SemiHidden=3D"false" =
UnhideWhenUsed=3D"false" Name=3D"Colorful Grid Accent 6"/>
<w:LsdException Locked=3D"false" Priority=3D"19" SemiHidden=3D"false" =
UnhideWhenUsed=3D"false" QFormat=3D"true" Name=3D"Subtle Emphasis"/>
<w:LsdException Locked=3D"false" Priority=3D"21" SemiHidden=3D"false" =
UnhideWhenUsed=3D"false" QFormat=3D"true" Name=3D"Intense Emphasis"/>
<w:LsdException Locked=3D"false" Priority=3D"31" SemiHidden=3D"false" =
UnhideWhenUsed=3D"false" QFormat=3D"true" Name=3D"Subtle Reference"/>
<w:LsdException Locked=3D"false" Priority=3D"32" SemiHidden=3D"false" =
UnhideWhenUsed=3D"false" QFormat=3D"true" Name=3D"Intense Reference"/>
<w:LsdException Locked=3D"false" Priority=3D"33" SemiHidden=3D"false" =
UnhideWhenUsed=3D"false" QFormat=3D"true" Name=3D"Book Title"/>
<w:LsdException Locked=3D"false" Priority=3D"37" Name=3D"Bibliography"/>
<w:LsdException Locked=3D"false" Priority=3D"39" QFormat=3D"true" =
Name=3D"TOC Heading"/>
</w:LatentStyles>
</xml><![endif]--><style><!--
/* Font Definitions */
@font-face
	{font-family:Calibri;
	panose-1:2 15 5 2 2 2 4 3 2 4;
	mso-font-charset:0;
	mso-generic-font-family:swiss;
	mso-font-pitch:variable;
	mso-font-signature:-536870145 1073786111 1 0 415 0;}
@font-face
	{font-family:Tahoma;
	panose-1:2 11 6 4 3 5 4 4 2 4;
	mso-font-charset:0;
	mso-generic-font-family:swiss;
	mso-font-pitch:variable;
	mso-font-signature:-520081665 -1073717157 41 0 66047 0;}
@font-face
	{font-family:Consolas;
	panose-1:2 11 6 9 2 2 4 3 2 4;
	mso-font-charset:0;
	mso-generic-font-family:modern;
	mso-font-pitch:fixed;
	mso-font-signature:-520092929 1073806591 9 0 415 0;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
	{mso-style-unhide:no;
	mso-style-qformat:yes;
	mso-style-parent:"";
	margin:0cm;
	margin-bottom:.0001pt;
	mso-pagination:widow-orphan;
	font-size:12.0pt;
	font-family:"Times New Roman","serif";
	mso-fareast-font-family:Calibri;
	color:black;}
a:link, span.MsoHyperlink
	{mso-style-noshow:yes;
	mso-style-priority:99;
	color:blue;
	text-decoration:underline;
	text-underline:single;}
a:visited, span.MsoHyperlinkFollowed
	{mso-style-noshow:yes;
	mso-style-priority:99;
	color:purple;
	text-decoration:underline;
	text-underline:single;}
pre
	{mso-style-noshow:yes;
	mso-style-priority:99;
	mso-style-link:"HTML Preformatted Char";
	margin:0cm;
	margin-bottom:.0001pt;
	mso-pagination:widow-orphan;
	font-size:10.0pt;
	font-family:"Courier New";
	mso-fareast-font-family:Calibri;
	color:black;}
span.HTMLPreformattedChar
	{mso-style-name:"HTML Preformatted Char";
	mso-style-noshow:yes;
	mso-style-priority:99;
	mso-style-unhide:no;
	mso-style-locked:yes;
	mso-style-link:"HTML Preformatted";
	font-family:Consolas;
	mso-ascii-font-family:Consolas;
	mso-fareast-font-family:Calibri;
	mso-hansi-font-family:Consolas;
	mso-bidi-font-family:Consolas;
	color:black;}
span.EmailStyle19
	{mso-style-type:personal-reply;
	mso-style-noshow:yes;
	mso-style-unhide:no;
	mso-ansi-font-size:11.0pt;
	mso-bidi-font-size:11.0pt;
	font-family:"Calibri","sans-serif";
	mso-ascii-font-family:Calibri;
	mso-fareast-font-family:Calibri;
	mso-hansi-font-family:Calibri;
	mso-bidi-font-family:"Times New Roman";
	color:#1F497D;}
.MsoChpDefault
	{mso-style-type:export-only;
	mso-default-props:yes;
	font-size:10.0pt;
	mso-ansi-font-size:10.0pt;
	mso-bidi-font-size:10.0pt;}
@page WordSection1
	{size:612.0pt 792.0pt;
	margin:72.0pt 72.0pt 72.0pt 72.0pt;
	mso-header-margin:36.0pt;
	mso-footer-margin:36.0pt;
	mso-paper-source:0;}
div.WordSection1
	{page:WordSection1;}
--></style><!--[if gte mso 10]><style>/* Style Definitions */
table.MsoNormalTable
	{mso-style-name:"Table Normal";
	mso-tstyle-rowband-size:0;
	mso-tstyle-colband-size:0;
	mso-style-noshow:yes;
	mso-style-priority:99;
	mso-style-parent:"";
	mso-padding-alt:0cm 5.4pt 0cm 5.4pt;
	mso-para-margin:0cm;
	mso-para-margin-bottom:.0001pt;
	mso-pagination:widow-orphan;
	font-size:10.0pt;
	font-family:"Times New Roman","serif";}
</style><![endif]--><!--[if gte mso 9]><xml>
<o:shapedefaults v:ext=3D"edit" spidmax=3D"1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
<o:shapelayout v:ext=3D"edit">
<o:idmap v:ext=3D"edit" data=3D"1" />
</o:shapelayout></xml><![endif]--></head><body bgcolor=3Dwhite =
lang=3DEN-GB link=3Dblue vlink=3Dpurple =
style=3D'tab-interval:36.0pt'><div class=3DWordSection1><p =
class=3DMsoNormal><span =
style=3D'font-size:11.0pt;font-family:"Calibri","sans-serif";mso-bidi-fon=
t-family:"Times New Roman";color:#1F497D'>And Stewart wanted to =
say...<o:p></o:p></span></p><p class=3DMsoNormal><span =
style=3D'font-size:11.0pt;font-family:"Calibri","sans-serif";mso-bidi-fon=
t-family:"Times New Roman";color:#1F497D'><o:p>&nbsp;</o:p></span></p><p =
class=3DMsoNormal><span =
style=3D'font-size:11.0pt;font-family:"Calibri","sans-serif";mso-bidi-fon=
t-family:"Times New =
Roman";color:#1F497D'>http://datatracker.ietf.org/wg/spring/charter/<o:p>=
</o:p></span></p><p class=3DMsoNormal><span =
style=3D'font-size:11.0pt;font-family:"Calibri","sans-serif";mso-bidi-fon=
t-family:"Times New =
Roman";color:#1F497D'><o:p>&nbsp;</o:p></span></p><div =
style=3D'border:none;border-left:solid blue 1.5pt;padding:0cm 0cm 0cm =
4.0pt'><div><div style=3D'border:none;border-top:solid #B5C4DF =
1.0pt;padding:3.0pt 0cm 0cm 0cm'><p class=3DMsoNormal><b><span =
lang=3DEN-US =
style=3D'font-size:10.0pt;font-family:"Tahoma","sans-serif";mso-fareast-f=
ont-family:"Times New =
Roman";color:windowtext;mso-ansi-language:EN-US'>From:</span></b><span =
lang=3DEN-US =
style=3D'font-size:10.0pt;font-family:"Tahoma","sans-serif";mso-fareast-f=
ont-family:"Times New Roman";color:windowtext;mso-ansi-language:EN-US'> =
[email-masked] [mailto:[email-masked]] <b>On Behalf Of =
</b>Stewart Bryant<br><b>Sent:</b> 30 September 2013 16:52<br><b>To:</b> =
[email-masked]<br><b>Subject:</b> [Status] Updated charter - version 3 =
and maybe 4<o:p></o:p></span></p></div></div><p =
class=3DMsoNormal><o:p>&nbsp;</o:p></p><pre>Adrian and I took a close =
look the SPRING charter<o:p></o:p></pre><pre>and have edited it to get =
text that we think is more<o:p></o:p></pre><pre>likely to get through =
the review cycles.<o:p></o:p></pre><pre><o:p>&nbsp;</o:p></pre><pre>The =
intent of the changes is not change the work =
<o:p></o:p></pre><pre>programme, the deliverables or the networks. =
The<o:p></o:p></pre><pre>purpose of the changes is to generate what we =
think<o:p></o:p></pre><pre>is a viable charter that matches the intent =
of<o:p></o:p></pre><pre>this =
list.<o:p></o:p></pre><pre><o:p>&nbsp;</o:p></pre><pre>First we added a =
summary of what spring is and <o:p></o:p></pre><pre>why it is needed - =
that is covered by the first<o:p></o:p></pre><pre>paragraph, the list of =
*example* and the =
following<o:p></o:p></pre><pre>paragraph.<o:p></o:p></pre><pre><o:p>&nbsp=
;</o:p></pre><pre>We then note that we need bot strict and =
loose<o:p></o:p></pre><pre>path =
specification.<o:p></o:p></pre><pre><o:p>&nbsp;</o:p></pre><pre>We then =
discuss the trust =
model<o:p></o:p></pre><pre><o:p>&nbsp;</o:p></pre><pre>We then say we =
start with single AS but must be<o:p></o:p></pre><pre>able to =
multi-AS<o:p></o:p></pre><pre><o:p>&nbsp;</o:p></pre><pre>We call out =
centralized and distributed path =
comp.<o:p></o:p></pre><pre><o:p>&nbsp;</o:p></pre><pre>We then call out =
SPRING as an OAM and the need<o:p></o:p></pre><pre>to manage =
SPRING.<o:p></o:p></pre><pre><o:p>&nbsp;</o:p></pre><pre>Then for data =
plane, control plane and management<o:p></o:p></pre><pre>we say, try to =
use existing, but if that does<o:p></o:p></pre><pre>not work we specify =
the process for change.<o:p></o:p></pre><pre>Note that we talk about =
data planes in the =
plural.<o:p></o:p></pre><pre><o:p>&nbsp;</o:p></pre><pre>We then provide =
the deliverable as an edited<o:p></o:p></pre><pre>version of the =
delivery plan.<o:p></o:p></pre><pre><o:p>&nbsp;</o:p></pre><pre>We do =
not explicitly call out either MPLS or<o:p></o:p></pre><pre>IPv6 (or any =
other data plane), because, =
<o:p></o:p></pre><pre><o:p>&nbsp;</o:p></pre><pre>1) That emerges from =
the use cases.<o:p></o:p></pre><pre>2) The charter says use the =
dataplanes (note the <o:p></o:p></pre><pre>plural) and protocols that =
are derived from<o:p></o:p></pre><pre>the use =
cases.<o:p></o:p></pre><pre><o:p>&nbsp;</o:p></pre><pre>The charter =
therefore set a strong expectation<o:p></o:p></pre><pre>that whatever =
dataplanes need to to be used <o:p></o:p></pre><pre>to satisfy the =
network need is in =
scope.<o:p></o:p></pre><pre><o:p>&nbsp;</o:p></pre><pre>Comments please =
<o:p></o:p></pre><pre><o:p>&nbsp;</o:p></pre><pre>Stewart<o:p></o:p></pre=
><pre><o:p>&nbsp;</o:p></pre><pre>PS you may see -04 with some =
cosmetic/layout =
changes.<o:p></o:p></pre><pre><o:p>&nbsp;</o:p></pre><pre><o:p>&nbsp;</o:=
p></pre><pre><o:p>&nbsp;</o:p></pre></div></div></body></html>
------=_NextPart_000_07C5_01CEBE1B.1A22DD50--

Date: Mon, 30 Sep 2013 16:52:29 +0100
From: Stewart Bryant <[email-masked]>
To: "[email-masked]" <[email-masked]>
Subject: [Status] Updated charter - version 3 and maybe 4
Reply-To: [email-masked]

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

Adrian and I took a close look the SPRING charter
and have edited it to get text that we think is more
likely to get through the review cycles.

The intent of the changes is not change the work
programme, the deliverables or the networks. The
purpose of the changes is to generate what we think
is a viable charter that matches the intent of
this list.

First we added a summary of what spring is and
why it is needed - that is covered by the first
paragraph, the list of *example* and the following
paragraph.

We then note that we need bot strict and loose
path specification.

We then discuss the trust model

We then say we start with single AS but must be
able to multi-AS

We call out centralized and distributed path comp.

We then call out SPRING as an OAM and the need
to manage SPRING.

Then for data plane, control plane and management
we say, try to use existing, but if that does
not work we specify the process for change.
Note that we talk about data planes in the plural.

We then provide the deliverable as an edited
version of the delivery plan.

We do not explicitly call out either MPLS or
IPv6 (or any other data plane), because,

1) That emerges from the use cases.
2) The charter says use the dataplanes (note the
plural) and protocols that are derived from
the use cases.

The charter therefore set a strong expectation
that whatever dataplanes need to to be used
to satisfy the network need is in scope.

Comments please

Stewart

PS you may see -04 with some cosmetic/layout changes.

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

<html>
  <head>

    <meta http-equiv="content-type" content="text/html; charset=ISO-8859-1">
  </head>
  <body bgcolor="#FFFFFF" text="#000000">
    <meta http-equiv="content-type" content="text/html;
      charset=ISO-8859-1">
    <pre>Adrian and I took a close look the SPRING charter
and have edited it to get text that we think is more
likely to get through the review cycles.

The intent of the changes is not change the work 
programme, the deliverables or the networks. The
purpose of the changes is to generate what we think
is a viable charter that matches the intent of
this list.

First we added a summary of what spring is and 
why it is needed - that is covered by the first
paragraph, the list of *example* and the following
paragraph.

We then note that we need bot strict and loose
path specification.

We then discuss the trust model

We then say we start with single AS but must be
able to multi-AS

We call out centralized and distributed path comp.

We then call out SPRING as an OAM and the need
to manage SPRING.

Then for data plane, control plane and management
we say, try to use existing, but if that does
not work we specify the process for change.
Note that we talk about data planes in the plural.

We then provide the deliverable as an edited
version of the delivery plan.

We do not explicitly call out either MPLS or
IPv6 (or any other data plane), because, 

1) That emerges from the use cases.
2) The charter says use the dataplanes (note the 
plural) and protocols that are derived from
the use cases.

The charter therefore set a strong expectation
that whatever dataplanes need to to be used 
to satisfy the network need is in scope.

Comments please 

Stewart

PS you may see -04 with some cosmetic/layout changes.

</pre>
  </body>
</html>

--------------010701090203050001030008--

From: Hannes Gredler <[email-masked]>
Date: Wed, 25 Sep 2013 11:02:15 +0200
To: <[email-masked]>
Cc: [email-masked]
Subject: Re: [Status] Chartering next steps

On Sep 25, 2013, at 8:32 AM, <[email-masked]> wrote:
> -----Original Message-----
> From: Hannes Gredler [mailto:[email-masked]]
>=20
>    my read is that it its the other way around.
>    there is enough exisiting protocols which support hop-by-hop =
routing.
>=20
>    what i am looking for the spot which is not covered by
>    existing protocols (read: explicit routing at scale,
>    w/o tracking midpoint state)
>=20
> Means we've solved all hop-by-hop and ER issues by the existing =
protocols and you don't see a point in any SPRING related activity?

what i am looking in SPRING is to augment the protocol stack with
semantics which do not yet exist. as a counter-example introducing IGP
advertised hop-by-hop labels (just to replace LDP for transport
labels is redundant) and as such rather uninteresting.

however there are use cases which require transport labels to be learned
from non-adjacecnt routers. (e.g. R-LFA, R-LFA+DF) and IGP
disseminated labels would fix that problem just nice.

>=20
>    thats fine - note that in all the exisiting IGP MPLS drafts there =
is both support for
>    explicit routes and hop-by-hop LSPs, mostly to avoid T-LDP sessions
>    such that you can learn transport labels from non adjacent routers.
>=20
> Yes, and you are one of the authors. If you believe there's no spot =
covered by existing protocols, why are you entertaining drafts related =
to SPRING?

today no protocol supports learning of labels from non-adjacent =
neighbors,
like we need it in R-LFA and R-LFA+DF - so the 'workaround' is
to dynamically bring up LDP sessions which is arguably a bit more =
expensive
as you cannot construct R-LFA backup paths in s "single pass",
after initial PQ set calculation you always need to wait until the
T-LDP labels from the PQ neighbors have been learned.

upon major topology changes this translates into twice the forwarding =
table
updates, twice the BGP route resolver dependency checking, etc.

the 'segment routing extensions' draft and the 'label in IGP drafts=20
which i co-authored, fix that specific problem by allowing to =
calculate/update
backup paths in a "single pass".

> If all spots are covered: which single existing protocol detects a =
domain's complete MPLS topology coupled with IGP topology and =
utilisation of the MPLS topology discovered that way for routing at a =
source node?

the cardinal mistake in here seems to me is the desire to have a 'single =
protocol'.

as no protocol has the sum of properties of all the other protocols,
there will be always a 'plurality' of protocols.

IOW just because we introduce hop-by-hop labels and explicit routes in =
the IGP
does not imply that neither LDP, RSVP nor BGP-LU is going away.
at best we may see some shift of functionality from protocol X to =
protocol Y.

hope that clarifies,

/hannes

From: <[email-masked]>
To: <[email-masked]>
Date: Wed, 25 Sep 2013 08:32:38 +0200
Accept-Language: en-US, de-DE
acceptlanguage: en-US, de-DE
Cc: [email-masked]
Subject: Re: [Status] Chartering next steps

Hannes,

please explain your point.

Regards,

Ruediger

-----Original Message-----
From: Hannes Gredler [mailto:[email-masked]]

    my read is that it its the other way around.
    there is enough exisiting protocols which support hop-by-hop routing.

    what i am looking for the spot which is not covered by
    existing protocols (read: explicit routing at scale,
    w/o tracking midpoint state)

Means we've solved all hop-by-hop and ER issues by the existing protocols a=
nd you don't see a point in any SPRING related activity?

    thats fine - note that in all the exisiting IGP MPLS drafts there is bo=
th support for
    explicit routes and hop-by-hop LSPs, mostly to avoid T-LDP sessions
    such that you can learn transport labels from non adjacent routers.

Yes, and you are one of the authors. If you believe there's no spot covered=
 by existing protocols, why are you entertaining drafts related to SPRING?

If all spots are covered: which single existing protocol detects a domain's=
 complete MPLS topology coupled with IGP topology and utilisation of the MP=
LS topology discovered that way for routing at a source node?

To: [email-masked], [email-masked]
Date: Tue, 24 Sep 2013 16:27:27 -0400 (EDT)
From: [email-masked] (Noel Chiappa)
Cc: [email-masked]
Subject: Re: [Status] Chartering next steps

    > From: Hannes Gredler <[email-masked]>

    > what i am looking for the spot which is not covered by existing
    > protocols (read: explicit routing at scale, w/o tracking midpoint state)

This is probably not quite what you're looking for, but may I point you
at:

  http://ana-3.lcs.mit.edu/~jnc/nimrod/docs.html

It had the characteristics you're looking for (explicit routing, without
knowing all the details in the middle), but of course it was a much more
powerful, general design, intended as it was to replace _all_ EGPs and most
IGPs.

	Noel

Date: Tue, 24 Sep 2013 14:12:08 +0200
From: Hannes Gredler <[email-masked]>
To: <[email-masked]>
Cc: [email-masked]
Subject: Re: [Status] Chartering next steps

On Tue, Sep 24, 2013 at 08:40:02AM +0200, [email-masked] wrote:
| thanks for pointing out. I think SPRING's objective is to enhance hop-by-hop routing to additionally allow explicit routing without state maintainance at transit nodes.

my read is that it its the other way around.
there is enough exisiting protocols which support hop-by-hop routing. 

what i am looking for the spot which is not covered by 
existing protocols (read: explicit routing at scale,
w/o tracking midpoint state)

| Robert indicated, that changes in routing protocols required by SPRING are not limited to features required to set up such explicit routes. And he's absolutely correct with that.

thats fine - note that in all the exisiting IGP MPLS drafts there is both support for
explicit routes and hop-by-hop LSPs, mostly to avoid T-LDP sessions
such that you can learn transport labels from non adjacent routers.

/hannes

| 
| -----Original Message-----
| From: [email-masked] [mailto:[email-masked]] On Behalf Of Hannes Gredler
| Sent: Tuesday, September 24, 2013 1:03 AM
| To: Robert Raszuk
| Cc: John E Drake; [email-masked]; [email-masked]; Jeff Tantsura; Sriganesh Kini
| Subject: Re: [Status] Chartering next steps
| 
| 
| On Sep 23, 2013, at 10:53 PM, Robert Raszuk wrote:
| 
| > Last email on this ...
| >
| > rfc3031 says:
| >
| >      -  Sometimes it is desirable to force a packet to follow a
| >         particular route which is explicitly chosen at or before the
| >         time the packet enters the network, rather than being chosen by
| >         the normal dynamic routing algorithm as the packet travels
| >         through the network.
| >
| > My example application is to use normal dynamic routing algorithm
| > which based on the above text does not fall under term of "explicit"
| > it is neither loose ERO or strict ERO - there is no ERO.
| 
| there is always an ERO.
| for hop-by-hop LSPs the ERO admittedly is as 'loose' as 'loose' can get -
| which is consisting of a single 'loose' hop denominating the egress point.
| 
| just ask yourself how is e.g.
| a RSVP/SR LSP: 192.168.1.1 'L' ERO different than
| a LDP LSP: FEC 192.168.1.1 ?
| 
| /hannes
| 
| 
| _______________________________________________
| status mailing list
| [email-masked]
| https://www.ietf.org/mailman/listinfo/status
| 
| 

Date: Tue, 24 Sep 2013 11:00:02 +0100
From: Stewart Bryant <[email-masked]>
To: Robert Raszuk <[email-masked]>
Cc: John E Drake <[email-masked]>, "[email-masked]" <[email-masked]>, Jeff Tantsura <[email-masked]>, Sriganesh Kini <[email-masked]>
Subject: Re: [Status] Chartering next steps
Reply-To: [email-masked]

A one hop loose source route with the next hop = the egress PE.

Stewart

On 23/09/2013 19:08, Robert Raszuk wrote:
> Hi Jeff,
>
> If I want to use SPRING to get rid of LDP between my ingress and
> egress PEs what is my "explicit-route" in that case ?
>
> r.
>
> On Mon, Sep 23, 2013 at 8:05 PM, Jeff Tantsura
> <[email-masked]> wrote:
>> Agree with Sri.
>> Strict and loose explicit routes define pretty well what SPRING does
>>
>> Cheers,
>> Jeff
>>
>>
>>
>>
>> -----Original Message-----
>> From: Sriganesh Kini <[email-masked]>
>> Date: Monday, September 23, 2013 11:02 AM
>> To: "[email-masked]" <[email-masked]>
>> Cc: John Drake <[email-masked]>, "[email-masked]" <[email-masked]>,
>> "[email-masked]" <[email-masked]>
>> Subject: Re: [Status] Chartering next steps
>>
>>> Robert,
>>>
>>> MPLS has defined "strict", "loose" and combinations of those in the
>>> context of "explicit-routes". SPRING should be able to re-use/re-define it
>>> as necessary.
>>>
>>> Interpreting "explicit-route" as "hop-by-hop" seems like a stretch.
>>>
>>> I don't see a strong reason for yet another term "defined path".
>>>
>>> -- Sri
>>>
>>>
>>>
>>>
>>>
>>>
>>> On 9/23/13 10:50 AM, "Robert Raszuk" <[email-masked]> wrote:
>>>
>>>> The observation is that SR may not require explicit-route in all
>>>> scenarios. I can see cases of loose-routes yet based on segment based
>>>> routing paradigm.
>>>>
>>>> Besides explicit route may be interpreted as hop-by-hop path which is
>>>> clearly not the case.
>>>>
>>>> I would recommend to s/explicit route/defined path/
>>>>
>>>> r.
>>>>
>>>>
>>>>
>>>> On Mon, Sep 23, 2013 at 7:44 PM, Sriganesh Kini
>>>> <[email-masked]> wrote:
>>>>>  From RFC 3031, sec 3.21
>>>>>
>>>>>     Explicit routing may be useful for a number of purposes, such as
>>>>>     policy routing or traffic engineering.  In MPLS, the explicit route
>>>>>     needs to be specified at the time that labels are assigned, but the
>>>>>     explicit route does not have to be specified with each IP packet.
>>>>>     This makes MPLS explicit routing much more efficient than the
>>>>>     alternative of IP source routing.
>>>>>
>>>>>
>>>>> If the "explicit-route" in SPRING is the same as explicit-route in
>>>>> RFC3031
>>>>> then we are ruling out source-routing ! IMO we should call it
>>>>> explicit-route
>>>>> but re-define it for SPRING. The definition could be "a set of
>>>>> identifiers
>>>>> in the packet that allow it to be steered through the network without
>>>>> having
>>>>> per flow information at each intermediate node". However this
>>>>> re-definition
>>>>> need not be in the charter but could go in another document
>>>>> (architecture
>>>>> document).
>>>>>
>>>>> - Sri
>>>>>
>>>>>
>>>>>
>>>>> On Mon, Sep 23, 2013 at 8:01 AM, John E Drake <[email-masked]>
>>>>> wrote:
>>>>>> Stewart,
>>>>>>
>>>>>>
>>>>>>
>>>>>> Upon reflection, I spoke too soon.  The use of the term Œexplicit
>>>>>> route¹
>>>>>> as suggested by Lou and myself is fine, but the sentence you added:
>>>>>>
>>>>>>
>>>>>>
>>>>>> ³Steering is achieved by specifying in the packet an ordered set of
>>>>>> nodes
>>>>>> and/or links and/or shortest-path-next-hops to be traversed by the
>>>>>> packet.²
>>>>>>
>>>>>>
>>>>>>
>>>>>> has issues.  A packet *will not* have contain an ordered set of nodes
>>>>>> and/or links and/or shortest-path-next-hops to be traversed by the
>>>>>> packet,
>>>>>> rather it will have a set of identifiers specifying resources within a
>>>>>> SPRING region, and these specified resources *are not* limited to
>>>>>> ³nodes
>>>>>> and/or links and/or shortest-path-next-hops²; they may also include,
>>>>>> for
>>>>>> example, forwarding adjacencies and services.
>>>>>>
>>>>>>
>>>>>>
>>>>>> I suggest that we strike the sentence.  As Stefano points out, a
>>>>>> charter
>>>>>> is not a design specification.
>>>>>>
>>>>>>
>>>>>>
>>>>>> Yours Irrespectively,
>>>>>>
>>>>>>
>>>>>>
>>>>>> John
>>>>>>
>>>>>>
>>>>>>
>>>>>> From: [email-masked] [mailto:[email-masked]] On
>>>>>> Behalf
>>>>>> Of Stewart Bryant
>>>>>> Sent: Monday, September 23, 2013 6:13 AM
>>>>>> To: [email-masked]
>>>>>>
>>>>>>
>>>>>> Subject: Re: [Status] Chartering next steps
>>>>>>
>>>>>>
>>>>>>
>>>>>> I have included the proposed changes and some text that
>>>>>>
>>>>>>
>>>>>> clarifies the link-node discussion.
>>>>>>
>>>>>> The current charter text is at
>>>>>>
>>>>>> https://datatracker.ietf.org/doc/charter-ietf-spring/
>>>>>>
>>>>>> The diffs are at
>>>>>>
>>>>>>
>>>>>>
>>>>>> https://www.ietf.org/rfcdiff?url1=https%3A%2F%2Fdatatracker.ietf.org%2F
>>>>>> d
>>>>>> oc%2Fcharter-ietf-spring%2Fwithmilestones-00-00.txt&difftype=--html&sub
>>>>>> m
>>>>>> it=Go!&url2=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fcharter-ietf-spr
>>>>>> i
>>>>>> ng%2Fwithmilestones-00-01.txt
>>>>>>
>>>>>> or if you prefer:
>>>>>>
>>>>>> http://tinyurl.com/o24a9lz
>>>>>>
>>>>>> The link node text I added was
>>>>>>
>>>>>> "Steering is achieved by specifying in the packet an ordered
>>>>>> set of nodes and/or links and/or shortest-path-next-hops
>>>>>> to be traversed by the packet."
>>>>>>
>>>>>> - Stewart
>>>>>>
>>>>>>
>>>>>> _______________________________________________
>>>>>> status mailing list
>>>>>> [email-masked]
>>>>>> https://www.ietf.org/mailman/listinfo/status
>>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> status mailing list
>>>>> [email-masked]
>>>>> https://www.ietf.org/mailman/listinfo/status
>>>>>
>>> _______________________________________________
>>> status mailing list
>>> [email-masked]
>>> https://www.ietf.org/mailman/listinfo/status
> _______________________________________________
> status mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/status
> .
>

-- 
For corporate legal information go to:

http://www.cisco.com/web/about/doing_business/legal/cri/index.html

From: <[email-masked]>
To: <[email-masked]>
Date: Tue, 24 Sep 2013 08:40:02 +0200
Accept-Language: en-US, de-DE
acceptlanguage: en-US, de-DE
Cc: [email-masked]
Subject: Re: [Status] Chartering next steps

Hannes, all,

thanks for pointing out. I think SPRING's objective is to enhance hop-by-ho=
p routing to additionally allow explicit routing without state maintainance=
 at transit nodes.

Robert indicated, that changes in routing protocols required by SPRING are =
not limited to features required to set up such explicit routes. And he's a=
bsolutely correct with that.

Regards,

Ruediger

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of=
 Hannes Gredler
Sent: Tuesday, September 24, 2013 1:03 AM
To: Robert Raszuk
Cc: John E Drake; [email-masked]; [email-masked]; Jeff Tantsura; Sriga=
nesh Kini
Subject: Re: [Status] Chartering next steps

On Sep 23, 2013, at 10:53 PM, Robert Raszuk wrote:

> Last email on this ...
>
> rfc3031 says:
>
>      -  Sometimes it is desirable to force a packet to follow a
>         particular route which is explicitly chosen at or before the
>         time the packet enters the network, rather than being chosen by
>         the normal dynamic routing algorithm as the packet travels
>         through the network.
>
> My example application is to use normal dynamic routing algorithm
> which based on the above text does not fall under term of "explicit"
> it is neither loose ERO or strict ERO - there is no ERO.

there is always an ERO.
for hop-by-hop LSPs the ERO admittedly is as 'loose' as 'loose' can get -
which is consisting of a single 'loose' hop denominating the egress point.

just ask yourself how is e.g.
a RSVP/SR LSP: 192.168.1.1 'L' ERO different than
a LDP LSP: FEC 192.168.1.1 ?

/hannes

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

From: Hannes Gredler <[email-masked]>
Date: Tue, 24 Sep 2013 01:03:29 +0200
To: Robert Raszuk <[email-masked]>
Cc: John E Drake <[email-masked]>, "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>, Jeff Tantsura <[email-masked]>, Sriganesh Kini <[email-masked]>
Subject: Re: [Status] Chartering next steps

On Sep 23, 2013, at 10:53 PM, Robert Raszuk wrote:

> Last email on this ...
> 
> rfc3031 says:
> 
>      -  Sometimes it is desirable to force a packet to follow a
>         particular route which is explicitly chosen at or before the
>         time the packet enters the network, rather than being chosen by
>         the normal dynamic routing algorithm as the packet travels
>         through the network.
> 
> My example application is to use normal dynamic routing algorithm
> which based on the above text does not fall under term of "explicit"
> it is neither loose ERO or strict ERO - there is no ERO.

there is always an ERO.
for hop-by-hop LSPs the ERO admittedly is as 'loose' as 'loose' can get -
which is consisting of a single 'loose' hop denominating the egress point.

just ask yourself how is e.g. 
a RSVP/SR LSP: 192.168.1.1 'L' ERO different than 
a LDP LSP: FEC 192.168.1.1 ?

/hannes

From: Sriganesh Kini <[email-masked]>
To: Robert Raszuk <[email-masked]>
Date: Mon, 23 Sep 2013 21:06:16 +0000
Accept-Language: en-US
Cc: John E Drake <[email-masked]>, "[email-masked]" <[email-masked]>, Jeff Tantsura <[email-masked]>, "[email-masked]" <[email-masked]>
Subject: Re: [Status] Chartering next steps

Robert, as has been said on the list before, RFC 3031 is not listed in the
charter. But there are definitions in it that are useful to be adapted for
SPRING.=20

-- Sri

On 9/23/13 1:53 PM, "Robert Raszuk" <[email-masked]> wrote:

>Last email on this ...
>
>rfc3031 says:
>
>      -  Sometimes it is desirable to force a packet to follow a
>         particular route which is explicitly chosen at or before the
>         time the packet enters the network, rather than being chosen by
>         the normal dynamic routing algorithm as the packet travels
>         through the network.
>
>My example application is to use normal dynamic routing algorithm
>which based on the above text does not fall under term of "explicit"
>it is neither loose ERO or strict ERO - there is no ERO.
>
>Best,
>R.
>
>
>
>
>
>On Mon, Sep 23, 2013 at 10:07 PM, Sriganesh Kini
><[email-masked]> wrote:
>> If that is your application, then the (loose) explicit-route is the
>> shortest-path. In case of MPLS-SPRING the source will push a label that
>> results in the packet going along the shortest-path.
>>
>>
>> On Mon, Sep 23, 2013 at 12:43 PM, Robert Raszuk <[email-masked]>
>>wrote:
>>>
>>> Such "directions" in the application of removing need for LDP for
>>> unicast traffic are computed by OSPF/ISIS SPF.
>>>
>>> Rgs,
>>> R.
>>>
>>> > Directions, at a given level of detail, for getting from the ingress
>>> > node to the egress node.
>>> >
>>> > Yours Irrespectively,
>>> _______________________________________________
>>> status mailing list
>>> [email-masked]
>>> https://www.ietf.org/mailman/listinfo/status
>>
>>
>_______________________________________________
>status mailing list
>[email-masked]
>https://www.ietf.org/mailman/listinfo/status

From: John E Drake <[email-masked]>
To: Robert Raszuk <[email-masked]>
Date: Mon, 23 Sep 2013 20:53:42 +0000
Accept-Language: en-US
Cc: Sriganesh Kini <[email-masked]>, "[email-masked]" <[email-masked]>, Jeff Tantsura <[email-masked]>, "[email-masked]" <[email-masked]>
Subject: Re: [Status] Chartering next steps

You're getting the hang of this.

Sent from my iPhone

> On Sep 23, 2013, at 3:43 PM, "Robert Raszuk" <[email-masked]> wrote:
>=20
> Such "directions" in the application of removing need for LDP for
> unicast traffic are computed by OSPF/ISIS SPF.
>=20
> Rgs,
> R.
>=20
>> Directions, at a given level of detail, for getting from the ingress nod=
e to the egress node.
>>=20
>> Yours Irrespectively,
>=20
>=20

Sender: [email-masked]
Date: Mon, 23 Sep 2013 22:53:59 +0200
From: Robert Raszuk <[email-masked]>
To: Sriganesh Kini <[email-masked]>
Cc: John E Drake <[email-masked]>, "[email-masked]" <[email-masked]>, Jeff Tantsura <[email-masked]>, "[email-masked]" <[email-masked]>
Subject: Re: [Status] Chartering next steps

Last email on this ...

rfc3031 says:

      -  Sometimes it is desirable to force a packet to follow a
         particular route which is explicitly chosen at or before the
         time the packet enters the network, rather than being chosen by
         the normal dynamic routing algorithm as the packet travels
         through the network.

My example application is to use normal dynamic routing algorithm
which based on the above text does not fall under term of "explicit"
it is neither loose ERO or strict ERO - there is no ERO.

Best,
R.

On Mon, Sep 23, 2013 at 10:07 PM, Sriganesh Kini
<[email-masked]> wrote:
> If that is your application, then the (loose) explicit-route is the
> shortest-path. In case of MPLS-SPRING the source will push a label that
> results in the packet going along the shortest-path.
>
>
> On Mon, Sep 23, 2013 at 12:43 PM, Robert Raszuk <[email-masked]> wrote:
>>
>> Such "directions" in the application of removing need for LDP for
>> unicast traffic are computed by OSPF/ISIS SPF.
>>
>> Rgs,
>> R.
>>
>> > Directions, at a given level of detail, for getting from the ingress
>> > node to the egress node.
>> >
>> > Yours Irrespectively,
>> _______________________________________________
>> status mailing list
>> [email-masked]
>> https://www.ietf.org/mailman/listinfo/status
>
>

Sender: [email-masked]
From: Sriganesh Kini <[email-masked]>
Date: Mon, 23 Sep 2013 13:07:53 -0700
To: Robert Raszuk <[email-masked]>
Cc: John E Drake <[email-masked]>, "[email-masked]" <[email-masked]>, Jeff Tantsura <[email-masked]>, "[email-masked]" <[email-masked]>
Subject: Re: [Status] Chartering next steps

--047d7bae45ac74ddad04e7129516
Content-Type: text/plain; charset=UTF-8

If that is your application, then the (loose) explicit-route is the
shortest-path. In case of MPLS-SPRING the source will push a label that
results in the packet going along the shortest-path.

On Mon, Sep 23, 2013 at 12:43 PM, Robert Raszuk <[email-masked]> wrote:

> Such "directions" in the application of removing need for LDP for
> unicast traffic are computed by OSPF/ISIS SPF.
>
> Rgs,
> R.
>
> > Directions, at a given level of detail, for getting from the ingress
> node to the egress node.
> >
> > Yours Irrespectively,
> _______________________________________________
> status mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/status
>

--047d7bae45ac74ddad04e7129516
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">If that is your application, then the (loose) explicit-rou=
te is the shortest-path. In case of MPLS-SPRING the source will push a labe=
l that results in the packet going along the shortest-path.<div class=3D"gm=
ail_extra">

<br><br><div class=3D"gmail_quote">On Mon, Sep 23, 2013 at 12:43 PM, Robert=
 Raszuk <span dir=3D"ltr">&lt;<a href=3D"mailto:[email-masked]" target=
=3D"_blank">[email-masked]</a>&gt;</span> wrote:<br><blockquote class=3D=
"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding=
-left:1ex">

Such &quot;directions&quot; in the application of removing need for LDP for=
<br>
unicast traffic are computed by OSPF/ISIS SPF.<br>
<br>
Rgs,<br>
R.<br>
<div><br>
&gt; Directions, at a given level of detail, for getting from the ingress n=
ode to the egress node.<br>
&gt;<br>
&gt; Yours Irrespectively,<br>
</div><div><div>_______________________________________________<br>
status mailing list<br>
<a href=3D"mailto:[email-masked]" target=3D"_blank">[email-masked]</a><br=
>
<a href=3D"https://www.ietf.org/mailman/listinfo/status" target=3D"_blank">=
https://www.ietf.org/mailman/listinfo/status</a><br>
</div></div></blockquote></div><br></div></div>

--047d7bae45ac74ddad04e7129516--

Sender: [email-masked]
Date: Mon, 23 Sep 2013 21:43:17 +0200
From: Robert Raszuk <[email-masked]>
To: John E Drake <[email-masked]>
Cc: Sriganesh Kini <[email-masked]>, "[email-masked]" <[email-masked]>, Jeff Tantsura <[email-masked]>, "[email-masked]" <[email-masked]>
Subject: Re: [Status] Chartering next steps

Such "directions" in the application of removing need for LDP for
unicast traffic are computed by OSPF/ISIS SPF.

Rgs,
R.

> Directions, at a given level of detail, for getting from the ingress node to the egress node.
>
> Yours Irrespectively,

From: John E Drake <[email-masked]>
To: Robert Raszuk <[email-masked]>, Jeff Tantsura <[email-masked]>
Date: Mon, 23 Sep 2013 19:17:50 +0000
Accept-Language: en-US
Cc: "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>, Sriganesh Kini <[email-masked]>
Subject: Re: [Status] Chartering next steps

Directions, at a given level of detail, for getting from the ingress node t=
o the egress node.=20

Yours Irrespectively,

John

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of Robert
> Raszuk
> Sent: Monday, September 23, 2013 11:09 AM
> To: Jeff Tantsura
> Cc: Sriganesh Kini; John E Drake; [email-masked]; [email-masked]
> Subject: Re: [Status] Chartering next steps
>=20
> Hi Jeff,
>=20
> If I want to use SPRING to get rid of LDP between my ingress and egress P=
Es
> what is my "explicit-route" in that case ?
>=20
> r.
>=20
> On Mon, Sep 23, 2013 at 8:05 PM, Jeff Tantsura
> <[email-masked]> wrote:
> > Agree with Sri.
> > Strict and loose explicit routes define pretty well what SPRING does
> >
> > Cheers,
> > Jeff
> >
> >
> >
> >
> > -----Original Message-----
> > From: Sriganesh Kini <[email-masked]>
> > Date: Monday, September 23, 2013 11:02 AM
> > To: "[email-masked]" <[email-masked]>
> > Cc: John Drake <[email-masked]>, "[email-masked]"
> > <[email-masked]>, "[email-masked]" <[email-masked]>
> > Subject: Re: [Status] Chartering next steps
> >
> >>Robert,
> >>
> >>MPLS has defined "strict", "loose" and combinations of those in the
> >>context of "explicit-routes". SPRING should be able to
> >>re-use/re-define it as necessary.
> >>
> >>Interpreting "explicit-route" as "hop-by-hop" seems like a stretch.
> >>
> >>I don't see a strong reason for yet another term "defined path".
> >>
> >>-- Sri
> >>
> >>
> >>
> >>
> >>
> >>
> >>On 9/23/13 10:50 AM, "Robert Raszuk" <[email-masked]> wrote:
> >>
> >>>The observation is that SR may not require explicit-route in all
> >>>scenarios. I can see cases of loose-routes yet based on segment based
> >>>routing paradigm.
> >>>
> >>>Besides explicit route may be interpreted as hop-by-hop path which is
> >>>clearly not the case.
> >>>
> >>>I would recommend to s/explicit route/defined path/
> >>>
> >>>r.
> >>>
> >>>
> >>>
> >>>On Mon, Sep 23, 2013 at 7:44 PM, Sriganesh Kini
> >>><[email-masked]> wrote:
> >>>> From RFC 3031, sec 3.21
> >>>>
> >>>>    Explicit routing may be useful for a number of purposes, such as
> >>>>    policy routing or traffic engineering.  In MPLS, the explicit rou=
te
> >>>>    needs to be specified at the time that labels are assigned, but t=
he
> >>>>    explicit route does not have to be specified with each IP packet.
> >>>>    This makes MPLS explicit routing much more efficient than the
> >>>>    alternative of IP source routing.
> >>>>
> >>>>
> >>>> If the "explicit-route" in SPRING is the same as explicit-route in
> >>>>RFC3031
> >>>> then we are ruling out source-routing ! IMO we should call it
> >>>>explicit-route  but re-define it for SPRING. The definition could be
> >>>>"a set of identifiers  in the packet that allow it to be steered
> >>>>through the network without having  per flow information at each
> >>>>intermediate node". However this re-definition  need not be in the
> >>>>charter but could go in another document (architecture  document).
> >>>>
> >>>> - Sri
> >>>>
> >>>>
> >>>>
> >>>> On Mon, Sep 23, 2013 at 8:01 AM, John E Drake <[email-masked]>
> >>>>wrote:
> >>>>>
> >>>>> Stewart,
> >>>>>
> >>>>>
> >>>>>
> >>>>> Upon reflection, I spoke too soon.  The use of the term =8Cexplicit
> >>>>>route=B9  as suggested by Lou and myself is fine, but the sentence
> >>>>>you added:
> >>>>>
> >>>>>
> >>>>>
> >>>>> =B3Steering is achieved by specifying in the packet an ordered set
> >>>>>of nodes  and/or links and/or shortest-path-next-hops to be
> >>>>>traversed by the packet.=B2
> >>>>>
> >>>>>
> >>>>>
> >>>>> has issues.  A packet *will not* have contain an ordered set of
> >>>>>nodes  and/or links and/or shortest-path-next-hops to be traversed
> >>>>>by the packet,  rather it will have a set of identifiers specifying
> >>>>>resources within a  SPRING region, and these specified resources
> >>>>>*are not* limited to =B3nodes  and/or links and/or
> >>>>>shortest-path-next-hops=B2; they may also include, for  example,
> >>>>>forwarding adjacencies and services.
> >>>>>
> >>>>>
> >>>>>
> >>>>> I suggest that we strike the sentence.  As Stefano points out, a
> >>>>>charter  is not a design specification.
> >>>>>
> >>>>>
> >>>>>
> >>>>> Yours Irrespectively,
> >>>>>
> >>>>>
> >>>>>
> >>>>> John
> >>>>>
> >>>>>
> >>>>>
> >>>>> From: [email-masked] [mailto:[email-masked]] On
> >>>>>Behalf  Of Stewart Bryant
> >>>>> Sent: Monday, September 23, 2013 6:13 AM
> >>>>> To: [email-masked]
> >>>>>
> >>>>>
> >>>>> Subject: Re: [Status] Chartering next steps
> >>>>>
> >>>>>
> >>>>>
> >>>>> I have included the proposed changes and some text that
> >>>>>
> >>>>>
> >>>>> clarifies the link-node discussion.
> >>>>>
> >>>>> The current charter text is at
> >>>>>
> >>>>> https://datatracker.ietf.org/doc/charter-ietf-spring/
> >>>>>
> >>>>> The diffs are at
> >>>>>
> >>>>>
> >>>>>
> >>>>>https://www.ietf.org/rfcdiff?url1=3Dhttps%3A%2F%2Fdatatracker.ietf.o
> r
> >>>>>g%2F
> >>>>>d
> >>>>>oc%2Fcharter-ietf-spring%2Fwithmilestones-00-00.txt&difftype=3D--
> html
> >>>>>&sub
> >>>>>m
> >>>>>it=3DGo!&url2=3Dhttps%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fcharter-
> ietf
> >>>>>-spr
> >>>>>i
> >>>>>ng%2Fwithmilestones-00-01.txt
> >>>>>
> >>>>> or if you prefer:
> >>>>>
> >>>>> http://tinyurl.com/o24a9lz
> >>>>>
> >>>>> The link node text I added was
> >>>>>
> >>>>> "Steering is achieved by specifying in the packet an ordered set
> >>>>> of nodes and/or links and/or shortest-path-next-hops to be
> >>>>> traversed by the packet."
> >>>>>
> >>>>> - Stewart
> >>>>>
> >>>>>
> >>>>> _______________________________________________
> >>>>> status mailing list
> >>>>> [email-masked]
> >>>>> https://www.ietf.org/mailman/listinfo/status
> >>>>>
> >>>>
> >>>>
> >>>> _______________________________________________
> >>>> status mailing list
> >>>> [email-masked]
> >>>> https://www.ietf.org/mailman/listinfo/status
> >>>>
> >>
> >>_______________________________________________
> >>status mailing list
> >>[email-masked]
> >>https://www.ietf.org/mailman/listinfo/status
> >
>=20

From: John E Drake <[email-masked]>
To: Robert Raszuk <[email-masked]>, Sriganesh Kini <[email-masked]>
Date: Mon, 23 Sep 2013 19:14:40 +0000
Accept-Language: en-US
Cc: "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>
Subject: Re: [Status] Chartering next steps

And your point is?

Yours Irrespectively,

John

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of Robert
> Raszuk
> Sent: Monday, September 23, 2013 11:05 AM
> To: Sriganesh Kini
> Cc: John E Drake; [email-masked]; [email-masked]
> Subject: Re: [Status] Chartering next steps
>=20
> But SPRING is not only about MPLS encapsulation ..
>=20
> r.
>=20
> On Mon, Sep 23, 2013 at 8:02 PM, Sriganesh Kini
> <[email-masked]> wrote:
> > Robert,
> >
> > MPLS has defined "strict", "loose" and combinations of those in the
> > context of "explicit-routes". SPRING should be able to
> > re-use/re-define it as necessary.
> >
> > Interpreting "explicit-route" as "hop-by-hop" seems like a stretch.
> >
> > I don't see a strong reason for yet another term "defined path".
> >
> > -- Sri
> >
> >
> >
> >
> >
> >
> > On 9/23/13 10:50 AM, "Robert Raszuk" <[email-masked]> wrote:
> >
> >>The observation is that SR may not require explicit-route in all
> >>scenarios. I can see cases of loose-routes yet based on segment based
> >>routing paradigm.
> >>
> >>Besides explicit route may be interpreted as hop-by-hop path which is
> >>clearly not the case.
> >>
> >>I would recommend to s/explicit route/defined path/
> >>
> >>r.
> >>
> >>
> >>
> >>On Mon, Sep 23, 2013 at 7:44 PM, Sriganesh Kini
> >><[email-masked]> wrote:
> >>> From RFC 3031, sec 3.21
> >>>
> >>>    Explicit routing may be useful for a number of purposes, such as
> >>>    policy routing or traffic engineering.  In MPLS, the explicit rout=
e
> >>>    needs to be specified at the time that labels are assigned, but th=
e
> >>>    explicit route does not have to be specified with each IP packet.
> >>>    This makes MPLS explicit routing much more efficient than the
> >>>    alternative of IP source routing.
> >>>
> >>>
> >>> If the "explicit-route" in SPRING is the same as explicit-route in
> >>>RFC3031
> >>> then we are ruling out source-routing ! IMO we should call it
> >>>explicit-route  but re-define it for SPRING. The definition could be
> >>>"a set of identifiers  in the packet that allow it to be steered
> >>>through the network without having  per flow information at each
> >>>intermediate node". However this re-definition  need not be in the
> >>>charter but could go in another document (architecture  document).
> >>>
> >>> - Sri
> >>>
> >>>
> >>>
> >>> On Mon, Sep 23, 2013 at 8:01 AM, John E Drake <[email-masked]>
> >>>wrote:
> >>>>
> >>>> Stewart,
> >>>>
> >>>>
> >>>>
> >>>> Upon reflection, I spoke too soon.  The use of the term =8Cexplicit
> >>>>route=B9
> >>>> as suggested by Lou and myself is fine, but the sentence you added:
> >>>>
> >>>>
> >>>>
> >>>> =B3Steering is achieved by specifying in the packet an ordered set o=
f
> >>>>nodes
> >>>> and/or links and/or shortest-path-next-hops to be traversed by the
> >>>>packet.=B2
> >>>>
> >>>>
> >>>>
> >>>> has issues.  A packet *will not* have contain an ordered set of node=
s
> >>>> and/or links and/or shortest-path-next-hops to be traversed by the
> >>>>packet,
> >>>> rather it will have a set of identifiers specifying resources within=
 a
> >>>> SPRING region, and these specified resources *are not* limited to
> >>>>=B3nodes
> >>>> and/or links and/or shortest-path-next-hops=B2; they may also includ=
e,
> >>>>for
> >>>> example, forwarding adjacencies and services.
> >>>>
> >>>>
> >>>>
> >>>> I suggest that we strike the sentence.  As Stefano points out, a
> >>>>charter
> >>>> is not a design specification.
> >>>>
> >>>>
> >>>>
> >>>> Yours Irrespectively,
> >>>>
> >>>>
> >>>>
> >>>> John
> >>>>
> >>>>
> >>>>
> >>>> From: [email-masked] [mailto:[email-masked]] On
> >>>>Behalf
> >>>> Of Stewart Bryant
> >>>> Sent: Monday, September 23, 2013 6:13 AM
> >>>> To: [email-masked]
> >>>>
> >>>>
> >>>> Subject: Re: [Status] Chartering next steps
> >>>>
> >>>>
> >>>>
> >>>> I have included the proposed changes and some text that
> >>>>
> >>>>
> >>>> clarifies the link-node discussion.
> >>>>
> >>>> The current charter text is at
> >>>>
> >>>> https://datatracker.ietf.org/doc/charter-ietf-spring/
> >>>>
> >>>> The diffs are at
> >>>>
> >>>>
> >>>>
> >>>>https://www.ietf.org/rfcdiff?url1=3Dhttps%3A%2F%2Fdatatracker.ietf.or
> g%2Fd
> >>>>oc%2Fcharter-ietf-spring%2Fwithmilestones-00-00.txt&difftype=3D--
> html&subm
> >>>>it=3DGo!&url2=3Dhttps%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fcharter-
> ietf-spri
> >>>>ng%2Fwithmilestones-00-01.txt
> >>>>
> >>>> or if you prefer:
> >>>>
> >>>> http://tinyurl.com/o24a9lz
> >>>>
> >>>> The link node text I added was
> >>>>
> >>>> "Steering is achieved by specifying in the packet an ordered
> >>>> set of nodes and/or links and/or shortest-path-next-hops
> >>>> to be traversed by the packet."
> >>>>
> >>>> - Stewart
> >>>>
> >>>>
> >>>> _______________________________________________
> >>>> status mailing list
> >>>> [email-masked]
> >>>> https://www.ietf.org/mailman/listinfo/status
> >>>>
> >>>
> >>>
> >>> _______________________________________________
> >>> status mailing list
> >>> [email-masked]
> >>> https://www.ietf.org/mailman/listinfo/status
> >>>
> >
>=20

From: John E Drake <[email-masked]>
To: Sriganesh Kini <[email-masked]>, Robert Raszuk <[email-masked]>
Date: Mon, 23 Sep 2013 19:14:20 +0000
Accept-Language: en-US
Cc: "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>
Subject: Re: [Status] Chartering next steps

Sri,

I completely agree.

Yours Irrespectively,

John

> -----Original Message-----
> From: Sriganesh Kini [mailto:[email-masked]]
> Sent: Monday, September 23, 2013 11:02 AM
> To: Robert Raszuk
> Cc: John E Drake; [email-masked]; [email-masked]
> Subject: Re: [Status] Chartering next steps
>=20
> Robert,
>=20
> MPLS has defined "strict", "loose" and combinations of those in the conte=
xt
> of "explicit-routes". SPRING should be able to re-use/re-define it as
> necessary.
>=20
> Interpreting "explicit-route" as "hop-by-hop" seems like a stretch.
>=20
> I don't see a strong reason for yet another term "defined path".
>=20
> -- Sri
>=20
>=20
>=20
>=20
>=20
>=20
> On 9/23/13 10:50 AM, "Robert Raszuk" <[email-masked]> wrote:
>=20
> >The observation is that SR may not require explicit-route in all
> >scenarios. I can see cases of loose-routes yet based on segment based
> >routing paradigm.
> >
> >Besides explicit route may be interpreted as hop-by-hop path which is
> >clearly not the case.
> >
> >I would recommend to s/explicit route/defined path/
> >
> >r.
> >
> >
> >
> >On Mon, Sep 23, 2013 at 7:44 PM, Sriganesh Kini
> ><[email-masked]> wrote:
> >> From RFC 3031, sec 3.21
> >>
> >>    Explicit routing may be useful for a number of purposes, such as
> >>    policy routing or traffic engineering.  In MPLS, the explicit route
> >>    needs to be specified at the time that labels are assigned, but the
> >>    explicit route does not have to be specified with each IP packet.
> >>    This makes MPLS explicit routing much more efficient than the
> >>    alternative of IP source routing.
> >>
> >>
> >> If the "explicit-route" in SPRING is the same as explicit-route in
> >>RFC3031
> >> then we are ruling out source-routing ! IMO we should call it
> >>explicit-route  but re-define it for SPRING. The definition could be
> >>"a set of identifiers  in the packet that allow it to be steered
> >>through the network without having  per flow information at each
> >>intermediate node". However this re-definition  need not be in the
> >>charter but could go in another document (architecture  document).
> >>
> >> - Sri
> >>
> >>
> >>
> >> On Mon, Sep 23, 2013 at 8:01 AM, John E Drake <[email-masked]>
> >>wrote:
> >>>
> >>> Stewart,
> >>>
> >>>
> >>>
> >>> Upon reflection, I spoke too soon.  The use of the term =8Cexplicit
> >>>route=B9  as suggested by Lou and myself is fine, but the sentence you
> >>>added:
> >>>
> >>>
> >>>
> >>> =B3Steering is achieved by specifying in the packet an ordered set of
> >>>nodes  and/or links and/or shortest-path-next-hops to be traversed by
> >>>the packet.=B2
> >>>
> >>>
> >>>
> >>> has issues.  A packet *will not* have contain an ordered set of
> >>>nodes  and/or links and/or shortest-path-next-hops to be traversed by
> >>>the packet,  rather it will have a set of identifiers specifying
> >>>resources within a  SPRING region, and these specified resources *are
> >>>not* limited to =B3nodes  and/or links and/or shortest-path-next-hops=
=B2;
> >>>they may also include, for  example, forwarding adjacencies and
> >>>services.
> >>>
> >>>
> >>>
> >>> I suggest that we strike the sentence.  As Stefano points out, a
> >>>charter  is not a design specification.
> >>>
> >>>
> >>>
> >>> Yours Irrespectively,
> >>>
> >>>
> >>>
> >>> John
> >>>
> >>>
> >>>
> >>> From: [email-masked] [mailto:[email-masked]] On
> >>>Behalf  Of Stewart Bryant
> >>> Sent: Monday, September 23, 2013 6:13 AM
> >>> To: [email-masked]
> >>>
> >>>
> >>> Subject: Re: [Status] Chartering next steps
> >>>
> >>>
> >>>
> >>> I have included the proposed changes and some text that
> >>>
> >>>
> >>> clarifies the link-node discussion.
> >>>
> >>> The current charter text is at
> >>>
> >>> https://datatracker.ietf.org/doc/charter-ietf-spring/
> >>>
> >>> The diffs are at
> >>>
> >>>
> >>>
> >>>https://www.ietf.org/rfcdiff?url1=3Dhttps%3A%2F%2Fdatatracker.ietf.org
> %
> >>>2Fd
> >>>oc%2Fcharter-ietf-spring%2Fwithmilestones-00-00.txt&difftype=3D--
> html&s
> >>>ubm
> >>>it=3DGo!&url2=3Dhttps%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fcharter-
> ietf-s
> >>>pri
> >>>ng%2Fwithmilestones-00-01.txt
> >>>
> >>> or if you prefer:
> >>>
> >>> http://tinyurl.com/o24a9lz
> >>>
> >>> The link node text I added was
> >>>
> >>> "Steering is achieved by specifying in the packet an ordered set of
> >>> nodes and/or links and/or shortest-path-next-hops to be traversed by
> >>> the packet."
> >>>
> >>> - Stewart
> >>>
> >>>
> >>> _______________________________________________
> >>> status mailing list
> >>> [email-masked]
> >>> https://www.ietf.org/mailman/listinfo/status
> >>>
> >>
> >>
> >> _______________________________________________
> >> status mailing list
> >> [email-masked]
> >> https://www.ietf.org/mailman/listinfo/status
> >>
>=20
>=20

From: Jeff Tantsura <[email-masked]>
To: Robert Raszuk <[email-masked]>
Date: Mon, 23 Sep 2013 18:28:38 +0000
Accept-Language: en-US
Cc: John E Drake <[email-masked]>, "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>, Sriganesh Kini <[email-masked]>
Subject: Re: [Status] Chartering next steps

Sender: [email-masked]
Date: Mon, 23 Sep 2013 20:08:45 +0200
From: Robert Raszuk <[email-masked]>
To: Jeff Tantsura <[email-masked]>
Cc: John E Drake <[email-masked]>, "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>, Sriganesh Kini <[email-masked]>
Subject: Re: [Status] Chartering next steps

Hi Jeff,

If I want to use SPRING to get rid of LDP between my ingress and
egress PEs what is my "explicit-route" in that case ?

r.

On Mon, Sep 23, 2013 at 8:05 PM, Jeff Tantsura
<[email-masked]> wrote:
> Agree with Sri.
> Strict and loose explicit routes define pretty well what SPRING does
>
> Cheers,
> Jeff
>
>
>
>
> -----Original Message-----
> From: Sriganesh Kini <[email-masked]>
> Date: Monday, September 23, 2013 11:02 AM
> To: "[email-masked]" <[email-masked]>
> Cc: John Drake <[email-masked]>, "[email-masked]" <[email-masked]>,
> "[email-masked]" <[email-masked]>
> Subject: Re: [Status] Chartering next steps
>
>>Robert,
>>
>>MPLS has defined "strict", "loose" and combinations of those in the
>>context of "explicit-routes". SPRING should be able to re-use/re-define i=
t
>>as necessary.
>>
>>Interpreting "explicit-route" as "hop-by-hop" seems like a stretch.
>>
>>I don't see a strong reason for yet another term "defined path".
>>
>>-- Sri
>>
>>
>>
>>
>>
>>
>>On 9/23/13 10:50 AM, "Robert Raszuk" <[email-masked]> wrote:
>>
>>>The observation is that SR may not require explicit-route in all
>>>scenarios. I can see cases of loose-routes yet based on segment based
>>>routing paradigm.
>>>
>>>Besides explicit route may be interpreted as hop-by-hop path which is
>>>clearly not the case.
>>>
>>>I would recommend to s/explicit route/defined path/
>>>
>>>r.
>>>
>>>
>>>
>>>On Mon, Sep 23, 2013 at 7:44 PM, Sriganesh Kini
>>><[email-masked]> wrote:
>>>> From RFC 3031, sec 3.21
>>>>
>>>>    Explicit routing may be useful for a number of purposes, such as
>>>>    policy routing or traffic engineering.  In MPLS, the explicit route
>>>>    needs to be specified at the time that labels are assigned, but the
>>>>    explicit route does not have to be specified with each IP packet.
>>>>    This makes MPLS explicit routing much more efficient than the
>>>>    alternative of IP source routing.
>>>>
>>>>
>>>> If the "explicit-route" in SPRING is the same as explicit-route in
>>>>RFC3031
>>>> then we are ruling out source-routing ! IMO we should call it
>>>>explicit-route
>>>> but re-define it for SPRING. The definition could be "a set of
>>>>identifiers
>>>> in the packet that allow it to be steered through the network without
>>>>having
>>>> per flow information at each intermediate node". However this
>>>>re-definition
>>>> need not be in the charter but could go in another document
>>>>(architecture
>>>> document).
>>>>
>>>> - Sri
>>>>
>>>>
>>>>
>>>> On Mon, Sep 23, 2013 at 8:01 AM, John E Drake <[email-masked]>
>>>>wrote:
>>>>>
>>>>> Stewart,
>>>>>
>>>>>
>>>>>
>>>>> Upon reflection, I spoke too soon.  The use of the term =8Cexplicit
>>>>>route=B9
>>>>> as suggested by Lou and myself is fine, but the sentence you added:
>>>>>
>>>>>
>>>>>
>>>>> =B3Steering is achieved by specifying in the packet an ordered set of
>>>>>nodes
>>>>> and/or links and/or shortest-path-next-hops to be traversed by the
>>>>>packet.=B2
>>>>>
>>>>>
>>>>>
>>>>> has issues.  A packet *will not* have contain an ordered set of nodes
>>>>> and/or links and/or shortest-path-next-hops to be traversed by the
>>>>>packet,
>>>>> rather it will have a set of identifiers specifying resources within =
a
>>>>> SPRING region, and these specified resources *are not* limited to
>>>>>=B3nodes
>>>>> and/or links and/or shortest-path-next-hops=B2; they may also include=
,
>>>>>for
>>>>> example, forwarding adjacencies and services.
>>>>>
>>>>>
>>>>>
>>>>> I suggest that we strike the sentence.  As Stefano points out, a
>>>>>charter
>>>>> is not a design specification.
>>>>>
>>>>>
>>>>>
>>>>> Yours Irrespectively,
>>>>>
>>>>>
>>>>>
>>>>> John
>>>>>
>>>>>
>>>>>
>>>>> From: [email-masked] [mailto:[email-masked]] On
>>>>>Behalf
>>>>> Of Stewart Bryant
>>>>> Sent: Monday, September 23, 2013 6:13 AM
>>>>> To: [email-masked]
>>>>>
>>>>>
>>>>> Subject: Re: [Status] Chartering next steps
>>>>>
>>>>>
>>>>>
>>>>> I have included the proposed changes and some text that
>>>>>
>>>>>
>>>>> clarifies the link-node discussion.
>>>>>
>>>>> The current charter text is at
>>>>>
>>>>> https://datatracker.ietf.org/doc/charter-ietf-spring/
>>>>>
>>>>> The diffs are at
>>>>>
>>>>>
>>>>>
>>>>>https://www.ietf.org/rfcdiff?url1=3Dhttps%3A%2F%2Fdatatracker.ietf.org=
%2F
>>>>>d
>>>>>oc%2Fcharter-ietf-spring%2Fwithmilestones-00-00.txt&difftype=3D--html&=
sub
>>>>>m
>>>>>it=3DGo!&url2=3Dhttps%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fcharter-iet=
f-spr
>>>>>i
>>>>>ng%2Fwithmilestones-00-01.txt
>>>>>
>>>>> or if you prefer:
>>>>>
>>>>> http://tinyurl.com/o24a9lz
>>>>>
>>>>> The link node text I added was
>>>>>
>>>>> "Steering is achieved by specifying in the packet an ordered
>>>>> set of nodes and/or links and/or shortest-path-next-hops
>>>>> to be traversed by the packet."
>>>>>
>>>>> - Stewart
>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> status mailing list
>>>>> [email-masked]
>>>>> https://www.ietf.org/mailman/listinfo/status
>>>>>
>>>>
>>>>
>>>> _______________________________________________
>>>> status mailing list
>>>> [email-masked]
>>>> https://www.ietf.org/mailman/listinfo/status
>>>>
>>
>>_______________________________________________
>>status mailing list
>>[email-masked]
>>https://www.ietf.org/mailman/listinfo/status
>

Date: Mon, 23 Sep 2013 14:07:43 -0400
From: Lou Berger <[email-masked]>
To: Robert Raszuk <[email-masked]>,  Sriganesh Kini <[email-masked]>
Cc: John E Drake <[email-masked]>, "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>
Subject: Re: [Status] Chartering next steps

Right. And RFC3031 isn't listed in the charter.

So I agree with Sri.

Lou

On 09/23/2013 02:04 PM, Robert Raszuk wrote:
> But SPRING is not only about MPLS encapsulation ..
> 
> r.
> 
> On Mon, Sep 23, 2013 at 8:02 PM, Sriganesh Kini
> <[email-masked]> wrote:
>> Robert,
>>
>> MPLS has defined "strict", "loose" and combinations of those in the
>> context of "explicit-routes". SPRING should be able to re-use/re-define it
>> as necessary.
>>
>> Interpreting "explicit-route" as "hop-by-hop" seems like a stretch.
>>
>> I don't see a strong reason for yet another term "defined path".
>>
>> -- Sri
>>
>>
>>
>>
>>
>>
>> On 9/23/13 10:50 AM, "Robert Raszuk" <[email-masked]> wrote:
>>
>>> The observation is that SR may not require explicit-route in all
>>> scenarios. I can see cases of loose-routes yet based on segment based
>>> routing paradigm.
>>>
>>> Besides explicit route may be interpreted as hop-by-hop path which is
>>> clearly not the case.
>>>
>>> I would recommend to s/explicit route/defined path/
>>>
>>> r.
>>>
>>>
>>>
>>> On Mon, Sep 23, 2013 at 7:44 PM, Sriganesh Kini
>>> <[email-masked]> wrote:
>>>> From RFC 3031, sec 3.21
>>>>
>>>>    Explicit routing may be useful for a number of purposes, such as
>>>>    policy routing or traffic engineering.  In MPLS, the explicit route
>>>>    needs to be specified at the time that labels are assigned, but the
>>>>    explicit route does not have to be specified with each IP packet.
>>>>    This makes MPLS explicit routing much more efficient than the
>>>>    alternative of IP source routing.
>>>>
>>>>
>>>> If the "explicit-route" in SPRING is the same as explicit-route in
>>>> RFC3031
>>>> then we are ruling out source-routing ! IMO we should call it
>>>> explicit-route
>>>> but re-define it for SPRING. The definition could be "a set of
>>>> identifiers
>>>> in the packet that allow it to be steered through the network without
>>>> having
>>>> per flow information at each intermediate node". However this
>>>> re-definition
>>>> need not be in the charter but could go in another document
>>>> (architecture
>>>> document).
>>>>
>>>> - Sri
>>>>
>>>>
>>>>
>>>> On Mon, Sep 23, 2013 at 8:01 AM, John E Drake <[email-masked]>
>>>> wrote:
>>>>>
>>>>> Stewart,
>>>>>
>>>>>
>>>>>
>>>>> Upon reflection, I spoke too soon.  The use of the term Œexplicit
>>>>> route¹
>>>>> as suggested by Lou and myself is fine, but the sentence you added:
>>>>>
>>>>>
>>>>>
>>>>> ³Steering is achieved by specifying in the packet an ordered set of
>>>>> nodes
>>>>> and/or links and/or shortest-path-next-hops to be traversed by the
>>>>> packet.²
>>>>>
>>>>>
>>>>>
>>>>> has issues.  A packet *will not* have contain an ordered set of nodes
>>>>> and/or links and/or shortest-path-next-hops to be traversed by the
>>>>> packet,
>>>>> rather it will have a set of identifiers specifying resources within a
>>>>> SPRING region, and these specified resources *are not* limited to
>>>>> ³nodes
>>>>> and/or links and/or shortest-path-next-hops²; they may also include,
>>>>> for
>>>>> example, forwarding adjacencies and services.
>>>>>
>>>>>
>>>>>
>>>>> I suggest that we strike the sentence.  As Stefano points out, a
>>>>> charter
>>>>> is not a design specification.
>>>>>
>>>>>
>>>>>
>>>>> Yours Irrespectively,
>>>>>
>>>>>
>>>>>
>>>>> John
>>>>>
>>>>>
>>>>>
>>>>> From: [email-masked] [mailto:[email-masked]] On
>>>>> Behalf
>>>>> Of Stewart Bryant
>>>>> Sent: Monday, September 23, 2013 6:13 AM
>>>>> To: [email-masked]
>>>>>
>>>>>
>>>>> Subject: Re: [Status] Chartering next steps
>>>>>
>>>>>
>>>>>
>>>>> I have included the proposed changes and some text that
>>>>>
>>>>>
>>>>> clarifies the link-node discussion.
>>>>>
>>>>> The current charter text is at
>>>>>
>>>>> https://datatracker.ietf.org/doc/charter-ietf-spring/
>>>>>
>>>>> The diffs are at
>>>>>
>>>>>
>>>>>
>>>>> https://www.ietf.org/rfcdiff?url1=https%3A%2F%2Fdatatracker.ietf.org%2Fd
>>>>> oc%2Fcharter-ietf-spring%2Fwithmilestones-00-00.txt&difftype=--html&subm
>>>>> it=Go!&url2=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fcharter-ietf-spri
>>>>> ng%2Fwithmilestones-00-01.txt
>>>>>
>>>>> or if you prefer:
>>>>>
>>>>> http://tinyurl.com/o24a9lz
>>>>>
>>>>> The link node text I added was
>>>>>
>>>>> "Steering is achieved by specifying in the packet an ordered
>>>>> set of nodes and/or links and/or shortest-path-next-hops
>>>>> to be traversed by the packet."
>>>>>
>>>>> - Stewart
>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> status mailing list
>>>>> [email-masked]
>>>>> https://www.ietf.org/mailman/listinfo/status
>>>>>
>>>>
>>>>
>>>> _______________________________________________
>>>> status mailing list
>>>> [email-masked]
>>>> https://www.ietf.org/mailman/listinfo/status
>>>>
>>
> _______________________________________________
> status mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/status
> 

From: Jeff Tantsura <[email-masked]>
To: Sriganesh Kini <[email-masked]>, Robert Raszuk <[email-masked]>
Date: Mon, 23 Sep 2013 18:05:24 +0000
Accept-Language: en-US
Cc: John E Drake <[email-masked]>, "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>
Subject: Re: [Status] Chartering next steps

Sender: [email-masked]
Date: Mon, 23 Sep 2013 20:04:37 +0200
From: Robert Raszuk <[email-masked]>
To: Sriganesh Kini <[email-masked]>
Cc: John E Drake <[email-masked]>, "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>
Subject: Re: [Status] Chartering next steps

But SPRING is not only about MPLS encapsulation ..

r.

On Mon, Sep 23, 2013 at 8:02 PM, Sriganesh Kini
<[email-masked]> wrote:
> Robert,
>
> MPLS has defined "strict", "loose" and combinations of those in the
> context of "explicit-routes". SPRING should be able to re-use/re-define i=
t
> as necessary.
>
> Interpreting "explicit-route" as "hop-by-hop" seems like a stretch.
>
> I don't see a strong reason for yet another term "defined path".
>
> -- Sri
>
>
>
>
>
>
> On 9/23/13 10:50 AM, "Robert Raszuk" <[email-masked]> wrote:
>
>>The observation is that SR may not require explicit-route in all
>>scenarios. I can see cases of loose-routes yet based on segment based
>>routing paradigm.
>>
>>Besides explicit route may be interpreted as hop-by-hop path which is
>>clearly not the case.
>>
>>I would recommend to s/explicit route/defined path/
>>
>>r.
>>
>>
>>
>>On Mon, Sep 23, 2013 at 7:44 PM, Sriganesh Kini
>><[email-masked]> wrote:
>>> From RFC 3031, sec 3.21
>>>
>>>    Explicit routing may be useful for a number of purposes, such as
>>>    policy routing or traffic engineering.  In MPLS, the explicit route
>>>    needs to be specified at the time that labels are assigned, but the
>>>    explicit route does not have to be specified with each IP packet.
>>>    This makes MPLS explicit routing much more efficient than the
>>>    alternative of IP source routing.
>>>
>>>
>>> If the "explicit-route" in SPRING is the same as explicit-route in
>>>RFC3031
>>> then we are ruling out source-routing ! IMO we should call it
>>>explicit-route
>>> but re-define it for SPRING. The definition could be "a set of
>>>identifiers
>>> in the packet that allow it to be steered through the network without
>>>having
>>> per flow information at each intermediate node". However this
>>>re-definition
>>> need not be in the charter but could go in another document
>>>(architecture
>>> document).
>>>
>>> - Sri
>>>
>>>
>>>
>>> On Mon, Sep 23, 2013 at 8:01 AM, John E Drake <[email-masked]>
>>>wrote:
>>>>
>>>> Stewart,
>>>>
>>>>
>>>>
>>>> Upon reflection, I spoke too soon.  The use of the term =8Cexplicit
>>>>route=B9
>>>> as suggested by Lou and myself is fine, but the sentence you added:
>>>>
>>>>
>>>>
>>>> =B3Steering is achieved by specifying in the packet an ordered set of
>>>>nodes
>>>> and/or links and/or shortest-path-next-hops to be traversed by the
>>>>packet.=B2
>>>>
>>>>
>>>>
>>>> has issues.  A packet *will not* have contain an ordered set of nodes
>>>> and/or links and/or shortest-path-next-hops to be traversed by the
>>>>packet,
>>>> rather it will have a set of identifiers specifying resources within a
>>>> SPRING region, and these specified resources *are not* limited to
>>>>=B3nodes
>>>> and/or links and/or shortest-path-next-hops=B2; they may also include,
>>>>for
>>>> example, forwarding adjacencies and services.
>>>>
>>>>
>>>>
>>>> I suggest that we strike the sentence.  As Stefano points out, a
>>>>charter
>>>> is not a design specification.
>>>>
>>>>
>>>>
>>>> Yours Irrespectively,
>>>>
>>>>
>>>>
>>>> John
>>>>
>>>>
>>>>
>>>> From: [email-masked] [mailto:[email-masked]] On
>>>>Behalf
>>>> Of Stewart Bryant
>>>> Sent: Monday, September 23, 2013 6:13 AM
>>>> To: [email-masked]
>>>>
>>>>
>>>> Subject: Re: [Status] Chartering next steps
>>>>
>>>>
>>>>
>>>> I have included the proposed changes and some text that
>>>>
>>>>
>>>> clarifies the link-node discussion.
>>>>
>>>> The current charter text is at
>>>>
>>>> https://datatracker.ietf.org/doc/charter-ietf-spring/
>>>>
>>>> The diffs are at
>>>>
>>>>
>>>>
>>>>https://www.ietf.org/rfcdiff?url1=3Dhttps%3A%2F%2Fdatatracker.ietf.org%=
2Fd
>>>>oc%2Fcharter-ietf-spring%2Fwithmilestones-00-00.txt&difftype=3D--html&s=
ubm
>>>>it=3DGo!&url2=3Dhttps%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fcharter-ietf=
-spri
>>>>ng%2Fwithmilestones-00-01.txt
>>>>
>>>> or if you prefer:
>>>>
>>>> http://tinyurl.com/o24a9lz
>>>>
>>>> The link node text I added was
>>>>
>>>> "Steering is achieved by specifying in the packet an ordered
>>>> set of nodes and/or links and/or shortest-path-next-hops
>>>> to be traversed by the packet."
>>>>
>>>> - Stewart
>>>>
>>>>
>>>> _______________________________________________
>>>> status mailing list
>>>> [email-masked]
>>>> https://www.ietf.org/mailman/listinfo/status
>>>>
>>>
>>>
>>> _______________________________________________
>>> status mailing list
>>> [email-masked]
>>> https://www.ietf.org/mailman/listinfo/status
>>>
>

From: Sriganesh Kini <[email-masked]>
To: Robert Raszuk <[email-masked]>
Date: Mon, 23 Sep 2013 18:02:19 +0000
Accept-Language: en-US
Cc: John E Drake <[email-masked]>, "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>
Subject: Re: [Status] Chartering next steps

Robert,

MPLS has defined "strict", "loose" and combinations of those in the
context of "explicit-routes". SPRING should be able to re-use/re-define it
as necessary.

Interpreting "explicit-route" as "hop-by-hop" seems like a stretch.

I don't see a strong reason for yet another term "defined path".

-- Sri

On 9/23/13 10:50 AM, "Robert Raszuk" <[email-masked]> wrote:

>The observation is that SR may not require explicit-route in all
>scenarios. I can see cases of loose-routes yet based on segment based
>routing paradigm.
>
>Besides explicit route may be interpreted as hop-by-hop path which is
>clearly not the case.
>
>I would recommend to s/explicit route/defined path/
>
>r.
>
>
>
>On Mon, Sep 23, 2013 at 7:44 PM, Sriganesh Kini
><[email-masked]> wrote:
>> From RFC 3031, sec 3.21
>>
>>    Explicit routing may be useful for a number of purposes, such as
>>    policy routing or traffic engineering.  In MPLS, the explicit route
>>    needs to be specified at the time that labels are assigned, but the
>>    explicit route does not have to be specified with each IP packet.
>>    This makes MPLS explicit routing much more efficient than the
>>    alternative of IP source routing.
>>
>>
>> If the "explicit-route" in SPRING is the same as explicit-route in
>>RFC3031
>> then we are ruling out source-routing ! IMO we should call it
>>explicit-route
>> but re-define it for SPRING. The definition could be "a set of
>>identifiers
>> in the packet that allow it to be steered through the network without
>>having
>> per flow information at each intermediate node". However this
>>re-definition
>> need not be in the charter but could go in another document
>>(architecture
>> document).
>>
>> - Sri
>>
>>
>>
>> On Mon, Sep 23, 2013 at 8:01 AM, John E Drake <[email-masked]>
>>wrote:
>>>
>>> Stewart,
>>>
>>>
>>>
>>> Upon reflection, I spoke too soon.  The use of the term =8Cexplicit
>>>route=B9
>>> as suggested by Lou and myself is fine, but the sentence you added:
>>>
>>>
>>>
>>> =B3Steering is achieved by specifying in the packet an ordered set of
>>>nodes
>>> and/or links and/or shortest-path-next-hops to be traversed by the
>>>packet.=B2
>>>
>>>
>>>
>>> has issues.  A packet *will not* have contain an ordered set of nodes
>>> and/or links and/or shortest-path-next-hops to be traversed by the
>>>packet,
>>> rather it will have a set of identifiers specifying resources within a
>>> SPRING region, and these specified resources *are not* limited to
>>>=B3nodes
>>> and/or links and/or shortest-path-next-hops=B2; they may also include,
>>>for
>>> example, forwarding adjacencies and services.
>>>
>>>
>>>
>>> I suggest that we strike the sentence.  As Stefano points out, a
>>>charter
>>> is not a design specification.
>>>
>>>
>>>
>>> Yours Irrespectively,
>>>
>>>
>>>
>>> John
>>>
>>>
>>>
>>> From: [email-masked] [mailto:[email-masked]] On
>>>Behalf
>>> Of Stewart Bryant
>>> Sent: Monday, September 23, 2013 6:13 AM
>>> To: [email-masked]
>>>
>>>
>>> Subject: Re: [Status] Chartering next steps
>>>
>>>
>>>
>>> I have included the proposed changes and some text that
>>>
>>>
>>> clarifies the link-node discussion.
>>>
>>> The current charter text is at
>>>
>>> https://datatracker.ietf.org/doc/charter-ietf-spring/
>>>
>>> The diffs are at
>>>
>>>
>>>=20
>>>https://www.ietf.org/rfcdiff?url1=3Dhttps%3A%2F%2Fdatatracker.ietf.org%2=
Fd
>>>oc%2Fcharter-ietf-spring%2Fwithmilestones-00-00.txt&difftype=3D--html&su=
bm
>>>it=3DGo!&url2=3Dhttps%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fcharter-ietf-=
spri
>>>ng%2Fwithmilestones-00-01.txt
>>>
>>> or if you prefer:
>>>
>>> http://tinyurl.com/o24a9lz
>>>
>>> The link node text I added was
>>>
>>> "Steering is achieved by specifying in the packet an ordered
>>> set of nodes and/or links and/or shortest-path-next-hops
>>> to be traversed by the packet."
>>>
>>> - Stewart
>>>
>>>
>>> _______________________________________________
>>> status mailing list
>>> [email-masked]
>>> https://www.ietf.org/mailman/listinfo/status
>>>
>>
>>
>> _______________________________________________
>> status mailing list
>> [email-masked]
>> https://www.ietf.org/mailman/listinfo/status
>>

Sender: [email-masked]
Date: Mon, 23 Sep 2013 19:50:22 +0200
From: Robert Raszuk <[email-masked]>
To: Sriganesh Kini <[email-masked]>
Cc: John E Drake <[email-masked]>, "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>
Subject: Re: [Status] Chartering next steps

The observation is that SR may not require explicit-route in all
scenarios. I can see cases of loose-routes yet based on segment based
routing paradigm.

Besides explicit route may be interpreted as hop-by-hop path which is
clearly not the case.

I would recommend to s/explicit route/defined path/

r.

On Mon, Sep 23, 2013 at 7:44 PM, Sriganesh Kini
<[email-masked]> wrote:
> From RFC 3031, sec 3.21
>
>    Explicit routing may be useful for a number of purposes, such as
>    policy routing or traffic engineering.  In MPLS, the explicit route
>    needs to be specified at the time that labels are assigned, but the
>    explicit route does not have to be specified with each IP packet.
>    This makes MPLS explicit routing much more efficient than the
>    alternative of IP source routing.
>
>
> If the "explicit-route" in SPRING is the same as explicit-route in RFC303=
1
> then we are ruling out source-routing ! IMO we should call it explicit-ro=
ute
> but re-define it for SPRING. The definition could be "a set of identifier=
s
> in the packet that allow it to be steered through the network without hav=
ing
> per flow information at each intermediate node". However this re-definiti=
on
> need not be in the charter but could go in another document (architecture
> document).
>
> - Sri
>
>
>
> On Mon, Sep 23, 2013 at 8:01 AM, John E Drake <[email-masked]> wrote:
>>
>> Stewart,
>>
>>
>>
>> Upon reflection, I spoke too soon.  The use of the term =91explicit rout=
e=92
>> as suggested by Lou and myself is fine, but the sentence you added:
>>
>>
>>
>> =93Steering is achieved by specifying in the packet an ordered set of no=
des
>> and/or links and/or shortest-path-next-hops to be traversed by the packe=
t.=94
>>
>>
>>
>> has issues.  A packet *will not* have contain an ordered set of nodes
>> and/or links and/or shortest-path-next-hops to be traversed by the packe=
t,
>> rather it will have a set of identifiers specifying resources within a
>> SPRING region, and these specified resources *are not* limited to =93nod=
es
>> and/or links and/or shortest-path-next-hops=94; they may also include, f=
or
>> example, forwarding adjacencies and services.
>>
>>
>>
>> I suggest that we strike the sentence.  As Stefano points out, a charter
>> is not a design specification.
>>
>>
>>
>> Yours Irrespectively,
>>
>>
>>
>> John
>>
>>
>>
>> From: [email-masked] [mailto:[email-masked]] On Behalf
>> Of Stewart Bryant
>> Sent: Monday, September 23, 2013 6:13 AM
>> To: [email-masked]
>>
>>
>> Subject: Re: [Status] Chartering next steps
>>
>>
>>
>> I have included the proposed changes and some text that
>>
>>
>> clarifies the link-node discussion.
>>
>> The current charter text is at
>>
>> https://datatracker.ietf.org/doc/charter-ietf-spring/
>>
>> The diffs are at
>>
>>
>> https://www.ietf.org/rfcdiff?url1=3Dhttps%3A%2F%2Fdatatracker.ietf.org%2=
Fdoc%2Fcharter-ietf-spring%2Fwithmilestones-00-00.txt&difftype=3D--html&sub=
mit=3DGo!&url2=3Dhttps%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fcharter-ietf-sp=
ring%2Fwithmilestones-00-01.txt
>>
>> or if you prefer:
>>
>> http://tinyurl.com/o24a9lz
>>
>> The link node text I added was
>>
>> "Steering is achieved by specifying in the packet an ordered
>> set of nodes and/or links and/or shortest-path-next-hops
>> to be traversed by the packet."
>>
>> - Stewart
>>
>>
>> _______________________________________________
>> status mailing list
>> [email-masked]
>> https://www.ietf.org/mailman/listinfo/status
>>
>
>
> _______________________________________________
> status mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/status
>

Sender: [email-masked]
From: Sriganesh Kini <[email-masked]>
Date: Mon, 23 Sep 2013 10:44:03 -0700
To: John E Drake <[email-masked]>
Cc: "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>
Subject: Re: [Status] Chartering next steps

--047d7b111f3fabe2c304e71092ec
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

>From RFC 3031, sec 3.21

   Explicit routing may be useful for a number of purposes, such as
   policy routing or traffic engineering.  In MPLS, the explicit route
   needs to be specified at the time that labels are assigned, but the
   explicit route does not have to be specified with each IP packet.
   This makes MPLS explicit routing much more efficient than the
   alternative of IP source routing.

If the "explicit-route" in SPRING is the same as explicit-route in RFC3031
then we are ruling out source-routing ! IMO we should call it
explicit-route but re-define it for SPRING. The definition could be "a set
of identifiers in the packet that allow it to be steered through the
network without having per flow information at each intermediate node".
However this re-definition need not be in the charter but could go in
another document (architecture document).

- Sri

On Mon, Sep 23, 2013 at 8:01 AM, John E Drake <[email-masked]> wrote:

>  Stewart,****
>
> ** **
>
> Upon reflection, I spoke too soon.  The use of the term =E2=80=98explicit=
 route=E2=80=99
> as suggested by Lou and myself is fine, but the sentence you added:****
>
> ** **
>
> =E2=80=9CSteering is achieved by specifying in the packet an ordered set =
of nodes
> and/or links and/or shortest-path-next-hops to be traversed by the packet=
.=E2=80=9D
> ****
>
> ** **
>
> has issues.  A packet **will not** have contain an ordered set of nodes
> and/or links and/or shortest-path-next-hops to be traversed by the packet=
,
> rather it will have a set of identifiers specifying resources within a
> SPRING region, and these specified resources **are not** limited to
> =E2=80=9Cnodes and/or links and/or shortest-path-next-hops=E2=80=9D; they=
 may also include,
> for example, forwarding adjacencies and services.****
>
> ** **
>
> I suggest that we strike the sentence.  As Stefano points out, a charter
> is not a design specification. ****
>
> ** **
>
> Yours Irrespectively,****
>
> ** **
>
> John****
>
> ** **
>
> *From:* [email-masked] [mailto:[email-masked]] *On
> Behalf Of *Stewart Bryant
> *Sent:* Monday, September 23, 2013 6:13 AM
> *To:* [email-masked]
>
> *Subject:* Re: [Status] Chartering next steps****
>
>  ** **
>
> I have included the proposed changes and some text that
>
> clarifies the link-node discussion.
>
> The current charter text is at
>
> https://datatracker.ietf.org/doc/charter-ietf-spring/
>
> The diffs are at
>
>
> https://www.ietf.org/rfcdiff?url1=3Dhttps%3A%2F%2Fdatatracker.ietf.org%2F=
doc%2Fcharter-ietf-spring%2Fwithmilestones-00-00.txt&difftype=3D--html&subm=
it=3DGo!&url2=3Dhttps%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fcharter-ietf-spr=
ing%2Fwithmilestones-00-01.txt
>
> or if you prefer:
>
> *http://tinyurl.com/o24a9lz*
>
> The link node text I added was
>
> "Steering is achieved by specifying in the packet an ordered
> set of nodes and/or links and/or shortest-path-next-hops
> to be traversed by the packet."
>
> - Stewart****
>
>
> _______________________________________________
> status mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/status
>
>

--047d7b111f3fabe2c304e71092ec
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">From RFC 3031, sec 3.21<div><br></div><div><pre class=3D""=
 style=3D"font-size:1em;margin-top:0px;margin-bottom:0px;color:rgb(0,0,0)">=
   Explicit routing may be useful for a number of purposes, such as
   policy routing or traffic engineering.  In MPLS, the explicit route
   needs to be specified at the time that labels are assigned, but the
   explicit route does not have to be specified with each IP packet.
   This makes MPLS explicit routing much more efficient than the
   alternative of IP source routing.</pre></div><div><br></div><div>If the =
&quot;explicit-route&quot; in SPRING is the same as explicit-route in RFC30=
31 then we are ruling out source-routing ! IMO we should call it explicit-r=
oute but re-define it for SPRING. The definition could be &quot;a set of id=
entifiers in the packet that allow it to be steered through the network wit=
hout having per flow information at each intermediate node&quot;. However t=
his re-definition need not be in the charter but could go in another docume=
nt (architecture document).</div>

<div><br></div><div>- Sri</div><div>=C2=A0</div><div class=3D"gmail_extra">=
<br><br><div class=3D"gmail_quote">On Mon, Sep 23, 2013 at 8:01 AM, John E =
Drake <span dir=3D"ltr">&lt;<a href=3D"mailto:[email-masked]" target=3D=
"_blank">[email-masked]</a>&gt;</span> wrote:<br>

<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex">

<div bgcolor=3D"white" lang=3D"EN-US" link=3D"blue" vlink=3D"purple">
<div>
<p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=
libri&quot;,&quot;sans-serif&quot;;color:#1f497d">Stewart,<u></u><u></u></s=
pan></p>
<p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=
libri&quot;,&quot;sans-serif&quot;;color:#1f497d"><u></u>=C2=A0<u></u></spa=
n></p>
<p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=
libri&quot;,&quot;sans-serif&quot;;color:#1f497d">Upon reflection, I spoke =
too soon.=C2=A0 The use of the term =E2=80=98explicit route=E2=80=99 as sug=
gested by Lou and myself is fine, but the sentence you added:<u></u><u></u>=
</span></p>

<p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=
libri&quot;,&quot;sans-serif&quot;;color:#1f497d"><u></u>=C2=A0<u></u></spa=
n></p>
<p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=
libri&quot;,&quot;sans-serif&quot;;color:#1f497d">=E2=80=9CSteering is achi=
eved by specifying in the packet an ordered set of nodes and/or links and/o=
r shortest-path-next-hops to be traversed by the packet.=E2=80=9D<u></u><u>=
</u></span></p>

<p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=
libri&quot;,&quot;sans-serif&quot;;color:#1f497d"><u></u>=C2=A0<u></u></spa=
n></p>
<p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=
libri&quot;,&quot;sans-serif&quot;;color:#1f497d">has issues.=C2=A0 A packe=
t *<b>will not</b>* have contain an ordered set of nodes and/or links and/o=
r shortest-path-next-hops to be traversed by the packet, rather
 it will have a set of identifiers specifying resources within a SPRING reg=
ion, and these specified resources *<b>are not</b>* limited to =E2=80=9Cnod=
es and/or links and/or shortest-path-next-hops=E2=80=9D; they may also incl=
ude, for example, forwarding adjacencies and services.<u></u><u></u></span>=
</p>

<p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=
libri&quot;,&quot;sans-serif&quot;;color:#1f497d"><u></u>=C2=A0<u></u></spa=
n></p>
<p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=
libri&quot;,&quot;sans-serif&quot;;color:#1f497d">I suggest that we strike =
the sentence.=C2=A0 As Stefano points out, a charter is not a design specif=
ication.
<u></u><u></u></span></p>
<p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=
libri&quot;,&quot;sans-serif&quot;;color:#1f497d"><u></u>=C2=A0<u></u></spa=
n></p>
<div>
<p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=
libri&quot;,&quot;sans-serif&quot;;color:#1f497d">Yours Irrespectively,<u><=
/u><u></u></span></p>
<p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=
libri&quot;,&quot;sans-serif&quot;;color:#1f497d"><u></u>=C2=A0<u></u></spa=
n></p>
<p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=
libri&quot;,&quot;sans-serif&quot;;color:#1f497d">John<u></u><u></u></span>=
</p>
</div>
<p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=
libri&quot;,&quot;sans-serif&quot;;color:#1f497d"><u></u>=C2=A0<u></u></spa=
n></p>
<div style=3D"border:none;border-left:solid blue 1.5pt;padding:0in 0in 0in =
4.0pt">
<div>
<div style=3D"border:none;border-top:solid #e1e1e1 1.0pt;padding:3.0pt 0in =
0in 0in">
<p class=3D"MsoNormal"><b><span style=3D"font-size:11.0pt;font-family:&quot=
;Calibri&quot;,&quot;sans-serif&quot;;color:windowtext">From:</span></b><sp=
an style=3D"font-size:11.0pt;font-family:&quot;Calibri&quot;,&quot;sans-ser=
if&quot;;color:windowtext"> <a href=3D"mailto:[email-masked]" targ=
et=3D"_blank">[email-masked]</a> [mailto:<a href=3D"mailto:status-=
[email-masked]" target=3D"_blank">[email-masked]</a>]
<b>On Behalf Of </b>Stewart Bryant<br>
<b>Sent:</b> Monday, September 23, 2013 6:13 AM<br>
<b>To:</b> <a href=3D"mailto:[email-masked]" target=3D"_blank">status@ietf=
.org</a></span></p><div class=3D"im"><br>
<b>Subject:</b> Re: [Status] Chartering next steps<u></u><u></u></div><p></=
p>
</div>
</div>
<p class=3D"MsoNormal"><u></u>=C2=A0<u></u></p>
<p class=3D"MsoNormal">I have included the proposed changes and some text t=
hat</p><div><div class=3D"h5"><br>
clarifies the link-node discussion.<br>
<br>
The current charter text is at <br>
<br>
<a href=3D"https://datatracker.ietf.org/doc/charter-ietf-spring/" target=3D=
"_blank">https://datatracker.ietf.org/doc/charter-ietf-spring/</a><br>
<br>
The diffs are at<br>
<br>
<a href=3D"https://www.ietf.org/rfcdiff?url1=3Dhttps%3A%2F%2Fdatatracker.ie=
tf.org%2Fdoc%2Fcharter-ietf-spring%2Fwithmilestones-00-00.txt&amp;difftype=
=3D--html&amp;submit=3DGo!&amp;url2=3Dhttps%3A%2F%2Fdatatracker.ietf.org%2F=
doc%2Fcharter-ietf-spring%2Fwithmilestones-00-01.txt" target=3D"_blank">htt=
ps://www.ietf.org/rfcdiff?url1=3Dhttps%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2=
Fcharter-ietf-spring%2Fwithmilestones-00-00.txt&amp;difftype=3D--html&amp;s=
ubmit=3DGo!&amp;url2=3Dhttps%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fcharter-i=
etf-spring%2Fwithmilestones-00-01.txt</a><br>

<br>
or if you prefer:<br>
<br>
<b><a href=3D"http://tinyurl.com/o24a9lz" target=3D"_blank">http://tinyurl.=
com/o24a9lz</a></b><br>
<br>
The link node text I added was <br>
<br>
&quot;Steering is achieved by specifying in the packet an ordered <br>
set of nodes and/or links and/or shortest-path-next-hops <br>
to be traversed by the packet.&quot;<br>
<br>
- Stewart<u></u><u></u></div></div><p></p>
</div>
</div>
</div>

<br>_______________________________________________<br>
status mailing list<br>
<a href=3D"mailto:[email-masked]">[email-masked]</a><br>
<a href=3D"https://www.ietf.org/mailman/listinfo/status" target=3D"_blank">=
https://www.ietf.org/mailman/listinfo/status</a><br>
<br></blockquote></div><br></div></div>

--047d7b111f3fabe2c304e71092ec--

From: John E Drake <[email-masked]>
To: "<[email-masked]>" <[email-masked]>
Date: Mon, 23 Sep 2013 17:43:31 +0000
Accept-Language: en-US
Cc: "[email-masked]" <[email-masked]>
Subject: Re: [Status] Chartering next steps

--_000_9831C1489C794648896A383E9B791BE7junipernet_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

Sent from my iPhone

On Sep 23, 2013, at 12:27 PM, "Stewart Bryant" <[email-masked]<mailto:s=
[email-masked]>> wrote:

Maybe I will take the sentence out, because there
is more to identifiers than next hops. For example,
a PW label, which we may find on the stack, is an
instruction (decap, munge and sent to an interface),
so the concern is that the text might be unnecessarily
constraining which would outweigh its utility as
tutorial material.

Stewart

On 23/09/2013 16:01, John E Drake wrote:
Stewart,

Upon reflection, I spoke too soon.  The use of the term 'explicit route' as=
 suggested by Lou and myself is fine, but the sentence you added:

"Steering is achieved by specifying in the packet an ordered set of nodes a=
nd/or links and/or shortest-path-next-hops to be traversed by the packet."

has issues.  A packet *will not* have contain an ordered set of nodes and/o=
r links and/or shortest-path-next-hops to be traversed by the packet, rathe=
r it will have a set of identifiers specifying resources within a SPRING re=
gion, and these specified resources *are not* limited to "nodes and/or link=
s and/or shortest-path-next-hops"; they may also include, for example, forw=
arding adjacencies and services.

I suggest that we strike the sentence.  As Stefano points out, a charter is=
 not a design specification.

Yours Irrespectively,

John

From: [email-masked]<mailto:[email-masked]> [mailto:statu=
[email-masked]] On Behalf Of Stewart Bryant
Sent: Monday, September 23, 2013 6:13 AM
To: [email-masked]<mailto:[email-masked]>
Subject: Re: [Status] Chartering next steps

I have included the proposed changes and some text that
clarifies the link-node discussion.

The current charter text is at

https://datatracker.ietf.org/doc/charter-ietf-spring/

The diffs are at

https://www.ietf.org/rfcdiff?url1=3Dhttps%3A%2F%2Fdatatracker.ietf.org%2Fdo=
c%2Fcharter-ietf-spring%2Fwithmilestones-00-00.txt&difftype=3D--html&submit=
=3DGo!&url2=3Dhttps%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fcharter-ietf-sprin=
g%2Fwithmilestones-00-01.txt<https://www.ietf.org/rfcdiff?url1=3Dhttps%3A%2=
F%2Fdatatracker.ietf.org%2Fdoc%2Fcharter-ietf-spring%2Fwithmilestones-00-00=
.txt&difftype=3D--html&submit=3DGo%21&url2=3Dhttps%3A%2F%2Fdatatracker.ietf=
.org%2Fdoc%2Fcharter-ietf-spring%2Fwithmilestones-00-01.txt>

or if you prefer:

http://tinyurl.com/o24a9lz

The link node text I added was

"Steering is achieved by specifying in the packet an ordered
set of nodes and/or links and/or shortest-path-next-hops
to be traversed by the packet."

- Stewart

_______________________________________________
status mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/status

--
For corporate legal information go to:

http://www.cisco.com/web/about/doing_business/legal/cri/index.html

--_000_9831C1489C794648896A383E9B791BE7junipernet_
Content-Type: text/html; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

<html>
<head>
<meta http-equiv=3D"Content-Type" content=3D"text/html; charset=3Dus-ascii"=
>
</head>
<body dir=3D"auto">
<div><br>
<br>
Sent from my iPhone</div>
<div><br>
On Sep 23, 2013, at 12:27 PM, &quot;Stewart Bryant&quot; &lt;<a href=3D"mai=
lto:[email-masked]">[email-masked]</a>&gt; wrote:<br>
<br>
</div>
<blockquote type=3D"cite">
<div>
<div class=3D"moz-cite-prefix">Maybe I will take the sentence out, because =
there<br>
is more to identifiers than next hops. For example,<br>
a PW label, which we may find on the stack, is an <br>
instruction (decap, munge and sent to an interface), <br>
so the concern is that the text might be unnecessarily <br>
constraining which would outweigh its utility as<br>
tutorial material.<br>
<br>
Stewart<br>
<br>
<br>
<br>
On 23/09/2013 16:01, John E Drake wrote:<br>
</div>
<blockquote cite=3D"mid:[email-masked]=
d05.prod.outlook.com" type=3D"cite">
<meta name=3D"Generator" content=3D"Microsoft Word 15 (filtered
        medium)">
<style><!--
/* Font Definitions */
@font-face
	{font-family:"Cambria Math";
	panose-1:2 4 5 3 5 4 6 3 2 4;}
@font-face
	{font-family:Calibri;
	panose-1:2 15 5 2 2 2 4 3 2 4;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
	{margin:0in;
	margin-bottom:.0001pt;
	font-size:12.0pt;
	font-family:"Times New Roman","serif";
	color:black;}
a:link, span.MsoHyperlink
	{mso-style-priority:99;
	color:blue;
	text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
	{mso-style-priority:99;
	color:purple;
	text-decoration:underline;}
span.EmailStyle17
	{mso-style-type:personal-reply;
	font-family:"Calibri","sans-serif";
	color:#1F497D;}
.MsoChpDefault
	{mso-style-type:export-only;
	font-size:10.0pt;}
@page WordSection1
	{size:8.5in 11.0in;
	margin:1.0in 1.0in 1.0in 1.0in;}
div.WordSection1
	{page:WordSection1;}
--></style><!--[if gte mso 9]><xml>
<o:shapedefaults v:ext=3D"edit" spidmax=3D"1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
<o:shapelayout v:ext=3D"edit">
<o:idmap v:ext=3D"edit" data=3D"1" />
</o:shapelayout></xml><![endif]-->
<div class=3D"WordSection1">
<p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=
libri&quot;,&quot;sans-serif&quot;;color:#1F497D">Stewart,<o:p></o:p></span=
></p>
<p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=
libri&quot;,&quot;sans-serif&quot;;color:#1F497D"><o:p>&nbsp;</o:p></span><=
/p>
<p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=
libri&quot;,&quot;sans-serif&quot;;color:#1F497D">Upon reflection, I spoke =
too soon.&nbsp; The use of the term &#8216;explicit route&#8217; as suggest=
ed by Lou and myself is fine, but the sentence you added:<o:p></o:p></span>=
</p>
<p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=
libri&quot;,&quot;sans-serif&quot;;color:#1F497D"><o:p>&nbsp;</o:p></span><=
/p>
<p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=
libri&quot;,&quot;sans-serif&quot;;color:#1F497D">&#8220;Steering is achiev=
ed by specifying in the packet an ordered set of nodes and/or links and/or =
shortest-path-next-hops to be traversed by the packet.&#8221;<o:p></o:p></s=
pan></p>
<p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=
libri&quot;,&quot;sans-serif&quot;;color:#1F497D"><o:p>&nbsp;</o:p></span><=
/p>
<p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=
libri&quot;,&quot;sans-serif&quot;;color:#1F497D">has issues.&nbsp; A packe=
t *<b>will not</b>* have contain an ordered set of nodes and/or links and/o=
r shortest-path-next-hops to be traversed by the packet, rather
 it will have a set of identifiers specifying resources within a SPRING reg=
ion, and these specified resources *<b>are not</b>* limited to &#8220;nodes=
 and/or links and/or shortest-path-next-hops&#8221;; they may also include,=
 for example, forwarding adjacencies and services.<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=
libri&quot;,&quot;sans-serif&quot;;color:#1F497D"><o:p>&nbsp;</o:p></span><=
/p>
<p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=
libri&quot;,&quot;sans-serif&quot;;color:#1F497D">I suggest that we strike =
the sentence.&nbsp; As Stefano points out, a charter is not a design specif=
ication.
<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=
libri&quot;,&quot;sans-serif&quot;;color:#1F497D"><o:p>&nbsp;</o:p></span><=
/p>
<div>
<p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=
libri&quot;,&quot;sans-serif&quot;;color:#1F497D">Yours Irrespectively,<o:p=
></o:p></span></p>
<p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=
libri&quot;,&quot;sans-serif&quot;;color:#1F497D"><o:p>&nbsp;</o:p></span><=
/p>
<p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=
libri&quot;,&quot;sans-serif&quot;;color:#1F497D">John<o:p></o:p></span></p=
>
</div>
<p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=
libri&quot;,&quot;sans-serif&quot;;color:#1F497D"><o:p>&nbsp;</o:p></span><=
/p>
<div style=3D"border:none;border-left:solid blue 1.5pt;padding:0in
          0in 0in 4.0pt">
<div>
<div style=3D"border:none;border-top:solid #E1E1E1
              1.0pt;padding:3.0pt 0in 0in 0in">
<p class=3D"MsoNormal"><b><span style=3D"font-size:11.0pt;font-family:&quot=
;Calibri&quot;,&quot;sans-serif&quot;;color:windowtext">From:</span></b><sp=
an style=3D"font-size:11.0pt;font-family:&quot;Calibri&quot;,&quot;sans-ser=
if&quot;;color:windowtext">
<a class=3D"moz-txt-link-abbreviated" href=3D"mailto:[email-masked]=
g">[email-masked]</a> [<a class=3D"moz-txt-link-freetext" href=3D"=
mailto:[email-masked]">mailto:[email-masked]</a>]
<b>On Behalf Of </b>Stewart Bryant<br>
<b>Sent:</b> Monday, September 23, 2013 6:13 AM<br>
<b>To:</b> <a class=3D"moz-txt-link-abbreviated" href=3D"mailto:status@ietf=
.org">[email-masked]</a><br>
<b>Subject:</b> Re: [Status] Chartering next steps<o:p></o:p></span></p>
</div>
</div>
<p class=3D"MsoNormal"><o:p>&nbsp;</o:p></p>
<p class=3D"MsoNormal">I have included the proposed changes and some text t=
hat<br>
clarifies the link-node discussion.<br>
<br>
The current charter text is at <br>
<br>
<a moz-do-not-send=3D"true" href=3D"https://datatracker.ietf.org/doc/charte=
r-ietf-spring/">https://datatracker.ietf.org/doc/charter-ietf-spring/</a><b=
r>
<br>
The diffs are at<br>
<br>
<a moz-do-not-send=3D"true" href=3D"https://www.ietf.org/rfcdiff?url1=3Dhtt=
ps%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fcharter-ietf-spring%2Fwithmilestone=
s-00-00.txt&amp;difftype=3D--html&amp;submit=3DGo%21&amp;url2=3Dhttps%3A%2F=
%2Fdatatracker.ietf.org%2Fdoc%2Fcharter-ietf-spring%2Fwithmilestones-00-01.=
txt">https://www.ietf.org/rfcdiff?url1=3Dhttps%3A%2F%2Fdatatracker.ietf.org=
%2Fdoc%2Fcharter-ietf-spring%2Fwithmilestones-00-00.txt&amp;difftype=3D--ht=
ml&amp;submit=3DGo!&amp;url2=3Dhttps%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fc=
harter-ietf-spring%2Fwithmilestones-00-01.txt</a><br>
<br>
or if you prefer:<br>
<br>
<b><a moz-do-not-send=3D"true" href=3D"http://tinyurl.com/o24a9lz">http://t=
inyurl.com/o24a9lz</a></b><br>
<br>
The link node text I added was <br>
<br>
&quot;Steering is achieved by specifying in the packet an ordered <br>
set of nodes and/or links and/or shortest-path-next-hops <br>
to be traversed by the packet.&quot;<br>
<br>
- Stewart<o:p></o:p></p>
</div>
</div>
<br>
<fieldset class=3D"mimeAttachmentHeader"></fieldset> <br>
<pre wrap=3D"">_______________________________________________
status mailing list
<a class=3D"moz-txt-link-abbreviated" href=3D"mailto:[email-masked]">statu=
[email-masked]</a>
<a class=3D"moz-txt-link-freetext" href=3D"https://www.ietf.org/mailman/lis=
tinfo/status">https://www.ietf.org/mailman/listinfo/status</a>
</pre>
</blockquote>
<br>
<br>
<pre class=3D"moz-signature" cols=3D"72">--=20
For corporate legal information go to:

<a class=3D"moz-txt-link-freetext" href=3D"http://www.cisco.com/web/about/d=
oing_business/legal/cri/index.html">http://www.cisco.com/web/about/doing_bu=
siness/legal/cri/index.html</a>

</pre>
</div>
</blockquote>
</body>
</html>

--_000_9831C1489C794648896A383E9B791BE7junipernet_--

Date: Mon, 23 Sep 2013 17:26:10 +0100
From: Stewart Bryant <[email-masked]>
To: John E Drake <[email-masked]>
Cc: "[email-masked]" <[email-masked]>
Subject: Re: [Status] Chartering next steps
Reply-To: [email-masked]

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

Maybe I will take the sentence out, because there
is more to identifiers than next hops. For example,
a PW label, which we may find on the stack, is an
instruction (decap, munge and sent to an interface),
so the concern is that the text might be unnecessarily
constraining which would outweigh its utility as
tutorial material.

Stewart

On 23/09/2013 16:01, John E Drake wrote:
>
> Stewart,
>
> Upon reflection, I spoke too soon.  The use of the term 'explicit 
> route' as suggested by Lou and myself is fine, but the sentence you added:
>
> "Steering is achieved by specifying in the packet an ordered set of 
> nodes and/or links and/or shortest-path-next-hops to be traversed by 
> the packet."
>
> has issues.  A packet **will not** have contain an ordered set of 
> nodes and/or links and/or shortest-path-next-hops to be traversed by 
> the packet, rather it will have a set of identifiers specifying 
> resources within a SPRING region, and these specified resources **are 
> not** limited to "nodes and/or links and/or shortest-path-next-hops"; 
> they may also include, for example, forwarding adjacencies and services.
>
> I suggest that we strike the sentence.  As Stefano points out, a 
> charter is not a design specification.
>
> Yours Irrespectively,
>
> John
>
> *From:[email-masked] [mailto:[email-masked]] *On 
> Behalf Of *Stewart Bryant
> *Sent:* Monday, September 23, 2013 6:13 AM
> *To:* [email-masked]
> *Subject:* Re: [Status] Chartering next steps
>
> I have included the proposed changes and some text that
> clarifies the link-node discussion.
>
> The current charter text is at
>
> https://datatracker.ietf.org/doc/charter-ietf-spring/
>
> The diffs are at
>
> https://www.ietf.org/rfcdiff?url1=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fcharter-ietf-spring%2Fwithmilestones-00-00.txt&difftype=--html&submit=Go!&url2=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fcharter-ietf-spring%2Fwithmilestones-00-01.txt 
> <https://www.ietf.org/rfcdiff?url1=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fcharter-ietf-spring%2Fwithmilestones-00-00.txt&difftype=--html&submit=Go%21&url2=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fcharter-ietf-spring%2Fwithmilestones-00-01.txt>
>
> or if you prefer:
>
> *http://tinyurl.com/o24a9lz*
>
> The link node text I added was
>
> "Steering is achieved by specifying in the packet an ordered
> set of nodes and/or links and/or shortest-path-next-hops
> to be traversed by the packet."
>
> - Stewart
>
>
>
> _______________________________________________
> status mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/status

-- 
For corporate legal information go to:

http://www.cisco.com/web/about/doing_business/legal/cri/index.html

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

<html>
  <head>
    <meta content="text/html; charset=ISO-8859-1"
      http-equiv="Content-Type">
  </head>
  <body bgcolor="#FFFFFF" text="#000000">
    <div class="moz-cite-prefix">Maybe I will take the sentence out,
      because there<br>
      is more to identifiers than next hops. For example,<br>
      a PW label, which we may find on the stack, is an <br>
      instruction (decap, munge and sent to an interface), <br>
      so the concern is that the text might be unnecessarily <br>
      constraining which would outweigh its utility as<br>
      tutorial material.<br>
      <br>
      Stewart<br>
      <br>
      <br>
      <br>
      On 23/09/2013 16:01, John E Drake wrote:<br>
    </div>
    <blockquote
cite="mid:[email-masked]"
      type="cite">
      <meta http-equiv="Content-Type" content="text/html;
        charset=ISO-8859-1">
      <meta name="Generator" content="Microsoft Word 15 (filtered
        medium)">
      <style><!--
/* Font Definitions */
@font-face
	{font-family:"Cambria Math";
	panose-1:2 4 5 3 5 4 6 3 2 4;}
@font-face
	{font-family:Calibri;
	panose-1:2 15 5 2 2 2 4 3 2 4;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
	{margin:0in;
	margin-bottom:.0001pt;
	font-size:12.0pt;
	font-family:"Times New Roman","serif";
	color:black;}
a:link, span.MsoHyperlink
	{mso-style-priority:99;
	color:blue;
	text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
	{mso-style-priority:99;
	color:purple;
	text-decoration:underline;}
span.EmailStyle17
	{mso-style-type:personal-reply;
	font-family:"Calibri","sans-serif";
	color:#1F497D;}
.MsoChpDefault
	{mso-style-type:export-only;
	font-size:10.0pt;}
@page WordSection1
	{size:8.5in 11.0in;
	margin:1.0in 1.0in 1.0in 1.0in;}
div.WordSection1
	{page:WordSection1;}
--></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]-->
      <div class="WordSection1">
        <p class="MsoNormal"><span
style="font-size:11.0pt;font-family:&quot;Calibri&quot;,&quot;sans-serif&quot;;color:#1F497D">Stewart,<o:p></o:p></span></p>
        <p class="MsoNormal"><span
style="font-size:11.0pt;font-family:&quot;Calibri&quot;,&quot;sans-serif&quot;;color:#1F497D"><o:p>&nbsp;</o:p></span></p>
        <p class="MsoNormal"><span
style="font-size:11.0pt;font-family:&quot;Calibri&quot;,&quot;sans-serif&quot;;color:#1F497D">Upon
            reflection, I spoke too soon.&nbsp; The use of the term &#8216;explicit
            route&#8217; as suggested by Lou and myself is fine, but the
            sentence you added:<o:p></o:p></span></p>
        <p class="MsoNormal"><span
style="font-size:11.0pt;font-family:&quot;Calibri&quot;,&quot;sans-serif&quot;;color:#1F497D"><o:p>&nbsp;</o:p></span></p>
        <p class="MsoNormal"><span
style="font-size:11.0pt;font-family:&quot;Calibri&quot;,&quot;sans-serif&quot;;color:#1F497D">&#8220;Steering
            is achieved by specifying in the packet an ordered set of
            nodes and/or links and/or shortest-path-next-hops to be
            traversed by the packet.&#8221;<o:p></o:p></span></p>
        <p class="MsoNormal"><span
style="font-size:11.0pt;font-family:&quot;Calibri&quot;,&quot;sans-serif&quot;;color:#1F497D"><o:p>&nbsp;</o:p></span></p>
        <p class="MsoNormal"><span
style="font-size:11.0pt;font-family:&quot;Calibri&quot;,&quot;sans-serif&quot;;color:#1F497D">has
            issues.&nbsp; A packet *<b>will not</b>* have contain an ordered
            set of nodes and/or links and/or shortest-path-next-hops to
            be traversed by the packet, rather it will have a set of
            identifiers specifying resources within a SPRING region, and
            these specified resources *<b>are not</b>* limited to &#8220;nodes
            and/or links and/or shortest-path-next-hops&#8221;; they may also
            include, for example, forwarding adjacencies and services.<o:p></o:p></span></p>
        <p class="MsoNormal"><span
style="font-size:11.0pt;font-family:&quot;Calibri&quot;,&quot;sans-serif&quot;;color:#1F497D"><o:p>&nbsp;</o:p></span></p>
        <p class="MsoNormal"><span
style="font-size:11.0pt;font-family:&quot;Calibri&quot;,&quot;sans-serif&quot;;color:#1F497D">I
            suggest that we strike the sentence.&nbsp; As Stefano points out,
            a charter is not a design specification.
            <o:p></o:p></span></p>
        <p class="MsoNormal"><span
style="font-size:11.0pt;font-family:&quot;Calibri&quot;,&quot;sans-serif&quot;;color:#1F497D"><o:p>&nbsp;</o:p></span></p>
        <div>
          <p class="MsoNormal"><span
style="font-size:11.0pt;font-family:&quot;Calibri&quot;,&quot;sans-serif&quot;;color:#1F497D">Yours
              Irrespectively,<o:p></o:p></span></p>
          <p class="MsoNormal"><span
style="font-size:11.0pt;font-family:&quot;Calibri&quot;,&quot;sans-serif&quot;;color:#1F497D"><o:p>&nbsp;</o:p></span></p>
          <p class="MsoNormal"><span
style="font-size:11.0pt;font-family:&quot;Calibri&quot;,&quot;sans-serif&quot;;color:#1F497D">John<o:p></o:p></span></p>
        </div>
        <p class="MsoNormal"><span
style="font-size:11.0pt;font-family:&quot;Calibri&quot;,&quot;sans-serif&quot;;color:#1F497D"><o:p>&nbsp;</o:p></span></p>
        <div style="border:none;border-left:solid blue 1.5pt;padding:0in
          0in 0in 4.0pt">
          <div>
            <div style="border:none;border-top:solid #E1E1E1
              1.0pt;padding:3.0pt 0in 0in 0in">
              <p class="MsoNormal"><b><span
style="font-size:11.0pt;font-family:&quot;Calibri&quot;,&quot;sans-serif&quot;;color:windowtext">From:</span></b><span
style="font-size:11.0pt;font-family:&quot;Calibri&quot;,&quot;sans-serif&quot;;color:windowtext">
                  <a class="moz-txt-link-abbreviated" href="mailto:[email-masked]">[email-masked]</a>
                  [<a class="moz-txt-link-freetext" href="mailto:[email-masked]">mailto:[email-masked]</a>]
                  <b>On Behalf Of </b>Stewart Bryant<br>
                  <b>Sent:</b> Monday, September 23, 2013 6:13 AM<br>
                  <b>To:</b> <a class="moz-txt-link-abbreviated" href="mailto:[email-masked]">[email-masked]</a><br>
                  <b>Subject:</b> Re: [Status] Chartering next steps<o:p></o:p></span></p>
            </div>
          </div>
          <p class="MsoNormal"><o:p>&nbsp;</o:p></p>
          <p class="MsoNormal">I have included the proposed changes and
            some text that<br>
            clarifies the link-node discussion.<br>
            <br>
            The current charter text is at <br>
            <br>
            <a moz-do-not-send="true"
              href="https://datatracker.ietf.org/doc/charter-ietf-spring/">https://datatracker.ietf.org/doc/charter-ietf-spring/</a><br>
            <br>
            The diffs are at<br>
            <br>
            <a moz-do-not-send="true"
href="https://www.ietf.org/rfcdiff?url1=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fcharter-ietf-spring%2Fwithmilestones-00-00.txt&amp;difftype=--html&amp;submit=Go%21&amp;url2=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fcharter-ietf-spring%2Fwithmilestones-00-01.txt">https://www.ietf.org/rfcdiff?url1=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fcharter-ietf-spring%2Fwithmilestones-00-00.txt&amp;difftype=--html&amp;submit=Go!&amp;url2=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fcharter-ietf-spring%2Fwithmilestones-00-01.txt</a><br>
            <br>
            or if you prefer:<br>
            <br>
            <b><a moz-do-not-send="true"
                href="http://tinyurl.com/o24a9lz">http://tinyurl.com/o24a9lz</a></b><br>
            <br>
            The link node text I added was <br>
            <br>
            "Steering is achieved by specifying in the packet an ordered
            <br>
            set of nodes and/or links and/or shortest-path-next-hops <br>
            to be traversed by the packet."<br>
            <br>
            - Stewart<o:p></o:p></p>
        </div>
      </div>
      <br>
      <fieldset class="mimeAttachmentHeader"></fieldset>
      <br>
      <pre wrap="">_______________________________________________
status mailing list
<a class="moz-txt-link-abbreviated" href="mailto:[email-masked]">[email-masked]</a>
<a class="moz-txt-link-freetext" href="https://www.ietf.org/mailman/listinfo/status">https://www.ietf.org/mailman/listinfo/status</a>
</pre>
    </blockquote>
    <br>
    <br>
    <pre class="moz-signature" cols="72">-- 
For corporate legal information go to:

<a class="moz-txt-link-freetext" href="http://www.cisco.com/web/about/doing_business/legal/cri/index.html">http://www.cisco.com/web/about/doing_business/legal/cri/index.html</a>

</pre>
  </body>
</html>

--------------080200020501080809040204--

From: "Stefano Previdi (sprevidi)" <[email-masked]>
To: "Stewart Bryant (stbryant)" <[email-masked]>, "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>
Date: Mon, 23 Sep 2013 15:08:51 +0000
Accept-Language: en-US
Subject: Re: [Status] Chartering next steps

--_000_E0A1DE675FEC854ABF07D319E556FE643F53091Bxmbrcdx01ciscoc_
Content-Type: text/plain; charset="Windows-1252"
Content-Transfer-Encoding: quoted-printable

John,

To me, the text is ok as proposed in last email from Stewart. My comment ap=
plies more on your last comment.

s.

--
Sent from a device pretending to be smart.

-----Original Message-----
From: John E Drake [[email-masked]]
Received: Monday, 23 Sep 2013, 17:02
To: Stewart Bryant (stbryant) [[email-masked]]; [email-masked] [status=
@ietf.org]
Subject: Re: [Status] Chartering next steps

Stewart,

Upon reflection, I spoke too soon.  The use of the term =91explicit route=
=92 as suggested by Lou and myself is fine, but the sentence you added:

=93Steering is achieved by specifying in the packet an ordered set of nodes=
 and/or links and/or shortest-path-next-hops to be traversed by the packet.=
=94

has issues.  A packet *will not* have contain an ordered set of nodes and/o=
r links and/or shortest-path-next-hops to be traversed by the packet, rathe=
r it will have a set of identifiers specifying resources within a SPRING re=
gion, and these specified resources *are not* limited to =93nodes and/or li=
nks and/or shortest-path-next-hops=94; they may also include, for example, =
forwarding adjacencies and services.

I suggest that we strike the sentence.  As Stefano points out, a charter is=
 not a design specification.

Yours Irrespectively,

John

From: [email-masked] [mailto:[email-masked]] On Behalf Of=
 Stewart Bryant
Sent: Monday, September 23, 2013 6:13 AM
To: [email-masked]
Subject: Re: [Status] Chartering next steps

I have included the proposed changes and some text that
clarifies the link-node discussion.

The current charter text is at

https://datatracker.ietf.org/doc/charter-ietf-spring/

The diffs are at

https://www.ietf.org/rfcdiff?url1=3Dhttps%3A%2F%2Fdatatracker.ietf.org%2Fdo=
c%2Fcharter-ietf-spring%2Fwithmilestones-00-00.txt&difftype=3D--html&submit=
=3DGo!&url2=3Dhttps%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fcharter-ietf-sprin=
g%2Fwithmilestones-00-01.txt

or if you prefer:

http://tinyurl.com/o24a9lz

The link node text I added was

"Steering is achieved by specifying in the packet an ordered
set of nodes and/or links and/or shortest-path-next-hops
to be traversed by the packet."

- Stewart

--_000_E0A1DE675FEC854ABF07D319E556FE643F53091Bxmbrcdx01ciscoc_
Content-Type: text/html; charset="Windows-1252"
Content-Transfer-Encoding: quoted-printable

<html>
<head>
<meta http-equiv=3D"Content-Type" content=3D"text/html; charset=3DWindows-1=
252">
<style>
<!--
@font-face
	{font-family:"Cambria Math"}
@font-face
	{font-family:Calibri}
p.MsoNormal, li.MsoNormal, div.MsoNormal
	{margin:0in;
	margin-bottom:.0001pt;
	font-size:12.0pt;
	font-family:"Times New Roman","serif";
	color:black}
a:link, span.MsoHyperlink
	{color:blue;
	text-decoration:underline}
a:visited, span.MsoHyperlinkFollowed
	{color:purple;
	text-decoration:underline}
span.EmailStyle17
	{font-family:"Calibri","sans-serif";
	color:#1F497D}
.MsoChpDefault
	{font-size:10.0pt}
@page WordSection1
	{margin:1.0in 1.0in 1.0in 1.0in}
div.WordSection1
	{}
-->
</style>
</head>
<body bgcolor=3D"white" lang=3D"EN-US" link=3D"blue" vlink=3D"purple">
<span style=3D"font-family:Calibri,Arial,Helvetica,sans-serif; font-size:11=
pt; color:black">John,
<br>
<br>
To me, the text is ok as proposed in last email from Stewart. My comment ap=
plies more on your last comment.<br>
<br>
s.<br>
<br>
<br>
<br>
--<br>
Sent from a device pretending to be smart. <br>
<br>
<span style=3D"color:black">-----Original Message----- <br>
<b>From:</b> John E Drake [[email-masked]]<br>
<b>Received:</b> Monday, 23 Sep 2013, 17:02<br>
<b>To:</b> Stewart Bryant (stbryant) [[email-masked]]; [email-masked] =
[[email-masked]]<br>
<b>Subject:</b> Re: [Status] Chartering next steps<br>
<br>
</span></span>
<div>
<div class=3D"WordSection1">
<p class=3D"MsoNormal"><span style=3D"font-size:11.0pt; font-family:&quot;C=
alibri&quot;,&quot;sans-serif&quot;; color:#1F497D">Stewart,</span></p>
<p class=3D"MsoNormal"><span style=3D"font-size:11.0pt; font-family:&quot;C=
alibri&quot;,&quot;sans-serif&quot;; color:#1F497D">&nbsp;</span></p>
<p class=3D"MsoNormal"><span style=3D"font-size:11.0pt; font-family:&quot;C=
alibri&quot;,&quot;sans-serif&quot;; color:#1F497D">Upon reflection, I spok=
e too soon.&nbsp; The use of the term =91explicit route=92 as suggested by =
Lou and myself is fine, but the sentence you added:</span></p>
<p class=3D"MsoNormal"><span style=3D"font-size:11.0pt; font-family:&quot;C=
alibri&quot;,&quot;sans-serif&quot;; color:#1F497D">&nbsp;</span></p>
<p class=3D"MsoNormal"><span style=3D"font-size:11.0pt; font-family:&quot;C=
alibri&quot;,&quot;sans-serif&quot;; color:#1F497D">=93Steering is achieved=
 by specifying in the packet an ordered set of nodes and/or links and/or sh=
ortest-path-next-hops to be traversed by the packet.=94</span></p>
<p class=3D"MsoNormal"><span style=3D"font-size:11.0pt; font-family:&quot;C=
alibri&quot;,&quot;sans-serif&quot;; color:#1F497D">&nbsp;</span></p>
<p class=3D"MsoNormal"><span style=3D"font-size:11.0pt; font-family:&quot;C=
alibri&quot;,&quot;sans-serif&quot;; color:#1F497D">has issues.&nbsp; A pac=
ket *<b>will not</b>* have contain an ordered set of nodes and/or links and=
/or shortest-path-next-hops to be traversed by the packet, rather
 it will have a set of identifiers specifying resources within a SPRING reg=
ion, and these specified resources *<b>are not</b>* limited to =93nodes and=
/or links and/or shortest-path-next-hops=94; they may also include, for exa=
mple, forwarding adjacencies and services.</span></p>
<p class=3D"MsoNormal"><span style=3D"font-size:11.0pt; font-family:&quot;C=
alibri&quot;,&quot;sans-serif&quot;; color:#1F497D">&nbsp;</span></p>
<p class=3D"MsoNormal"><span style=3D"font-size:11.0pt; font-family:&quot;C=
alibri&quot;,&quot;sans-serif&quot;; color:#1F497D">I suggest that we strik=
e the sentence.&nbsp; As Stefano points out, a charter is not a design spec=
ification.
</span></p>
<p class=3D"MsoNormal"><span style=3D"font-size:11.0pt; font-family:&quot;C=
alibri&quot;,&quot;sans-serif&quot;; color:#1F497D">&nbsp;</span></p>
<div>
<p class=3D"MsoNormal"><span style=3D"font-size:11.0pt; font-family:&quot;C=
alibri&quot;,&quot;sans-serif&quot;; color:#1F497D">Yours Irrespectively,</=
span></p>
<p class=3D"MsoNormal"><span style=3D"font-size:11.0pt; font-family:&quot;C=
alibri&quot;,&quot;sans-serif&quot;; color:#1F497D">&nbsp;</span></p>
<p class=3D"MsoNormal"><span style=3D"font-size:11.0pt; font-family:&quot;C=
alibri&quot;,&quot;sans-serif&quot;; color:#1F497D">John</span></p>
</div>
<p class=3D"MsoNormal"><span style=3D"font-size:11.0pt; font-family:&quot;C=
alibri&quot;,&quot;sans-serif&quot;; color:#1F497D">&nbsp;</span></p>
<div style=3D"border:none; border-left:solid blue 1.5pt; padding:0in 0in 0i=
n 4.0pt">
<div>
<div style=3D"border:none; border-top:solid #E1E1E1 1.0pt; padding:3.0pt 0i=
n 0in 0in">
<p class=3D"MsoNormal"><b><span style=3D"font-size:11.0pt; font-family:&quo=
t;Calibri&quot;,&quot;sans-serif&quot;; color:windowtext">From:</span></b><=
span style=3D"font-size:11.0pt; font-family:&quot;Calibri&quot;,&quot;sans-=
serif&quot;; color:windowtext"> [email-masked] [mailto:status-boun=
[email-masked]]
<b>On Behalf Of </b>Stewart Bryant<br>
<b>Sent:</b> Monday, September 23, 2013 6:13 AM<br>
<b>To:</b> [email-masked]<br>
<b>Subject:</b> Re: [Status] Chartering next steps</span></p>
</div>
</div>
<p class=3D"MsoNormal">&nbsp;</p>
<p class=3D"MsoNormal">I have included the proposed changes and some text t=
hat<br>
clarifies the link-node discussion.<br>
<br>
The current charter text is at <br>
<br>
<a href=3D"https://datatracker.ietf.org/doc/charter-ietf-spring/">https://d=
atatracker.ietf.org/doc/charter-ietf-spring/</a><br>
<br>
The diffs are at<br>
<br>
<a href=3D"https://www.ietf.org/rfcdiff?url1=3Dhttps%3A%2F%2Fdatatracker.ie=
tf.org%2Fdoc%2Fcharter-ietf-spring%2Fwithmilestones-00-00.txt&amp;difftype=
=3D--html&amp;submit=3DGo!&amp;url2=3Dhttps%3A%2F%2Fdatatracker.ietf.org%2F=
doc%2Fcharter-ietf-spring%2Fwithmilestones-00-01.txt">https://www.ietf.org/=
rfcdiff?url1=3Dhttps%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fcharter-ietf-spri=
ng%2Fwithmilestones-00-00.txt&amp;difftype=3D--html&amp;submit=3DGo!&amp;ur=
l2=3Dhttps%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fcharter-ietf-spring%2Fwithm=
ilestones-00-01.txt</a><br>
<br>
or if you prefer:<br>
<br>
<b><a href=3D"http://tinyurl.com/o24a9lz">http://tinyurl.com/o24a9lz</a></b=
><br>
<br>
The link node text I added was <br>
<br>
&quot;Steering is achieved by specifying in the packet an ordered <br>
set of nodes and/or links and/or shortest-path-next-hops <br>
to be traversed by the packet.&quot;<br>
<br>
- Stewart</p>
</div>
</div>
</div>
</body>
</html>

--_000_E0A1DE675FEC854ABF07D319E556FE643F53091Bxmbrcdx01ciscoc_--

From: John E Drake <[email-masked]>
To: "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>
Date: Mon, 23 Sep 2013 15:01:41 +0000
Accept-Language: en-US
Subject: Re: [Status] Chartering next steps

--_000_d382f78d4a2f4ee4a65b0814e76ef373BY2PR05MB142namprd05pro_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

Stewart,

Upon reflection, I spoke too soon.  The use of the term 'explicit route' as=
 suggested by Lou and myself is fine, but the sentence you added:

"Steering is achieved by specifying in the packet an ordered set of nodes a=
nd/or links and/or shortest-path-next-hops to be traversed by the packet."

has issues.  A packet *will not* have contain an ordered set of nodes and/o=
r links and/or shortest-path-next-hops to be traversed by the packet, rathe=
r it will have a set of identifiers specifying resources within a SPRING re=
gion, and these specified resources *are not* limited to "nodes and/or link=
s and/or shortest-path-next-hops"; they may also include, for example, forw=
arding adjacencies and services.

I suggest that we strike the sentence.  As Stefano points out, a charter is=
 not a design specification.

Yours Irrespectively,

John

From: [email-masked] [mailto:[email-masked]] On Behalf Of=
 Stewart Bryant
Sent: Monday, September 23, 2013 6:13 AM
To: [email-masked]
Subject: Re: [Status] Chartering next steps

I have included the proposed changes and some text that
clarifies the link-node discussion.

The current charter text is at

https://datatracker.ietf.org/doc/charter-ietf-spring/

The diffs are at

https://www.ietf.org/rfcdiff?url1=3Dhttps%3A%2F%2Fdatatracker.ietf.org%2Fdo=
c%2Fcharter-ietf-spring%2Fwithmilestones-00-00.txt&difftype=3D--html&submit=
=3DGo!&url2=3Dhttps%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fcharter-ietf-sprin=
g%2Fwithmilestones-00-01.txt

or if you prefer:

http://tinyurl.com/o24a9lz

The link node text I added was

"Steering is achieved by specifying in the packet an ordered
set of nodes and/or links and/or shortest-path-next-hops
to be traversed by the packet."

- Stewart

--_000_d382f78d4a2f4ee4a65b0814e76ef373BY2PR05MB142namprd05pro_
Content-Type: text/html; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

<html xmlns:v=3D"urn:schemas-microsoft-com:vml" xmlns:o=3D"urn:schemas-micr=
osoft-com:office:office" xmlns:w=3D"urn:schemas-microsoft-com:office:word" =
xmlns:m=3D"http://schemas.microsoft.com/office/2004/12/omml" xmlns=3D"http:=
//www.w3.org/TR/REC-html40">
<head>
<meta http-equiv=3D"Content-Type" content=3D"text/html; charset=3Dus-ascii"=
>
<meta name=3D"Generator" content=3D"Microsoft Word 15 (filtered medium)">
<style><!--
/* Font Definitions */
@font-face
	{font-family:"Cambria Math";
	panose-1:2 4 5 3 5 4 6 3 2 4;}
@font-face
	{font-family:Calibri;
	panose-1:2 15 5 2 2 2 4 3 2 4;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
	{margin:0in;
	margin-bottom:.0001pt;
	font-size:12.0pt;
	font-family:"Times New Roman","serif";
	color:black;}
a:link, span.MsoHyperlink
	{mso-style-priority:99;
	color:blue;
	text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
	{mso-style-priority:99;
	color:purple;
	text-decoration:underline;}
span.EmailStyle17
	{mso-style-type:personal-reply;
	font-family:"Calibri","sans-serif";
	color:#1F497D;}
.MsoChpDefault
	{mso-style-type:export-only;
	font-size:10.0pt;}
@page WordSection1
	{size:8.5in 11.0in;
	margin:1.0in 1.0in 1.0in 1.0in;}
div.WordSection1
	{page:WordSection1;}
--></style><!--[if gte mso 9]><xml>
<o:shapedefaults v:ext=3D"edit" spidmax=3D"1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
<o:shapelayout v:ext=3D"edit">
<o:idmap v:ext=3D"edit" data=3D"1" />
</o:shapelayout></xml><![endif]-->
</head>
<body bgcolor=3D"white" lang=3D"EN-US" link=3D"blue" vlink=3D"purple">
<div class=3D"WordSection1">
<p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=
libri&quot;,&quot;sans-serif&quot;;color:#1F497D">Stewart,<o:p></o:p></span=
></p>
<p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=
libri&quot;,&quot;sans-serif&quot;;color:#1F497D"><o:p>&nbsp;</o:p></span><=
/p>
<p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=
libri&quot;,&quot;sans-serif&quot;;color:#1F497D">Upon reflection, I spoke =
too soon.&nbsp; The use of the term &#8216;explicit route&#8217; as suggest=
ed by Lou and myself is fine, but the sentence you added:<o:p></o:p></span>=
</p>
<p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=
libri&quot;,&quot;sans-serif&quot;;color:#1F497D"><o:p>&nbsp;</o:p></span><=
/p>
<p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=
libri&quot;,&quot;sans-serif&quot;;color:#1F497D">&#8220;Steering is achiev=
ed by specifying in the packet an ordered set of nodes and/or links and/or =
shortest-path-next-hops to be traversed by the packet.&#8221;<o:p></o:p></s=
pan></p>
<p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=
libri&quot;,&quot;sans-serif&quot;;color:#1F497D"><o:p>&nbsp;</o:p></span><=
/p>
<p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=
libri&quot;,&quot;sans-serif&quot;;color:#1F497D">has issues.&nbsp; A packe=
t *<b>will not</b>* have contain an ordered set of nodes and/or links and/o=
r shortest-path-next-hops to be traversed by the packet, rather
 it will have a set of identifiers specifying resources within a SPRING reg=
ion, and these specified resources *<b>are not</b>* limited to &#8220;nodes=
 and/or links and/or shortest-path-next-hops&#8221;; they may also include,=
 for example, forwarding adjacencies and services.<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=
libri&quot;,&quot;sans-serif&quot;;color:#1F497D"><o:p>&nbsp;</o:p></span><=
/p>
<p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=
libri&quot;,&quot;sans-serif&quot;;color:#1F497D">I suggest that we strike =
the sentence.&nbsp; As Stefano points out, a charter is not a design specif=
ication.
<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=
libri&quot;,&quot;sans-serif&quot;;color:#1F497D"><o:p>&nbsp;</o:p></span><=
/p>
<div>
<p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=
libri&quot;,&quot;sans-serif&quot;;color:#1F497D">Yours Irrespectively,<o:p=
></o:p></span></p>
<p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=
libri&quot;,&quot;sans-serif&quot;;color:#1F497D"><o:p>&nbsp;</o:p></span><=
/p>
<p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=
libri&quot;,&quot;sans-serif&quot;;color:#1F497D">John<o:p></o:p></span></p=
>
</div>
<p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=
libri&quot;,&quot;sans-serif&quot;;color:#1F497D"><o:p>&nbsp;</o:p></span><=
/p>
<div style=3D"border:none;border-left:solid blue 1.5pt;padding:0in 0in 0in =
4.0pt">
<div>
<div style=3D"border:none;border-top:solid #E1E1E1 1.0pt;padding:3.0pt 0in =
0in 0in">
<p class=3D"MsoNormal"><b><span style=3D"font-size:11.0pt;font-family:&quot=
;Calibri&quot;,&quot;sans-serif&quot;;color:windowtext">From:</span></b><sp=
an style=3D"font-size:11.0pt;font-family:&quot;Calibri&quot;,&quot;sans-ser=
if&quot;;color:windowtext"> [email-masked] [mailto:status-bounces@=
ietf.org]
<b>On Behalf Of </b>Stewart Bryant<br>
<b>Sent:</b> Monday, September 23, 2013 6:13 AM<br>
<b>To:</b> [email-masked]<br>
<b>Subject:</b> Re: [Status] Chartering next steps<o:p></o:p></span></p>
</div>
</div>
<p class=3D"MsoNormal"><o:p>&nbsp;</o:p></p>
<p class=3D"MsoNormal">I have included the proposed changes and some text t=
hat<br>
clarifies the link-node discussion.<br>
<br>
The current charter text is at <br>
<br>
<a href=3D"https://datatracker.ietf.org/doc/charter-ietf-spring/">https://d=
atatracker.ietf.org/doc/charter-ietf-spring/</a><br>
<br>
The diffs are at<br>
<br>
<a href=3D"https://www.ietf.org/rfcdiff?url1=3Dhttps%3A%2F%2Fdatatracker.ie=
tf.org%2Fdoc%2Fcharter-ietf-spring%2Fwithmilestones-00-00.txt&amp;difftype=
=3D--html&amp;submit=3DGo!&amp;url2=3Dhttps%3A%2F%2Fdatatracker.ietf.org%2F=
doc%2Fcharter-ietf-spring%2Fwithmilestones-00-01.txt">https://www.ietf.org/=
rfcdiff?url1=3Dhttps%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fcharter-ietf-spri=
ng%2Fwithmilestones-00-00.txt&amp;difftype=3D--html&amp;submit=3DGo!&amp;ur=
l2=3Dhttps%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fcharter-ietf-spring%2Fwithm=
ilestones-00-01.txt</a><br>
<br>
or if you prefer:<br>
<br>
<b><a href=3D"http://tinyurl.com/o24a9lz">http://tinyurl.com/o24a9lz</a></b=
><br>
<br>
The link node text I added was <br>
<br>
&quot;Steering is achieved by specifying in the packet an ordered <br>
set of nodes and/or links and/or shortest-path-next-hops <br>
to be traversed by the packet.&quot;<br>
<br>
- Stewart<o:p></o:p></p>
</div>
</div>
</body>
</html>

--_000_d382f78d4a2f4ee4a65b0814e76ef373BY2PR05MB142namprd05pro_--

From: AshwoodsmithPeter <[email-masked]>
To: "[email-masked]" <[email-masked]>
Date: Mon, 23 Sep 2013 13:53:01 +0000
Accept-Language: en-US, zh-CN
Subject: Re: [Status] Chartering next steps

--_000_7AE6A4247B044C4ABE0A5B6BF427F8E2099078CBdfweml513mbbchi_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

Seems reasonable to me too.

Peter

From: [email-masked] [mailto:[email-masked]] On Behalf Of=
 Stewart Bryant
Sent: Monday, September 23, 2013 9:37 AM
To: [email-masked]
Cc: Stefano Previdi (sprevidi)
Subject: Re: [Status] Chartering next steps

I can take that text out if people wish.

One purpose that it serves is to educate those reviewing the charter that h=
ave not been following the detail.

I have also updated the BoF placeholder, and this can be found at:

http://trac.tools.ietf.org/bof/trac/wiki/WikiStart

Note that the purpose of the draft list is partially to educate people abou=
t the subject area and partially to demonstrate that the IETF has the energ=
y work on this. I thus hoovered up all the relevant drafts, and make no com=
ment about order, or priority, or which will be pursued and which will be d=
ropped. If I missed any that was accidental.

- Stewart

On 23/09/2013 14:16, Stefano Previdi (sprevidi) wrote:
If we go deeper in the charter text discussion we'll end up defining the de=
tails of the solution...

s.

Sent from my Android phone using TouchDown (www.nitrodesk.com<http://www.ni=
trodesk.com>)

-----Original Message-----
From: Stewart Bryant (stbryant) [[email-masked]<mailto:[email-masked]=
om>]
Received: Monday, 23 Sep 2013, 15:13
To: [email-masked]<mailto:[email-masked]> [[email-masked]<mailto:status@=
ietf.org>]
Subject: Re: [Status] Chartering next steps
I have included the proposed changes and some text that
clarifies the link-node discussion.

The current charter text is at

https://datatracker.ietf.org/doc/charter-ietf-spring/

The diffs are at

https://www.ietf.org/rfcdiff?url1=3Dhttps%3A%2F%2Fdatatracker.ietf.org%2Fdo=
c%2Fcharter-ietf-spring%2Fwithmilestones-00-00.txt&difftype=3D--html&submit=
=3DGo!&url2=3Dhttps%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fcharter-ietf-sprin=
g%2Fwithmilestones-00-01.txt<https://www.ietf.org/rfcdiff?url1=3Dhttps%3A%2=
F%2Fdatatracker.ietf.org%2Fdoc%2Fcharter-ietf-spring%2Fwithmilestones-00-00=
.txt&difftype=3D--html&submit=3DGo%21&url2=3Dhttps%3A%2F%2Fdatatracker.ietf=
.org%2Fdoc%2Fcharter-ietf-spring%2Fwithmilestones-00-01.txt>

or if you prefer:

http://tinyurl.com/o24a9lz

The link node text I added was

"Steering is achieved by specifying in the packet an ordered
set of nodes and/or links and/or shortest-path-next-hops
to be traversed by the packet."

- Stewart

--

For corporate legal information go to:

http://www.cisco.com/web/about/doing_business/legal/cri/index.html

--_000_7AE6A4247B044C4ABE0A5B6BF427F8E2099078CBdfweml513mbbchi_
Content-Type: text/html; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

<html xmlns:v=3D"urn:schemas-microsoft-com:vml" xmlns:o=3D"urn:schemas-micr=
osoft-com:office:office" xmlns:w=3D"urn:schemas-microsoft-com:office:word" =
xmlns:x=3D"urn:schemas-microsoft-com:office:excel" xmlns:p=3D"urn:schemas-m=
icrosoft-com:office:powerpoint" xmlns:a=3D"urn:schemas-microsoft-com:office=
:access" xmlns:dt=3D"uuid:C2F41010-65B3-11d1-A29F-00AA00C14882" xmlns:s=3D"=
uuid:BDC6E3F0-6DA3-11d1-A2A3-00AA00C14882" xmlns:rs=3D"urn:schemas-microsof=
t-com:rowset" xmlns:z=3D"#RowsetSchema" xmlns:b=3D"urn:schemas-microsoft-co=
m:office:publisher" xmlns:ss=3D"urn:schemas-microsoft-com:office:spreadshee=
t" xmlns:c=3D"urn:schemas-microsoft-com:office:component:spreadsheet" xmlns=
:odc=3D"urn:schemas-microsoft-com:office:odc" xmlns:oa=3D"urn:schemas-micro=
soft-com:office:activation" xmlns:html=3D"http://www.w3.org/TR/REC-html40" =
xmlns:q=3D"http://schemas.xmlsoap.org/soap/envelope/" xmlns:rtc=3D"http://m=
icrosoft.com/officenet/conferencing" xmlns:D=3D"DAV:" xmlns:Repl=3D"http://=
schemas.microsoft.com/repl/" xmlns:mt=3D"http://schemas.microsoft.com/share=
point/soap/meetings/" xmlns:x2=3D"http://schemas.microsoft.com/office/excel=
/2003/xml" xmlns:ppda=3D"http://www.passport.com/NameSpace.xsd" xmlns:ois=
=3D"http://schemas.microsoft.com/sharepoint/soap/ois/" xmlns:dir=3D"http://=
schemas.microsoft.com/sharepoint/soap/directory/" xmlns:ds=3D"http://www.w3=
.org/2000/09/xmldsig#" xmlns:dsp=3D"http://schemas.microsoft.com/sharepoint=
/dsp" xmlns:udc=3D"http://schemas.microsoft.com/data/udc" xmlns:xsd=3D"http=
://www.w3.org/2001/XMLSchema" xmlns:sub=3D"http://schemas.microsoft.com/sha=
repoint/soap/2002/1/alerts/" xmlns:ec=3D"http://www.w3.org/2001/04/xmlenc#"=
 xmlns:sp=3D"http://schemas.microsoft.com/sharepoint/" xmlns:sps=3D"http://=
schemas.microsoft.com/sharepoint/soap/" xmlns:xsi=3D"http://www.w3.org/2001=
/XMLSchema-instance" xmlns:udcs=3D"http://schemas.microsoft.com/data/udc/so=
ap" xmlns:udcxf=3D"http://schemas.microsoft.com/data/udc/xmlfile" xmlns:udc=
p2p=3D"http://schemas.microsoft.com/data/udc/parttopart" xmlns:wf=3D"http:/=
/schemas.microsoft.com/sharepoint/soap/workflow/" xmlns:dsss=3D"http://sche=
mas.microsoft.com/office/2006/digsig-setup" xmlns:dssi=3D"http://schemas.mi=
crosoft.com/office/2006/digsig" xmlns:mdssi=3D"http://schemas.openxmlformat=
s.org/package/2006/digital-signature" xmlns:mver=3D"http://schemas.openxmlf=
ormats.org/markup-compatibility/2006" xmlns:m=3D"http://schemas.microsoft.c=
om/office/2004/12/omml" xmlns:mrels=3D"http://schemas.openxmlformats.org/pa=
ckage/2006/relationships" xmlns:spwp=3D"http://microsoft.com/sharepoint/web=
partpages" xmlns:ex12t=3D"http://schemas.microsoft.com/exchange/services/20=
06/types" xmlns:ex12m=3D"http://schemas.microsoft.com/exchange/services/200=
6/messages" xmlns:pptsl=3D"http://schemas.microsoft.com/sharepoint/soap/Sli=
deLibrary/" xmlns:spsl=3D"http://microsoft.com/webservices/SharePointPortal=
Server/PublishedLinksService" xmlns:Z=3D"urn:schemas-microsoft-com:" xmlns:=
st=3D"&#1;" xmlns=3D"http://www.w3.org/TR/REC-html40">
<head>
<meta http-equiv=3D"Content-Type" content=3D"text/html; charset=3Dus-ascii"=
>
<meta name=3D"Generator" content=3D"Microsoft Word 12 (filtered medium)">
<style><!--
/* Font Definitions */
@font-face
	{font-family:"Cambria Math";
	panose-1:2 4 5 3 5 4 6 3 2 4;}
@font-face
	{font-family:Calibri;
	panose-1:2 15 5 2 2 2 4 3 2 4;}
@font-face
	{font-family:Tahoma;
	panose-1:2 11 6 4 3 5 4 4 2 4;}
@font-face
	{font-family:Consolas;
	panose-1:2 11 6 9 2 2 4 3 2 4;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
	{margin:0in;
	margin-bottom:.0001pt;
	font-size:12.0pt;
	font-family:"Times New Roman","serif";
	color:black;}
a:link, span.MsoHyperlink
	{mso-style-priority:99;
	color:blue;
	text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
	{mso-style-priority:99;
	color:purple;
	text-decoration:underline;}
pre
	{mso-style-priority:99;
	mso-style-link:"HTML Preformatted Char";
	margin:0in;
	margin-bottom:.0001pt;
	font-size:10.0pt;
	font-family:"Courier New";
	color:black;}
span.HTMLPreformattedChar
	{mso-style-name:"HTML Preformatted Char";
	mso-style-priority:99;
	mso-style-link:"HTML Preformatted";
	font-family:Consolas;
	color:black;}
span.EmailStyle19
	{mso-style-type:personal-reply;
	font-family:"Calibri","sans-serif";
	color:#1F497D;}
.MsoChpDefault
	{mso-style-type:export-only;
	font-size:10.0pt;}
@page WordSection1
	{size:8.5in 11.0in;
	margin:1.0in 1.0in 1.0in 1.0in;}
div.WordSection1
	{page:WordSection1;}
--></style><!--[if gte mso 9]><xml>
<o:shapedefaults v:ext=3D"edit" spidmax=3D"1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
<o:shapelayout v:ext=3D"edit">
<o:idmap v:ext=3D"edit" data=3D"1" />
</o:shapelayout></xml><![endif]-->
</head>
<body bgcolor=3D"white" lang=3D"EN-US" link=3D"blue" vlink=3D"purple">
<div class=3D"WordSection1">
<p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=
libri&quot;,&quot;sans-serif&quot;;color:#1F497D">Seems reasonable to me to=
o.<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=
libri&quot;,&quot;sans-serif&quot;;color:#1F497D"><o:p>&nbsp;</o:p></span><=
/p>
<p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=
libri&quot;,&quot;sans-serif&quot;;color:#1F497D">Peter<o:p></o:p></span></=
p>
<p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=
libri&quot;,&quot;sans-serif&quot;;color:#1F497D"><o:p>&nbsp;</o:p></span><=
/p>
<div>
<div style=3D"border:none;border-top:solid #B5C4DF 1.0pt;padding:3.0pt 0in =
0in 0in">
<p class=3D"MsoNormal"><b><span style=3D"font-size:10.0pt;font-family:&quot=
;Tahoma&quot;,&quot;sans-serif&quot;;color:windowtext">From:</span></b><spa=
n style=3D"font-size:10.0pt;font-family:&quot;Tahoma&quot;,&quot;sans-serif=
&quot;;color:windowtext"> [email-masked] [mailto:status-bounces@ie=
tf.org]
<b>On Behalf Of </b>Stewart Bryant<br>
<b>Sent:</b> Monday, September 23, 2013 9:37 AM<br>
<b>To:</b> [email-masked]<br>
<b>Cc:</b> Stefano Previdi (sprevidi)<br>
<b>Subject:</b> Re: [Status] Chartering next steps<o:p></o:p></span></p>
</div>
</div>
<p class=3D"MsoNormal"><o:p>&nbsp;</o:p></p>
<div>
<p class=3D"MsoNormal">I can take that text out if people wish.<br>
<br>
One purpose that it serves is to educate those reviewing the charter that h=
ave not been following the detail.<br>
<br>
I have also updated the BoF placeholder, and this can be found at:<br>
<br>
<a href=3D"http://trac.tools.ietf.org/bof/trac/wiki/WikiStart">http://trac.=
tools.ietf.org/bof/trac/wiki/WikiStart</a><br>
<br>
Note that the purpose of the draft list is partially to educate people abou=
t the subject area and partially to demonstrate that the IETF has the energ=
y work on this. I thus hoovered up all the relevant drafts, and make no com=
ment about order, or priority, or
 which will be pursued and which will be dropped. If I missed any that was =
accidental.<br>
<br>
- Stewart<br>
<br>
<br>
On 23/09/2013 14:16, Stefano Previdi (sprevidi) wrote:<o:p></o:p></p>
</div>
<blockquote style=3D"margin-top:5.0pt;margin-bottom:5.0pt">
<p class=3D"MsoNormal" style=3D"margin-bottom:12.0pt"><span style=3D"font-s=
ize:11.0pt;font-family:&quot;Calibri&quot;,&quot;sans-serif&quot;">If we go=
 deeper in the charter text discussion we'll end up defining the details of=
 the solution...<br>
<br>
s.<br>
<br>
Sent from my Android phone using TouchDown (<a href=3D"http://www.nitrodesk=
.com">www.nitrodesk.com</a>)<br>
<br>
-----Original Message----- <br>
<b>From:</b> Stewart Bryant (stbryant) [<a href=3D"mailto:[email-masked]=
m">[email-masked]</a>]<br>
<b>Received:</b> Monday, 23 Sep 2013, 15:13<br>
<b>To:</b> <a href=3D"mailto:[email-masked]">[email-masked]</a> [<a href=
=3D"mailto:[email-masked]">[email-masked]</a>]<br>
<b>Subject:</b> Re: [Status] Chartering next steps</span><o:p></o:p></p>
<div>
<p class=3D"MsoNormal">I have included the proposed changes and some text t=
hat<br>
clarifies the link-node discussion.<br>
<br>
The current charter text is at <br>
<br>
<a href=3D"https://datatracker.ietf.org/doc/charter-ietf-spring/">https://d=
atatracker.ietf.org/doc/charter-ietf-spring/</a><br>
<br>
The diffs are at<br>
<br>
<a href=3D"https://www.ietf.org/rfcdiff?url1=3Dhttps%3A%2F%2Fdatatracker.ie=
tf.org%2Fdoc%2Fcharter-ietf-spring%2Fwithmilestones-00-00.txt&amp;difftype=
=3D--html&amp;submit=3DGo%21&amp;url2=3Dhttps%3A%2F%2Fdatatracker.ietf.org%=
2Fdoc%2Fcharter-ietf-spring%2Fwithmilestones-00-01.txt">https://www.ietf.or=
g/rfcdiff?url1=3Dhttps%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fcharter-ietf-sp=
ring%2Fwithmilestones-00-00.txt&amp;difftype=3D--html&amp;submit=3DGo!&amp;=
url2=3Dhttps%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fcharter-ietf-spring%2Fwit=
hmilestones-00-01.txt</a><br>
<br>
or if you prefer:<br>
<br>
<b><a href=3D"http://tinyurl.com/o24a9lz">http://tinyurl.com/o24a9lz</a></b=
><br>
<br>
The link node text I added was <br>
<br>
&quot;Steering is achieved by specifying in the packet an ordered <br>
set of nodes and/or links and/or shortest-path-next-hops <br>
to be traversed by the packet.&quot;<br>
<br>
- Stewart<o:p></o:p></p>
</div>
</blockquote>
<p class=3D"MsoNormal"><br>
<br>
<br>
<o:p></o:p></p>
<pre>-- <o:p></o:p></pre>
<pre>For corporate legal information go to:<o:p></o:p></pre>
<pre><o:p>&nbsp;</o:p></pre>
<pre><a href=3D"http://www.cisco.com/web/about/doing_business/legal/cri/ind=
ex.html">http://www.cisco.com/web/about/doing_business/legal/cri/index.html=
</a><o:p></o:p></pre>
<pre><o:p>&nbsp;</o:p></pre>
</div>
</body>
</html>

--_000_7AE6A4247B044C4ABE0A5B6BF427F8E2099078CBdfweml513mbbchi_--

From: John E Drake <[email-masked]>
To: "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>
Date: Mon, 23 Sep 2013 13:36:40 +0000
Accept-Language: en-US
Subject: Re: [Status] Chartering next steps

--_000_195ac307b7714864b8c358b5f425f5a0BY2PR05MB142namprd05pro_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

Stewart,

This looks fine.

Yours Irrespectively,

John

From: [email-masked] [mailto:[email-masked]] On Behalf Of=
 Stewart Bryant
Sent: Monday, September 23, 2013 6:13 AM
To: [email-masked]
Subject: Re: [Status] Chartering next steps

I have included the proposed changes and some text that
clarifies the link-node discussion.

The current charter text is at

https://datatracker.ietf.org/doc/charter-ietf-spring/

The diffs are at

https://www.ietf.org/rfcdiff?url1=3Dhttps%3A%2F%2Fdatatracker.ietf.org%2Fdo=
c%2Fcharter-ietf-spring%2Fwithmilestones-00-00.txt&difftype=3D--html&submit=
=3DGo!&url2=3Dhttps%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fcharter-ietf-sprin=
g%2Fwithmilestones-00-01.txt

or if you prefer:

http://tinyurl.com/o24a9lz

The link node text I added was

"Steering is achieved by specifying in the packet an ordered
set of nodes and/or links and/or shortest-path-next-hops
to be traversed by the packet."

- Stewart

--_000_195ac307b7714864b8c358b5f425f5a0BY2PR05MB142namprd05pro_
Content-Type: text/html; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

<html xmlns:v=3D"urn:schemas-microsoft-com:vml" xmlns:o=3D"urn:schemas-micr=
osoft-com:office:office" xmlns:w=3D"urn:schemas-microsoft-com:office:word" =
xmlns:m=3D"http://schemas.microsoft.com/office/2004/12/omml" xmlns=3D"http:=
//www.w3.org/TR/REC-html40">
<head>
<meta http-equiv=3D"Content-Type" content=3D"text/html; charset=3Dus-ascii"=
>
<meta name=3D"Generator" content=3D"Microsoft Word 15 (filtered medium)">
<style><!--
/* Font Definitions */
@font-face
	{font-family:"Cambria Math";
	panose-1:2 4 5 3 5 4 6 3 2 4;}
@font-face
	{font-family:Calibri;
	panose-1:2 15 5 2 2 2 4 3 2 4;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
	{margin:0in;
	margin-bottom:.0001pt;
	font-size:12.0pt;
	font-family:"Times New Roman","serif";
	color:black;}
a:link, span.MsoHyperlink
	{mso-style-priority:99;
	color:blue;
	text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
	{mso-style-priority:99;
	color:purple;
	text-decoration:underline;}
span.EmailStyle17
	{mso-style-type:personal-reply;
	font-family:"Calibri","sans-serif";
	color:#1F497D;}
.MsoChpDefault
	{mso-style-type:export-only;
	font-size:10.0pt;}
@page WordSection1
	{size:8.5in 11.0in;
	margin:1.0in 1.0in 1.0in 1.0in;}
div.WordSection1
	{page:WordSection1;}
--></style><!--[if gte mso 9]><xml>
<o:shapedefaults v:ext=3D"edit" spidmax=3D"1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
<o:shapelayout v:ext=3D"edit">
<o:idmap v:ext=3D"edit" data=3D"1" />
</o:shapelayout></xml><![endif]-->
</head>
<body bgcolor=3D"white" lang=3D"EN-US" link=3D"blue" vlink=3D"purple">
<div class=3D"WordSection1">
<p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=
libri&quot;,&quot;sans-serif&quot;;color:#1F497D">Stewart,<o:p></o:p></span=
></p>
<p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=
libri&quot;,&quot;sans-serif&quot;;color:#1F497D"><o:p>&nbsp;</o:p></span><=
/p>
<p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=
libri&quot;,&quot;sans-serif&quot;;color:#1F497D">This looks fine.<o:p></o:=
p></span></p>
<p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=
libri&quot;,&quot;sans-serif&quot;;color:#1F497D"><o:p>&nbsp;</o:p></span><=
/p>
<div>
<p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=
libri&quot;,&quot;sans-serif&quot;;color:#1F497D">Yours Irrespectively,<o:p=
></o:p></span></p>
<p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=
libri&quot;,&quot;sans-serif&quot;;color:#1F497D"><o:p>&nbsp;</o:p></span><=
/p>
<p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=
libri&quot;,&quot;sans-serif&quot;;color:#1F497D">John<o:p></o:p></span></p=
>
</div>
<p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=
libri&quot;,&quot;sans-serif&quot;;color:#1F497D"><o:p>&nbsp;</o:p></span><=
/p>
<div style=3D"border:none;border-left:solid blue 1.5pt;padding:0in 0in 0in =
4.0pt">
<div>
<div style=3D"border:none;border-top:solid #E1E1E1 1.0pt;padding:3.0pt 0in =
0in 0in">
<p class=3D"MsoNormal"><b><span style=3D"font-size:11.0pt;font-family:&quot=
;Calibri&quot;,&quot;sans-serif&quot;;color:windowtext">From:</span></b><sp=
an style=3D"font-size:11.0pt;font-family:&quot;Calibri&quot;,&quot;sans-ser=
if&quot;;color:windowtext"> [email-masked] [mailto:status-bounces@=
ietf.org]
<b>On Behalf Of </b>Stewart Bryant<br>
<b>Sent:</b> Monday, September 23, 2013 6:13 AM<br>
<b>To:</b> [email-masked]<br>
<b>Subject:</b> Re: [Status] Chartering next steps<o:p></o:p></span></p>
</div>
</div>
<p class=3D"MsoNormal"><o:p>&nbsp;</o:p></p>
<p class=3D"MsoNormal">I have included the proposed changes and some text t=
hat<br>
clarifies the link-node discussion.<br>
<br>
The current charter text is at <br>
<br>
<a href=3D"https://datatracker.ietf.org/doc/charter-ietf-spring/">https://d=
atatracker.ietf.org/doc/charter-ietf-spring/</a><br>
<br>
The diffs are at<br>
<br>
<a href=3D"https://www.ietf.org/rfcdiff?url1=3Dhttps%3A%2F%2Fdatatracker.ie=
tf.org%2Fdoc%2Fcharter-ietf-spring%2Fwithmilestones-00-00.txt&amp;difftype=
=3D--html&amp;submit=3DGo!&amp;url2=3Dhttps%3A%2F%2Fdatatracker.ietf.org%2F=
doc%2Fcharter-ietf-spring%2Fwithmilestones-00-01.txt">https://www.ietf.org/=
rfcdiff?url1=3Dhttps%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fcharter-ietf-spri=
ng%2Fwithmilestones-00-00.txt&amp;difftype=3D--html&amp;submit=3DGo!&amp;ur=
l2=3Dhttps%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fcharter-ietf-spring%2Fwithm=
ilestones-00-01.txt</a><br>
<br>
or if you prefer:<br>
<br>
<b><a href=3D"http://tinyurl.com/o24a9lz">http://tinyurl.com/o24a9lz</a></b=
><br>
<br>
The link node text I added was <br>
<br>
&quot;Steering is achieved by specifying in the packet an ordered <br>
set of nodes and/or links and/or shortest-path-next-hops <br>
to be traversed by the packet.&quot;<br>
<br>
- Stewart<o:p></o:p></p>
</div>
</div>
</body>
</html>

--_000_195ac307b7714864b8c358b5f425f5a0BY2PR05MB142namprd05pro_--

Date: Mon, 23 Sep 2013 14:36:33 +0100
From: Stewart Bryant <[email-masked]>
To: "[email-masked]" <[email-masked]>
Cc: "Stefano Previdi \(sprevidi\)" <[email-masked]>
Subject: Re: [Status] Chartering next steps
Reply-To: [email-masked]

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

I can take that text out if people wish.

One purpose that it serves is to educate those reviewing the charter 
that have not been following the detail.

I have also updated the BoF placeholder, and this can be found at:

http://trac.tools.ietf.org/bof/trac/wiki/WikiStart

Note that the purpose of the draft list is partially to educate people 
about the subject area and partially to demonstrate that the IETF has 
the energy work on this. I thus hoovered up all the relevant drafts, and 
make no comment about order, or priority, or which will be pursued and 
which will be dropped. If I missed any that was accidental.

- Stewart

On 23/09/2013 14:16, Stefano Previdi (sprevidi) wrote:
> If we go deeper in the charter text discussion we'll end up defining 
> the details of the solution...
>
> s.
>
> Sent from my Android phone using TouchDown (www.nitrodesk.com)
>
> -----Original Message-----
> *From:* Stewart Bryant (stbryant) [[email-masked]]
> *Received:* Monday, 23 Sep 2013, 15:13
> *To:* [email-masked] [[email-masked]]
> *Subject:* Re: [Status] Chartering next steps
>
> I have included the proposed changes and some text that
> clarifies the link-node discussion.
>
> The current charter text is at
>
> https://datatracker.ietf.org/doc/charter-ietf-spring/
>
> The diffs are at
>
> https://www.ietf.org/rfcdiff?url1=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fcharter-ietf-spring%2Fwithmilestones-00-00.txt&difftype=--html&submit=Go!&url2=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fcharter-ietf-spring%2Fwithmilestones-00-01.txt
>
> or if you prefer:
>
> *http://tinyurl.com/o24a9lz*
>
> The link node text I added was
>
> "Steering is achieved by specifying in the packet an ordered
> set of nodes and/or links and/or shortest-path-next-hops
> to be traversed by the packet."
>
> - Stewart

-- 
For corporate legal information go to:

http://www.cisco.com/web/about/doing_business/legal/cri/index.html

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

<html>
  <head>
    <meta content="text/html; charset=ISO-8859-1"
      http-equiv="Content-Type">
  </head>
  <body bgcolor="#FFFFFF" text="#000000">
    <div class="moz-cite-prefix">I can take that text out if people
      wish.<br>
      <br>
      One purpose that it serves is to educate those reviewing the
      charter that have not been following the detail.<br>
      <br>
      I have also updated the BoF placeholder, and this can be found at:<br>
      <br>
      <a class="moz-txt-link-freetext" href="http://trac.tools.ietf.org/bof/trac/wiki/WikiStart">http://trac.tools.ietf.org/bof/trac/wiki/WikiStart</a><br>
      <br>
      Note that the purpose of the draft list is partially to educate
      people about the subject area and partially to demonstrate that
      the IETF has the energy work on this. I thus hoovered up all the
      relevant drafts, and make no comment about order, or priority, or
      which will be pursued and which will be dropped. If I missed any
      that was accidental.<br>
      <br>
      - Stewart<br>
      <br>
      <br>
      On 23/09/2013 14:16, Stefano Previdi (sprevidi) wrote:<br>
    </div>
    <blockquote
cite="mid:[email-masked]"
      type="cite">
      <meta http-equiv="Content-Type" content="text/html;
        charset=ISO-8859-1">
      <span style="font-family:Calibri,Arial,Helvetica,sans-serif;
        font-size:11pt; color:black">If we go deeper in the charter text
        discussion we'll end up defining the details of the solution...<br>
        <br>
        s.<br>
        <br>
        Sent from my Android phone using TouchDown (<a class="moz-txt-link-abbreviated" href="http://www.nitrodesk.com">www.nitrodesk.com</a>)<br>
        <br>
        <span style="color:black">-----Original Message----- <br>
          <b>From:</b> Stewart Bryant (stbryant) [<a class="moz-txt-link-abbreviated" href="mailto:[email-masked]">[email-masked]</a>]<br>
          <b>Received:</b> Monday, 23 Sep 2013, 15:13<br>
          <b>To:</b> <a class="moz-txt-link-abbreviated" href="mailto:[email-masked]">[email-masked]</a> [<a class="moz-txt-link-abbreviated" href="mailto:[email-masked]">[email-masked]</a>]<br>
          <b>Subject:</b> Re: [Status] Chartering next steps<br>
          <br>
        </span></span>
      <div>I have included the proposed changes and some text that<br>
        clarifies the link-node discussion.<br>
        <br>
        The current charter text is at <br>
        <br>
        <a moz-do-not-send="true" class="moz-txt-link-freetext"
          href="https://datatracker.ietf.org/doc/charter-ietf-spring/">https://datatracker.ietf.org/doc/charter-ietf-spring/</a><br>
        <br>
        The diffs are at<br>
        <br>
        <a moz-do-not-send="true" class="moz-txt-link-freetext"
href="https://www.ietf.org/rfcdiff?url1=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fcharter-ietf-spring%2Fwithmilestones-00-00.txt&amp;difftype=--html&amp;submit=Go%21&amp;url2=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fcharter-ietf-spring%2Fwithmilestones-00-01.txt">https://www.ietf.org/rfcdiff?url1=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fcharter-ietf-spring%2Fwithmilestones-00-00.txt&amp;difftype=--html&amp;submit=Go!&amp;url2=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fcharter-ietf-spring%2Fwithmilestones-00-01.txt</a><br>
        <br>
        or if you prefer:<br>
        <br>
        <b><a moz-do-not-send="true" class="moz-txt-link-freetext"
            href="http://tinyurl.com/o24a9lz">http://tinyurl.com/o24a9lz</a></b><br>
        <br>
        The link node text I added was <br>
        <br>
        "Steering is achieved by specifying in the packet an ordered <br>
        set of nodes and/or links and/or shortest-path-next-hops <br>
        to be traversed by the packet."<br>
        <br>
        - Stewart<br>
      </div>
    </blockquote>
    <br>
    <br>
    <pre class="moz-signature" cols="72">-- 
For corporate legal information go to:

<a class="moz-txt-link-freetext" href="http://www.cisco.com/web/about/doing_business/legal/cri/index.html">http://www.cisco.com/web/about/doing_business/legal/cri/index.html</a>

</pre>
  </body>
</html>

--------------000009000908070708090008--

From: "Stefano Previdi (sprevidi)" <[email-masked]>
To: "[email-masked]" <[email-masked]>, "Stewart Bryant (stbryant)" <[email-masked]>
Date: Mon, 23 Sep 2013 13:16:28 +0000
Accept-Language: en-US
Subject: Re: [Status] Chartering next steps

--_000_E0A1DE675FEC854ABF07D319E556FE643F530655xmbrcdx01ciscoc_
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

If we go deeper in the charter text discussion we'll end up defining the de=
tails of the solution...

s.

Sent from my Android phone using TouchDown (www.nitrodesk.com)

-----Original Message-----
From: Stewart Bryant (stbryant) [[email-masked]]
Received: Monday, 23 Sep 2013, 15:13
To: [email-masked] [[email-masked]]
Subject: Re: [Status] Chartering next steps

I have included the proposed changes and some text that
clarifies the link-node discussion.

The current charter text is at

https://datatracker.ietf.org/doc/charter-ietf-spring/

The diffs are at

https://www.ietf.org/rfcdiff?url1=3Dhttps%3A%2F%2Fdatatracker.ietf.org%2Fdo=
c%2Fcharter-ietf-spring%2Fwithmilestones-00-00.txt&difftype=3D--html&submit=
=3DGo!&url2=3Dhttps%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fcharter-ietf-sprin=
g%2Fwithmilestones-00-01.txt

or if you prefer:

http://tinyurl.com/o24a9lz

The link node text I added was

"Steering is achieved by specifying in the packet an ordered
set of nodes and/or links and/or shortest-path-next-hops
to be traversed by the packet."

- Stewart

--_000_E0A1DE675FEC854ABF07D319E556FE643F530655xmbrcdx01ciscoc_
Content-Type: text/html; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<html>
<head>
<meta http-equiv=3D"Content-Type" content=3D"text/html; charset=3Diso-8859-=
1">
</head>
<body bgcolor=3D"#FFFFFF">
<span style=3D"font-family:Calibri,Arial,Helvetica,sans-serif; font-size:11=
pt; color:black">If we go deeper in the charter text discussion we'll end u=
p defining the details of the solution...<br>
<br>
s.<br>
<br>
Sent from my Android phone using TouchDown (www.nitrodesk.com)<br>
<br>
<span style=3D"color:black">-----Original Message----- <br>
<b>From:</b> Stewart Bryant (stbryant) [[email-masked]]<br>
<b>Received:</b> Monday, 23 Sep 2013, 15:13<br>
<b>To:</b> [email-masked] [[email-masked]]<br>
<b>Subject:</b> Re: [Status] Chartering next steps<br>
<br>
</span></span>
<div>I have included the proposed changes and some text that<br>
clarifies the link-node discussion.<br>
<br>
The current charter text is at <br>
<br>
<a class=3D"moz-txt-link-freetext" href=3D"https://datatracker.ietf.org/doc=
/charter-ietf-spring/">https://datatracker.ietf.org/doc/charter-ietf-spring=
/</a><br>
<br>
The diffs are at<br>
<br>
<a class=3D"moz-txt-link-freetext" href=3D"https://www.ietf.org/rfcdiff?url=
1=3Dhttps%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fcharter-ietf-spring%2Fwithmi=
lestones-00-00.txt&amp;difftype=3D--html&amp;submit=3DGo!&amp;url2=3Dhttps%=
3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fcharter-ietf-spring%2Fwithmilestones-0=
0-01.txt">https://www.ietf.org/rfcdiff?url1=3Dhttps%3A%2F%2Fdatatracker.iet=
f.org%2Fdoc%2Fcharter-ietf-spring%2Fwithmilestones-00-00.txt&amp;difftype=
=3D--html&amp;submit=3DGo!&amp;url2=3Dhttps%3A%2F%2Fdatatracker.ietf.org%2F=
doc%2Fcharter-ietf-spring%2Fwithmilestones-00-01.txt</a><br>
<br>
or if you prefer:<br>
<br>
<b><a class=3D"moz-txt-link-freetext" href=3D"http://tinyurl.com/o24a9lz">h=
ttp://tinyurl.com/o24a9lz</a></b><br>
<br>
The link node text I added was <br>
<br>
&quot;Steering is achieved by specifying in the packet an ordered <br>
set of nodes and/or links and/or shortest-path-next-hops <br>
to be traversed by the packet.&quot;<br>
<br>
- Stewart<br>
</div>
</body>
</html>

--_000_E0A1DE675FEC854ABF07D319E556FE643F530655xmbrcdx01ciscoc_--

Date: Mon, 23 Sep 2013 14:12:55 +0100
From: Stewart Bryant <[email-masked]>
To: [email-masked]
Subject: Re: [Status] Chartering next steps
Reply-To: [email-masked]

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

I have included the proposed changes and some text that
clarifies the link-node discussion.

The current charter text is at

https://datatracker.ietf.org/doc/charter-ietf-spring/

The diffs are at

https://www.ietf.org/rfcdiff?url1=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fcharter-ietf-spring%2Fwithmilestones-00-00.txt&difftype=--html&submit=Go!&url2=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fcharter-ietf-spring%2Fwithmilestones-00-01.txt

or if you prefer:

*http://tinyurl.com/o24a9lz*

The link node text I added was

"Steering is achieved by specifying in the packet an ordered
set of nodes and/or links and/or shortest-path-next-hops
to be traversed by the packet."

- Stewart

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

<html>
  <head>
    <meta content="text/html; charset=ISO-8859-1"
      http-equiv="Content-Type">
  </head>
  <body bgcolor="#FFFFFF" text="#000000">
    I have included the proposed changes and some text that<br>
    clarifies the link-node discussion.<br>
    <br>
    The current charter text is at <br>
    <br>
    <a class="moz-txt-link-freetext" href="https://datatracker.ietf.org/doc/charter-ietf-spring/">https://datatracker.ietf.org/doc/charter-ietf-spring/</a><br>
    <br>
    The diffs are at<br>
    <br>
<a class="moz-txt-link-freetext" href="https://www.ietf.org/rfcdiff?url1=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fcharter-ietf-spring%2Fwithmilestones-00-00.txt&amp;difftype=--html&amp;submit=Go!&amp;url2=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fcharter-ietf-spring%2Fwithmilestones-00-01.txt">https://www.ietf.org/rfcdiff?url1=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fcharter-ietf-spring%2Fwithmilestones-00-00.txt&amp;difftype=--html&amp;submit=Go!&amp;url2=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fcharter-ietf-spring%2Fwithmilestones-00-01.txt</a><br>
    <br>
    or if you prefer:<br>
    <br>
    <meta http-equiv="content-type" content="text/html;
      charset=ISO-8859-1">
    <b><a class="moz-txt-link-freetext" href="http://tinyurl.com/o24a9lz">http://tinyurl.com/o24a9lz</a></b><br>
    <br>
    The link node text I added was <br>
    <br>
    <meta http-equiv="content-type" content="text/html;
      charset=ISO-8859-1">
    "Steering is achieved by specifying in the packet an ordered <br>
    set of nodes and/or links and/or shortest-path-next-hops <br>
    to be traversed by the packet."<br>
    <br>
    - Stewart<br>
  </body>
</html>

--------------030209000301020108010408--

Date: Mon, 23 Sep 2013 12:02:54 +0800
From: Loa Andersson <[email-masked]>
To: [email-masked]
Cc: [email-masked]
Subject: Re: [Status] Chartering next steps

Stewart,

I think the proposed text is fine and would be a nice addition.

However, ....

What really concerns me is that there is a slight ambiguity in the list
that the SPRIBNG working group will be chartered for.

Propose that we change:

OLD
o Determine whether the above mentioned procedures require
   modification/changes to the existing MPLS architecture, and
   if so, then document such modifications/changes.
o Determine whether the above mentioned procedures require
   modification/changes to the existing IPv6 architecture, and
   if so, then document such modifications/changes.

NEW
o Determine whether the above mentioned procedures require
   modification/changes to the existing MPLS architecture, and
   if so, then document requirements for such modifications/changes.
o Determine whether the above mentioned procedures require
   modification/changes to the existing IPv6 architecture, and
   if so, then document requirements for such modifications/changes.

OLD
o Changes to MPLS architecture, if needed
o Changes to IPv6 architecture, if needed

NEW
o Requirements for changes to MPLS architecture, if needed
o Requirements for changes to IPv6 architecture, if needed

/Loa

On 2013-09-20 20:39, Stewart Bryant wrote:
> Hi Loa,
>
> That is a good point, here is some text that might be considered for
> inclusion:
>
> "Where possible, existing protocols must be used to implement the SPRING
> function. Any modification or extension of existing architectures or
> protocols must be carried out in the working groups responsible for the
> architectures or protocols being modified in co-ordination with this
> working group, but may be done in this working group after agreement
> with all the relevant WG chairs and responsible ADs."
>
> A good place to put this would be before: "The SPRING working group is
> chartered for the following list of items: "
>
> Would this address your concern?
>
> Stewart
>
>
> On 20/09/2013 12:29, Loa Andersson wrote:
>> Stewart,
>>
>> SPRING is a nice name :).
>>
>> The only thing that I don't find clear in this charter is
>> whether to specify modifications to the data planes and architectures
>> or if the group is supposed to act as a source for requirements for
>> such changes.
>>
>> I hope we can agree to see SPRING as source for requirements for
>> modification where the data plane and architecture has been developed
>> by another active working group.
>>
>> /Loa
>>
>>
>> On 2013-09-20 11:28, Stewart Bryant wrote:
>>> This note is a summary of where we are with chartering the
>>> work that we are discussing on the STATUS list and
>>> the next steps.
>>>
>>> Firstly, as you know we (the ADs) had concerns with the
>>> name "STATUS" being confusing. Having considered quite
>>> a lot of possibilities, and not wanting the discussion
>>> to bog down on a name,  Adrian and I have decided
>>> that the name Source Packet Routing in NetworkinG is
>>> as good as any. Thus SPRING is name that we are using
>>> in the charter process and is that I am putting in the
>>> data-tracker for formal processing.
>>>
>>> Propose to start with the charter text that John Scudder
>>> posted on 17/Sept with the following changes:
>>>
>>> s/<TBD>/SPRING/
>>>
>>> I removed "ordered" from ordered list, as I think there
>>> was a consensus to do so in the following emails in
>>> the thread.
>>>
>>> I have not changed the state text, as I could not see
>>> a consensus on what if any change I should make.
>>>
>>> The charter is uploaded at
>>>
>>> https://datatracker.ietf.org/doc/charter-ietf-spring/
>>>
>>> What we now need the list members to do is to propose
>>> any necessary changes to the text, and I will reflect
>>> the consensus of the group in revised charter text.
>>> The differences in the version of the charter text will
>>> be visible through the datatracker charter diff tool.
>>>
>>> For continuity, discussion will continue on the STATUS
>>> list until we have a chartered WG, at which point the
>>> Secretariat will switch us over.
>>>
>>> For reference the text I uploaded is as follows:
>>>
>>> Name: Source Packet Routing in Networking (SPRING)
>>>
>>> The SPRING working group will define procedures that will allow
>>> a node to steer a packet between any source and destination through
>>> a SPRING region on any path without requiring state to be
>>> maintained by transited nodes, but rather at the source device. A
>>> SPRING region is a network comprised of nodes (which may be of
>>> any type, including routers and appliances) that share the following
>>> trust model: any node in the SPRING region is trusted to steer
>>> a packet through any of the other nodes within the region. The
>>> SPRING region may comprise one or more ASes, or even less than a
>>> single AS. Although a region may comprise more than one AS, initial
>>> work will focus on the intra-domain, that is, single AS, scenario.
>>>
>>> The procedures should support both centralised and distributed path
>>> computation. The procedures should also cover support for OAM
>>> functions.
>>>
>>> Where use cases are documented, care should be taken to define the
>>> data plane requirements for the environment within which they are
>>> to be implemented. The procedures should avoid modifications to
>>> the MPLS data plane, in order to remain compatible with existing
>>> extensive deployments of MPLS. It is anticipated that the procedures
>>> may require modifications to the IPv6 data plane.  While the initial
>>> focus of the SPRING WG is on the intra-domain deployment scenarios
>>> (see below), the modifications to the IPv6 data plane must support
>>> both intra and inter-domain deployment scenarios.
>>>
>>> The SPRING working group is chartered for the following list of
>>> items:
>>>
>>> o Identification and evaluation of use cases for which there
>>>    is consensus within the WG.
>>> o Definition of new procedures, driven by the use cases and underlying
>>>    technology. The new procedures must cover security considerations
>>>    (including the relationship between networks forming the SPRING
>>>    region) and allow for solutions which substantially improve upon
>>>    current technologies by defining requirements, extensions, or new
>>>    functionality in existing routing, management or other protocols.
>>> o Determine whether the above mentioned procedures require
>>>    modification/changes to the existing MPLS architecture, and
>>>    if so, then document such modifications/changes.
>>> o Determine whether the above mentioned procedures require
>>>    modification/changes to the existing IPv6 architecture, and
>>>    if so, then document such modifications/changes.
>>> o The SPRING working group will then develop solutions, focusing
>>>    initially on intra-domain deployment scenarios. Where such
>>>    solutions utilize existing protocols (IS-IS, OSPF, BGP, PCE) this
>>> will
>>>    be done in conjunction with the responsible IETF working group. Work
>>>    on new protocols may be carried out by the SPRING working group.
>>>
>>> The working group will develop the following documents:
>>>
>>> o One or more documents describing SPRING use cases,
>>> o Specification of new procedures to support SPRING use cases,
>>> o Changes to MPLS architecture, if needed
>>> o Changes to IPv6 architecture, if needed
>>> o Document interworking and co-existence between the new procedures
>>>    and the existing MPLS signaling protocols (LDP, RSVP-TE, BGP),
>>> o Document impact (if any) of any proposed IPv6 data plane modifications
>>>    on existing deployment of IPv6,
>>> o A set of one or more protocol extensions requirements documents,
>>> o Inter-operability reports pertaining to the implementation of
>>> extensions
>>>    supporting SPRING.
>>>
>>> Please review and propose changes you think are necessary to the
>>> list.
>>>
>>> - Stewart
>>>
>>>
>>>
>>> _______________________________________________
>>> status mailing list
>>> [email-masked]
>>> https://www.ietf.org/mailman/listinfo/status
>>
>
>
> --
> For corporate legal information go to:
>
> http://www.cisco.com/web/about/doing_business/legal/cri/index.html
>

-- 

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

From: John E Drake <[email-masked]>
To: Sriganesh Kini <[email-masked]>, Lou Berger <[email-masked]>
Date: Fri, 20 Sep 2013 20:17:35 +0000
Accept-Language: en-US
Cc: "Stewart Bryant \(stbryant\)" <[email-masked]>, "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>
Subject: Re: [Status] Chartering next steps

--_000_aa748c6b240642b9bdfecf836e918a48BY2PR05MB142namprd05pro_
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64

--_000_aa748c6b240642b9bdfecf836e918a48BY2PR05MB142namprd05pro_
Content-Type: text/html; charset="utf-8"
Content-Transfer-Encoding: base64

--_000_aa748c6b240642b9bdfecf836e918a48BY2PR05MB142namprd05pro_--

Sender: [email-masked]
From: Sriganesh Kini <[email-masked]>
Date: Fri, 20 Sep 2013 13:05:46 -0700
To: Lou Berger <[email-masked]>
Cc: "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>, "Stewart Bryant \(stbryant\)" <[email-masked]>
Subject: Re: [Status] Chartering next steps

--047d7bf16572f753cd04e6d633fa
Content-Type: text/plain; charset=UTF-8

I agree Lou. Your wording seems fine to me.

On Fri, Sep 20, 2013 at 12:42 PM, Lou Berger <[email-masked]> wrote:

> Sriganesh,
>
> See below.
>
> On 9/20/2013 3:01 PM, Sriganesh Kini wrote:
> >
> >
> >
> > On Fri, Sep 20, 2013 at 7:00 AM, Lou Berger <[email-masked]
> > <mailto:[email-masked]>> wrote:
> >
> >     Stewart,
> >             A comment and a question:
> >     - You say:
> >       any path without requiring state to be maintained by transited
> nodes
> >
> >     I think it would be worth clarifying that no "per-path state" is
> >     required to be maintained. The extensions eluded to below will
> certainly
> >     control/install state per node, just not per path.
> >
> >
> > That is an important distinction. Maybe worthwhile to be explicit that
> > this is applicable both to control and data plane state.
> >
> >
> >
> >     - You say:
> >       any node in the SPRING region is trusted to steer a packet
> >       through any of the other nodes within the region.
> >
> >     To me this limits "steering", and perhaps steering identifiers, to
> the
> >     node level. Is steering at the interface/link level now excluded?
>  The
> >     text should be clear that this is in scope.
> >
> >
> > This could be worded as "steer a packet along an explicit path". That
> > should cover both.
>
> I think this overloads path by having it refer to an end-to-end
> construct (e.g., shortest, non-shortest, explicit, ... ) and an
> interface/segment construct.
>
> How about "along an explicit route"?
>
> Lou
>
> >
> >
> >     Thanks,
> >     Lou
> >
> >     On 09/20/2013 05:28 AM, Stewart Bryant wrote:
> >     > This note is a summary of where we are with chartering the
> >     > work that we are discussing on the STATUS list and
> >     > the next steps.
> >     >
> >     > Firstly, as you know we (the ADs) had concerns with the
> >     > name "STATUS" being confusing. Having considered quite
> >     > a lot of possibilities, and not wanting the discussion
> >     > to bog down on a name,  Adrian and I have decided
> >     > that the name Source Packet Routing in NetworkinG is
> >     > as good as any. Thus SPRING is name that we are using
> >     > in the charter process and is that I am putting in the
> >     > data-tracker for formal processing.
> >     >
> >     > Propose to start with the charter text that John Scudder
> >     > posted on 17/Sept with the following changes:
> >     >
> >     > s/<TBD>/SPRING/
> >     >
> >     > I removed "ordered" from ordered list, as I think there
> >     > was a consensus to do so in the following emails in
> >     > the thread.
> >     >
> >     > I have not changed the state text, as I could not see
> >     > a consensus on what if any change I should make.
> >     >
> >     > The charter is uploaded at
> >     >
> >     > https://datatracker.ietf.org/doc/charter-ietf-spring/
> >     >
> >     > What we now need the list members to do is to propose
> >     > any necessary changes to the text, and I will reflect
> >     > the consensus of the group in revised charter text.
> >     > The differences in the version of the charter text will
> >     > be visible through the datatracker charter diff tool.
> >     >
> >     > For continuity, discussion will continue on the STATUS
> >     > list until we have a chartered WG, at which point the
> >     > Secretariat will switch us over.
> >     >
> >     > For reference the text I uploaded is as follows:
> >     >
> >     > Name: Source Packet Routing in Networking (SPRING)
> >     >
> >     > The SPRING working group will define procedures that will allow
> >     > a node to steer a packet between any source and destination through
> >     > a SPRING region on any path without requiring state to be
> >     > maintained by transited nodes, but rather at the source device.  A
> >     > SPRING region is a network comprised of nodes (which may be of
> >     > any type, including routers and appliances) that share the
> following
> >     > trust model: any node in the SPRING region is trusted to steer
> >     > a packet through any of the other nodes within the region. The
> >     > SPRING region may comprise one or more ASes, or even less than a
> >     > single AS. Although a region may comprise more than one AS, initial
> >     > work will focus on the intra-domain, that is, single AS, scenario.
> >     >
> >     > The procedures should support both centralised and distributed path
> >     > computation. The procedures should also cover support for OAM
> >     > functions.
> >     >
> >     > Where use cases are documented, care should be taken to define the
> >     > data plane requirements for the environment within which they are
> >     > to be implemented. The procedures should avoid modifications to
> >     > the MPLS data plane, in order to remain compatible with existing
> >     > extensive deployments of MPLS. It is anticipated that the
> procedures
> >     > may require modifications to the IPv6 data plane.  While the
> initial
> >     > focus of the SPRING WG is on the intra-domain deployment scenarios
> >     > (see below), the modifications to the IPv6 data plane must support
> >     > both intra and inter-domain deployment scenarios.
> >     >
> >     > The SPRING working group is chartered for the following list of
> >     > items:
> >     >
> >     > o Identification and evaluation of use cases for which there
> >     >   is consensus within the WG.
> >     > o Definition of new procedures, driven by the use cases and
> underlying
> >     >   technology. The new procedures must cover security considerations
> >     >   (including the relationship between networks forming the SPRING
> >     >   region) and allow for solutions which substantially improve upon
> >     >   current technologies by defining requirements, extensions, or new
> >     >   functionality in existing routing, management or other protocols.
> >     > o Determine whether the above mentioned procedures require
> >     >   modification/changes to the existing MPLS architecture, and
> >     >   if so, then document such modifications/changes.
> >     > o Determine whether the above mentioned procedures require
> >     >   modification/changes to the existing IPv6 architecture, and
> >     >   if so, then document such modifications/changes.
> >     > o The SPRING working group will then develop solutions, focusing
> >     >   initially on intra-domain deployment scenarios. Where such
> >     >   solutions utilize existing protocols (IS-IS, OSPF, BGP, PCE)
> >     this will
> >     >   be done in conjunction with the responsible IETF working group.
> Work
> >     >   on new protocols may be carried out by the SPRING working group.
> >     >
> >     > The working group will develop the following documents:
> >     >
> >     > o One or more documents describing SPRING use cases,
> >     > o Specification of new procedures to support SPRING use cases,
> >     > o Changes to MPLS architecture, if needed
> >     > o Changes to IPv6 architecture, if needed
> >     > o Document interworking and co-existence between the new procedures
> >     >   and the existing MPLS signaling protocols (LDP, RSVP-TE, BGP),
> >     > o Document impact (if any) of any proposed IPv6 data plane
> >     modifications
> >     >   on existing deployment of IPv6,
> >     > o A set of one or more protocol extensions requirements documents,
> >     > o Inter-operability reports pertaining to the implementation of
> >     extensions
> >     >   supporting SPRING.
> >     >
> >     > Please review and propose changes you think are necessary to the
> >     > list.
> >     >
> >     > - Stewart
> >     >
> >     >
> >     >
> >     > _______________________________________________
> >     > status mailing list
> >     > [email-masked] <mailto:[email-masked]>
> >     > https://www.ietf.org/mailman/listinfo/status
> >     >
> >
> >     _______________________________________________
> >     status mailing list
> >     [email-masked] <mailto:[email-masked]>
> >     https://www.ietf.org/mailman/listinfo/status
> >
> >
> >
> >
> > _______________________________________________
> > status mailing list
> > [email-masked]
> > https://www.ietf.org/mailman/listinfo/status
> >
> _______________________________________________
> status mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/status
>

--047d7bf16572f753cd04e6d633fa
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">I agree Lou. Your wording seems fine to me.</div><div clas=
s=3D"gmail_extra"><br><br><div class=3D"gmail_quote">On Fri, Sep 20, 2013 a=
t 12:42 PM, Lou Berger <span dir=3D"ltr">&lt;<a href=3D"mailto:lberger@labn=
.net" target=3D"_blank">[email-masked]</a>&gt;</span> wrote:<br>

<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex">Sriganesh,<br>
<br>
See below.<br>
<div class=3D"im"><br>
On 9/20/2013 3:01 PM, Sriganesh Kini wrote:<br>
&gt;<br>
&gt;<br>
&gt;<br>
&gt; On Fri, Sep 20, 2013 at 7:00 AM, Lou Berger &lt;<a href=3D"mailto:lber=
[email-masked]">[email-masked]</a><br>
</div><div class=3D"im">&gt; &lt;mailto:<a href=3D"mailto:[email-masked]"=
>[email-masked]</a>&gt;&gt; wrote:<br>
&gt;<br>
&gt; =C2=A0 =C2=A0 Stewart,<br>
&gt; =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 A comment and a question:<br=
>
&gt; =C2=A0 =C2=A0 - You say:<br>
&gt; =C2=A0 =C2=A0 =C2=A0 any path without requiring state to be maintained=
 by transited nodes<br>
&gt;<br>
&gt; =C2=A0 =C2=A0 I think it would be worth clarifying that no &quot;per-p=
ath state&quot; is<br>
&gt; =C2=A0 =C2=A0 required to be maintained. The extensions eluded to belo=
w will certainly<br>
&gt; =C2=A0 =C2=A0 control/install state per node, just not per path.<br>
&gt;<br>
&gt;<br>
&gt; That is an important distinction. Maybe worthwhile to be explicit that=
<br>
&gt; this is applicable both to control and data plane state.<br>
&gt;<br>
&gt;<br>
&gt;<br>
&gt; =C2=A0 =C2=A0 - You say:<br>
&gt; =C2=A0 =C2=A0 =C2=A0 any node in the SPRING region is trusted to steer=
 a packet<br>
&gt; =C2=A0 =C2=A0 =C2=A0 through any of the other nodes within the region.=
<br>
&gt;<br>
&gt; =C2=A0 =C2=A0 To me this limits &quot;steering&quot;, and perhaps stee=
ring identifiers, to the<br>
&gt; =C2=A0 =C2=A0 node level. Is steering at the interface/link level now =
excluded? =C2=A0The<br>
&gt; =C2=A0 =C2=A0 text should be clear that this is in scope.<br>
&gt;<br>
&gt;<br>
&gt; This could be worded as &quot;steer a packet along an explicit path&qu=
ot;. That<br>
&gt; should cover both.<br>
<br>
</div>I think this overloads path by having it refer to an end-to-end<br>
construct (e.g., shortest, non-shortest, explicit, ... ) and an<br>
interface/segment construct.<br>
<br>
How about &quot;along an explicit route&quot;?<br>
<br>
Lou<br>
<div><div class=3D"h5"><br>
&gt;<br>
&gt;<br>
&gt; =C2=A0 =C2=A0 Thanks,<br>
&gt; =C2=A0 =C2=A0 Lou<br>
&gt;<br>
&gt; =C2=A0 =C2=A0 On 09/20/2013 05:28 AM, Stewart Bryant wrote:<br>
&gt; =C2=A0 =C2=A0 &gt; This note is a summary of where we are with charter=
ing the<br>
&gt; =C2=A0 =C2=A0 &gt; work that we are discussing on the STATUS list and<=
br>
&gt; =C2=A0 =C2=A0 &gt; the next steps.<br>
&gt; =C2=A0 =C2=A0 &gt;<br>
&gt; =C2=A0 =C2=A0 &gt; Firstly, as you know we (the ADs) had concerns with=
 the<br>
&gt; =C2=A0 =C2=A0 &gt; name &quot;STATUS&quot; being confusing. Having con=
sidered quite<br>
&gt; =C2=A0 =C2=A0 &gt; a lot of possibilities, and not wanting the discuss=
ion<br>
&gt; =C2=A0 =C2=A0 &gt; to bog down on a name, =C2=A0Adrian and I have deci=
ded<br>
&gt; =C2=A0 =C2=A0 &gt; that the name Source Packet Routing in NetworkinG i=
s<br>
&gt; =C2=A0 =C2=A0 &gt; as good as any. Thus SPRING is name that we are usi=
ng<br>
&gt; =C2=A0 =C2=A0 &gt; in the charter process and is that I am putting in =
the<br>
&gt; =C2=A0 =C2=A0 &gt; data-tracker for formal processing.<br>
&gt; =C2=A0 =C2=A0 &gt;<br>
&gt; =C2=A0 =C2=A0 &gt; Propose to start with the charter text that John Sc=
udder<br>
&gt; =C2=A0 =C2=A0 &gt; posted on 17/Sept with the following changes:<br>
&gt; =C2=A0 =C2=A0 &gt;<br>
&gt; =C2=A0 =C2=A0 &gt; s/&lt;TBD&gt;/SPRING/<br>
&gt; =C2=A0 =C2=A0 &gt;<br>
&gt; =C2=A0 =C2=A0 &gt; I removed &quot;ordered&quot; from ordered list, as=
 I think there<br>
&gt; =C2=A0 =C2=A0 &gt; was a consensus to do so in the following emails in=
<br>
&gt; =C2=A0 =C2=A0 &gt; the thread.<br>
&gt; =C2=A0 =C2=A0 &gt;<br>
&gt; =C2=A0 =C2=A0 &gt; I have not changed the state text, as I could not s=
ee<br>
&gt; =C2=A0 =C2=A0 &gt; a consensus on what if any change I should make.<br=
>
&gt; =C2=A0 =C2=A0 &gt;<br>
&gt; =C2=A0 =C2=A0 &gt; The charter is uploaded at<br>
&gt; =C2=A0 =C2=A0 &gt;<br>
&gt; =C2=A0 =C2=A0 &gt; <a href=3D"https://datatracker.ietf.org/doc/charter=
-ietf-spring/" target=3D"_blank">https://datatracker.ietf.org/doc/charter-i=
etf-spring/</a><br>
&gt; =C2=A0 =C2=A0 &gt;<br>
&gt; =C2=A0 =C2=A0 &gt; What we now need the list members to do is to propo=
se<br>
&gt; =C2=A0 =C2=A0 &gt; any necessary changes to the text, and I will refle=
ct<br>
&gt; =C2=A0 =C2=A0 &gt; the consensus of the group in revised charter text.=
<br>
&gt; =C2=A0 =C2=A0 &gt; The differences in the version of the charter text =
will<br>
&gt; =C2=A0 =C2=A0 &gt; be visible through the datatracker charter diff too=
l.<br>
&gt; =C2=A0 =C2=A0 &gt;<br>
&gt; =C2=A0 =C2=A0 &gt; For continuity, discussion will continue on the STA=
TUS<br>
&gt; =C2=A0 =C2=A0 &gt; list until we have a chartered WG, at which point t=
he<br>
&gt; =C2=A0 =C2=A0 &gt; Secretariat will switch us over.<br>
&gt; =C2=A0 =C2=A0 &gt;<br>
&gt; =C2=A0 =C2=A0 &gt; For reference the text I uploaded is as follows:<br=
>
&gt; =C2=A0 =C2=A0 &gt;<br>
&gt; =C2=A0 =C2=A0 &gt; Name: Source Packet Routing in Networking (SPRING)<=
br>
&gt; =C2=A0 =C2=A0 &gt;<br>
&gt; =C2=A0 =C2=A0 &gt; The SPRING working group will define procedures tha=
t will allow<br>
&gt; =C2=A0 =C2=A0 &gt; a node to steer a packet between any source and des=
tination through<br>
&gt; =C2=A0 =C2=A0 &gt; a SPRING region on any path without requiring state=
 to be<br>
&gt; =C2=A0 =C2=A0 &gt; maintained by transited nodes, but rather at the so=
urce device. =C2=A0A<br>
&gt; =C2=A0 =C2=A0 &gt; SPRING region is a network comprised of nodes (whic=
h may be of<br>
&gt; =C2=A0 =C2=A0 &gt; any type, including routers and appliances) that sh=
are the following<br>
&gt; =C2=A0 =C2=A0 &gt; trust model: any node in the SPRING region is trust=
ed to steer<br>
&gt; =C2=A0 =C2=A0 &gt; a packet through any of the other nodes within the =
region. The<br>
&gt; =C2=A0 =C2=A0 &gt; SPRING region may comprise one or more ASes, or eve=
n less than a<br>
&gt; =C2=A0 =C2=A0 &gt; single AS. Although a region may comprise more than=
 one AS, initial<br>
&gt; =C2=A0 =C2=A0 &gt; work will focus on the intra-domain, that is, singl=
e AS, scenario.<br>
&gt; =C2=A0 =C2=A0 &gt;<br>
&gt; =C2=A0 =C2=A0 &gt; The procedures should support both centralised and =
distributed path<br>
&gt; =C2=A0 =C2=A0 &gt; computation. The procedures should also cover suppo=
rt for OAM<br>
&gt; =C2=A0 =C2=A0 &gt; functions.<br>
&gt; =C2=A0 =C2=A0 &gt;<br>
&gt; =C2=A0 =C2=A0 &gt; Where use cases are documented, care should be take=
n to define the<br>
&gt; =C2=A0 =C2=A0 &gt; data plane requirements for the environment within =
which they are<br>
&gt; =C2=A0 =C2=A0 &gt; to be implemented. The procedures should avoid modi=
fications to<br>
&gt; =C2=A0 =C2=A0 &gt; the MPLS data plane, in order to remain compatible =
with existing<br>
&gt; =C2=A0 =C2=A0 &gt; extensive deployments of MPLS. It is anticipated th=
at the procedures<br>
&gt; =C2=A0 =C2=A0 &gt; may require modifications to the IPv6 data plane. =
=C2=A0While the initial<br>
&gt; =C2=A0 =C2=A0 &gt; focus of the SPRING WG is on the intra-domain deplo=
yment scenarios<br>
&gt; =C2=A0 =C2=A0 &gt; (see below), the modifications to the IPv6 data pla=
ne must support<br>
&gt; =C2=A0 =C2=A0 &gt; both intra and inter-domain deployment scenarios.<b=
r>
&gt; =C2=A0 =C2=A0 &gt;<br>
&gt; =C2=A0 =C2=A0 &gt; The SPRING working group is chartered for the follo=
wing list of<br>
&gt; =C2=A0 =C2=A0 &gt; items:<br>
&gt; =C2=A0 =C2=A0 &gt;<br>
&gt; =C2=A0 =C2=A0 &gt; o Identification and evaluation of use cases for wh=
ich there<br>
&gt; =C2=A0 =C2=A0 &gt; =C2=A0 is consensus within the WG.<br>
&gt; =C2=A0 =C2=A0 &gt; o Definition of new procedures, driven by the use c=
ases and underlying<br>
&gt; =C2=A0 =C2=A0 &gt; =C2=A0 technology. The new procedures must cover se=
curity considerations<br>
&gt; =C2=A0 =C2=A0 &gt; =C2=A0 (including the relationship between networks=
 forming the SPRING<br>
&gt; =C2=A0 =C2=A0 &gt; =C2=A0 region) and allow for solutions which substa=
ntially improve upon<br>
&gt; =C2=A0 =C2=A0 &gt; =C2=A0 current technologies by defining requirement=
s, extensions, or new<br>
&gt; =C2=A0 =C2=A0 &gt; =C2=A0 functionality in existing routing, managemen=
t or other protocols.<br>
&gt; =C2=A0 =C2=A0 &gt; o Determine whether the above mentioned procedures =
require<br>
&gt; =C2=A0 =C2=A0 &gt; =C2=A0 modification/changes to the existing MPLS ar=
chitecture, and<br>
&gt; =C2=A0 =C2=A0 &gt; =C2=A0 if so, then document such modifications/chan=
ges.<br>
&gt; =C2=A0 =C2=A0 &gt; o Determine whether the above mentioned procedures =
require<br>
&gt; =C2=A0 =C2=A0 &gt; =C2=A0 modification/changes to the existing IPv6 ar=
chitecture, and<br>
&gt; =C2=A0 =C2=A0 &gt; =C2=A0 if so, then document such modifications/chan=
ges.<br>
&gt; =C2=A0 =C2=A0 &gt; o The SPRING working group will then develop soluti=
ons, focusing<br>
&gt; =C2=A0 =C2=A0 &gt; =C2=A0 initially on intra-domain deployment scenari=
os. Where such<br>
&gt; =C2=A0 =C2=A0 &gt; =C2=A0 solutions utilize existing protocols (IS-IS,=
 OSPF, BGP, PCE)<br>
&gt; =C2=A0 =C2=A0 this will<br>
&gt; =C2=A0 =C2=A0 &gt; =C2=A0 be done in conjunction with the responsible =
IETF working group. Work<br>
&gt; =C2=A0 =C2=A0 &gt; =C2=A0 on new protocols may be carried out by the S=
PRING working group.<br>
&gt; =C2=A0 =C2=A0 &gt;<br>
&gt; =C2=A0 =C2=A0 &gt; The working group will develop the following docume=
nts:<br>
&gt; =C2=A0 =C2=A0 &gt;<br>
&gt; =C2=A0 =C2=A0 &gt; o One or more documents describing SPRING use cases=
,<br>
&gt; =C2=A0 =C2=A0 &gt; o Specification of new procedures to support SPRING=
 use cases,<br>
&gt; =C2=A0 =C2=A0 &gt; o Changes to MPLS architecture, if needed<br>
&gt; =C2=A0 =C2=A0 &gt; o Changes to IPv6 architecture, if needed<br>
&gt; =C2=A0 =C2=A0 &gt; o Document interworking and co-existence between th=
e new procedures<br>
&gt; =C2=A0 =C2=A0 &gt; =C2=A0 and the existing MPLS signaling protocols (L=
DP, RSVP-TE, BGP),<br>
&gt; =C2=A0 =C2=A0 &gt; o Document impact (if any) of any proposed IPv6 dat=
a plane<br>
&gt; =C2=A0 =C2=A0 modifications<br>
&gt; =C2=A0 =C2=A0 &gt; =C2=A0 on existing deployment of IPv6,<br>
&gt; =C2=A0 =C2=A0 &gt; o A set of one or more protocol extensions requirem=
ents documents,<br>
&gt; =C2=A0 =C2=A0 &gt; o Inter-operability reports pertaining to the imple=
mentation of<br>
&gt; =C2=A0 =C2=A0 extensions<br>
&gt; =C2=A0 =C2=A0 &gt; =C2=A0 supporting SPRING.<br>
&gt; =C2=A0 =C2=A0 &gt;<br>
&gt; =C2=A0 =C2=A0 &gt; Please review and propose changes you think are nec=
essary to the<br>
&gt; =C2=A0 =C2=A0 &gt; list.<br>
&gt; =C2=A0 =C2=A0 &gt;<br>
&gt; =C2=A0 =C2=A0 &gt; - Stewart<br>
&gt; =C2=A0 =C2=A0 &gt;<br>
&gt; =C2=A0 =C2=A0 &gt;<br>
&gt; =C2=A0 =C2=A0 &gt;<br>
&gt; =C2=A0 =C2=A0 &gt; _______________________________________________<br>
&gt; =C2=A0 =C2=A0 &gt; status mailing list<br>
</div></div>&gt; =C2=A0 =C2=A0 &gt; <a href=3D"mailto:[email-masked]">stat=
[email-masked]</a> &lt;mailto:<a href=3D"mailto:[email-masked]">[email-masked]=
rg</a>&gt;<br>
<div class=3D"im">&gt; =C2=A0 =C2=A0 &gt; <a href=3D"https://www.ietf.org/m=
ailman/listinfo/status" target=3D"_blank">https://www.ietf.org/mailman/list=
info/status</a><br>
&gt; =C2=A0 =C2=A0 &gt;<br>
&gt;<br>
&gt; =C2=A0 =C2=A0 _______________________________________________<br>
&gt; =C2=A0 =C2=A0 status mailing list<br>
</div>&gt; =C2=A0 =C2=A0 <a href=3D"mailto:[email-masked]">[email-masked]=
</a> &lt;mailto:<a href=3D"mailto:[email-masked]">[email-masked]</a>&gt;<=
br>
<div class=3D"HOEnZb"><div class=3D"h5">&gt; =C2=A0 =C2=A0 <a href=3D"https=
://www.ietf.org/mailman/listinfo/status" target=3D"_blank">https://www.ietf=
.org/mailman/listinfo/status</a><br>
&gt;<br>
&gt;<br>
&gt;<br>
&gt;<br>
&gt; _______________________________________________<br>
&gt; status mailing list<br>
&gt; <a href=3D"mailto:[email-masked]">[email-masked]</a><br>
&gt; <a href=3D"https://www.ietf.org/mailman/listinfo/status" target=3D"_bl=
ank">https://www.ietf.org/mailman/listinfo/status</a><br>
&gt;<br>
_______________________________________________<br>
status mailing list<br>
<a href=3D"mailto:[email-masked]">[email-masked]</a><br>
<a href=3D"https://www.ietf.org/mailman/listinfo/status" target=3D"_blank">=
https://www.ietf.org/mailman/listinfo/status</a><br>
</div></div></blockquote></div><br></div>

--047d7bf16572f753cd04e6d633fa--

Date: Fri, 20 Sep 2013 15:42:27 -0400
From: Lou Berger <[email-masked]>
To: Sriganesh Kini <[email-masked]>
Cc: "Stewart Bryant \(stbryant\)" <[email-masked]>, "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>
Subject: Re: [Status] Chartering next steps

Sriganesh,

See below.

On 9/20/2013 3:01 PM, Sriganesh Kini wrote:
> 
> 
> 
> On Fri, Sep 20, 2013 at 7:00 AM, Lou Berger <[email-masked]
> <mailto:[email-masked]>> wrote:
> 
>     Stewart,
>             A comment and a question:
>     - You say:
>       any path without requiring state to be maintained by transited nodes
> 
>     I think it would be worth clarifying that no "per-path state" is
>     required to be maintained. The extensions eluded to below will certainly
>     control/install state per node, just not per path.
> 
> 
> That is an important distinction. Maybe worthwhile to be explicit that
> this is applicable both to control and data plane state.
>  
> 
> 
>     - You say:
>       any node in the SPRING region is trusted to steer a packet
>       through any of the other nodes within the region.
> 
>     To me this limits "steering", and perhaps steering identifiers, to the
>     node level. Is steering at the interface/link level now excluded?  The
>     text should be clear that this is in scope.
> 
> 
> This could be worded as "steer a packet along an explicit path". That
> should cover both.

I think this overloads path by having it refer to an end-to-end
construct (e.g., shortest, non-shortest, explicit, ... ) and an
interface/segment construct.

How about "along an explicit route"?

Lou

> 
> 
>     Thanks,
>     Lou
> 
>     On 09/20/2013 05:28 AM, Stewart Bryant wrote:
>     > This note is a summary of where we are with chartering the
>     > work that we are discussing on the STATUS list and
>     > the next steps.
>     >
>     > Firstly, as you know we (the ADs) had concerns with the
>     > name "STATUS" being confusing. Having considered quite
>     > a lot of possibilities, and not wanting the discussion
>     > to bog down on a name,  Adrian and I have decided
>     > that the name Source Packet Routing in NetworkinG is
>     > as good as any. Thus SPRING is name that we are using
>     > in the charter process and is that I am putting in the
>     > data-tracker for formal processing.
>     >
>     > Propose to start with the charter text that John Scudder
>     > posted on 17/Sept with the following changes:
>     >
>     > s/<TBD>/SPRING/
>     >
>     > I removed "ordered" from ordered list, as I think there
>     > was a consensus to do so in the following emails in
>     > the thread.
>     >
>     > I have not changed the state text, as I could not see
>     > a consensus on what if any change I should make.
>     >
>     > The charter is uploaded at
>     >
>     > https://datatracker.ietf.org/doc/charter-ietf-spring/
>     >
>     > What we now need the list members to do is to propose
>     > any necessary changes to the text, and I will reflect
>     > the consensus of the group in revised charter text.
>     > The differences in the version of the charter text will
>     > be visible through the datatracker charter diff tool.
>     >
>     > For continuity, discussion will continue on the STATUS
>     > list until we have a chartered WG, at which point the
>     > Secretariat will switch us over.
>     >
>     > For reference the text I uploaded is as follows:
>     >
>     > Name: Source Packet Routing in Networking (SPRING)
>     >
>     > The SPRING working group will define procedures that will allow
>     > a node to steer a packet between any source and destination through
>     > a SPRING region on any path without requiring state to be
>     > maintained by transited nodes, but rather at the source device.  A
>     > SPRING region is a network comprised of nodes (which may be of
>     > any type, including routers and appliances) that share the following
>     > trust model: any node in the SPRING region is trusted to steer
>     > a packet through any of the other nodes within the region. The
>     > SPRING region may comprise one or more ASes, or even less than a
>     > single AS. Although a region may comprise more than one AS, initial
>     > work will focus on the intra-domain, that is, single AS, scenario.
>     >
>     > The procedures should support both centralised and distributed path
>     > computation. The procedures should also cover support for OAM
>     > functions.
>     >
>     > Where use cases are documented, care should be taken to define the
>     > data plane requirements for the environment within which they are
>     > to be implemented. The procedures should avoid modifications to
>     > the MPLS data plane, in order to remain compatible with existing
>     > extensive deployments of MPLS. It is anticipated that the procedures
>     > may require modifications to the IPv6 data plane.  While the initial
>     > focus of the SPRING WG is on the intra-domain deployment scenarios
>     > (see below), the modifications to the IPv6 data plane must support
>     > both intra and inter-domain deployment scenarios.
>     >
>     > The SPRING working group is chartered for the following list of
>     > items:
>     >
>     > o Identification and evaluation of use cases for which there
>     >   is consensus within the WG.
>     > o Definition of new procedures, driven by the use cases and underlying
>     >   technology. The new procedures must cover security considerations
>     >   (including the relationship between networks forming the SPRING
>     >   region) and allow for solutions which substantially improve upon
>     >   current technologies by defining requirements, extensions, or new
>     >   functionality in existing routing, management or other protocols.
>     > o Determine whether the above mentioned procedures require
>     >   modification/changes to the existing MPLS architecture, and
>     >   if so, then document such modifications/changes.
>     > o Determine whether the above mentioned procedures require
>     >   modification/changes to the existing IPv6 architecture, and
>     >   if so, then document such modifications/changes.
>     > o The SPRING working group will then develop solutions, focusing
>     >   initially on intra-domain deployment scenarios. Where such
>     >   solutions utilize existing protocols (IS-IS, OSPF, BGP, PCE)
>     this will
>     >   be done in conjunction with the responsible IETF working group. Work
>     >   on new protocols may be carried out by the SPRING working group.
>     >
>     > The working group will develop the following documents:
>     >
>     > o One or more documents describing SPRING use cases,
>     > o Specification of new procedures to support SPRING use cases,
>     > o Changes to MPLS architecture, if needed
>     > o Changes to IPv6 architecture, if needed
>     > o Document interworking and co-existence between the new procedures
>     >   and the existing MPLS signaling protocols (LDP, RSVP-TE, BGP),
>     > o Document impact (if any) of any proposed IPv6 data plane
>     modifications
>     >   on existing deployment of IPv6,
>     > o A set of one or more protocol extensions requirements documents,
>     > o Inter-operability reports pertaining to the implementation of
>     extensions
>     >   supporting SPRING.
>     >
>     > Please review and propose changes you think are necessary to the
>     > list.
>     >
>     > - Stewart
>     >
>     >
>     >
>     > _______________________________________________
>     > status mailing list
>     > [email-masked] <mailto:[email-masked]>
>     > https://www.ietf.org/mailman/listinfo/status
>     >
> 
>     _______________________________________________
>     status mailing list
>     [email-masked] <mailto:[email-masked]>
>     https://www.ietf.org/mailman/listinfo/status
> 
> 
> 
> 
> _______________________________________________
> status mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/status
> 

From: "John G. Scudder" <[email-masked]>
Date: Fri, 20 Sep 2013 15:18:42 -0400
To: Loa Andersson <[email-masked]>
Cc: [email-masked], [email-masked], [email-masked], [email-masked]
Subject: Re: [Status] TBD Charter - ready of RTG AD review yes/no

--Apple-Mail=_83F36047-5D32-44B9-90F3-285AC42EDB18
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset="us-ascii"

[Thanks, Ruediger, for reminding me of this]

Loa,

I think your proposed change is good.

Thanks,

--John

On Sep 19, 2013, at 11:48 AM, Loa Andersson <[email-masked]> wrote:

> Ruediger,
>=20
> it depends on what you mean with "document such =
modifications/changes".
> Almost everything we do in the IETF is documents - we are documenting.
>=20
> In this case I assume you mean "document the requirements for such
> changes" and then let the the working group that owns the particular
> data plane specify the actual changes.
>=20
> Otherwise this look pretty good.
>=20
> /Loa
>=20
> On 2013-09-19 08:33, [email-masked] wrote:
>> John,
>>=20
>> there's another detail which should be clarified:
>>=20
>>> The <Name-TBD> working group is chartered for the following =
(ordered) list of items:
>> ....
>>=20
>> I'd expect work related to MPLS based SR to start relatively soon, =
while work on IPv6 based SR may require a more thorough analysis. The =
"(ordered)" therefore should be removed or the  order should be adapted =
to express that:
>>=20
>>   o Determine whether the above mentioned procedures require
>>     modification/changes to the existing MPLS architecture, and
>>     if so, then document such modifications/changes.
>>   o Determine whether the above mentioned procedures require
>>     modification/changes to the existing IPv6 architecture, and
>>     if so, then document such modifications/changes.
>>     In parallel, the <Name-TBD> working group will develop
>>     solutions for a MPLS architecture, focusing initially on
>>     intra-domain deployment scenarios. Where such solutions
>>     utilize existing protocols (IS-IS, OSPF, BGP, PCE) this will
>>     be done in conjunction with the responsible IETF working group. =
Work
>>     on new protocols may be carried out by the <Name-TBD> working =
group.
>>   o The <Name-TBD> working group will then develop solutions for an =
IPv6
>>     architecture, focusing initially on intra-domain deployment =
scenarios.
>>     Where such solutions utilize existing protocols (IS-IS, OSPF, =
BGP, PCE)
>>     this will be done in conjunction with the responsible IETF =
working group.
>>     Work on new protocols may be carried out by the <Name-TBD> =
working group.
>>=20
>> Regards,
>>=20
>> Ruediger
>>=20
>>=20
>>> -----Original Message-----
>>> From: [email-masked] [mailto:[email-masked]] On
>>> Behalf Of John G.Scudder
>>> Sent: Tuesday, September 17, 2013 7:22 AM
>>> To: [email-masked]
>>> Cc: Adrian Farrel; [email-masked]
>>> Subject: Re: [Status] TBD Charter - ready of RTG AD review yes/no
>>>=20
>>> All,
>>>=20
>>> Here's another attempt. It tries to address the 'architecture' issue =
I raised earlier, as well as incorporate Mark Townsley, Bruno Decraene =
and Rob Shakir's comments. With luck the change from '<Name-TBD> domain' =
to '<Name-TBD> region' relieves the ambiguity that was present in =
earlier versions.
>>>=20
>>> --John
>>>=20
>>> ---------------------------------------------------------
>>> Name: <TBD>
>>>=20
>>> The <Name-TBD> working group will define procedures that will allow =
a node to steer a packet between any source and destination through a =
<Name-TBD> region on any path without requiring state to be maintained =
by transited nodes, but rather at the source device.  A <Name-TBD> =
region is a network comprised of nodes (which may be of any type, =
including routers and appliances) that share the following trust model: =
any node in the <Name-TBD> region is trusted to steer a packet through =
any of the other nodes within the region. The <Name-TBD> region may =
comprise one or more ASes, or even less than a single AS. Although a =
region may comprise more than one AS, initial work will focus on the =
intra-domain, that is, single AS, scenario.
>>>=20
>>> The procedures should support both centralised and distributed path =
computation. The procedures should also cover support for OAM functions.
>>>=20
>>> Where use cases are documented, care should be taken to define the =
data plane requirements for the environment within which they are to be =
implemented. The procedures should avoid modifications to the MPLS data =
plane, in order to remain compatible with existing extensive deployments =
of MPLS. It is anticipated that the procedures may require modifications =
to the IPv6 data plane.  While the initial focus of the <Name-TBD> WG is =
on the intra-domain deployment scenarios (see below), the modifications =
to the IPv6 data plane must support both intra and inter-domain =
deployment scenarios.
>>>=20
>>> The <Name-TBD> working group is chartered for the following =
(ordered) list of items:
>>>=20
>>> o Identification and evaluation of use cases for which there
>>>   is consensus within the WG.
>>> o Definition of new procedures, driven by the use cases and =
underlying
>>>   technology. The new procedures must cover security considerations
>>>   (including the relationship between networks forming the =
<Name-TBD>
>>>   region) and allow for solutions which substantially improve upon
>>>   current technologies by defining requirements, extensions, or new
>>>   functionality in existing routing, management or other protocols.
>>> o Determine whether the above mentioned procedures require
>>>   modification/changes to the existing MPLS architecture, and
>>>   if so, then document such modifications/changes.
>>> o Determine whether the above mentioned procedures require
>>>   modification/changes to the existing IPv6 architecture, and
>>>   if so, then document such modifications/changes.
>>> o The <Name-TBD> working group will then develop solutions, focusing
>>>   initially on intra-domain deployment scenarios. Where such
>>>   solutions utilize existing protocols (IS-IS, OSPF, BGP, PCE) this =
will
>>>   be done in conjunction with the responsible IETF working group. =
Work
>>>   on new protocols may be carried out by the <Name-TBD> working =
group.
>>>=20
>>> The working group will develop the following documents:
>>>=20
>>> o One or more documents describing <Name-TBD> use cases, o =
Specification of new procedures to support <Name-TBD> use cases, o =
Changes to MPLS architecture, if needed o Changes to IPv6 architecture, =
if needed o Document interworking and co-existence between the new =
procedures
>>>   and the existing MPLS signaling protocols (LDP, RSVP-TE, BGP), o =
Document impact (if any) of any proposed IPv6 data plane modifications
>>>   on existing deployment of IPv6,
>>> o A set of one or more protocol extensions requirements documents, o =
Inter-operability reports pertaining to the implementation of extensions
>>>   supporting <Name-TBD>.
>>> _______________________________________________
>>> status mailing list
>>> [email-masked]
>>> https://www.ietf.org/mailman/listinfo/status
>>> _______________________________________________
>>> status mailing list
>>> [email-masked]
>>> https://www.ietf.org/mailman/listinfo/status
>> _______________________________________________
>> status mailing list
>> [email-masked]
>> https://www.ietf.org/mailman/listinfo/status
>> _______________________________________________
>> status mailing list
>> [email-masked]
>> https://www.ietf.org/mailman/listinfo/status
>>=20
>=20
> --=20
>=20
>=20
> Loa Andersson                        email: [email-masked]
> Senior MPLS Expert                          [email-masked]
> Huawei Technologies (consultant)     phone: +46 739 81 21 64
> _______________________________________________
> status mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/status
>=20
>=20

--Apple-Mail=_83F36047-5D32-44B9-90F3-285AC42EDB18
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html; charset="us-ascii"

<html><head><meta http-equiv=3D"Content-Type" content=3D"text/html =
charset=3Dus-ascii"></head><body style=3D"word-wrap: break-word; =
-webkit-nbsp-mode: space; -webkit-line-break: after-white-space; =
">[Thanks, Ruediger, for reminding me of =
this]<div><br></div><div>Loa,</div><div><br></div><div>I think your =
proposed change is =
good.</div><div><br></div><div>Thanks,</div><div><br></div><div>--John</di=
v><div><br><div><div>On Sep 19, 2013, at 11:48 AM, Loa Andersson &lt;<a =
href=3D"mailto:[email-masked]">[email-masked]</a>&gt; wrote:</div><br =
class=3D"Apple-interchange-newline"><blockquote =
type=3D"cite">Ruediger,<br><br>it depends on what you mean with =
"document such modifications/changes".<br>Almost everything we do in the =
IETF is documents - we are documenting.<br><br>In this case I assume you =
mean "document the requirements for such<br>changes" and then let the =
the working group that owns the particular<br>data plane specify the =
actual changes.<br><br>Otherwise this look pretty =
good.<br><br>/Loa<br><br>On 2013-09-19 08:33, <a =
href=3D"mailto:[email-masked]">[email-masked]</a> =
wrote:<br><blockquote type=3D"cite">John,<br><br>there's another detail =
which should be clarified:<br><br><blockquote type=3D"cite">The =
&lt;Name-TBD&gt; working group is chartered for the following (ordered) =
list of items:<br></blockquote>....<br><br>I'd expect work related to =
MPLS based SR to start relatively soon, while work on IPv6 based SR may =
require a more thorough analysis. The "(ordered)" therefore should be =
removed or the &nbsp;order should be adapted to express that:<br><br> =
&nbsp;&nbsp;o Determine whether the above mentioned procedures =
require<br> &nbsp;&nbsp;&nbsp;&nbsp;modification/changes to the existing =
MPLS architecture, and<br> &nbsp;&nbsp;&nbsp;&nbsp;if so, then document =
such modifications/changes.<br> &nbsp;&nbsp;o Determine whether the =
above mentioned procedures require<br> =
&nbsp;&nbsp;&nbsp;&nbsp;modification/changes to the existing IPv6 =
architecture, and<br> &nbsp;&nbsp;&nbsp;&nbsp;if so, then document such =
modifications/changes.<br> &nbsp;&nbsp;&nbsp;&nbsp;In parallel, the =
&lt;Name-TBD&gt; working group will develop<br> =
&nbsp;&nbsp;&nbsp;&nbsp;solutions for a MPLS architecture, focusing =
initially on<br> &nbsp;&nbsp;&nbsp;&nbsp;intra-domain deployment =
scenarios. Where such solutions<br> &nbsp;&nbsp;&nbsp;&nbsp;utilize =
existing protocols (IS-IS, OSPF, BGP, PCE) this will<br> =
&nbsp;&nbsp;&nbsp;&nbsp;be done in conjunction with the responsible IETF =
working group. Work<br> &nbsp;&nbsp;&nbsp;&nbsp;on new protocols may be =
carried out by the &lt;Name-TBD&gt; working group.<br> &nbsp;&nbsp;o The =
&lt;Name-TBD&gt; working group will then develop solutions for an =
IPv6<br> &nbsp;&nbsp;&nbsp;&nbsp;architecture, focusing initially on =
intra-domain deployment scenarios.<br> &nbsp;&nbsp;&nbsp;&nbsp;Where =
such solutions utilize existing protocols (IS-IS, OSPF, BGP, PCE)<br> =
&nbsp;&nbsp;&nbsp;&nbsp;this will be done in conjunction with the =
responsible IETF working group.<br> &nbsp;&nbsp;&nbsp;&nbsp;Work on new =
protocols may be carried out by the &lt;Name-TBD&gt; working =
group.<br><br>Regards,<br><br>Ruediger<br><br><br><blockquote =
type=3D"cite">-----Original Message-----<br>From: <a =
href=3D"mailto:[email-masked]">[email-masked]</a> =
[mailto:status-<a href=3D"mailto:[email-masked]">[email-masked]</a>] =
On<br>Behalf Of John G.Scudder<br>Sent: Tuesday, September 17, 2013 7:22 =
AM<br>To: <a =
href=3D"mailto:[email-masked]">[email-masked]</a><br>Cc: Adrian =
Farrel; <a href=3D"mailto:[email-masked]">[email-masked]</a><br>Subject:=
 Re: [Status] TBD Charter - ready of RTG AD review =
yes/no<br><br>All,<br><br>Here's another attempt. It tries to address =
the 'architecture' issue I raised earlier, as well as incorporate Mark =
Townsley, Bruno Decraene and Rob Shakir's comments. With luck the change =
from '&lt;Name-TBD&gt; domain' to '&lt;Name-TBD&gt; region' relieves the =
ambiguity that was present in earlier =
versions.<br><br>--John<br><br>-------------------------------------------=
--------------<br>Name: &lt;TBD&gt;<br><br>The &lt;Name-TBD&gt; working =
group will define procedures that will allow a node to steer a packet =
between any source and destination through a &lt;Name-TBD&gt; region on =
any path without requiring state to be maintained by transited nodes, =
but rather at the source device. &nbsp;A &lt;Name-TBD&gt; region is a =
network comprised of nodes (which may be of any type, including routers =
and appliances) that share the following trust model: any node in the =
&lt;Name-TBD&gt; region is trusted to steer a packet through any of the =
other nodes within the region. The &lt;Name-TBD&gt; region may comprise =
one or more ASes, or even less than a single AS. Although a region may =
comprise more than one AS, initial work will focus on the intra-domain, =
that is, single AS, scenario.<br><br>The procedures should support both =
centralised and distributed path computation. The procedures should also =
cover support for OAM functions.<br><br>Where use cases are documented, =
care should be taken to define the data plane requirements for the =
environment within which they are to be implemented. The procedures =
should avoid modifications to the MPLS data plane, in order to remain =
compatible with existing extensive deployments of MPLS. It is =
anticipated that the procedures may require modifications to the IPv6 =
data plane. &nbsp;While the initial focus of the &lt;Name-TBD&gt; WG is =
on the intra-domain deployment scenarios (see below), the modifications =
to the IPv6 data plane must support both intra and inter-domain =
deployment scenarios.<br><br>The &lt;Name-TBD&gt; working group is =
chartered for the following (ordered) list of items:<br><br>o =
Identification and evaluation of use cases for which there<br> =
&nbsp;&nbsp;is consensus within the WG.<br>o Definition of new =
procedures, driven by the use cases and underlying<br> =
&nbsp;&nbsp;technology. The new procedures must cover security =
considerations<br> &nbsp;&nbsp;(including the relationship between =
networks forming the &lt;Name-TBD&gt;<br> &nbsp;&nbsp;region) and allow =
for solutions which substantially improve upon<br> &nbsp;&nbsp;current =
technologies by defining requirements, extensions, or new<br> =
&nbsp;&nbsp;functionality in existing routing, management or other =
protocols.<br>o Determine whether the above mentioned procedures =
require<br> &nbsp;&nbsp;modification/changes to the existing MPLS =
architecture, and<br> &nbsp;&nbsp;if so, then document such =
modifications/changes.<br>o Determine whether the above mentioned =
procedures require<br> &nbsp;&nbsp;modification/changes to the existing =
IPv6 architecture, and<br> &nbsp;&nbsp;if so, then document such =
modifications/changes.<br>o The &lt;Name-TBD&gt; working group will then =
develop solutions, focusing<br> &nbsp;&nbsp;initially on intra-domain =
deployment scenarios. Where such<br> &nbsp;&nbsp;solutions utilize =
existing protocols (IS-IS, OSPF, BGP, PCE) this will<br> &nbsp;&nbsp;be =
done in conjunction with the responsible IETF working group. Work<br> =
&nbsp;&nbsp;on new protocols may be carried out by the &lt;Name-TBD&gt; =
working group.<br><br>The working group will develop the following =
documents:<br><br>o One or more documents describing &lt;Name-TBD&gt; =
use cases, o Specification of new procedures to support &lt;Name-TBD&gt; =
use cases, o Changes to MPLS architecture, if needed o Changes to IPv6 =
architecture, if needed o Document interworking and co-existence between =
the new procedures<br> &nbsp;&nbsp;and the existing MPLS signaling =
protocols (LDP, RSVP-TE, BGP), o Document impact (if any) of any =
proposed IPv6 data plane modifications<br> &nbsp;&nbsp;on existing =
deployment of IPv6,<br>o A set of one or more protocol extensions =
requirements documents, o Inter-operability reports pertaining to the =
implementation of extensions<br> &nbsp;&nbsp;supporting =
&lt;Name-TBD&gt;.<br>_______________________________________________<br>st=
atus mailing list<br><a =
href=3D"mailto:[email-masked]">[email-masked]</a><br>https://www.ietf.or=
g/mailman/listinfo/status<br>_____________________________________________=
__<br>status mailing =
list<br>[email-masked]<br>https://www.ietf.org/mailman/listinfo/status<br=
></blockquote>_______________________________________________<br>status =
mailing list<br><a =
href=3D"mailto:[email-masked]">[email-masked]</a><br>https://www.ietf.or=
g/mailman/listinfo/status<br>_____________________________________________=
__<br>status mailing =
list<br>[email-masked]<br>https://www.ietf.org/mailman/listinfo/status<br=
><br></blockquote><br>-- <br><br><br>Loa Andersson =
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;email: =
<a =
href=3D"mailto:[email-masked]">[email-masked]</a><br>Senior =
MPLS Expert =
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;<a href=3D"mailto:[email-masked]">[email-masked]</a><br>Huawei Technologies =
(consultant) &nbsp;&nbsp;&nbsp;&nbsp;phone: +46 739 81 21 =
64<br>_______________________________________________<br>status mailing =
list<br><a =
href=3D"mailto:[email-masked]">[email-masked]</a><br>https://www.ietf.or=
g/mailman/listinfo/status<br><br><br></blockquote></div><br></div></body><=
/html>=

--Apple-Mail=_83F36047-5D32-44B9-90F3-285AC42EDB18--

Sender: [email-masked]
From: Sriganesh Kini <[email-masked]>
Date: Fri, 20 Sep 2013 12:01:27 -0700
To: Lou Berger <[email-masked]>
Cc: "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>, "Stewart Bryant \(stbryant\)" <[email-masked]>
Subject: Re: [Status] Chartering next steps

--047d7b111f3ff5614d04e6d54d38
Content-Type: text/plain; charset=UTF-8

On Fri, Sep 20, 2013 at 7:00 AM, Lou Berger <[email-masked]> wrote:

> Stewart,
>         A comment and a question:
> - You say:
>   any path without requiring state to be maintained by transited nodes
>
> I think it would be worth clarifying that no "per-path state" is
> required to be maintained. The extensions eluded to below will certainly
> control/install state per node, just not per path.
>

That is an important distinction. Maybe worthwhile to be explicit that this
is applicable both to control and data plane state.

>
> - You say:
>   any node in the SPRING region is trusted to steer a packet
>   through any of the other nodes within the region.
>
> To me this limits "steering", and perhaps steering identifiers, to the
> node level. Is steering at the interface/link level now excluded?  The
> text should be clear that this is in scope.
>

This could be worded as "steer a packet along an explicit path". That
should cover both.

>
> Thanks,
> Lou
>
> On 09/20/2013 05:28 AM, Stewart Bryant wrote:
> > This note is a summary of where we are with chartering the
> > work that we are discussing on the STATUS list and
> > the next steps.
> >
> > Firstly, as you know we (the ADs) had concerns with the
> > name "STATUS" being confusing. Having considered quite
> > a lot of possibilities, and not wanting the discussion
> > to bog down on a name,  Adrian and I have decided
> > that the name Source Packet Routing in NetworkinG is
> > as good as any. Thus SPRING is name that we are using
> > in the charter process and is that I am putting in the
> > data-tracker for formal processing.
> >
> > Propose to start with the charter text that John Scudder
> > posted on 17/Sept with the following changes:
> >
> > s/<TBD>/SPRING/
> >
> > I removed "ordered" from ordered list, as I think there
> > was a consensus to do so in the following emails in
> > the thread.
> >
> > I have not changed the state text, as I could not see
> > a consensus on what if any change I should make.
> >
> > The charter is uploaded at
> >
> > https://datatracker.ietf.org/doc/charter-ietf-spring/
> >
> > What we now need the list members to do is to propose
> > any necessary changes to the text, and I will reflect
> > the consensus of the group in revised charter text.
> > The differences in the version of the charter text will
> > be visible through the datatracker charter diff tool.
> >
> > For continuity, discussion will continue on the STATUS
> > list until we have a chartered WG, at which point the
> > Secretariat will switch us over.
> >
> > For reference the text I uploaded is as follows:
> >
> > Name: Source Packet Routing in Networking (SPRING)
> >
> > The SPRING working group will define procedures that will allow
> > a node to steer a packet between any source and destination through
> > a SPRING region on any path without requiring state to be
> > maintained by transited nodes, but rather at the source device.  A
> > SPRING region is a network comprised of nodes (which may be of
> > any type, including routers and appliances) that share the following
> > trust model: any node in the SPRING region is trusted to steer
> > a packet through any of the other nodes within the region. The
> > SPRING region may comprise one or more ASes, or even less than a
> > single AS. Although a region may comprise more than one AS, initial
> > work will focus on the intra-domain, that is, single AS, scenario.
> >
> > The procedures should support both centralised and distributed path
> > computation. The procedures should also cover support for OAM
> > functions.
> >
> > Where use cases are documented, care should be taken to define the
> > data plane requirements for the environment within which they are
> > to be implemented. The procedures should avoid modifications to
> > the MPLS data plane, in order to remain compatible with existing
> > extensive deployments of MPLS. It is anticipated that the procedures
> > may require modifications to the IPv6 data plane.  While the initial
> > focus of the SPRING WG is on the intra-domain deployment scenarios
> > (see below), the modifications to the IPv6 data plane must support
> > both intra and inter-domain deployment scenarios.
> >
> > The SPRING working group is chartered for the following list of
> > items:
> >
> > o Identification and evaluation of use cases for which there
> >   is consensus within the WG.
> > o Definition of new procedures, driven by the use cases and underlying
> >   technology. The new procedures must cover security considerations
> >   (including the relationship between networks forming the SPRING
> >   region) and allow for solutions which substantially improve upon
> >   current technologies by defining requirements, extensions, or new
> >   functionality in existing routing, management or other protocols.
> > o Determine whether the above mentioned procedures require
> >   modification/changes to the existing MPLS architecture, and
> >   if so, then document such modifications/changes.
> > o Determine whether the above mentioned procedures require
> >   modification/changes to the existing IPv6 architecture, and
> >   if so, then document such modifications/changes.
> > o The SPRING working group will then develop solutions, focusing
> >   initially on intra-domain deployment scenarios. Where such
> >   solutions utilize existing protocols (IS-IS, OSPF, BGP, PCE) this will
> >   be done in conjunction with the responsible IETF working group. Work
> >   on new protocols may be carried out by the SPRING working group.
> >
> > The working group will develop the following documents:
> >
> > o One or more documents describing SPRING use cases,
> > o Specification of new procedures to support SPRING use cases,
> > o Changes to MPLS architecture, if needed
> > o Changes to IPv6 architecture, if needed
> > o Document interworking and co-existence between the new procedures
> >   and the existing MPLS signaling protocols (LDP, RSVP-TE, BGP),
> > o Document impact (if any) of any proposed IPv6 data plane modifications
> >   on existing deployment of IPv6,
> > o A set of one or more protocol extensions requirements documents,
> > o Inter-operability reports pertaining to the implementation of
> extensions
> >   supporting SPRING.
> >
> > Please review and propose changes you think are necessary to the
> > list.
> >
> > - Stewart
> >
> >
> >
> > _______________________________________________
> > status mailing list
> > [email-masked]
> > https://www.ietf.org/mailman/listinfo/status
> >
>
> _______________________________________________
> status mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/status
>

--047d7b111f3ff5614d04e6d54d38
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><br><div class=3D"gmail_extra"><br><br><div class=3D"gmail=
_quote">On Fri, Sep 20, 2013 at 7:00 AM, Lou Berger <span dir=3D"ltr">&lt;<=
a href=3D"mailto:[email-masked]" target=3D"_blank">[email-masked]</a>&g=
t;</span> wrote:<br>

<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex">Stewart,<br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 A comment and a question:<br>
- You say:<br>
<div class=3D"im">=C2=A0 any path without requiring state to be maintained =
by transited nodes<br>
<br>
</div>I think it would be worth clarifying that no &quot;per-path state&quo=
t; is<br>
required to be maintained. The extensions eluded to below will certainly<br=
>
control/install state per node, just not per path.<br></blockquote><div><br=
></div><div>That is an important distinction. Maybe worthwhile to be explic=
it that this is applicable both to control and data plane state.</div>

<div>=C2=A0</div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8=
ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
- You say:<br>
<div class=3D"im">=C2=A0 any node in the SPRING region is trusted to steer =
a packet<br>
=C2=A0 through any of the other nodes within the region.<br>
<br>
</div>To me this limits &quot;steering&quot;, and perhaps steering identifi=
ers, to the<br>
node level. Is steering at the interface/link level now excluded? =C2=A0The=
<br>
text should be clear that this is in scope.<br></blockquote><div><br></div>=
<div>This could be worded as &quot;steer a packet along an explicit path&qu=
ot;. That should cover both.</div><div>=C2=A0</div><blockquote class=3D"gma=
il_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-lef=
t:1ex">

<br>
Thanks,<br>
Lou<br>
<div class=3D"HOEnZb"><div class=3D"h5"><br>
On 09/20/2013 05:28 AM, Stewart Bryant wrote:<br>
&gt; This note is a summary of where we are with chartering the<br>
&gt; work that we are discussing on the STATUS list and<br>
&gt; the next steps.<br>
&gt;<br>
&gt; Firstly, as you know we (the ADs) had concerns with the<br>
&gt; name &quot;STATUS&quot; being confusing. Having considered quite<br>
&gt; a lot of possibilities, and not wanting the discussion<br>
&gt; to bog down on a name, =C2=A0Adrian and I have decided<br>
&gt; that the name Source Packet Routing in NetworkinG is<br>
&gt; as good as any. Thus SPRING is name that we are using<br>
&gt; in the charter process and is that I am putting in the<br>
&gt; data-tracker for formal processing.<br>
&gt;<br>
&gt; Propose to start with the charter text that John Scudder<br>
&gt; posted on 17/Sept with the following changes:<br>
&gt;<br>
&gt; s/&lt;TBD&gt;/SPRING/<br>
&gt;<br>
&gt; I removed &quot;ordered&quot; from ordered list, as I think there<br>
&gt; was a consensus to do so in the following emails in<br>
&gt; the thread.<br>
&gt;<br>
&gt; I have not changed the state text, as I could not see<br>
&gt; a consensus on what if any change I should make.<br>
&gt;<br>
&gt; The charter is uploaded at<br>
&gt;<br>
&gt; <a href=3D"https://datatracker.ietf.org/doc/charter-ietf-spring/" targ=
et=3D"_blank">https://datatracker.ietf.org/doc/charter-ietf-spring/</a><br>
&gt;<br>
&gt; What we now need the list members to do is to propose<br>
&gt; any necessary changes to the text, and I will reflect<br>
&gt; the consensus of the group in revised charter text.<br>
&gt; The differences in the version of the charter text will<br>
&gt; be visible through the datatracker charter diff tool.<br>
&gt;<br>
&gt; For continuity, discussion will continue on the STATUS<br>
&gt; list until we have a chartered WG, at which point the<br>
&gt; Secretariat will switch us over.<br>
&gt;<br>
&gt; For reference the text I uploaded is as follows:<br>
&gt;<br>
&gt; Name: Source Packet Routing in Networking (SPRING)<br>
&gt;<br>
&gt; The SPRING working group will define procedures that will allow<br>
&gt; a node to steer a packet between any source and destination through<br=
>
&gt; a SPRING region on any path without requiring state to be<br>
&gt; maintained by transited nodes, but rather at the source device. =C2=A0=
A<br>
&gt; SPRING region is a network comprised of nodes (which may be of<br>
&gt; any type, including routers and appliances) that share the following<b=
r>
&gt; trust model: any node in the SPRING region is trusted to steer<br>
&gt; a packet through any of the other nodes within the region. The<br>
&gt; SPRING region may comprise one or more ASes, or even less than a<br>
&gt; single AS. Although a region may comprise more than one AS, initial<br=
>
&gt; work will focus on the intra-domain, that is, single AS, scenario.<br>
&gt;<br>
&gt; The procedures should support both centralised and distributed path<br=
>
&gt; computation. The procedures should also cover support for OAM<br>
&gt; functions.<br>
&gt;<br>
&gt; Where use cases are documented, care should be taken to define the<br>
&gt; data plane requirements for the environment within which they are<br>
&gt; to be implemented. The procedures should avoid modifications to<br>
&gt; the MPLS data plane, in order to remain compatible with existing<br>
&gt; extensive deployments of MPLS. It is anticipated that the procedures<b=
r>
&gt; may require modifications to the IPv6 data plane. =C2=A0While the init=
ial<br>
&gt; focus of the SPRING WG is on the intra-domain deployment scenarios<br>
&gt; (see below), the modifications to the IPv6 data plane must support<br>
&gt; both intra and inter-domain deployment scenarios.<br>
&gt;<br>
&gt; The SPRING working group is chartered for the following list of<br>
&gt; items:<br>
&gt;<br>
&gt; o Identification and evaluation of use cases for which there<br>
&gt; =C2=A0 is consensus within the WG.<br>
&gt; o Definition of new procedures, driven by the use cases and underlying=
<br>
&gt; =C2=A0 technology. The new procedures must cover security consideratio=
ns<br>
&gt; =C2=A0 (including the relationship between networks forming the SPRING=
<br>
&gt; =C2=A0 region) and allow for solutions which substantially improve upo=
n<br>
&gt; =C2=A0 current technologies by defining requirements, extensions, or n=
ew<br>
&gt; =C2=A0 functionality in existing routing, management or other protocol=
s.<br>
&gt; o Determine whether the above mentioned procedures require<br>
&gt; =C2=A0 modification/changes to the existing MPLS architecture, and<br>
&gt; =C2=A0 if so, then document such modifications/changes.<br>
&gt; o Determine whether the above mentioned procedures require<br>
&gt; =C2=A0 modification/changes to the existing IPv6 architecture, and<br>
&gt; =C2=A0 if so, then document such modifications/changes.<br>
&gt; o The SPRING working group will then develop solutions, focusing<br>
&gt; =C2=A0 initially on intra-domain deployment scenarios. Where such<br>
&gt; =C2=A0 solutions utilize existing protocols (IS-IS, OSPF, BGP, PCE) th=
is will<br>
&gt; =C2=A0 be done in conjunction with the responsible IETF working group.=
 Work<br>
&gt; =C2=A0 on new protocols may be carried out by the SPRING working group=
.<br>
&gt;<br>
&gt; The working group will develop the following documents:<br>
&gt;<br>
&gt; o One or more documents describing SPRING use cases,<br>
&gt; o Specification of new procedures to support SPRING use cases,<br>
&gt; o Changes to MPLS architecture, if needed<br>
&gt; o Changes to IPv6 architecture, if needed<br>
&gt; o Document interworking and co-existence between the new procedures<br=
>
&gt; =C2=A0 and the existing MPLS signaling protocols (LDP, RSVP-TE, BGP),<=
br>
&gt; o Document impact (if any) of any proposed IPv6 data plane modificatio=
ns<br>
&gt; =C2=A0 on existing deployment of IPv6,<br>
&gt; o A set of one or more protocol extensions requirements documents,<br>
&gt; o Inter-operability reports pertaining to the implementation of extens=
ions<br>
&gt; =C2=A0 supporting SPRING.<br>
&gt;<br>
&gt; Please review and propose changes you think are necessary to the<br>
&gt; list.<br>
&gt;<br>
&gt; - Stewart<br>
&gt;<br>
&gt;<br>
&gt;<br>
&gt; _______________________________________________<br>
&gt; status mailing list<br>
&gt; <a href=3D"mailto:[email-masked]">[email-masked]</a><br>
&gt; <a href=3D"https://www.ietf.org/mailman/listinfo/status" target=3D"_bl=
ank">https://www.ietf.org/mailman/listinfo/status</a><br>
&gt;<br>
<br>
_______________________________________________<br>
status mailing list<br>
<a href=3D"mailto:[email-masked]">[email-masked]</a><br>
<a href=3D"https://www.ietf.org/mailman/listinfo/status" target=3D"_blank">=
https://www.ietf.org/mailman/listinfo/status</a><br>
</div></div></blockquote></div><br></div></div>

--047d7b111f3ff5614d04e6d54d38--

From: Rob Shakir <[email-masked]>
Date: Fri, 20 Sep 2013 16:47:48 +0100
To: Lou Berger <[email-masked]>
Cc: "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>, [email-masked]
Subject: Re: [Status] Chartering next steps

Hi Lou,

On 20 Sep 2013, at 15:00, Lou Berger <[email-masked]> wrote:

> Stewart,
> 	A comment and a question:
> - You say:
>  any path without requiring state to be maintained by transited nodes
>=20
> I think it would be worth clarifying that no "per-path state" is
> required to be maintained. The extensions eluded to below will =
certainly
> control/install state per node, just not per path.

I think this is correct :-)

>=20
> - You say:
>  any node in the SPRING region is trusted to steer a packet
>  through any of the other nodes within the region.
>=20
> To me this limits "steering", and perhaps steering identifiers, to the
> node level. Is steering at the interface/link level now excluded?  The
> text should be clear that this is in scope.

The previous wording that we had here is quoted below:

"The architecture defined by this working group will allow steering of =
packets between any source and destination node within the <Name-TBD> =
domain, which may be formed of one or more networks, on any path =
(shortest, non-shortest, explicit, or based on other resources or =
characteristics specified by segment identifiers)."

Thanks for picking up that this has changed somewhat -- I would suggest =
that we amend the wording to "Any node in the SPRING region is trusted =
to steer a packet along any path within the region" -- which allows for =
the possibility of the path being of identifiers which refer to =
nodes/links/subtopologies etc.

Kind regards,
r.

>=20
> Thanks,
> Lou
>=20
> On 09/20/2013 05:28 AM, Stewart Bryant wrote:
>> This note is a summary of where we are with chartering the
>> work that we are discussing on the STATUS list and
>> the next steps.
>>=20
>> Firstly, as you know we (the ADs) had concerns with the
>> name "STATUS" being confusing. Having considered quite
>> a lot of possibilities, and not wanting the discussion
>> to bog down on a name,  Adrian and I have decided
>> that the name Source Packet Routing in NetworkinG is
>> as good as any. Thus SPRING is name that we are using
>> in the charter process and is that I am putting in the
>> data-tracker for formal processing.
>>=20
>> Propose to start with the charter text that John Scudder
>> posted on 17/Sept with the following changes:
>>=20
>> s/<TBD>/SPRING/
>>=20
>> I removed "ordered" from ordered list, as I think there
>> was a consensus to do so in the following emails in
>> the thread.
>>=20
>> I have not changed the state text, as I could not see
>> a consensus on what if any change I should make.
>>=20
>> The charter is uploaded at
>>=20
>> https://datatracker.ietf.org/doc/charter-ietf-spring/
>>=20
>> What we now need the list members to do is to propose
>> any necessary changes to the text, and I will reflect
>> the consensus of the group in revised charter text.
>> The differences in the version of the charter text will
>> be visible through the datatracker charter diff tool.
>>=20
>> For continuity, discussion will continue on the STATUS
>> list until we have a chartered WG, at which point the
>> Secretariat will switch us over.
>>=20
>> For reference the text I uploaded is as follows:
>>=20
>> Name: Source Packet Routing in Networking (SPRING)
>>=20
>> The SPRING working group will define procedures that will allow
>> a node to steer a packet between any source and destination through
>> a SPRING region on any path without requiring state to be
>> maintained by transited nodes, but rather at the source device.  A
>> SPRING region is a network comprised of nodes (which may be of
>> any type, including routers and appliances) that share the following
>> trust model: any node in the SPRING region is trusted to steer
>> a packet through any of the other nodes within the region. The
>> SPRING region may comprise one or more ASes, or even less than a
>> single AS. Although a region may comprise more than one AS, initial
>> work will focus on the intra-domain, that is, single AS, scenario.
>>=20
>> The procedures should support both centralised and distributed path
>> computation. The procedures should also cover support for OAM
>> functions.
>>=20
>> Where use cases are documented, care should be taken to define the
>> data plane requirements for the environment within which they are
>> to be implemented. The procedures should avoid modifications to
>> the MPLS data plane, in order to remain compatible with existing
>> extensive deployments of MPLS. It is anticipated that the procedures
>> may require modifications to the IPv6 data plane.  While the initial
>> focus of the SPRING WG is on the intra-domain deployment scenarios
>> (see below), the modifications to the IPv6 data plane must support
>> both intra and inter-domain deployment scenarios.
>>=20
>> The SPRING working group is chartered for the following list of
>> items:
>>=20
>> o Identification and evaluation of use cases for which there
>>  is consensus within the WG.
>> o Definition of new procedures, driven by the use cases and =
underlying
>>  technology. The new procedures must cover security considerations
>>  (including the relationship between networks forming the SPRING
>>  region) and allow for solutions which substantially improve upon
>>  current technologies by defining requirements, extensions, or new
>>  functionality in existing routing, management or other protocols.
>> o Determine whether the above mentioned procedures require
>>  modification/changes to the existing MPLS architecture, and
>>  if so, then document such modifications/changes.
>> o Determine whether the above mentioned procedures require
>>  modification/changes to the existing IPv6 architecture, and
>>  if so, then document such modifications/changes.
>> o The SPRING working group will then develop solutions, focusing
>>  initially on intra-domain deployment scenarios. Where such
>>  solutions utilize existing protocols (IS-IS, OSPF, BGP, PCE) this =
will
>>  be done in conjunction with the responsible IETF working group. Work
>>  on new protocols may be carried out by the SPRING working group.
>>=20
>> The working group will develop the following documents:
>>=20
>> o One or more documents describing SPRING use cases,
>> o Specification of new procedures to support SPRING use cases,
>> o Changes to MPLS architecture, if needed
>> o Changes to IPv6 architecture, if needed
>> o Document interworking and co-existence between the new procedures
>>  and the existing MPLS signaling protocols (LDP, RSVP-TE, BGP),
>> o Document impact (if any) of any proposed IPv6 data plane =
modifications
>>  on existing deployment of IPv6,
>> o A set of one or more protocol extensions requirements documents,
>> o Inter-operability reports pertaining to the implementation of =
extensions
>>  supporting SPRING.
>>=20
>> Please review and propose changes you think are necessary to the
>> list.
>>=20
>> - Stewart
>>=20
>>=20
>>=20
>> _______________________________________________
>> status mailing list
>> [email-masked]
>> https://www.ietf.org/mailman/listinfo/status
>>=20
>=20
> _______________________________________________
> status mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/status

Date: Fri, 20 Sep 2013 10:00:52 -0400
From: Lou Berger <[email-masked]>
To: [email-masked]
Cc: "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>
Subject: Re: [Status] Chartering next steps

Stewart,
	A comment and a question:
- You say:
  any path without requiring state to be maintained by transited nodes

I think it would be worth clarifying that no "per-path state" is
required to be maintained. The extensions eluded to below will certainly
control/install state per node, just not per path.

- You say:
  any node in the SPRING region is trusted to steer a packet
  through any of the other nodes within the region.

To me this limits "steering", and perhaps steering identifiers, to the
node level. Is steering at the interface/link level now excluded?  The
text should be clear that this is in scope.

Thanks,
Lou

On 09/20/2013 05:28 AM, Stewart Bryant wrote:
> This note is a summary of where we are with chartering the
> work that we are discussing on the STATUS list and
> the next steps.
> 
> Firstly, as you know we (the ADs) had concerns with the
> name "STATUS" being confusing. Having considered quite
> a lot of possibilities, and not wanting the discussion
> to bog down on a name,  Adrian and I have decided
> that the name Source Packet Routing in NetworkinG is
> as good as any. Thus SPRING is name that we are using
> in the charter process and is that I am putting in the
> data-tracker for formal processing.
> 
> Propose to start with the charter text that John Scudder
> posted on 17/Sept with the following changes:
> 
> s/<TBD>/SPRING/
> 
> I removed "ordered" from ordered list, as I think there
> was a consensus to do so in the following emails in
> the thread.
> 
> I have not changed the state text, as I could not see
> a consensus on what if any change I should make.
> 
> The charter is uploaded at
> 
> https://datatracker.ietf.org/doc/charter-ietf-spring/
> 
> What we now need the list members to do is to propose
> any necessary changes to the text, and I will reflect
> the consensus of the group in revised charter text.
> The differences in the version of the charter text will
> be visible through the datatracker charter diff tool.
> 
> For continuity, discussion will continue on the STATUS
> list until we have a chartered WG, at which point the
> Secretariat will switch us over.
> 
> For reference the text I uploaded is as follows:
> 
> Name: Source Packet Routing in Networking (SPRING)
> 
> The SPRING working group will define procedures that will allow
> a node to steer a packet between any source and destination through
> a SPRING region on any path without requiring state to be
> maintained by transited nodes, but rather at the source device.  A
> SPRING region is a network comprised of nodes (which may be of
> any type, including routers and appliances) that share the following
> trust model: any node in the SPRING region is trusted to steer
> a packet through any of the other nodes within the region. The
> SPRING region may comprise one or more ASes, or even less than a
> single AS. Although a region may comprise more than one AS, initial
> work will focus on the intra-domain, that is, single AS, scenario.
> 
> The procedures should support both centralised and distributed path
> computation. The procedures should also cover support for OAM
> functions.
> 
> Where use cases are documented, care should be taken to define the
> data plane requirements for the environment within which they are
> to be implemented. The procedures should avoid modifications to
> the MPLS data plane, in order to remain compatible with existing
> extensive deployments of MPLS. It is anticipated that the procedures
> may require modifications to the IPv6 data plane.  While the initial
> focus of the SPRING WG is on the intra-domain deployment scenarios
> (see below), the modifications to the IPv6 data plane must support
> both intra and inter-domain deployment scenarios.
> 
> The SPRING working group is chartered for the following list of
> items:
> 
> o Identification and evaluation of use cases for which there
>   is consensus within the WG.
> o Definition of new procedures, driven by the use cases and underlying
>   technology. The new procedures must cover security considerations
>   (including the relationship between networks forming the SPRING
>   region) and allow for solutions which substantially improve upon
>   current technologies by defining requirements, extensions, or new
>   functionality in existing routing, management or other protocols.
> o Determine whether the above mentioned procedures require
>   modification/changes to the existing MPLS architecture, and
>   if so, then document such modifications/changes.
> o Determine whether the above mentioned procedures require
>   modification/changes to the existing IPv6 architecture, and
>   if so, then document such modifications/changes.
> o The SPRING working group will then develop solutions, focusing
>   initially on intra-domain deployment scenarios. Where such
>   solutions utilize existing protocols (IS-IS, OSPF, BGP, PCE) this will
>   be done in conjunction with the responsible IETF working group. Work
>   on new protocols may be carried out by the SPRING working group.
> 
> The working group will develop the following documents:
> 
> o One or more documents describing SPRING use cases,
> o Specification of new procedures to support SPRING use cases,
> o Changes to MPLS architecture, if needed
> o Changes to IPv6 architecture, if needed
> o Document interworking and co-existence between the new procedures
>   and the existing MPLS signaling protocols (LDP, RSVP-TE, BGP),
> o Document impact (if any) of any proposed IPv6 data plane modifications
>   on existing deployment of IPv6,
> o A set of one or more protocol extensions requirements documents,
> o Inter-operability reports pertaining to the implementation of extensions
>   supporting SPRING.
> 
> Please review and propose changes you think are necessary to the
> list.
> 
> - Stewart
> 
> 
> 
> _______________________________________________
> status mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/status
> 

From: "Stefano Previdi (sprevidi)" <[email-masked]>
To: "Stewart Bryant (stbryant)" <[email-masked]>
Date: Fri, 20 Sep 2013 13:58:44 +0000
Accept-Language: en-US
Cc: Pierre Francois <[email-masked]>, "[email-masked]" <[email-masked]>, Loa Andersson <[email-masked]>
Subject: Re: [Status] Chartering next steps

On Sep 20, 2013, at 3:50 PM, Stewart Bryant wrote:

> Stef
>=20
> Specification by partial list always gives problems. WGs
> come and go, new protocols are noticed that need
> changing. Much better for a charter to state a principle
> that is likely to be true regardless of the IETF structure.

yes, the name of the WG was just as example (and not exhaustive)=20
but in order not to hurt anyone sensibility, I'd agree with your=20
text.

s.

> So, if you compare your text to mine, what operational
> issue do you see arising that yours catches?
>=20
> - Stewart
>=20
> On 20/09/2013 14:38, Stefano Previdi (sprevidi) wrote:
>> This is the text from my originally proposed charter:
>>=20
>> . The WG will work on the definition of the architecture and protocol
>>   extensions. No new protocol specification is expected within this WG.
>>   No MPLS data-plane changes are expected either.
>>=20
>> . Instead the standardization work should consist in extensions in well
>>   established protocols (ISIS, OSPF, BGP, PCEP, ...).
>>=20
>> . It is expected that the SEGROUTE WG will help in the orchestration
>>   of protocol extensions specification with the existing IETF Working
>>   Groups (ISIS, OSPF, IDR, PCE, 6MAN, MPLS, ...).
>>=20
>> s.
>>=20
>>=20
>>=20
>> On Sep 20, 2013, at 3:17 PM, Stewart Bryant wrote:
>>=20
>>> Pierre
>>>=20
>>> The last version of the charter that I pulled from the list
>>> says:
>>>=20
>>>  Where such
>>>  solutions utilize existing protocols (IS-IS, OSPF, BGP, PCE) this will
>>>  be done in conjunction with the responsible IETF working group. Work
>>>  on new protocols may be carried out by the SPRING working group.
>>>=20
>>> That is not as prescriptive as either your snippet, or mine, and Loa ra=
ised a concern.
>>>=20
>>> What do others think?
>>>=20
>>> Stewart
>>>=20
>>> On 20/09/2013 13:53, Pierre Francois wrote:
>>>> Stewart,
>>>>=20
>>>> It is already in John's text. At the end he writes that the work impac=
ting protocols will be carried out in their respective working groups.
>>>>=20
>>>> Cheers,
>>>>=20
>>>> Pierre.
>>>>=20
>>>> Sent from my iPhone
>>>>=20
>>>> On Sep 20, 2013, at 2:39 PM, Stewart Bryant <[email-masked]> wrote=
:
>>>>=20
>>>>> Hi Loa,
>>>>>=20
>>>>> That is a good point, here is some text that might be considered for =
inclusion:
>>>>>=20
>>>>> "Where possible, existing protocols must be used to implement the SPR=
ING function. Any modification or       extension of existing architectures=
 or protocols must be carried out in the working groups responsible for the=
 architectures or protocols being modified in co-ordination with this worki=
ng group, but may be done in this working group after agreement with all th=
e relevant WG chairs and responsible ADs."
>>>>>=20
>>>>> A good place to put this would be before: "The SPRING working group i=
s chartered for the following list of items: "
>>>>>=20
>>>>> _______________________________________________
>>>>> status mailing list
>>>>> [email-masked]
>>>>> https://www.ietf.org/mailman/listinfo/status
>>>> .
>>>>=20
>>>=20
>>> --=20
>>> For corporate legal information go to:
>>>=20
>>> http://www.cisco.com/web/about/doing_business/legal/cri/index.html
>>>=20
>>> _______________________________________________
>>> status mailing list
>>> [email-masked]
>>> https://www.ietf.org/mailman/listinfo/status
>> .
>>=20
>=20
>=20
> --=20
> For corporate legal information go to:
>=20
> http://www.cisco.com/web/about/doing_business/legal/cri/index.html
>=20

From: "Alvaro Retana (aretana)" <[email-masked]>
To: "Stewart Bryant (stbryant)" <[email-masked]>, Pierre Francois <[email-masked]>
Date: Fri, 20 Sep 2013 13:56:47 +0000
Accept-Language: en-US
Cc: "[email-masked]" <[email-masked]>, Loa Andersson <[email-masked]>
Subject: Re: [Status] Chartering next steps

On 9/20/13 9:17 AM, "Stewart Bryant (stbryant)" <[email-masked]> wrote:

>What do others think?

FWIW, I like the prescriptive nature of the text you proposed.

Thanks!

Alvaro.

>>On Sep 20, 2013, at 2:39 PM, Stewart Bryant <[email-masked]> wrote:
>>
>>> Hi Loa,
>>>
>>> That is a good point, here is some text that might be considered for
>>>inclusion:
>>>
>>> "Where possible, existing protocols must be used to implement the
>>>SPRING function. Any modification or       extension of existing
>>>architectures or protocols must be carried out in the working groups
>>>responsible for the architectures or protocols being modified in
>>>co-ordination with this working group, but may be done in this working
>>>group after agreement with all the relevant WG chairs and responsible
>>>ADs."
>>>
>>> A good place to put this would be before: "The SPRING working group is
>>>chartered for the following list of items: "

Date: Fri, 20 Sep 2013 14:50:26 +0100
From: Stewart Bryant <[email-masked]>
To: "Stefano Previdi (sprevidi)" <[email-masked]>
Cc: Pierre Francois <[email-masked]>, "[email-masked]" <[email-masked]>, Loa Andersson <[email-masked]>
Subject: Re: [Status] Chartering next steps
Reply-To: [email-masked]

Stef

Specification by partial list always gives problems. WGs
come and go, new protocols are noticed that need
changing. Much better for a charter to state a principle
that is likely to be true regardless of the IETF structure.

So, if you compare your text to mine, what operational
issue do you see arising that yours catches?

- Stewart

On 20/09/2013 14:38, Stefano Previdi (sprevidi) wrote:
> This is the text from my originally proposed charter:
>
> . The WG will work on the definition of the architecture and protocol
>    extensions. No new protocol specification is expected within this WG.
>    No MPLS data-plane changes are expected either.
>
> . Instead the standardization work should consist in extensions in well
>    established protocols (ISIS, OSPF, BGP, PCEP, ...).
>
> . It is expected that the SEGROUTE WG will help in the orchestration
>    of protocol extensions specification with the existing IETF Working
>    Groups (ISIS, OSPF, IDR, PCE, 6MAN, MPLS, ...).
>
> s.
>
>
>
> On Sep 20, 2013, at 3:17 PM, Stewart Bryant wrote:
>
>> Pierre
>>
>> The last version of the charter that I pulled from the list
>> says:
>>
>>   Where such
>>   solutions utilize existing protocols (IS-IS, OSPF, BGP, PCE) this will
>>   be done in conjunction with the responsible IETF working group. Work
>>   on new protocols may be carried out by the SPRING working group.
>>
>> That is not as prescriptive as either your snippet, or mine, and Loa raised a concern.
>>
>> What do others think?
>>
>> Stewart
>>
>> On 20/09/2013 13:53, Pierre Francois wrote:
>>> Stewart,
>>>
>>> It is already in John's text. At the end he writes that the work impacting protocols will be carried out in their respective working groups.
>>>
>>> Cheers,
>>>
>>> Pierre.
>>>
>>> Sent from my iPhone
>>>
>>> On Sep 20, 2013, at 2:39 PM, Stewart Bryant <[email-masked]> wrote:
>>>
>>>> Hi Loa,
>>>>
>>>> That is a good point, here is some text that might be considered for inclusion:
>>>>
>>>> "Where possible, existing protocols must be used to implement the SPRING function. Any modification or       extension of existing architectures or protocols must be carried out in the working groups responsible for the architectures or protocols being modified in co-ordination with this working group, but may be done in this working group after agreement with all the relevant WG chairs and responsible ADs."
>>>>
>>>> A good place to put this would be before: "The SPRING working group is chartered for the following list of items: "
>>>>
>>>> _______________________________________________
>>>> status mailing list
>>>> [email-masked]
>>>> https://www.ietf.org/mailman/listinfo/status
>>> .
>>>
>>
>> -- 
>> For corporate legal information go to:
>>
>> http://www.cisco.com/web/about/doing_business/legal/cri/index.html
>>
>> _______________________________________________
>> status mailing list
>> [email-masked]
>> https://www.ietf.org/mailman/listinfo/status
> .
>

-- 
For corporate legal information go to:

http://www.cisco.com/web/about/doing_business/legal/cri/index.html

From: John E Drake <[email-masked]>
To: "Stefano Previdi (sprevidi)" <[email-masked]>, "Stewart Bryant (stbryant)" <[email-masked]>
Date: Fri, 20 Sep 2013 13:42:22 +0000
Accept-Language: en-US
Cc: Pierre Francois <[email-masked]>, "[email-masked]" <[email-masked]>, Loa Andersson <[email-masked]>
Subject: Re: [Status] Chartering next steps

Hi,

I prefer Stewart's text.

Yours Irrespectively,

John

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf
> Of Stefano Previdi (sprevidi)
> Sent: Friday, September 20, 2013 6:38 AM
> To: Stewart Bryant (stbryant)
> Cc: Pierre Francois; [email-masked]; Loa Andersson
> Subject: Re: [Status] Chartering next steps
>=20
> This is the text from my originally proposed charter:
>=20
> . The WG will work on the definition of the architecture and protocol
>   extensions. No new protocol specification is expected within this WG.
>   No MPLS data-plane changes are expected either.
>=20
> . Instead the standardization work should consist in extensions in well
>   established protocols (ISIS, OSPF, BGP, PCEP, ...).
>=20
> . It is expected that the SEGROUTE WG will help in the orchestration
>   of protocol extensions specification with the existing IETF Working
>   Groups (ISIS, OSPF, IDR, PCE, 6MAN, MPLS, ...).
>=20
> s.
>=20
>=20
>=20
> On Sep 20, 2013, at 3:17 PM, Stewart Bryant wrote:
>=20
> > Pierre
> >
> > The last version of the charter that I pulled from the list
> > says:
> >
> >  Where such
> >  solutions utilize existing protocols (IS-IS, OSPF, BGP, PCE) this
> > will  be done in conjunction with the responsible IETF working group.
> > Work  on new protocols may be carried out by the SPRING working group.
> >
> > That is not as prescriptive as either your snippet, or mine, and Loa ra=
ised a
> concern.
> >
> > What do others think?
> >
> > Stewart
> >
> > On 20/09/2013 13:53, Pierre Francois wrote:
> >> Stewart,
> >>
> >> It is already in John's text. At the end he writes that the work impac=
ting
> protocols will be carried out in their respective working groups.
> >>
> >> Cheers,
> >>
> >> Pierre.
> >>
> >> Sent from my iPhone
> >>
> >> On Sep 20, 2013, at 2:39 PM, Stewart Bryant <[email-masked]> wrote=
:
> >>
> >>> Hi Loa,
> >>>
> >>> That is a good point, here is some text that might be considered for
> inclusion:
> >>>
> >>> "Where possible, existing protocols must be used to implement the
> SPRING function. Any modification or       extension of existing architec=
tures
> or protocols must be carried out in the working groups responsible for th=
e
> architectures or protocols being modified in co-ordination with this work=
ing
> group, but may be done in this working group after agreement with all the
> relevant WG chairs and responsible ADs."
> >>>
> >>> A good place to put this would be before: "The SPRING working group i=
s
> chartered for the following list of items: "
> >>>
> >>> _______________________________________________
> >>> status mailing list
> >>> [email-masked]
> >>> https://www.ietf.org/mailman/listinfo/status
> >> .
> >>
> >
> >
> > --
> > For corporate legal information go to:
> >
> > http://www.cisco.com/web/about/doing_business/legal/cri/index.html
> >
> > _______________________________________________
> > status mailing list
> > [email-masked]
> > https://www.ietf.org/mailman/listinfo/status
>=20
> _______________________________________________
> status mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/status
>=20

From: "Stefano Previdi (sprevidi)" <[email-masked]>
To: "Stewart Bryant (stbryant)" <[email-masked]>
Date: Fri, 20 Sep 2013 13:38:13 +0000
Accept-Language: en-US
Cc: Pierre Francois <[email-masked]>, "[email-masked]" <[email-masked]>, Loa Andersson <[email-masked]>
Subject: Re: [Status] Chartering next steps

This is the text from my originally proposed charter:

. The WG will work on the definition of the architecture and protocol=20
  extensions. No new protocol specification is expected within this WG.=20
  No MPLS data-plane changes are expected either.

. Instead the standardization work should consist in extensions in well=20
  established protocols (ISIS, OSPF, BGP, PCEP, ...).

. It is expected that the SEGROUTE WG will help in the orchestration=20
  of protocol extensions specification with the existing IETF Working=20
  Groups (ISIS, OSPF, IDR, PCE, 6MAN, MPLS, ...).

s.

On Sep 20, 2013, at 3:17 PM, Stewart Bryant wrote:

> Pierre
>=20
> The last version of the charter that I pulled from the list
> says:
>=20
>  Where such
>  solutions utilize existing protocols (IS-IS, OSPF, BGP, PCE) this will
>  be done in conjunction with the responsible IETF working group. Work
>  on new protocols may be carried out by the SPRING working group.
>=20
> That is not as prescriptive as either your snippet, or mine, and Loa rais=
ed a concern.
>=20
> What do others think?
>=20
> Stewart
>=20
> On 20/09/2013 13:53, Pierre Francois wrote:
>> Stewart,
>>=20
>> It is already in John's text. At the end he writes that the work impacti=
ng protocols will be carried out in their respective working groups.
>>=20
>> Cheers,
>>=20
>> Pierre.
>>=20
>> Sent from my iPhone
>>=20
>> On Sep 20, 2013, at 2:39 PM, Stewart Bryant <[email-masked]> wrote:
>>=20
>>> Hi Loa,
>>>=20
>>> That is a good point, here is some text that might be considered for in=
clusion:
>>>=20
>>> "Where possible, existing protocols must be used to implement the SPRIN=
G function. Any modification or       extension of existing architectures o=
r protocols must be carried out in the working groups responsible for the a=
rchitectures or protocols being modified in co-ordination with this working=
 group, but may be done in this working group after agreement with all the =
relevant WG chairs and responsible ADs."
>>>=20
>>> A good place to put this would be before: "The SPRING working group is =
chartered for the following list of items: "
>>>=20
>>> _______________________________________________
>>> status mailing list
>>> [email-masked]
>>> https://www.ietf.org/mailman/listinfo/status
>> .
>>=20
>=20
>=20
> --=20
> For corporate legal information go to:
>=20
> http://www.cisco.com/web/about/doing_business/legal/cri/index.html
>=20
> _______________________________________________
> status mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/status

Date: Fri, 20 Sep 2013 14:17:42 +0100
From: Stewart Bryant <[email-masked]>
To: Pierre Francois <[email-masked]>
Cc: "[email-masked]" <[email-masked]>, Loa Andersson <[email-masked]>
Subject: Re: [Status] Chartering next steps
Reply-To: [email-masked]

Pierre

The last version of the charter that I pulled from the list
says:

   Where such
   solutions utilize existing protocols (IS-IS, OSPF, BGP, PCE) this will
   be done in conjunction with the responsible IETF working group. Work
   on new protocols may be carried out by the SPRING working group.

That is not as prescriptive as either your snippet, or mine, and Loa 
raised a concern.

What do others think?

Stewart

On 20/09/2013 13:53, Pierre Francois wrote:
> Stewart,
>
> It is already in John's text. At the end he writes that the work impacting protocols will be carried out in their respective working groups.
>
> Cheers,
>
> Pierre.
>
> Sent from my iPhone
>
> On Sep 20, 2013, at 2:39 PM, Stewart Bryant <[email-masked]> wrote:
>
>> Hi Loa,
>>
>> That is a good point, here is some text that might be considered for inclusion:
>>
>> "Where possible, existing protocols must be used to implement the SPRING function. Any modification or       extension of existing architectures or protocols must be carried out in the working groups responsible for the architectures or protocols being modified in co-ordination with this working group, but may be done in this working group after agreement with all the relevant WG chairs and responsible ADs."
>>
>> A good place to put this would be before: "The SPRING working group is chartered for the following list of items: "
>>
>> _______________________________________________
>> status mailing list
>> [email-masked]
>> https://www.ietf.org/mailman/listinfo/status
> .
>

-- 
For corporate legal information go to:

http://www.cisco.com/web/about/doing_business/legal/cri/index.html

From: Pierre Francois <[email-masked]>
Date: Fri, 20 Sep 2013 14:53:26 +0200
To: "[email-masked]" <[email-masked]>
Cc: "[email-masked]" <[email-masked]>, Loa Andersson <[email-masked]>
Subject: Re: [Status] Chartering next steps

Stewart,

It is already in John's text. At the end he writes that the work impacting p=
rotocols will be carried out in their respective working groups.

Cheers,

Pierre.

Sent from my iPhone

On Sep 20, 2013, at 2:39 PM, Stewart Bryant <[email-masked]> wrote:

> Hi Loa,
>=20
> That is a good point, here is some text that might be considered for inclu=
sion:
>=20
> "Where possible, existing protocols must be used to implement the SPRING f=
unction. Any modification or       extension of existing architectures or pr=
otocols must be carried out in the working groups responsible for the archit=
ectures or protocols being modified in co-ordination with this working group=
, but may be done in this working group after agreement with all the relevan=
t WG chairs and responsible ADs."
>=20
> A good place to put this would be before: "The SPRING working group is cha=
rtered for the following list of items: "
>=20
> _______________________________________________
> status mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/status

Date: Fri, 20 Sep 2013 13:39:09 +0100
From: Stewart Bryant <[email-masked]>
To: Loa Andersson <[email-masked]>
Cc: [email-masked]
Subject: Re: [Status] Chartering next steps
Reply-To: [email-masked]

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

Hi Loa,

That is a good point, here is some text that might be considered for 
inclusion:

"Where possible, existing protocols must be used to implement the SPRING 
function. Any modification or extension of existing architectures or 
protocols must be carried out in the working groups responsible for the 
architectures or protocols being modified in co-ordination with this 
working group, but may be done in this working group after agreement 
with all the relevant WG chairs and responsible ADs."

A good place to put this would be before: "The SPRING working group is 
chartered for the following list of items: "

Would this address your concern?

Stewart

On 20/09/2013 12:29, Loa Andersson wrote:
> Stewart,
>
> SPRING is a nice name :).
>
> The only thing that I don't find clear in this charter is
> whether to specify modifications to the data planes and architectures
> or if the group is supposed to act as a source for requirements for
> such changes.
>
> I hope we can agree to see SPRING as source for requirements for
> modification where the data plane and architecture has been developed
> by another active working group.
>
> /Loa
>
>
> On 2013-09-20 11:28, Stewart Bryant wrote:
>> This note is a summary of where we are with chartering the
>> work that we are discussing on the STATUS list and
>> the next steps.
>>
>> Firstly, as you know we (the ADs) had concerns with the
>> name "STATUS" being confusing. Having considered quite
>> a lot of possibilities, and not wanting the discussion
>> to bog down on a name,  Adrian and I have decided
>> that the name Source Packet Routing in NetworkinG is
>> as good as any. Thus SPRING is name that we are using
>> in the charter process and is that I am putting in the
>> data-tracker for formal processing.
>>
>> Propose to start with the charter text that John Scudder
>> posted on 17/Sept with the following changes:
>>
>> s/<TBD>/SPRING/
>>
>> I removed "ordered" from ordered list, as I think there
>> was a consensus to do so in the following emails in
>> the thread.
>>
>> I have not changed the state text, as I could not see
>> a consensus on what if any change I should make.
>>
>> The charter is uploaded at
>>
>> https://datatracker.ietf.org/doc/charter-ietf-spring/
>>
>> What we now need the list members to do is to propose
>> any necessary changes to the text, and I will reflect
>> the consensus of the group in revised charter text.
>> The differences in the version of the charter text will
>> be visible through the datatracker charter diff tool.
>>
>> For continuity, discussion will continue on the STATUS
>> list until we have a chartered WG, at which point the
>> Secretariat will switch us over.
>>
>> For reference the text I uploaded is as follows:
>>
>> Name: Source Packet Routing in Networking (SPRING)
>>
>> The SPRING working group will define procedures that will allow
>> a node to steer a packet between any source and destination through
>> a SPRING region on any path without requiring state to be
>> maintained by transited nodes, but rather at the source device. A
>> SPRING region is a network comprised of nodes (which may be of
>> any type, including routers and appliances) that share the following
>> trust model: any node in the SPRING region is trusted to steer
>> a packet through any of the other nodes within the region. The
>> SPRING region may comprise one or more ASes, or even less than a
>> single AS. Although a region may comprise more than one AS, initial
>> work will focus on the intra-domain, that is, single AS, scenario.
>>
>> The procedures should support both centralised and distributed path
>> computation. The procedures should also cover support for OAM
>> functions.
>>
>> Where use cases are documented, care should be taken to define the
>> data plane requirements for the environment within which they are
>> to be implemented. The procedures should avoid modifications to
>> the MPLS data plane, in order to remain compatible with existing
>> extensive deployments of MPLS. It is anticipated that the procedures
>> may require modifications to the IPv6 data plane.  While the initial
>> focus of the SPRING WG is on the intra-domain deployment scenarios
>> (see below), the modifications to the IPv6 data plane must support
>> both intra and inter-domain deployment scenarios.
>>
>> The SPRING working group is chartered for the following list of
>> items:
>>
>> o Identification and evaluation of use cases for which there
>>    is consensus within the WG.
>> o Definition of new procedures, driven by the use cases and underlying
>>    technology. The new procedures must cover security considerations
>>    (including the relationship between networks forming the SPRING
>>    region) and allow for solutions which substantially improve upon
>>    current technologies by defining requirements, extensions, or new
>>    functionality in existing routing, management or other protocols.
>> o Determine whether the above mentioned procedures require
>>    modification/changes to the existing MPLS architecture, and
>>    if so, then document such modifications/changes.
>> o Determine whether the above mentioned procedures require
>>    modification/changes to the existing IPv6 architecture, and
>>    if so, then document such modifications/changes.
>> o The SPRING working group will then develop solutions, focusing
>>    initially on intra-domain deployment scenarios. Where such
>>    solutions utilize existing protocols (IS-IS, OSPF, BGP, PCE) this 
>> will
>>    be done in conjunction with the responsible IETF working group. Work
>>    on new protocols may be carried out by the SPRING working group.
>>
>> The working group will develop the following documents:
>>
>> o One or more documents describing SPRING use cases,
>> o Specification of new procedures to support SPRING use cases,
>> o Changes to MPLS architecture, if needed
>> o Changes to IPv6 architecture, if needed
>> o Document interworking and co-existence between the new procedures
>>    and the existing MPLS signaling protocols (LDP, RSVP-TE, BGP),
>> o Document impact (if any) of any proposed IPv6 data plane modifications
>>    on existing deployment of IPv6,
>> o A set of one or more protocol extensions requirements documents,
>> o Inter-operability reports pertaining to the implementation of 
>> extensions
>>    supporting SPRING.
>>
>> Please review and propose changes you think are necessary to the
>> list.
>>
>> - Stewart
>>
>>
>>
>> _______________________________________________
>> status mailing list
>> [email-masked]
>> https://www.ietf.org/mailman/listinfo/status
>

-- 
For corporate legal information go to:

http://www.cisco.com/web/about/doing_business/legal/cri/index.html

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

<html>
  <head>
    <meta content="text/html; charset=ISO-8859-1"
      http-equiv="Content-Type">
  </head>
  <body bgcolor="#FFFFFF" text="#000000">
    <div class="moz-cite-prefix">Hi Loa,<br>
      <br>
      That is a good point, here is some text that might be considered
      for inclusion:<br>
      <br>
      "Where possible, existing
      protocols must be used to implement the SPRING function. Any
      modification or
      extension of existing architectures or protocols must be carried
      out in the
      working groups responsible for the architectures or protocols
      being modified in
      co-ordination with this working group, but may be done in this
      working group
      after agreement with all the relevant WG chairs and responsible
      ADs."<br>
      <br>
      A good place to put this would be before: "The SPRING working
      group is chartered for the following list of
      items:
      "<br>
      <o:p></o:p><br>
      <meta name="Keywords" content="">
      <meta http-equiv="Content-Type" content="text/html;
        charset=ISO-8859-1">
      <meta name="ProgId" content="Word.Document">
      <meta name="Generator" content="Microsoft Word 14">
      <meta name="Originator" content="Microsoft Word 14">
      <link rel="File-List"
href="file://localhost/Users/sb/Library/Caches/TemporaryItems/msoclip/0/clip_filelist.xml">
      <!--[if gte mso 9]><xml>
 <o:DocumentProperties>
  <o:Revision>0</o:Revision>
  <o:TotalTime>0</o:TotalTime>
  <o:Pages>1</o:Pages>
  <o:Words>60</o:Words>
  <o:Characters>342</o:Characters>
  <o:Company>Cisco Systems, Inc.</o:Company>
  <o:Lines>2</o:Lines>
  <o:Paragraphs>1</o:Paragraphs>
  <o:CharactersWithSpaces>401</o:CharactersWithSpaces>
  <o:Version>14.0</o:Version>
 </o:DocumentProperties>
 <o:OfficeDocumentSettings>
  <o:AllowPNG/>
 </o:OfficeDocumentSettings>
</xml><![endif]-->
      <link rel="themeData"
href="file://localhost/Users/sb/Library/Caches/TemporaryItems/msoclip/0/clip_themedata.xml">
      <!--[if gte mso 9]><xml>
 <w:WordDocument>
  <w:View>Normal</w:View>
  <w:Zoom>0</w:Zoom>
  <w:TrackMoves/>
  <w:TrackFormatting/>
  <w:PunctuationKerning/>
  <w:ValidateAgainstSchemas/>
  <w:SaveIfXMLInvalid>false</w:SaveIfXMLInvalid>
  <w:IgnoreMixedContent>false</w:IgnoreMixedContent>
  <w:AlwaysShowPlaceholderText>false</w:AlwaysShowPlaceholderText>
  <w:DoNotPromoteQF/>
  <w:LidThemeOther>EN-GB</w:LidThemeOther>
  <w:LidThemeAsian>JA</w:LidThemeAsian>
  <w:LidThemeComplexScript>X-NONE</w:LidThemeComplexScript>
  <w:Compatibility>
   <w:BreakWrappedTables/>
   <w:SnapToGridInCell/>
   <w:WrapTextWithPunct/>
   <w:UseAsianBreakRules/>
   <w:DontGrowAutofit/>
   <w:SplitPgBreakAndParaMark/>
   <w:EnableOpenTypeKerning/>
   <w:DontFlipMirrorIndents/>
   <w:OverrideTableStyleHps/>
   <w:UseFELayout/>
  </w:Compatibility>
  <m:mathPr>
   <m:mathFont m:val="Cambria Math"/>
   <m:brkBin m:val="before"/>
   <m:brkBinSub m:val="&#45;-"/>
   <m:smallFrac m:val="off"/>
   <m:dispDef/>
   <m:lMargin m:val="0"/>
   <m:rMargin m:val="0"/>
   <m:defJc m:val="centerGroup"/>
   <m:wrapIndent m:val="1440"/>
   <m:intLim m:val="subSup"/>
   <m:naryLim m:val="undOvr"/>
  </m:mathPr></w:WordDocument>
</xml><![endif]--><!--[if gte mso 9]><xml>
 <w:LatentStyles DefLockedState="false" DefUnhideWhenUsed="true"
  DefSemiHidden="true" DefQFormat="false" DefPriority="99"
  LatentStyleCount="276">
  <w:LsdException Locked="false" Priority="0" SemiHidden="false"
   UnhideWhenUsed="false" QFormat="true" Name="Normal"/>
  <w:LsdException Locked="false" Priority="9" SemiHidden="false"
   UnhideWhenUsed="false" QFormat="true" Name="heading 1"/>
  <w:LsdException Locked="false" Priority="9" QFormat="true" Name="heading 2"/>
  <w:LsdException Locked="false" Priority="9" QFormat="true" Name="heading 3"/>
  <w:LsdException Locked="false" Priority="9" QFormat="true" Name="heading 4"/>
  <w:LsdException Locked="false" Priority="9" QFormat="true" Name="heading 5"/>
  <w:LsdException Locked="false" Priority="9" QFormat="true" Name="heading 6"/>
  <w:LsdException Locked="false" Priority="9" QFormat="true" Name="heading 7"/>
  <w:LsdException Locked="false" Priority="9" QFormat="true" Name="heading 8"/>
  <w:LsdException Locked="false" Priority="9" QFormat="true" Name="heading 9"/>
  <w:LsdException Locked="false" Priority="39" Name="toc 1"/>
  <w:LsdException Locked="false" Priority="39" Name="toc 2"/>
  <w:LsdException Locked="false" Priority="39" Name="toc 3"/>
  <w:LsdException Locked="false" Priority="39" Name="toc 4"/>
  <w:LsdException Locked="false" Priority="39" Name="toc 5"/>
  <w:LsdException Locked="false" Priority="39" Name="toc 6"/>
  <w:LsdException Locked="false" Priority="39" Name="toc 7"/>
  <w:LsdException Locked="false" Priority="39" Name="toc 8"/>
  <w:LsdException Locked="false" Priority="39" Name="toc 9"/>
  <w:LsdException Locked="false" Priority="35" QFormat="true" Name="caption"/>
  <w:LsdException Locked="false" Priority="10" SemiHidden="false"
   UnhideWhenUsed="false" QFormat="true" Name="Title"/>
  <w:LsdException Locked="false" Priority="1" Name="Default Paragraph Font"/>
  <w:LsdException Locked="false" Priority="11" SemiHidden="false"
   UnhideWhenUsed="false" QFormat="true" Name="Subtitle"/>
  <w:LsdException Locked="false" Priority="22" SemiHidden="false"
   UnhideWhenUsed="false" QFormat="true" Name="Strong"/>
  <w:LsdException Locked="false" Priority="20" SemiHidden="false"
   UnhideWhenUsed="false" QFormat="true" Name="Emphasis"/>
  <w:LsdException Locked="false" Priority="59" SemiHidden="false"
   UnhideWhenUsed="false" Name="Table Grid"/>
  <w:LsdException Locked="false" UnhideWhenUsed="false" Name="Placeholder Text"/>
  <w:LsdException Locked="false" Priority="1" SemiHidden="false"
   UnhideWhenUsed="false" QFormat="true" Name="No Spacing"/>
  <w:LsdException Locked="false" Priority="60" SemiHidden="false"
   UnhideWhenUsed="false" Name="Light Shading"/>
  <w:LsdException Locked="false" Priority="61" SemiHidden="false"
   UnhideWhenUsed="false" Name="Light List"/>
  <w:LsdException Locked="false" Priority="62" SemiHidden="false"
   UnhideWhenUsed="false" Name="Light Grid"/>
  <w:LsdException Locked="false" Priority="63" SemiHidden="false"
   UnhideWhenUsed="false" Name="Medium Shading 1"/>
  <w:LsdException Locked="false" Priority="64" SemiHidden="false"
   UnhideWhenUsed="false" Name="Medium Shading 2"/>
  <w:LsdException Locked="false" Priority="65" SemiHidden="false"
   UnhideWhenUsed="false" Name="Medium List 1"/>
  <w:LsdException Locked="false" Priority="66" SemiHidden="false"
   UnhideWhenUsed="false" Name="Medium List 2"/>
  <w:LsdException Locked="false" Priority="67" SemiHidden="false"
   UnhideWhenUsed="false" Name="Medium Grid 1"/>
  <w:LsdException Locked="false" Priority="68" SemiHidden="false"
   UnhideWhenUsed="false" Name="Medium Grid 2"/>
  <w:LsdException Locked="false" Priority="69" SemiHidden="false"
   UnhideWhenUsed="false" Name="Medium Grid 3"/>
  <w:LsdException Locked="false" Priority="70" SemiHidden="false"
   UnhideWhenUsed="false" Name="Dark List"/>
  <w:LsdException Locked="false" Priority="71" SemiHidden="false"
   UnhideWhenUsed="false" Name="Colorful Shading"/>
  <w:LsdException Locked="false" Priority="72" SemiHidden="false"
   UnhideWhenUsed="false" Name="Colorful List"/>
  <w:LsdException Locked="false" Priority="73" SemiHidden="false"
   UnhideWhenUsed="false" Name="Colorful Grid"/>
  <w:LsdException Locked="false" Priority="60" SemiHidden="false"
   UnhideWhenUsed="false" Name="Light Shading Accent 1"/>
  <w:LsdException Locked="false" Priority="61" SemiHidden="false"
   UnhideWhenUsed="false" Name="Light List Accent 1"/>
  <w:LsdException Locked="false" Priority="62" SemiHidden="false"
   UnhideWhenUsed="false" Name="Light Grid Accent 1"/>
  <w:LsdException Locked="false" Priority="63" SemiHidden="false"
   UnhideWhenUsed="false" Name="Medium Shading 1 Accent 1"/>
  <w:LsdException Locked="false" Priority="64" SemiHidden="false"
   UnhideWhenUsed="false" Name="Medium Shading 2 Accent 1"/>
  <w:LsdException Locked="false" Priority="65" SemiHidden="false"
   UnhideWhenUsed="false" Name="Medium List 1 Accent 1"/>
  <w:LsdException Locked="false" UnhideWhenUsed="false" Name="Revision"/>
  <w:LsdException Locked="false" Priority="34" SemiHidden="false"
   UnhideWhenUsed="false" QFormat="true" Name="List Paragraph"/>
  <w:LsdException Locked="false" Priority="29" SemiHidden="false"
   UnhideWhenUsed="false" QFormat="true" Name="Quote"/>
  <w:LsdException Locked="false" Priority="30" SemiHidden="false"
   UnhideWhenUsed="false" QFormat="true" Name="Intense Quote"/>
  <w:LsdException Locked="false" Priority="66" SemiHidden="false"
   UnhideWhenUsed="false" Name="Medium List 2 Accent 1"/>
  <w:LsdException Locked="false" Priority="67" SemiHidden="false"
   UnhideWhenUsed="false" Name="Medium Grid 1 Accent 1"/>
  <w:LsdException Locked="false" Priority="68" SemiHidden="false"
   UnhideWhenUsed="false" Name="Medium Grid 2 Accent 1"/>
  <w:LsdException Locked="false" Priority="69" SemiHidden="false"
   UnhideWhenUsed="false" Name="Medium Grid 3 Accent 1"/>
  <w:LsdException Locked="false" Priority="70" SemiHidden="false"
   UnhideWhenUsed="false" Name="Dark List Accent 1"/>
  <w:LsdException Locked="false" Priority="71" SemiHidden="false"
   UnhideWhenUsed="false" Name="Colorful Shading Accent 1"/>
  <w:LsdException Locked="false" Priority="72" SemiHidden="false"
   UnhideWhenUsed="false" Name="Colorful List Accent 1"/>
  <w:LsdException Locked="false" Priority="73" SemiHidden="false"
   UnhideWhenUsed="false" Name="Colorful Grid Accent 1"/>
  <w:LsdException Locked="false" Priority="60" SemiHidden="false"
   UnhideWhenUsed="false" Name="Light Shading Accent 2"/>
  <w:LsdException Locked="false" Priority="61" SemiHidden="false"
   UnhideWhenUsed="false" Name="Light List Accent 2"/>
  <w:LsdException Locked="false" Priority="62" SemiHidden="false"
   UnhideWhenUsed="false" Name="Light Grid Accent 2"/>
  <w:LsdException Locked="false" Priority="63" SemiHidden="false"
   UnhideWhenUsed="false" Name="Medium Shading 1 Accent 2"/>
  <w:LsdException Locked="false" Priority="64" SemiHidden="false"
   UnhideWhenUsed="false" Name="Medium Shading 2 Accent 2"/>
  <w:LsdException Locked="false" Priority="65" SemiHidden="false"
   UnhideWhenUsed="false" Name="Medium List 1 Accent 2"/>
  <w:LsdException Locked="false" Priority="66" SemiHidden="false"
   UnhideWhenUsed="false" Name="Medium List 2 Accent 2"/>
  <w:LsdException Locked="false" Priority="67" SemiHidden="false"
   UnhideWhenUsed="false" Name="Medium Grid 1 Accent 2"/>
  <w:LsdException Locked="false" Priority="68" SemiHidden="false"
   UnhideWhenUsed="false" Name="Medium Grid 2 Accent 2"/>
  <w:LsdException Locked="false" Priority="69" SemiHidden="false"
   UnhideWhenUsed="false" Name="Medium Grid 3 Accent 2"/>
  <w:LsdException Locked="false" Priority="70" SemiHidden="false"
   UnhideWhenUsed="false" Name="Dark List Accent 2"/>
  <w:LsdException Locked="false" Priority="71" SemiHidden="false"
   UnhideWhenUsed="false" Name="Colorful Shading Accent 2"/>
  <w:LsdException Locked="false" Priority="72" SemiHidden="false"
   UnhideWhenUsed="false" Name="Colorful List Accent 2"/>
  <w:LsdException Locked="false" Priority="73" SemiHidden="false"
   UnhideWhenUsed="false" Name="Colorful Grid Accent 2"/>
  <w:LsdException Locked="false" Priority="60" SemiHidden="false"
   UnhideWhenUsed="false" Name="Light Shading Accent 3"/>
  <w:LsdException Locked="false" Priority="61" SemiHidden="false"
   UnhideWhenUsed="false" Name="Light List Accent 3"/>
  <w:LsdException Locked="false" Priority="62" SemiHidden="false"
   UnhideWhenUsed="false" Name="Light Grid Accent 3"/>
  <w:LsdException Locked="false" Priority="63" SemiHidden="false"
   UnhideWhenUsed="false" Name="Medium Shading 1 Accent 3"/>
  <w:LsdException Locked="false" Priority="64" SemiHidden="false"
   UnhideWhenUsed="false" Name="Medium Shading 2 Accent 3"/>
  <w:LsdException Locked="false" Priority="65" SemiHidden="false"
   UnhideWhenUsed="false" Name="Medium List 1 Accent 3"/>
  <w:LsdException Locked="false" Priority="66" SemiHidden="false"
   UnhideWhenUsed="false" Name="Medium List 2 Accent 3"/>
  <w:LsdException Locked="false" Priority="67" SemiHidden="false"
   UnhideWhenUsed="false" Name="Medium Grid 1 Accent 3"/>
  <w:LsdException Locked="false" Priority="68" SemiHidden="false"
   UnhideWhenUsed="false" Name="Medium Grid 2 Accent 3"/>
  <w:LsdException Locked="false" Priority="69" SemiHidden="false"
   UnhideWhenUsed="false" Name="Medium Grid 3 Accent 3"/>
  <w:LsdException Locked="false" Priority="70" SemiHidden="false"
   UnhideWhenUsed="false" Name="Dark List Accent 3"/>
  <w:LsdException Locked="false" Priority="71" SemiHidden="false"
   UnhideWhenUsed="false" Name="Colorful Shading Accent 3"/>
  <w:LsdException Locked="false" Priority="72" SemiHidden="false"
   UnhideWhenUsed="false" Name="Colorful List Accent 3"/>
  <w:LsdException Locked="false" Priority="73" SemiHidden="false"
   UnhideWhenUsed="false" Name="Colorful Grid Accent 3"/>
  <w:LsdException Locked="false" Priority="60" SemiHidden="false"
   UnhideWhenUsed="false" Name="Light Shading Accent 4"/>
  <w:LsdException Locked="false" Priority="61" SemiHidden="false"
   UnhideWhenUsed="false" Name="Light List Accent 4"/>
  <w:LsdException Locked="false" Priority="62" SemiHidden="false"
   UnhideWhenUsed="false" Name="Light Grid Accent 4"/>
  <w:LsdException Locked="false" Priority="63" SemiHidden="false"
   UnhideWhenUsed="false" Name="Medium Shading 1 Accent 4"/>
  <w:LsdException Locked="false" Priority="64" SemiHidden="false"
   UnhideWhenUsed="false" Name="Medium Shading 2 Accent 4"/>
  <w:LsdException Locked="false" Priority="65" SemiHidden="false"
   UnhideWhenUsed="false" Name="Medium List 1 Accent 4"/>
  <w:LsdException Locked="false" Priority="66" SemiHidden="false"
   UnhideWhenUsed="false" Name="Medium List 2 Accent 4"/>
  <w:LsdException Locked="false" Priority="67" SemiHidden="false"
   UnhideWhenUsed="false" Name="Medium Grid 1 Accent 4"/>
  <w:LsdException Locked="false" Priority="68" SemiHidden="false"
   UnhideWhenUsed="false" Name="Medium Grid 2 Accent 4"/>
  <w:LsdException Locked="false" Priority="69" SemiHidden="false"
   UnhideWhenUsed="false" Name="Medium Grid 3 Accent 4"/>
  <w:LsdException Locked="false" Priority="70" SemiHidden="false"
   UnhideWhenUsed="false" Name="Dark List Accent 4"/>
  <w:LsdException Locked="false" Priority="71" SemiHidden="false"
   UnhideWhenUsed="false" Name="Colorful Shading Accent 4"/>
  <w:LsdException Locked="false" Priority="72" SemiHidden="false"
   UnhideWhenUsed="false" Name="Colorful List Accent 4"/>
  <w:LsdException Locked="false" Priority="73" SemiHidden="false"
   UnhideWhenUsed="false" Name="Colorful Grid Accent 4"/>
  <w:LsdException Locked="false" Priority="60" SemiHidden="false"
   UnhideWhenUsed="false" Name="Light Shading Accent 5"/>
  <w:LsdException Locked="false" Priority="61" SemiHidden="false"
   UnhideWhenUsed="false" Name="Light List Accent 5"/>
  <w:LsdException Locked="false" Priority="62" SemiHidden="false"
   UnhideWhenUsed="false" Name="Light Grid Accent 5"/>
  <w:LsdException Locked="false" Priority="63" SemiHidden="false"
   UnhideWhenUsed="false" Name="Medium Shading 1 Accent 5"/>
  <w:LsdException Locked="false" Priority="64" SemiHidden="false"
   UnhideWhenUsed="false" Name="Medium Shading 2 Accent 5"/>
  <w:LsdException Locked="false" Priority="65" SemiHidden="false"
   UnhideWhenUsed="false" Name="Medium List 1 Accent 5"/>
  <w:LsdException Locked="false" Priority="66" SemiHidden="false"
   UnhideWhenUsed="false" Name="Medium List 2 Accent 5"/>
  <w:LsdException Locked="false" Priority="67" SemiHidden="false"
   UnhideWhenUsed="false" Name="Medium Grid 1 Accent 5"/>
  <w:LsdException Locked="false" Priority="68" SemiHidden="false"
   UnhideWhenUsed="false" Name="Medium Grid 2 Accent 5"/>
  <w:LsdException Locked="false" Priority="69" SemiHidden="false"
   UnhideWhenUsed="false" Name="Medium Grid 3 Accent 5"/>
  <w:LsdException Locked="false" Priority="70" SemiHidden="false"
   UnhideWhenUsed="false" Name="Dark List Accent 5"/>
  <w:LsdException Locked="false" Priority="71" SemiHidden="false"
   UnhideWhenUsed="false" Name="Colorful Shading Accent 5"/>
  <w:LsdException Locked="false" Priority="72" SemiHidden="false"
   UnhideWhenUsed="false" Name="Colorful List Accent 5"/>
  <w:LsdException Locked="false" Priority="73" SemiHidden="false"
   UnhideWhenUsed="false" Name="Colorful Grid Accent 5"/>
  <w:LsdException Locked="false" Priority="60" SemiHidden="false"
   UnhideWhenUsed="false" Name="Light Shading Accent 6"/>
  <w:LsdException Locked="false" Priority="61" SemiHidden="false"
   UnhideWhenUsed="false" Name="Light List Accent 6"/>
  <w:LsdException Locked="false" Priority="62" SemiHidden="false"
   UnhideWhenUsed="false" Name="Light Grid Accent 6"/>
  <w:LsdException Locked="false" Priority="63" SemiHidden="false"
   UnhideWhenUsed="false" Name="Medium Shading 1 Accent 6"/>
  <w:LsdException Locked="false" Priority="64" SemiHidden="false"
   UnhideWhenUsed="false" Name="Medium Shading 2 Accent 6"/>
  <w:LsdException Locked="false" Priority="65" SemiHidden="false"
   UnhideWhenUsed="false" Name="Medium List 1 Accent 6"/>
  <w:LsdException Locked="false" Priority="66" SemiHidden="false"
   UnhideWhenUsed="false" Name="Medium List 2 Accent 6"/>
  <w:LsdException Locked="false" Priority="67" SemiHidden="false"
   UnhideWhenUsed="false" Name="Medium Grid 1 Accent 6"/>
  <w:LsdException Locked="false" Priority="68" SemiHidden="false"
   UnhideWhenUsed="false" Name="Medium Grid 2 Accent 6"/>
  <w:LsdException Locked="false" Priority="69" SemiHidden="false"
   UnhideWhenUsed="false" Name="Medium Grid 3 Accent 6"/>
  <w:LsdException Locked="false" Priority="70" SemiHidden="false"
   UnhideWhenUsed="false" Name="Dark List Accent 6"/>
  <w:LsdException Locked="false" Priority="71" SemiHidden="false"
   UnhideWhenUsed="false" Name="Colorful Shading Accent 6"/>
  <w:LsdException Locked="false" Priority="72" SemiHidden="false"
   UnhideWhenUsed="false" Name="Colorful List Accent 6"/>
  <w:LsdException Locked="false" Priority="73" SemiHidden="false"
   UnhideWhenUsed="false" Name="Colorful Grid Accent 6"/>
  <w:LsdException Locked="false" Priority="19" SemiHidden="false"
   UnhideWhenUsed="false" QFormat="true" Name="Subtle Emphasis"/>
  <w:LsdException Locked="false" Priority="21" SemiHidden="false"
   UnhideWhenUsed="false" QFormat="true" Name="Intense Emphasis"/>
  <w:LsdException Locked="false" Priority="31" SemiHidden="false"
   UnhideWhenUsed="false" QFormat="true" Name="Subtle Reference"/>
  <w:LsdException Locked="false" Priority="32" SemiHidden="false"
   UnhideWhenUsed="false" QFormat="true" Name="Intense Reference"/>
  <w:LsdException Locked="false" Priority="33" SemiHidden="false"
   UnhideWhenUsed="false" QFormat="true" Name="Book Title"/>
  <w:LsdException Locked="false" Priority="37" Name="Bibliography"/>
  <w:LsdException Locked="false" Priority="39" QFormat="true" Name="TOC Heading"/>
 </w:LatentStyles>
</xml><![endif]-->
      <style>
<!--
 /* Font Definitions */
@font-face
	{font-family:"&#65325;&#65331; &#26126;&#26397;";
	panose-1:0 0 0 0 0 0 0 0 0 0;
	mso-font-charset:128;
	mso-generic-font-family:roman;
	mso-font-format:other;
	mso-font-pitch:fixed;
	mso-font-signature:1 134676480 16 0 131072 0;}
@font-face
	{font-family:"Cambria Math";
	panose-1:2 4 5 3 5 4 6 3 2 4;
	mso-font-charset:0;
	mso-generic-font-family:auto;
	mso-font-pitch:variable;
	mso-font-signature:3 0 0 0 1 0;}
@font-face
	{font-family:Cambria;
	panose-1:2 4 5 3 5 4 6 3 2 4;
	mso-font-charset:0;
	mso-generic-font-family:auto;
	mso-font-pitch:variable;
	mso-font-signature:3 0 0 0 1 0;}
 /* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
	{mso-style-unhide:no;
	mso-style-qformat:yes;
	mso-style-parent:"";
	margin-top:0cm;
	margin-right:0cm;
	margin-bottom:10.0pt;
	margin-left:0cm;
	mso-pagination:widow-orphan;
	font-size:12.0pt;
	font-family:Cambria;
	mso-fareast-font-family:"&#65325;&#65331; &#26126;&#26397;";
	mso-bidi-font-family:"Times New Roman";
	mso-fareast-language:JA;}
.MsoChpDefault
	{mso-style-type:export-only;
	mso-default-props:yes;
	font-size:10.0pt;
	mso-ansi-font-size:10.0pt;
	mso-bidi-font-size:10.0pt;
	font-family:Cambria;
	mso-ascii-font-family:Cambria;
	mso-fareast-font-family:"&#65325;&#65331; &#26126;&#26397;";
	mso-hansi-font-family:Cambria;}
@page WordSection1
	{size:612.0pt 792.0pt;
	margin:72.0pt 90.0pt 72.0pt 90.0pt;
	mso-header-margin:36.0pt;
	mso-footer-margin:36.0pt;
	mso-paper-source:0;}
div.WordSection1
	{page:WordSection1;}
-->
</style><!--[if gte mso 10]>
<style>
 /* Style Definitions */
table.MsoNormalTable
	{mso-style-name:"Table Normal";
	mso-tstyle-rowband-size:0;
	mso-tstyle-colband-size:0;
	mso-style-noshow:yes;
	mso-style-priority:99;
	mso-style-parent:"";
	mso-padding-alt:0cm 5.4pt 0cm 5.4pt;
	mso-para-margin:0cm;
	mso-para-margin-bottom:.0001pt;
	mso-pagination:widow-orphan;
	font-size:10.0pt;
	font-family:Cambria;}
</style>
<![endif]--><!--StartFragment--><!--EndFragment-->Would this address
      your concern?<br>
      <br>
      Stewart<br>
      <br>
      <br>
      On 20/09/2013 12:29, Loa Andersson wrote:<br>
    </div>
    <blockquote cite="mid:[email-masked]" type="cite">Stewart,
      <br>
      <br>
      SPRING is a nice name :).
      <br>
      <br>
      The only thing that I don't find clear in this charter is
      <br>
      whether to specify modifications to the data planes and
      architectures
      <br>
      or if the group is supposed to act as a source for requirements
      for
      <br>
      such changes.
      <br>
      <br>
      I hope we can agree to see SPRING as source for requirements for
      <br>
      modification where the data plane and architecture has been
      developed
      <br>
      by another active working group.
      <br>
      <br>
      /Loa
      <br>
      <br>
      <br>
      On 2013-09-20 11:28, Stewart Bryant wrote:
      <br>
      <blockquote type="cite">This note is a summary of where we are
        with chartering the
        <br>
        work that we are discussing on the STATUS list and
        <br>
        the next steps.
        <br>
        <br>
        Firstly, as you know we (the ADs) had concerns with the
        <br>
        name "STATUS" being confusing. Having considered quite
        <br>
        a lot of possibilities, and not wanting the discussion
        <br>
        to bog down on a name,&nbsp; Adrian and I have decided
        <br>
        that the name Source Packet Routing in NetworkinG is
        <br>
        as good as any. Thus SPRING is name that we are using
        <br>
        in the charter process and is that I am putting in the
        <br>
        data-tracker for formal processing.
        <br>
        <br>
        Propose to start with the charter text that John Scudder
        <br>
        posted on 17/Sept with the following changes:
        <br>
        <br>
        s/&lt;TBD&gt;/SPRING/
        <br>
        <br>
        I removed "ordered" from ordered list, as I think there
        <br>
        was a consensus to do so in the following emails in
        <br>
        the thread.
        <br>
        <br>
        I have not changed the state text, as I could not see
        <br>
        a consensus on what if any change I should make.
        <br>
        <br>
        The charter is uploaded at
        <br>
        <br>
        <a class="moz-txt-link-freetext" href="https://datatracker.ietf.org/doc/charter-ietf-spring/">https://datatracker.ietf.org/doc/charter-ietf-spring/</a>
        <br>
        <br>
        What we now need the list members to do is to propose
        <br>
        any necessary changes to the text, and I will reflect
        <br>
        the consensus of the group in revised charter text.
        <br>
        The differences in the version of the charter text will
        <br>
        be visible through the datatracker charter diff tool.
        <br>
        <br>
        For continuity, discussion will continue on the STATUS
        <br>
        list until we have a chartered WG, at which point the
        <br>
        Secretariat will switch us over.
        <br>
        <br>
        For reference the text I uploaded is as follows:
        <br>
        <br>
        Name: Source Packet Routing in Networking (SPRING)
        <br>
        <br>
        The SPRING working group will define procedures that will allow
        <br>
        a node to steer a packet between any source and destination
        through
        <br>
        a SPRING region on any path without requiring state to be
        <br>
        maintained by transited nodes, but rather at the source device.&nbsp;
        A
        <br>
        SPRING region is a network comprised of nodes (which may be of
        <br>
        any type, including routers and appliances) that share the
        following
        <br>
        trust model: any node in the SPRING region is trusted to steer
        <br>
        a packet through any of the other nodes within the region. The
        <br>
        SPRING region may comprise one or more ASes, or even less than a
        <br>
        single AS. Although a region may comprise more than one AS,
        initial
        <br>
        work will focus on the intra-domain, that is, single AS,
        scenario.
        <br>
        <br>
        The procedures should support both centralised and distributed
        path
        <br>
        computation. The procedures should also cover support for OAM
        <br>
        functions.
        <br>
        <br>
        Where use cases are documented, care should be taken to define
        the
        <br>
        data plane requirements for the environment within which they
        are
        <br>
        to be implemented. The procedures should avoid modifications to
        <br>
        the MPLS data plane, in order to remain compatible with existing
        <br>
        extensive deployments of MPLS. It is anticipated that the
        procedures
        <br>
        may require modifications to the IPv6 data plane.&nbsp; While the
        initial
        <br>
        focus of the SPRING WG is on the intra-domain deployment
        scenarios
        <br>
        (see below), the modifications to the IPv6 data plane must
        support
        <br>
        both intra and inter-domain deployment scenarios.
        <br>
        <br>
        The SPRING working group is chartered for the following list of
        <br>
        items:
        <br>
        <br>
        o Identification and evaluation of use cases for which there
        <br>
        &nbsp;&nbsp; is consensus within the WG.
        <br>
        o Definition of new procedures, driven by the use cases and
        underlying
        <br>
        &nbsp;&nbsp; technology. The new procedures must cover security
        considerations
        <br>
        &nbsp;&nbsp; (including the relationship between networks forming the
        SPRING
        <br>
        &nbsp;&nbsp; region) and allow for solutions which substantially improve
        upon
        <br>
        &nbsp;&nbsp; current technologies by defining requirements, extensions, or
        new
        <br>
        &nbsp;&nbsp; functionality in existing routing, management or other
        protocols.
        <br>
        o Determine whether the above mentioned procedures require
        <br>
        &nbsp;&nbsp; modification/changes to the existing MPLS architecture, and
        <br>
        &nbsp;&nbsp; if so, then document such modifications/changes.
        <br>
        o Determine whether the above mentioned procedures require
        <br>
        &nbsp;&nbsp; modification/changes to the existing IPv6 architecture, and
        <br>
        &nbsp;&nbsp; if so, then document such modifications/changes.
        <br>
        o The SPRING working group will then develop solutions, focusing
        <br>
        &nbsp;&nbsp; initially on intra-domain deployment scenarios. Where such
        <br>
        &nbsp;&nbsp; solutions utilize existing protocols (IS-IS, OSPF, BGP, PCE)
        this will
        <br>
        &nbsp;&nbsp; be done in conjunction with the responsible IETF working
        group. Work
        <br>
        &nbsp;&nbsp; on new protocols may be carried out by the SPRING working
        group.
        <br>
        <br>
        The working group will develop the following documents:
        <br>
        <br>
        o One or more documents describing SPRING use cases,
        <br>
        o Specification of new procedures to support SPRING use cases,
        <br>
        o Changes to MPLS architecture, if needed
        <br>
        o Changes to IPv6 architecture, if needed
        <br>
        o Document interworking and co-existence between the new
        procedures
        <br>
        &nbsp;&nbsp; and the existing MPLS signaling protocols (LDP, RSVP-TE,
        BGP),
        <br>
        o Document impact (if any) of any proposed IPv6 data plane
        modifications
        <br>
        &nbsp;&nbsp; on existing deployment of IPv6,
        <br>
        o A set of one or more protocol extensions requirements
        documents,
        <br>
        o Inter-operability reports pertaining to the implementation of
        extensions
        <br>
        &nbsp;&nbsp; supporting SPRING.
        <br>
        <br>
        Please review and propose changes you think are necessary to the
        <br>
        list.
        <br>
        <br>
        - Stewart
        <br>
        <br>
        <br>
        <br>
        _______________________________________________
        <br>
        status mailing list
        <br>
        <a class="moz-txt-link-abbreviated" href="mailto:[email-masked]">[email-masked]</a>
        <br>
        <a class="moz-txt-link-freetext" href="https://www.ietf.org/mailman/listinfo/status">https://www.ietf.org/mailman/listinfo/status</a>
        <br>
      </blockquote>
      <br>
    </blockquote>
    <br>
    <br>
    <pre class="moz-signature" cols="72">-- 
For corporate legal information go to:

<a class="moz-txt-link-freetext" href="http://www.cisco.com/web/about/doing_business/legal/cri/index.html">http://www.cisco.com/web/about/doing_business/legal/cri/index.html</a>

</pre>
  </body>
</html>

--------------030101040306090307030501--

Date: Fri, 20 Sep 2013 13:29:42 +0200
From: Loa Andersson <[email-masked]>
To: [email-masked], "[email-masked]" <[email-masked]>
Subject: Re: [Status] Chartering next steps

Stewart,

SPRING is a nice name :).

The only thing that I don't find clear in this charter is
whether to specify modifications to the data planes and architectures
or if the group is supposed to act as a source for requirements for
such changes.

I hope we can agree to see SPRING as source for requirements for
modification where the data plane and architecture has been developed
by another active working group.

/Loa

On 2013-09-20 11:28, Stewart Bryant wrote:
> This note is a summary of where we are with chartering the
> work that we are discussing on the STATUS list and
> the next steps.
>
> Firstly, as you know we (the ADs) had concerns with the
> name "STATUS" being confusing. Having considered quite
> a lot of possibilities, and not wanting the discussion
> to bog down on a name,  Adrian and I have decided
> that the name Source Packet Routing in NetworkinG is
> as good as any. Thus SPRING is name that we are using
> in the charter process and is that I am putting in the
> data-tracker for formal processing.
>
> Propose to start with the charter text that John Scudder
> posted on 17/Sept with the following changes:
>
> s/<TBD>/SPRING/
>
> I removed "ordered" from ordered list, as I think there
> was a consensus to do so in the following emails in
> the thread.
>
> I have not changed the state text, as I could not see
> a consensus on what if any change I should make.
>
> The charter is uploaded at
>
> https://datatracker.ietf.org/doc/charter-ietf-spring/
>
> What we now need the list members to do is to propose
> any necessary changes to the text, and I will reflect
> the consensus of the group in revised charter text.
> The differences in the version of the charter text will
> be visible through the datatracker charter diff tool.
>
> For continuity, discussion will continue on the STATUS
> list until we have a chartered WG, at which point the
> Secretariat will switch us over.
>
> For reference the text I uploaded is as follows:
>
> Name: Source Packet Routing in Networking (SPRING)
>
> The SPRING working group will define procedures that will allow
> a node to steer a packet between any source and destination through
> a SPRING region on any path without requiring state to be
> maintained by transited nodes, but rather at the source device.  A
> SPRING region is a network comprised of nodes (which may be of
> any type, including routers and appliances) that share the following
> trust model: any node in the SPRING region is trusted to steer
> a packet through any of the other nodes within the region. The
> SPRING region may comprise one or more ASes, or even less than a
> single AS. Although a region may comprise more than one AS, initial
> work will focus on the intra-domain, that is, single AS, scenario.
>
> The procedures should support both centralised and distributed path
> computation. The procedures should also cover support for OAM
> functions.
>
> Where use cases are documented, care should be taken to define the
> data plane requirements for the environment within which they are
> to be implemented. The procedures should avoid modifications to
> the MPLS data plane, in order to remain compatible with existing
> extensive deployments of MPLS. It is anticipated that the procedures
> may require modifications to the IPv6 data plane.  While the initial
> focus of the SPRING WG is on the intra-domain deployment scenarios
> (see below), the modifications to the IPv6 data plane must support
> both intra and inter-domain deployment scenarios.
>
> The SPRING working group is chartered for the following list of
> items:
>
> o Identification and evaluation of use cases for which there
>    is consensus within the WG.
> o Definition of new procedures, driven by the use cases and underlying
>    technology. The new procedures must cover security considerations
>    (including the relationship between networks forming the SPRING
>    region) and allow for solutions which substantially improve upon
>    current technologies by defining requirements, extensions, or new
>    functionality in existing routing, management or other protocols.
> o Determine whether the above mentioned procedures require
>    modification/changes to the existing MPLS architecture, and
>    if so, then document such modifications/changes.
> o Determine whether the above mentioned procedures require
>    modification/changes to the existing IPv6 architecture, and
>    if so, then document such modifications/changes.
> o The SPRING working group will then develop solutions, focusing
>    initially on intra-domain deployment scenarios. Where such
>    solutions utilize existing protocols (IS-IS, OSPF, BGP, PCE) this will
>    be done in conjunction with the responsible IETF working group. Work
>    on new protocols may be carried out by the SPRING working group.
>
> The working group will develop the following documents:
>
> o One or more documents describing SPRING use cases,
> o Specification of new procedures to support SPRING use cases,
> o Changes to MPLS architecture, if needed
> o Changes to IPv6 architecture, if needed
> o Document interworking and co-existence between the new procedures
>    and the existing MPLS signaling protocols (LDP, RSVP-TE, BGP),
> o Document impact (if any) of any proposed IPv6 data plane modifications
>    on existing deployment of IPv6,
> o A set of one or more protocol extensions requirements documents,
> o Inter-operability reports pertaining to the implementation of extensions
>    supporting SPRING.
>
> Please review and propose changes you think are necessary to the
> list.
>
> - Stewart
>
>
>
> _______________________________________________
> status mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/status

-- 

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

Date: Fri, 20 Sep 2013 10:28:24 +0100
From: Stewart Bryant <[email-masked]>
To: "[email-masked]" <[email-masked]>
Cc: "[email-masked]" <[email-masked]>
Subject: [Status] Chartering next steps
Reply-To: [email-masked]

This note is a summary of where we are with chartering the
work that we are discussing on the STATUS list and
the next steps.

Firstly, as you know we (the ADs) had concerns with the
name "STATUS" being confusing. Having considered quite
a lot of possibilities, and not wanting the discussion
to bog down on a name,  Adrian and I have decided
that the name Source Packet Routing in NetworkinG is
as good as any. Thus SPRING is name that we are using
in the charter process and is that I am putting in the
data-tracker for formal processing.

Propose to start with the charter text that John Scudder
posted on 17/Sept with the following changes:

s/<TBD>/SPRING/

I removed "ordered" from ordered list, as I think there
was a consensus to do so in the following emails in
the thread.

I have not changed the state text, as I could not see
a consensus on what if any change I should make.

The charter is uploaded at

https://datatracker.ietf.org/doc/charter-ietf-spring/

What we now need the list members to do is to propose
any necessary changes to the text, and I will reflect
the consensus of the group in revised charter text.
The differences in the version of the charter text will
be visible through the datatracker charter diff tool.

For continuity, discussion will continue on the STATUS
list until we have a chartered WG, at which point the
Secretariat will switch us over.

For reference the text I uploaded is as follows:

Name: Source Packet Routing in Networking (SPRING)

The SPRING working group will define procedures that will allow
a node to steer a packet between any source and destination through
a SPRING region on any path without requiring state to be
maintained by transited nodes, but rather at the source device.  A
SPRING region is a network comprised of nodes (which may be of
any type, including routers and appliances) that share the following
trust model: any node in the SPRING region is trusted to steer
a packet through any of the other nodes within the region. The
SPRING region may comprise one or more ASes, or even less than a
single AS. Although a region may comprise more than one AS, initial
work will focus on the intra-domain, that is, single AS, scenario.

The procedures should support both centralised and distributed path
computation. The procedures should also cover support for OAM
functions.

Where use cases are documented, care should be taken to define the
data plane requirements for the environment within which they are
to be implemented. The procedures should avoid modifications to
the MPLS data plane, in order to remain compatible with existing
extensive deployments of MPLS. It is anticipated that the procedures
may require modifications to the IPv6 data plane.  While the initial
focus of the SPRING WG is on the intra-domain deployment scenarios
(see below), the modifications to the IPv6 data plane must support
both intra and inter-domain deployment scenarios.

The SPRING working group is chartered for the following list of
items:

o Identification and evaluation of use cases for which there
   is consensus within the WG.
o Definition of new procedures, driven by the use cases and underlying
   technology. The new procedures must cover security considerations
   (including the relationship between networks forming the SPRING
   region) and allow for solutions which substantially improve upon
   current technologies by defining requirements, extensions, or new
   functionality in existing routing, management or other protocols.
o Determine whether the above mentioned procedures require
   modification/changes to the existing MPLS architecture, and
   if so, then document such modifications/changes.
o Determine whether the above mentioned procedures require
   modification/changes to the existing IPv6 architecture, and
   if so, then document such modifications/changes.
o The SPRING working group will then develop solutions, focusing
   initially on intra-domain deployment scenarios. Where such
   solutions utilize existing protocols (IS-IS, OSPF, BGP, PCE) this will
   be done in conjunction with the responsible IETF working group. Work
   on new protocols may be carried out by the SPRING working group.

The working group will develop the following documents:

o One or more documents describing SPRING use cases,
o Specification of new procedures to support SPRING use cases,
o Changes to MPLS architecture, if needed
o Changes to IPv6 architecture, if needed
o Document interworking and co-existence between the new procedures
   and the existing MPLS signaling protocols (LDP, RSVP-TE, BGP),
o Document impact (if any) of any proposed IPv6 data plane modifications
   on existing deployment of IPv6,
o A set of one or more protocol extensions requirements documents,
o Inter-operability reports pertaining to the implementation of extensions
   supporting SPRING.

Please review and propose changes you think are necessary to the
list.

- Stewart

From: <[email-masked]>
To: <[email-masked]>
Date: Fri, 20 Sep 2013 08:31:33 +0200
Accept-Language: en-US, de-DE
acceptlanguage: en-US, de-DE
Cc: [email-masked], [email-masked], [email-masked], [email-masked]
Subject: Re: [Status] TBD Charter - ready of RTG AD review yes/no

Hi John,

Loa's comment below refers to a piece of text of your draft charter
which I didn't change. So I think you should pick up his comment.

Regards,

Ruediger

-----Original Message-----
From: Loa Andersson [mailto:[email-masked]]
Sent: Thursday, September 19, 2013 5:49 PM
To: Geib, R=FCdiger
Cc: [email-masked]; [email-masked]; [email-masked]
Subject: Re: [Status] TBD Charter - ready of RTG AD review yes/no

Ruediger,

it depends on what you mean with "document such modifications/changes".
Almost everything we do in the IETF is documents - we are documenting.

In this case I assume you mean "document the requirements for such
changes" and then let the the working group that owns the particular
data plane specify the actual changes.

Otherwise this look pretty good.

/Loa

On 2013-09-19 08:33, [email-masked] wrote:
> John,
>
> there's another detail which should be clarified:
>
>> The <Name-TBD> working group is chartered for the following (ordered) li=
st of items:
> ....
>
> I'd expect work related to MPLS based SR to start relatively soon, while =
work on IPv6 based SR may require a more thorough analysis. The "(ordered)"=
 therefore should be removed or the  order should be adapted to express tha=
t:
>
>    o Determine whether the above mentioned procedures require
>      modification/changes to the existing MPLS architecture, and
>      if so, then document such modifications/changes.
>    o Determine whether the above mentioned procedures require
>      modification/changes to the existing IPv6 architecture, and
>      if so, then document such modifications/changes.
>      In parallel, the <Name-TBD> working group will develop
>      solutions for a MPLS architecture, focusing initially on
>      intra-domain deployment scenarios. Where such solutions
>      utilize existing protocols (IS-IS, OSPF, BGP, PCE) this will
>      be done in conjunction with the responsible IETF working group. Work
>      on new protocols may be carried out by the <Name-TBD> working group.
>    o The <Name-TBD> working group will then develop solutions for an IPv6
>      architecture, focusing initially on intra-domain deployment scenario=
s.
>      Where such solutions utilize existing protocols (IS-IS, OSPF, BGP, P=
CE)
>      this will be done in conjunction with the responsible IETF working g=
roup.
>      Work on new protocols may be carried out by the <Name-TBD> working g=
roup.
>
> Regards,
>
> Ruediger
>
>
>> -----Original Message-----
>> From: [email-masked] [mailto:[email-masked]] On
>> Behalf Of John G.Scudder
>> Sent: Tuesday, September 17, 2013 7:22 AM
>> To: [email-masked]
>> Cc: Adrian Farrel; [email-masked]
>> Subject: Re: [Status] TBD Charter - ready of RTG AD review yes/no
>>
>> All,
>>
>> Here's another attempt. It tries to address the 'architecture' issue I r=
aised earlier, as well as incorporate Mark Townsley, Bruno Decraene and Rob=
 Shakir's comments. With luck the change from '<Name-TBD> domain' to '<Name=
-TBD> region' relieves the ambiguity that was present in earlier versions.
>>
>> --John
>>
>> ---------------------------------------------------------
>> Name: <TBD>
>>
>> The <Name-TBD> working group will define procedures that will allow a no=
de to steer a packet between any source and destination through a <Name-TBD=
> region on any path without requiring state to be maintained by transited =
nodes, but rather at the source device.  A <Name-TBD> region is a network c=
omprised of nodes (which may be of any type, including routers and applianc=
es) that share the following trust model: any node in the <Name-TBD> region=
 is trusted to steer a packet through any of the other nodes within the reg=
ion. The <Name-TBD> region may comprise one or more ASes, or even less than=
 a single AS. Although a region may comprise more than one AS, initial work=
 will focus on the intra-domain, that is, single AS, scenario.
>>
>> The procedures should support both centralised and distributed path comp=
utation. The procedures should also cover support for OAM functions.
>>
>> Where use cases are documented, care should be taken to define the data =
plane requirements for the environment within which they are to be implemen=
ted. The procedures should avoid modifications to the MPLS data plane, in o=
rder to remain compatible with existing extensive deployments of MPLS. It i=
s anticipated that the procedures may require modifications to the IPv6 dat=
a plane.  While the initial focus of the <Name-TBD> WG is on the intra-doma=
in deployment scenarios (see below), the modifications to the IPv6 data pla=
ne must support both intra and inter-domain deployment scenarios.
>>
>> The <Name-TBD> working group is chartered for the following (ordered) li=
st of items:
>>
>> o Identification and evaluation of use cases for which there
>>    is consensus within the WG.
>> o Definition of new procedures, driven by the use cases and underlying
>>    technology. The new procedures must cover security considerations
>>    (including the relationship between networks forming the <Name-TBD>
>>    region) and allow for solutions which substantially improve upon
>>    current technologies by defining requirements, extensions, or new
>>    functionality in existing routing, management or other protocols.
>> o Determine whether the above mentioned procedures require
>>    modification/changes to the existing MPLS architecture, and
>>    if so, then document such modifications/changes.
>> o Determine whether the above mentioned procedures require
>>    modification/changes to the existing IPv6 architecture, and
>>    if so, then document such modifications/changes.
>> o The <Name-TBD> working group will then develop solutions, focusing
>>    initially on intra-domain deployment scenarios. Where such
>>    solutions utilize existing protocols (IS-IS, OSPF, BGP, PCE) this wil=
l
>>    be done in conjunction with the responsible IETF working group. Work
>>    on new protocols may be carried out by the <Name-TBD> working group.
>>
>> The working group will develop the following documents:
>>
>> o One or more documents describing <Name-TBD> use cases, o Specification=
 of new procedures to support <Name-TBD> use cases, o Changes to MPLS archi=
tecture, if needed o Changes to IPv6 architecture, if needed o Document int=
erworking and co-existence between the new procedures
>>    and the existing MPLS signaling protocols (LDP, RSVP-TE, BGP), o Docu=
ment impact (if any) of any proposed IPv6 data plane modifications
>>    on existing deployment of IPv6,
>> o A set of one or more protocol extensions requirements documents, o Int=
er-operability reports pertaining to the implementation of extensions
>>    supporting <Name-TBD>.
>> _______________________________________________
>> status mailing list
>> [email-masked]
>> https://www.ietf.org/mailman/listinfo/status
>> _______________________________________________
>> status mailing list
>> [email-masked]
>> https://www.ietf.org/mailman/listinfo/status
> _______________________________________________
> status mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/status
> _______________________________________________
> status mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/status
>

--

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

Date: Thu, 19 Sep 2013 17:48:37 +0200
From: Loa Andersson <[email-masked]>
To: [email-masked]
Cc: [email-masked], [email-masked], [email-masked]
Subject: Re: [Status] TBD Charter - ready of RTG AD review yes/no

Ruediger,

it depends on what you mean with "document such modifications/changes".
Almost everything we do in the IETF is documents - we are documenting.

In this case I assume you mean "document the requirements for such
changes" and then let the the working group that owns the particular
data plane specify the actual changes.

Otherwise this look pretty good.

/Loa

On 2013-09-19 08:33, [email-masked] wrote:
> John,
>
> there's another detail which should be clarified:
>
>> The <Name-TBD> working group is chartered for the following (ordered) list of items:
> ....
>
> I'd expect work related to MPLS based SR to start relatively soon, while work on IPv6 based SR may require a more thorough analysis. The "(ordered)" therefore should be removed or the  order should be adapted to express that:
>
>    o Determine whether the above mentioned procedures require
>      modification/changes to the existing MPLS architecture, and
>      if so, then document such modifications/changes.
>    o Determine whether the above mentioned procedures require
>      modification/changes to the existing IPv6 architecture, and
>      if so, then document such modifications/changes.
>      In parallel, the <Name-TBD> working group will develop
>      solutions for a MPLS architecture, focusing initially on
>      intra-domain deployment scenarios. Where such solutions
>      utilize existing protocols (IS-IS, OSPF, BGP, PCE) this will
>      be done in conjunction with the responsible IETF working group. Work
>      on new protocols may be carried out by the <Name-TBD> working group.
>    o The <Name-TBD> working group will then develop solutions for an IPv6
>      architecture, focusing initially on intra-domain deployment scenarios.
>      Where such solutions utilize existing protocols (IS-IS, OSPF, BGP, PCE)
>      this will be done in conjunction with the responsible IETF working group.
>      Work on new protocols may be carried out by the <Name-TBD> working group.
>
> Regards,
>
> Ruediger
>
>
>> -----Original Message-----
>> From: [email-masked] [mailto:[email-masked]] On
>> Behalf Of John G.Scudder
>> Sent: Tuesday, September 17, 2013 7:22 AM
>> To: [email-masked]
>> Cc: Adrian Farrel; [email-masked]
>> Subject: Re: [Status] TBD Charter - ready of RTG AD review yes/no
>>
>> All,
>>
>> Here's another attempt. It tries to address the 'architecture' issue I raised earlier, as well as incorporate Mark Townsley, Bruno Decraene and Rob Shakir's comments. With luck the change from '<Name-TBD> domain' to '<Name-TBD> region' relieves the ambiguity that was present in earlier versions.
>>
>> --John
>>
>> ---------------------------------------------------------
>> Name: <TBD>
>>
>> The <Name-TBD> working group will define procedures that will allow a node to steer a packet between any source and destination through a <Name-TBD> region on any path without requiring state to be maintained by transited nodes, but rather at the source device.  A <Name-TBD> region is a network comprised of nodes (which may be of any type, including routers and appliances) that share the following trust model: any node in the <Name-TBD> region is trusted to steer a packet through any of the other nodes within the region. The <Name-TBD> region may comprise one or more ASes, or even less than a single AS. Although a region may comprise more than one AS, initial work will focus on the intra-domain, that is, single AS, scenario.
>>
>> The procedures should support both centralised and distributed path computation. The procedures should also cover support for OAM functions.
>>
>> Where use cases are documented, care should be taken to define the data plane requirements for the environment within which they are to be implemented. The procedures should avoid modifications to the MPLS data plane, in order to remain compatible with existing extensive deployments of MPLS. It is anticipated that the procedures may require modifications to the IPv6 data plane.  While the initial focus of the <Name-TBD> WG is on the intra-domain deployment scenarios (see below), the modifications to the IPv6 data plane must support both intra and inter-domain deployment scenarios.
>>
>> The <Name-TBD> working group is chartered for the following (ordered) list of items:
>>
>> o Identification and evaluation of use cases for which there
>>    is consensus within the WG.
>> o Definition of new procedures, driven by the use cases and underlying
>>    technology. The new procedures must cover security considerations
>>    (including the relationship between networks forming the <Name-TBD>
>>    region) and allow for solutions which substantially improve upon
>>    current technologies by defining requirements, extensions, or new
>>    functionality in existing routing, management or other protocols.
>> o Determine whether the above mentioned procedures require
>>    modification/changes to the existing MPLS architecture, and
>>    if so, then document such modifications/changes.
>> o Determine whether the above mentioned procedures require
>>    modification/changes to the existing IPv6 architecture, and
>>    if so, then document such modifications/changes.
>> o The <Name-TBD> working group will then develop solutions, focusing
>>    initially on intra-domain deployment scenarios. Where such
>>    solutions utilize existing protocols (IS-IS, OSPF, BGP, PCE) this will
>>    be done in conjunction with the responsible IETF working group. Work
>>    on new protocols may be carried out by the <Name-TBD> working group.
>>
>> The working group will develop the following documents:
>>
>> o One or more documents describing <Name-TBD> use cases, o Specification of new procedures to support <Name-TBD> use cases, o Changes to MPLS architecture, if needed o Changes to IPv6 architecture, if needed o Document interworking and co-existence between the new procedures
>>    and the existing MPLS signaling protocols (LDP, RSVP-TE, BGP), o Document impact (if any) of any proposed IPv6 data plane modifications
>>    on existing deployment of IPv6,
>> o A set of one or more protocol extensions requirements documents, o Inter-operability reports pertaining to the implementation of extensions
>>    supporting <Name-TBD>.
>> _______________________________________________
>> status mailing list
>> [email-masked]
>> https://www.ietf.org/mailman/listinfo/status
>> _______________________________________________
>> status mailing list
>> [email-masked]
>> https://www.ietf.org/mailman/listinfo/status
> _______________________________________________
> status mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/status
> _______________________________________________
> status mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/status
>

-- 

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

From: "John G. Scudder" <[email-masked]>
Date: Thu, 19 Sep 2013 09:45:37 -0400
To: <[email-masked]>
Cc: [email-masked], [email-masked], [email-masked]
Subject: Re: [Status] TBD Charter - ready of RTG AD review yes/no

On Sep 19, 2013, at 2:33 AM, [email-masked] wrote:

> The "(ordered)" therefore should be removed or the  order should be adapted

That would be just fine with me.

--John

From: <[email-masked]>
To: "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>
Date: Thu, 19 Sep 2013 07:49:38 +0000
Accept-Language: fr-FR, en-US
Cc: "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>
Subject: Re: [Status] TBD Charter - ready of RTG AD review yes/no

John,

Thank you for the proposed charter which looks fine to me.

Nonetheless, +1 to Ruediger's comment: the last 3 points (MPLS forwarding p=
lane, IPv6 forwarding plane, generic control plane) may be done in no parti=
cular order, including in parallel.
(and at the very least, if an order is mandatory, it would ease the WG life=
/work to favor an order based on maturity & consensus, i.e. starting with M=
PLS and not putting IPv6 forwarding plane extension on the critical path)

Regards,
Bruno

>From: [email-masked]
>
>John,
>
>there's another detail which should be clarified:
>
>> The <Name-TBD> working group is chartered for the following (ordered) li=
st
>of items:
>....
>
>I'd expect work related to MPLS based SR to start relatively soon, while
>work on IPv6 based SR may require a more thorough analysis. The "(ordered)"
>therefore should be removed or the  order should be adapted to express tha=
t:
>
>  o Determine whether the above mentioned procedures require
>    modification/changes to the existing MPLS architecture, and
>    if so, then document such modifications/changes.
>  o Determine whether the above mentioned procedures require
>    modification/changes to the existing IPv6 architecture, and
>    if so, then document such modifications/changes.
>    In parallel, the <Name-TBD> working group will develop
>    solutions for a MPLS architecture, focusing initially on
>    intra-domain deployment scenarios. Where such solutions
>    utilize existing protocols (IS-IS, OSPF, BGP, PCE) this will
>    be done in conjunction with the responsible IETF working group. Work
>    on new protocols may be carried out by the <Name-TBD> working group.
>  o The <Name-TBD> working group will then develop solutions for an IPv6
>    architecture, focusing initially on intra-domain deployment scenarios.
>    Where such solutions utilize existing protocols (IS-IS, OSPF, BGP, PCE)
>    this will be done in conjunction with the responsible IETF working
>group.
>    Work on new protocols may be carried out by the <Name-TBD> working
>group.
>
>Regards,
>
>Ruediger
>
>
>> -----Original Message-----
>> From: [email-masked] [mailto:[email-masked]] On
>> Behalf Of John G.Scudder
>> Sent: Tuesday, September 17, 2013 7:22 AM
>> To: [email-masked]
>> Cc: Adrian Farrel; [email-masked]
>> Subject: Re: [Status] TBD Charter - ready of RTG AD review yes/no
>>
>> All,
>>
>> Here's another attempt. It tries to address the 'architecture' issue I
>raised earlier, as well as incorporate Mark Townsley, Bruno Decraene and R=
ob
>Shakir's comments. With luck the change from '<Name-TBD> domain' to '<Name-
>TBD> region' relieves the ambiguity that was present in earlier versions.
>>
>> --John
>>
>> ---------------------------------------------------------
>> Name: <TBD>
>>
>> The <Name-TBD> working group will define procedures that will allow a no=
de
>to steer a packet between any source and destination through a <Name-TBD>
>region on any path without requiring state to be maintained by transited
>nodes, but rather at the source device.  A <Name-TBD> region is a network
>comprised of nodes (which may be of any type, including routers and
>appliances) that share the following trust model: any node in the <Name-TB=
D>
>region is trusted to steer a packet through any of the other nodes within
>the region. The <Name-TBD> region may comprise one or more ASes, or even
>less than a single AS. Although a region may comprise more than one AS,
>initial work will focus on the intra-domain, that is, single AS, scenario.
>>
>> The procedures should support both centralised and distributed path
>computation. The procedures should also cover support for OAM functions.
>>
>> Where use cases are documented, care should be taken to define the data
>plane requirements for the environment within which they are to be
>implemented. The procedures should avoid modifications to the MPLS data
>plane, in order to remain compatible with existing extensive deployments of
>MPLS. It is anticipated that the procedures may require modifications to t=
he
>IPv6 data plane.  While the initial focus of the <Name-TBD> WG is on the
>intra-domain deployment scenarios (see below), the modifications to the IP=
v6
>data plane must support both intra and inter-domain deployment scenarios.
>>
>> The <Name-TBD> working group is chartered for the following (ordered) li=
st
>of items:
>>
>> o Identification and evaluation of use cases for which there
>>   is consensus within the WG.
>> o Definition of new procedures, driven by the use cases and underlying
>>   technology. The new procedures must cover security considerations
>>   (including the relationship between networks forming the <Name-TBD>
>>   region) and allow for solutions which substantially improve upon
>>   current technologies by defining requirements, extensions, or new
>>   functionality in existing routing, management or other protocols.
>> o Determine whether the above mentioned procedures require
>>   modification/changes to the existing MPLS architecture, and
>>   if so, then document such modifications/changes.
>> o Determine whether the above mentioned procedures require
>>   modification/changes to the existing IPv6 architecture, and
>>   if so, then document such modifications/changes.
>> o The <Name-TBD> working group will then develop solutions, focusing
>>   initially on intra-domain deployment scenarios. Where such
>>   solutions utilize existing protocols (IS-IS, OSPF, BGP, PCE) this will
>>   be done in conjunction with the responsible IETF working group. Work
>>   on new protocols may be carried out by the <Name-TBD> working group.
>>
>> The working group will develop the following documents:
>>
>> o One or more documents describing <Name-TBD> use cases, o Specification
>of new procedures to support <Name-TBD> use cases, o Changes to MPLS
>architecture, if needed o Changes to IPv6 architecture, if needed o Docume=
nt
>interworking and co-existence between the new procedures
>>   and the existing MPLS signaling protocols (LDP, RSVP-TE, BGP), o
>Document impact (if any) of any proposed IPv6 data plane modifications
>>   on existing deployment of IPv6,
>> o A set of one or more protocol extensions requirements documents, o
>Inter-operability reports pertaining to the implementation of extensions
>>   supporting <Name-TBD>.
>> _______________________________________________
>> status mailing list
>> [email-masked]
>> https://www.ietf.org/mailman/listinfo/status
>> _______________________________________________
>> status mailing list
>> [email-masked]
>> https://www.ietf.org/mailman/listinfo/status
>_______________________________________________
>status mailing list
>[email-masked]
>https://www.ietf.org/mailman/listinfo/status
>_______________________________________________
>status mailing list
>[email-masked]
>https://www.ietf.org/mailman/listinfo/status

___________________________________________________________________________=
______________________________________________

Ce message et ses pieces jointes peuvent contenir des informations confiden=
tielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu=
 ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages el=
ectroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou =
falsifie. Merci.

This message and its attachments may contain confidential or privileged inf=
ormation that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and dele=
te this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been =
modified, changed or falsified.
Thank you.

From: Mark Townsley <[email-masked]>
Date: Thu, 19 Sep 2013 09:17:40 +0200
To: Jeff Tantsura <[email-masked]>
Cc: "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>
Subject: Re: [Status] TBD Charter - ready of RTG AD review yes/no

+1.=20

Also, any expected ordering can be reflected in the WG milestones that =
can be updated based on the pace and output of the WG without going =
through the entire IETF consensus process the charter text must go =
through.=20

- Mark

On Sep 19, 2013, at 8:52 AM, Jeff Tantsura wrote:

> Agree with Ruediger, also the order put looks about right.
>=20
> Regards,
> Jeff
>=20
> On Sep 18, 2013, at 11:34 PM, "[email-masked]" =
<[email-masked]> wrote:
>=20
>> John,
>>=20
>> there's another detail which should be clarified:
>>=20
>>> The <Name-TBD> working group is chartered for the following =
(ordered) list of items:
>> ....
>>=20
>> I'd expect work related to MPLS based SR to start relatively soon, =
while work on IPv6 based SR may require a more thorough analysis. The =
"(ordered)" therefore should be removed or the  order should be adapted =
to express that:
>>=20
>> o Determine whether the above mentioned procedures require
>>   modification/changes to the existing MPLS architecture, and
>>   if so, then document such modifications/changes.
>> o Determine whether the above mentioned procedures require
>>   modification/changes to the existing IPv6 architecture, and
>>   if so, then document such modifications/changes.
>>   In parallel, the <Name-TBD> working group will develop
>>   solutions for a MPLS architecture, focusing initially on
>>   intra-domain deployment scenarios. Where such solutions
>>   utilize existing protocols (IS-IS, OSPF, BGP, PCE) this will
>>   be done in conjunction with the responsible IETF working group. =
Work
>>   on new protocols may be carried out by the <Name-TBD> working =
group.
>> o The <Name-TBD> working group will then develop solutions for an =
IPv6
>>   architecture, focusing initially on intra-domain deployment =
scenarios.
>>   Where such solutions utilize existing protocols (IS-IS, OSPF, BGP, =
PCE)
>>   this will be done in conjunction with the responsible IETF working =
group.
>>   Work on new protocols may be carried out by the <Name-TBD> working =
group.
>>=20
>> Regards,
>>=20
>> Ruediger
>>=20
>>=20
>>> -----Original Message-----
>>> From: [email-masked] [mailto:[email-masked]] On
>>> Behalf Of John G.Scudder
>>> Sent: Tuesday, September 17, 2013 7:22 AM
>>> To: [email-masked]
>>> Cc: Adrian Farrel; [email-masked]
>>> Subject: Re: [Status] TBD Charter - ready of RTG AD review yes/no
>>>=20
>>> All,
>>>=20
>>> Here's another attempt. It tries to address the 'architecture' issue =
I raised earlier, as well as incorporate Mark Townsley, Bruno Decraene =
and Rob Shakir's comments. With luck the change from '<Name-TBD> domain' =
to '<Name-TBD> region' relieves the ambiguity that was present in =
earlier versions.
>>>=20
>>> --John
>>>=20
>>> ---------------------------------------------------------
>>> Name: <TBD>
>>>=20
>>> The <Name-TBD> working group will define procedures that will allow =
a node to steer a packet between any source and destination through a =
<Name-TBD> region on any path without requiring state to be maintained =
by transited nodes, but rather at the source device.  A <Name-TBD> =
region is a network comprised of nodes (which may be of any type, =
including routers and appliances) that share the following trust model: =
any node in the <Name-TBD> region is trusted to steer a packet through =
any of the other nodes within the region. The <Name-TBD> region may =
comprise one or more ASes, or even less than a single AS. Although a =
region may comprise more than one AS, initial work will focus on the =
intra-domain, that is, single AS, scenario.
>>>=20
>>> The procedures should support both centralised and distributed path =
computation. The procedures should also cover support for OAM functions.
>>>=20
>>> Where use cases are documented, care should be taken to define the =
data plane requirements for the environment within which they are to be =
implemented. The procedures should avoid modifications to the MPLS data =
plane, in order to remain compatible with existing extensive deployments =
of MPLS. It is anticipated that the procedures may require modifications =
to the IPv6 data plane.  While the initial focus of the <Name-TBD> WG is =
on the intra-domain deployment scenarios (see below), the modifications =
to the IPv6 data plane must support both intra and inter-domain =
deployment scenarios.
>>>=20
>>> The <Name-TBD> working group is chartered for the following =
(ordered) list of items:
>>>=20
>>> o Identification and evaluation of use cases for which there
>>> is consensus within the WG.
>>> o Definition of new procedures, driven by the use cases and =
underlying
>>> technology. The new procedures must cover security considerations
>>> (including the relationship between networks forming the <Name-TBD>
>>> region) and allow for solutions which substantially improve upon
>>> current technologies by defining requirements, extensions, or new
>>> functionality in existing routing, management or other protocols.
>>> o Determine whether the above mentioned procedures require
>>> modification/changes to the existing MPLS architecture, and
>>> if so, then document such modifications/changes.
>>> o Determine whether the above mentioned procedures require
>>> modification/changes to the existing IPv6 architecture, and
>>> if so, then document such modifications/changes.
>>> o The <Name-TBD> working group will then develop solutions, focusing
>>> initially on intra-domain deployment scenarios. Where such
>>> solutions utilize existing protocols (IS-IS, OSPF, BGP, PCE) this =
will
>>> be done in conjunction with the responsible IETF working group. Work
>>> on new protocols may be carried out by the <Name-TBD> working group.
>>>=20
>>> The working group will develop the following documents:
>>>=20
>>> o One or more documents describing <Name-TBD> use cases, o =
Specification of new procedures to support <Name-TBD> use cases, o =
Changes to MPLS architecture, if needed o Changes to IPv6 architecture, =
if needed o Document interworking and co-existence between the new =
procedures
>>> and the existing MPLS signaling protocols (LDP, RSVP-TE, BGP), o =
Document impact (if any) of any proposed IPv6 data plane modifications
>>> on existing deployment of IPv6,
>>> o A set of one or more protocol extensions requirements documents, o =
Inter-operability reports pertaining to the implementation of extensions
>>> supporting <Name-TBD>.
>>> _______________________________________________
>>> status mailing list
>>> [email-masked]
>>> https://www.ietf.org/mailman/listinfo/status
>>> _______________________________________________
>>> status mailing list
>>> [email-masked]
>>> https://www.ietf.org/mailman/listinfo/status
>> _______________________________________________
>> status mailing list
>> [email-masked]
>> https://www.ietf.org/mailman/listinfo/status
>> _______________________________________________
>> status mailing list
>> [email-masked]
>> https://www.ietf.org/mailman/listinfo/status
> _______________________________________________
> status mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/status

From: Jeff Tantsura <[email-masked]>
To: "[email-masked]" <[email-masked]>
Date: Thu, 19 Sep 2013 06:52:39 +0000
Accept-Language: en-US
Cc: "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>
Subject: Re: [Status] TBD Charter - ready of RTG AD review yes/no

Agree with Ruediger, also the order put looks about right.

Regards,
Jeff

On Sep 18, 2013, at 11:34 PM, "[email-masked]" <Ruediger.Geib@tel=
ekom.de> wrote:

> John,
>=20
> there's another detail which should be clarified:
>=20
>> The <Name-TBD> working group is chartered for the following (ordered) li=
st of items:
> ....
>=20
> I'd expect work related to MPLS based SR to start relatively soon, while =
work on IPv6 based SR may require a more thorough analysis. The "(ordered)"=
 therefore should be removed or the  order should be adapted to express tha=
t:
>=20
>  o Determine whether the above mentioned procedures require
>    modification/changes to the existing MPLS architecture, and
>    if so, then document such modifications/changes.
>  o Determine whether the above mentioned procedures require
>    modification/changes to the existing IPv6 architecture, and
>    if so, then document such modifications/changes.
>    In parallel, the <Name-TBD> working group will develop
>    solutions for a MPLS architecture, focusing initially on
>    intra-domain deployment scenarios. Where such solutions
>    utilize existing protocols (IS-IS, OSPF, BGP, PCE) this will
>    be done in conjunction with the responsible IETF working group. Work
>    on new protocols may be carried out by the <Name-TBD> working group.
>  o The <Name-TBD> working group will then develop solutions for an IPv6
>    architecture, focusing initially on intra-domain deployment scenarios.
>    Where such solutions utilize existing protocols (IS-IS, OSPF, BGP, PCE=
)
>    this will be done in conjunction with the responsible IETF working gro=
up.
>    Work on new protocols may be carried out by the <Name-TBD> working gro=
up.
>=20
> Regards,
>=20
> Ruediger
>=20
>=20
>> -----Original Message-----
>> From: [email-masked] [mailto:[email-masked]] On
>> Behalf Of John G.Scudder
>> Sent: Tuesday, September 17, 2013 7:22 AM
>> To: [email-masked]
>> Cc: Adrian Farrel; [email-masked]
>> Subject: Re: [Status] TBD Charter - ready of RTG AD review yes/no
>>=20
>> All,
>>=20
>> Here's another attempt. It tries to address the 'architecture' issue I r=
aised earlier, as well as incorporate Mark Townsley, Bruno Decraene and Rob=
 Shakir's comments. With luck the change from '<Name-TBD> domain' to '<Name=
-TBD> region' relieves the ambiguity that was present in earlier versions.
>>=20
>> --John
>>=20
>> ---------------------------------------------------------
>> Name: <TBD>
>>=20
>> The <Name-TBD> working group will define procedures that will allow a no=
de to steer a packet between any source and destination through a <Name-TBD=
> region on any path without requiring state to be maintained by transited =
nodes, but rather at the source device.  A <Name-TBD> region is a network c=
omprised of nodes (which may be of any type, including routers and applianc=
es) that share the following trust model: any node in the <Name-TBD> region=
 is trusted to steer a packet through any of the other nodes within the reg=
ion. The <Name-TBD> region may comprise one or more ASes, or even less than=
 a single AS. Although a region may comprise more than one AS, initial work=
 will focus on the intra-domain, that is, single AS, scenario.
>>=20
>> The procedures should support both centralised and distributed path comp=
utation. The procedures should also cover support for OAM functions.
>>=20
>> Where use cases are documented, care should be taken to define the data =
plane requirements for the environment within which they are to be implemen=
ted. The procedures should avoid modifications to the MPLS data plane, in o=
rder to remain compatible with existing extensive deployments of MPLS. It i=
s anticipated that the procedures may require modifications to the IPv6 dat=
a plane.  While the initial focus of the <Name-TBD> WG is on the intra-doma=
in deployment scenarios (see below), the modifications to the IPv6 data pla=
ne must support both intra and inter-domain deployment scenarios.
>>=20
>> The <Name-TBD> working group is chartered for the following (ordered) li=
st of items:
>>=20
>> o Identification and evaluation of use cases for which there
>>  is consensus within the WG.
>> o Definition of new procedures, driven by the use cases and underlying
>>  technology. The new procedures must cover security considerations
>>  (including the relationship between networks forming the <Name-TBD>
>>  region) and allow for solutions which substantially improve upon
>>  current technologies by defining requirements, extensions, or new
>>  functionality in existing routing, management or other protocols.
>> o Determine whether the above mentioned procedures require
>>  modification/changes to the existing MPLS architecture, and
>>  if so, then document such modifications/changes.
>> o Determine whether the above mentioned procedures require
>>  modification/changes to the existing IPv6 architecture, and
>>  if so, then document such modifications/changes.
>> o The <Name-TBD> working group will then develop solutions, focusing
>>  initially on intra-domain deployment scenarios. Where such
>>  solutions utilize existing protocols (IS-IS, OSPF, BGP, PCE) this will
>>  be done in conjunction with the responsible IETF working group. Work
>>  on new protocols may be carried out by the <Name-TBD> working group.
>>=20
>> The working group will develop the following documents:
>>=20
>> o One or more documents describing <Name-TBD> use cases, o Specification=
 of new procedures to support <Name-TBD> use cases, o Changes to MPLS archi=
tecture, if needed o Changes to IPv6 architecture, if needed o Document int=
erworking and co-existence between the new procedures
>>  and the existing MPLS signaling protocols (LDP, RSVP-TE, BGP), o Docume=
nt impact (if any) of any proposed IPv6 data plane modifications
>>  on existing deployment of IPv6,
>> o A set of one or more protocol extensions requirements documents, o Int=
er-operability reports pertaining to the implementation of extensions
>>  supporting <Name-TBD>.
>> _______________________________________________
>> status mailing list
>> [email-masked]
>> https://www.ietf.org/mailman/listinfo/status
>> _______________________________________________
>> status mailing list
>> [email-masked]
>> https://www.ietf.org/mailman/listinfo/status
> _______________________________________________
> status mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/status
> _______________________________________________
> status mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/status

From: "Stefano Previdi (sprevidi)" <[email-masked]>
To: Ruediger Geib <[email-masked]>, "John G. Scudder" <[email-masked]>
Date: Thu, 19 Sep 2013 06:47:29 +0000
Accept-Language: en-US
Cc: Adrian Farrel <[email-masked]>, "[email-masked]" <[email-masked]>, "Stewart Bryant \(stbryant\)" <[email-masked]>
Subject: Re: [Status] TBD Charter - ready of RTG AD review yes/no

Hi Ruediger, John,

On Sep 19, 2013, at 8:33 AM, <[email-masked]> wrote:
> John,
>=20
> there's another detail which should be clarified:
>=20
>> The <Name-TBD> working group is chartered for the following (ordered) li=
st of items:
> ....
>=20
> I'd expect work related to MPLS based SR to start relatively soon, while =
work on IPv6 based SR may require a more thorough analysis.

I agree.

We already have use-cases, architecture and protocol extensions=20
drafts (ISIS/OSPF) that have been submitted a while ago and we=20
should not defer the work on these just because we mandate an=20
ordered list.

> The "(ordered)" therefore should be removed or the  order should be adapt=
ed to express that:

yes, I'd just remove the "ordered" term. I believe the WG audience=20
will figure out what work can proceed without having to mandate any=20
"order".

Thanks.
s.

>=20
>  o Determine whether the above mentioned procedures require
>    modification/changes to the existing MPLS architecture, and
>    if so, then document such modifications/changes.
>  o Determine whether the above mentioned procedures require
>    modification/changes to the existing IPv6 architecture, and
>    if so, then document such modifications/changes.
>    In parallel, the <Name-TBD> working group will develop
>    solutions for a MPLS architecture, focusing initially on
>    intra-domain deployment scenarios. Where such solutions
>    utilize existing protocols (IS-IS, OSPF, BGP, PCE) this will
>    be done in conjunction with the responsible IETF working group. Work
>    on new protocols may be carried out by the <Name-TBD> working group.
>  o The <Name-TBD> working group will then develop solutions for an IPv6
>    architecture, focusing initially on intra-domain deployment scenarios.
>    Where such solutions utilize existing protocols (IS-IS, OSPF, BGP, PCE=
)
>    this will be done in conjunction with the responsible IETF working gro=
up.
>    Work on new protocols may be carried out by the <Name-TBD> working gro=
up.
>=20
> Regards,
>=20
> Ruediger
>=20
>=20
>> -----Original Message-----
>> From: [email-masked] [mailto:[email-masked]] On
>> Behalf Of John G.Scudder
>> Sent: Tuesday, September 17, 2013 7:22 AM
>> To: [email-masked]
>> Cc: Adrian Farrel; [email-masked]
>> Subject: Re: [Status] TBD Charter - ready of RTG AD review yes/no
>>=20
>> All,
>>=20
>> Here's another attempt. It tries to address the 'architecture' issue I r=
aised earlier, as well as incorporate Mark Townsley, Bruno Decraene and Rob=
 Shakir's comments. With luck the change from '<Name-TBD> domain' to '<Name=
-TBD> region' relieves the ambiguity that was present in earlier versions.
>>=20
>> --John
>>=20
>> ---------------------------------------------------------
>> Name: <TBD>
>>=20
>> The <Name-TBD> working group will define procedures that will allow a no=
de to steer a packet between any source and destination through a <Name-TBD=
> region on any path without requiring state to be maintained by transited =
nodes, but rather at the source device.  A <Name-TBD> region is a network c=
omprised of nodes (which may be of any type, including routers and applianc=
es) that share the following trust model: any node in the <Name-TBD> region=
 is trusted to steer a packet through any of the other nodes within the reg=
ion. The <Name-TBD> region may comprise one or more ASes, or even less than=
 a single AS. Although a region may comprise more than one AS, initial work=
 will focus on the intra-domain, that is, single AS, scenario.
>>=20
>> The procedures should support both centralised and distributed path comp=
utation. The procedures should also cover support for OAM functions.
>>=20
>> Where use cases are documented, care should be taken to define the data =
plane requirements for the environment within which they are to be implemen=
ted. The procedures should avoid modifications to the MPLS data plane, in o=
rder to remain compatible with existing extensive deployments of MPLS. It i=
s anticipated that the procedures may require modifications to the IPv6 dat=
a plane.  While the initial focus of the <Name-TBD> WG is on the intra-doma=
in deployment scenarios (see below), the modifications to the IPv6 data pla=
ne must support both intra and inter-domain deployment scenarios.
>>=20
>> The <Name-TBD> working group is chartered for the following (ordered) li=
st of items:
>>=20
>> o Identification and evaluation of use cases for which there
>>  is consensus within the WG.
>> o Definition of new procedures, driven by the use cases and underlying
>>  technology. The new procedures must cover security considerations
>>  (including the relationship between networks forming the <Name-TBD>
>>  region) and allow for solutions which substantially improve upon
>>  current technologies by defining requirements, extensions, or new
>>  functionality in existing routing, management or other protocols.
>> o Determine whether the above mentioned procedures require
>>  modification/changes to the existing MPLS architecture, and
>>  if so, then document such modifications/changes.
>> o Determine whether the above mentioned procedures require
>>  modification/changes to the existing IPv6 architecture, and
>>  if so, then document such modifications/changes.
>> o The <Name-TBD> working group will then develop solutions, focusing
>>  initially on intra-domain deployment scenarios. Where such
>>  solutions utilize existing protocols (IS-IS, OSPF, BGP, PCE) this will
>>  be done in conjunction with the responsible IETF working group. Work
>>  on new protocols may be carried out by the <Name-TBD> working group.
>>=20
>> The working group will develop the following documents:
>>=20
>> o One or more documents describing <Name-TBD> use cases, o Specification=
 of new procedures to support <Name-TBD> use cases, o Changes to MPLS archi=
tecture, if needed o Changes to IPv6 architecture, if needed o Document int=
erworking and co-existence between the new procedures
>>  and the existing MPLS signaling protocols (LDP, RSVP-TE, BGP), o Docume=
nt impact (if any) of any proposed IPv6 data plane modifications
>>  on existing deployment of IPv6,
>> o A set of one or more protocol extensions requirements documents, o Int=
er-operability reports pertaining to the implementation of extensions
>>  supporting <Name-TBD>.
>> _______________________________________________
>> status mailing list
>> [email-masked]
>> https://www.ietf.org/mailman/listinfo/status
>> _______________________________________________
>> status mailing list
>> [email-masked]
>> https://www.ietf.org/mailman/listinfo/status
> _______________________________________________
> status mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/status
> _______________________________________________
> status mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/status

From: <[email-masked]>
To: <[email-masked]>
Date: Thu, 19 Sep 2013 08:33:52 +0200
Accept-Language: en-US, de-DE
acceptlanguage: en-US, de-DE
Cc: [email-masked], [email-masked], [email-masked]
Subject: Re: [Status] TBD Charter - ready of RTG AD review yes/no

John,

there's another detail which should be clarified:

> The <Name-TBD> working group is chartered for the following (ordered) lis=
t of items:
....

I'd expect work related to MPLS based SR to start relatively soon, while wo=
rk on IPv6 based SR may require a more thorough analysis. The "(ordered)" t=
herefore should be removed or the  order should be adapted to express that:

  o Determine whether the above mentioned procedures require
    modification/changes to the existing MPLS architecture, and
    if so, then document such modifications/changes.
  o Determine whether the above mentioned procedures require
    modification/changes to the existing IPv6 architecture, and
    if so, then document such modifications/changes.
    In parallel, the <Name-TBD> working group will develop
    solutions for a MPLS architecture, focusing initially on
    intra-domain deployment scenarios. Where such solutions
    utilize existing protocols (IS-IS, OSPF, BGP, PCE) this will
    be done in conjunction with the responsible IETF working group. Work
    on new protocols may be carried out by the <Name-TBD> working group.
  o The <Name-TBD> working group will then develop solutions for an IPv6
    architecture, focusing initially on intra-domain deployment scenarios.
    Where such solutions utilize existing protocols (IS-IS, OSPF, BGP, PCE)
    this will be done in conjunction with the responsible IETF working grou=
p.
    Work on new protocols may be carried out by the <Name-TBD> working grou=
p.

Regards,

Ruediger

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On
> Behalf Of John G.Scudder
> Sent: Tuesday, September 17, 2013 7:22 AM
> To: [email-masked]
> Cc: Adrian Farrel; [email-masked]
> Subject: Re: [Status] TBD Charter - ready of RTG AD review yes/no
>
> All,
>
> Here's another attempt. It tries to address the 'architecture' issue I ra=
ised earlier, as well as incorporate Mark Townsley, Bruno Decraene and Rob =
Shakir's comments. With luck the change from '<Name-TBD> domain' to '<Name-=
TBD> region' relieves the ambiguity that was present in earlier versions.
>
> --John
>
> ---------------------------------------------------------
> Name: <TBD>
>
> The <Name-TBD> working group will define procedures that will allow a nod=
e to steer a packet between any source and destination through a <Name-TBD>=
 region on any path without requiring state to be maintained by transited n=
odes, but rather at the source device.  A <Name-TBD> region is a network co=
mprised of nodes (which may be of any type, including routers and appliance=
s) that share the following trust model: any node in the <Name-TBD> region =
is trusted to steer a packet through any of the other nodes within the regi=
on. The <Name-TBD> region may comprise one or more ASes, or even less than =
a single AS. Although a region may comprise more than one AS, initial work =
will focus on the intra-domain, that is, single AS, scenario.
>
> The procedures should support both centralised and distributed path compu=
tation. The procedures should also cover support for OAM functions.
>
> Where use cases are documented, care should be taken to define the data p=
lane requirements for the environment within which they are to be implement=
ed. The procedures should avoid modifications to the MPLS data plane, in or=
der to remain compatible with existing extensive deployments of MPLS. It is=
 anticipated that the procedures may require modifications to the IPv6 data=
 plane.  While the initial focus of the <Name-TBD> WG is on the intra-domai=
n deployment scenarios (see below), the modifications to the IPv6 data plan=
e must support both intra and inter-domain deployment scenarios.
>
> The <Name-TBD> working group is chartered for the following (ordered) lis=
t of items:
>
> o Identification and evaluation of use cases for which there
>   is consensus within the WG.
> o Definition of new procedures, driven by the use cases and underlying
>   technology. The new procedures must cover security considerations
>   (including the relationship between networks forming the <Name-TBD>
>   region) and allow for solutions which substantially improve upon
>   current technologies by defining requirements, extensions, or new
>   functionality in existing routing, management or other protocols.
> o Determine whether the above mentioned procedures require
>   modification/changes to the existing MPLS architecture, and
>   if so, then document such modifications/changes.
> o Determine whether the above mentioned procedures require
>   modification/changes to the existing IPv6 architecture, and
>   if so, then document such modifications/changes.
> o The <Name-TBD> working group will then develop solutions, focusing
>   initially on intra-domain deployment scenarios. Where such
>   solutions utilize existing protocols (IS-IS, OSPF, BGP, PCE) this will
>   be done in conjunction with the responsible IETF working group. Work
>   on new protocols may be carried out by the <Name-TBD> working group.
>
> The working group will develop the following documents:
>
> o One or more documents describing <Name-TBD> use cases, o Specification =
of new procedures to support <Name-TBD> use cases, o Changes to MPLS archit=
ecture, if needed o Changes to IPv6 architecture, if needed o Document inte=
rworking and co-existence between the new procedures
>   and the existing MPLS signaling protocols (LDP, RSVP-TE, BGP), o Docume=
nt impact (if any) of any proposed IPv6 data plane modifications
>   on existing deployment of IPv6,
> o A set of one or more protocol extensions requirements documents, o Inte=
r-operability reports pertaining to the implementation of extensions
>   supporting <Name-TBD>.
> _______________________________________________
> status mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/status
> _______________________________________________
> status mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/status
_______________________________________________
status mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/status

From: Gregory Mirsky <[email-masked]>
To: Robert Raszuk <[email-masked]>
Date: Wed, 18 Sep 2013 18:00:20 +0000
Accept-Language: en-US
Cc: "John G.Scudder" <[email-masked]>, Adrian Farrel <[email-masked]>, "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>
Subject: Re: [Status] TBD Charter - ready of RTG AD review yes/no

Hi Robert,
I think that intuitively we all understand what and who the transit nodes o=
f <Name_TBD> region are. But I wonder if this understanding is common. And =
I think that "transit node" characterization is more in path scope rather t=
han on regional scale. If that is not the case and there is clear distincti=
on between edge of head nodes and core or transit nodes, then, I think, we'=
ll need to capture that and then put into architectural document.

	Regards,
		Greg

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Robert Rasz=
uk
Sent: Tuesday, September 17, 2013 6:03 PM
To: Gregory Mirsky
Cc: John G.Scudder; [email-masked]; Adrian Farrel; [email-masked]
Subject: Re: [Status] TBD Charter - ready of RTG AD review yes/no

Hi Gregory,

Wouldn't it be simpler to say that state is not kept in those network eleme=
nts which are acting as transit nodes rather then enumerating all elements =
which may impose headers or compute paths ?

Thx,
R.

On Wed, Sep 18, 2013 at 1:36 AM, Gregory Mirsky <[email-masked]=
m> wrote:
> Hi John, et. al,
> I think that because of second paragraph, "... support both centralized a=
nd distributed path computation", a change is needed to specify that state =
must be maintained not necessarily at the source device but at the path com=
puting device (closing of the first sentence of the first paragraph).
>
>         Regards,
>                 Greg
>
> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On=20
> Behalf Of John G.Scudder
> Sent: Tuesday, September 17, 2013 7:22 AM
> To: [email-masked]
> Cc: Adrian Farrel; [email-masked]
> Subject: Re: [Status] TBD Charter - ready of RTG AD review yes/no
>
> All,
>
> Here's another attempt. It tries to address the 'architecture' issue I ra=
ised earlier, as well as incorporate Mark Townsley, Bruno Decraene and Rob =
Shakir's comments. With luck the change from '<Name-TBD> domain' to '<Name-=
TBD> region' relieves the ambiguity that was present in earlier versions.
>
> --John
>
> ---------------------------------------------------------
> Name: <TBD>
>
> The <Name-TBD> working group will define procedures that will allow a nod=
e to steer a packet between any source and destination through a <Name-TBD>=
 region on any path without requiring state to be maintained by transited n=
odes, but rather at the source device.  A <Name-TBD> region is a network co=
mprised of nodes (which may be of any type, including routers and appliance=
s) that share the following trust model: any node in the <Name-TBD> region =
is trusted to steer a packet through any of the other nodes within the regi=
on. The <Name-TBD> region may comprise one or more ASes, or even less than =
a single AS. Although a region may comprise more than one AS, initial work =
will focus on the intra-domain, that is, single AS, scenario.
>
> The procedures should support both centralised and distributed path compu=
tation. The procedures should also cover support for OAM functions.
>
> Where use cases are documented, care should be taken to define the data p=
lane requirements for the environment within which they are to be implement=
ed. The procedures should avoid modifications to the MPLS data plane, in or=
der to remain compatible with existing extensive deployments of MPLS. It is=
 anticipated that the procedures may require modifications to the IPv6 data=
 plane.  While the initial focus of the <Name-TBD> WG is on the intra-domai=
n deployment scenarios (see below), the modifications to the IPv6 data plan=
e must support both intra and inter-domain deployment scenarios.
>
> The <Name-TBD> working group is chartered for the following (ordered) lis=
t of items:
>
> o Identification and evaluation of use cases for which there
>   is consensus within the WG.
> o Definition of new procedures, driven by the use cases and underlying
>   technology. The new procedures must cover security considerations
>   (including the relationship between networks forming the <Name-TBD>
>   region) and allow for solutions which substantially improve upon
>   current technologies by defining requirements, extensions, or new
>   functionality in existing routing, management or other protocols.
> o Determine whether the above mentioned procedures require
>   modification/changes to the existing MPLS architecture, and
>   if so, then document such modifications/changes.
> o Determine whether the above mentioned procedures require
>   modification/changes to the existing IPv6 architecture, and
>   if so, then document such modifications/changes.
> o The <Name-TBD> working group will then develop solutions, focusing
>   initially on intra-domain deployment scenarios. Where such
>   solutions utilize existing protocols (IS-IS, OSPF, BGP, PCE) this will
>   be done in conjunction with the responsible IETF working group. Work
>   on new protocols may be carried out by the <Name-TBD> working group.
>
> The working group will develop the following documents:
>
> o One or more documents describing <Name-TBD> use cases, o Specification =
of new procedures to support <Name-TBD> use cases, o Changes to MPLS archit=
ecture, if needed o Changes to IPv6 architecture, if needed o Document inte=
rworking and co-existence between the new procedures
>   and the existing MPLS signaling protocols (LDP, RSVP-TE, BGP), o Docume=
nt impact (if any) of any proposed IPv6 data plane modifications
>   on existing deployment of IPv6,
> o A set of one or more protocol extensions requirements documents, o Inte=
r-operability reports pertaining to the implementation of extensions
>   supporting <Name-TBD>.
> _______________________________________________
> status mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/status
> _______________________________________________
> status mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/status

From: Rob Shakir <[email-masked]>
Date: Wed, 18 Sep 2013 10:49:09 +0100
To: John G.Scudder <[email-masked]>
Cc: Adrian Farrel <[email-masked]>, "[email-masked]" <[email-masked]>, [email-masked]
Subject: Re: [Status] TBD Charter - ready of RTG AD review yes/no

Hi John, STATUS,

I'd just like to voice my support for this revised wording - I think it =
addresses my previous comments.

I would agree with Robert - that we should not attempt to enumerate =
where state might need to be held within this charter. The fundamental =
here is that it is not on the mid-point. For some cases, the only state =
that will be held is at the head-end (where the forwarding state is the =
set of segment identifiers that it has calculated itself, or has been =
provided to it by a PCE), in other cases, such as where CAC/co-routing =
is being performed by a centralised entity (such as stateful PCE) then =
we will need the head-end to have the forwarding state, and the PCE will =
need to hold some state. Given there are a number of combinations of =
such cases, we should leave use-case documents to describe exactly the =
deployment which is envisaged.=20

Thanks,
r.

On 17 Sep 2013, at 15:21, John G.Scudder <[email-masked]> wrote:

> All,
>=20
> Here's another attempt. It tries to address the 'architecture' issue I =
raised earlier, as well as incorporate Mark Townsley, Bruno Decraene and =
Rob Shakir's comments. With luck the change from '<Name-TBD> domain' to =
'<Name-TBD> region' relieves the ambiguity that was present in earlier =
versions.
>=20
> --John
>=20
> ---------------------------------------------------------
> Name: <TBD>
>=20
> The <Name-TBD> working group will define procedures that will allow
> a node to steer a packet between any source and destination through
> a <Name-TBD> region on any path without requiring state to be
> maintained by transited nodes, but rather at the source device.  A
> <Name-TBD> region is a network comprised of nodes (which may be of
> any type, including routers and appliances) that share the following
> trust model: any node in the <Name-TBD> region is trusted to steer=20
> a packet through any of the other nodes within the region. The=20
> <Name-TBD> region may comprise one or more ASes, or even less than a=20=

> single AS. Although a region may comprise more than one AS, initial=20
> work will focus on the intra-domain, that is, single AS, scenario.
>=20
> The procedures should support both centralised and distributed path
> computation. The procedures should also cover support for OAM
> functions.
>=20
> Where use cases are documented, care should be taken to define the
> data plane requirements for the environment within which they are
> to be implemented. The procedures should avoid modifications to
> the MPLS data plane, in order to remain compatible with existing
> extensive deployments of MPLS. It is anticipated that the procedures
> may require modifications to the IPv6 data plane.  While the initial
> focus of the <Name-TBD> WG is on the intra-domain deployment scenarios
> (see below), the modifications to the IPv6 data plane must support
> both intra and inter-domain deployment scenarios.
>=20
> The <Name-TBD> working group is chartered for the following (ordered)
> list of items:
>=20
> o Identification and evaluation of use cases for which there=20
>  is consensus within the WG.
> o Definition of new procedures, driven by the use cases and underlying=20=

>  technology. The new procedures must cover security considerations=20
>  (including the relationship between networks forming the <Name-TBD>=20=

>  region) and allow for solutions which substantially improve upon=20
>  current technologies by defining requirements, extensions, or new
>  functionality in existing routing, management or other protocols.
> o Determine whether the above mentioned procedures require
>  modification/changes to the existing MPLS architecture, and
>  if so, then document such modifications/changes.
> o Determine whether the above mentioned procedures require
>  modification/changes to the existing IPv6 architecture, and
>  if so, then document such modifications/changes.
> o The <Name-TBD> working group will then develop solutions, focusing
>  initially on intra-domain deployment scenarios. Where such
>  solutions utilize existing protocols (IS-IS, OSPF, BGP, PCE) this =
will
>  be done in conjunction with the responsible IETF working group. Work
>  on new protocols may be carried out by the <Name-TBD> working group.
>=20
> The working group will develop the following documents:
>=20
> o One or more documents describing <Name-TBD> use cases,
> o Specification of new procedures to support <Name-TBD> use cases,
> o Changes to MPLS architecture, if needed
> o Changes to IPv6 architecture, if needed
> o Document interworking and co-existence between the new procedures
>  and the existing MPLS signaling protocols (LDP, RSVP-TE, BGP),
> o Document impact (if any) of any proposed IPv6 data plane =
modifications =20
>  on existing deployment of IPv6,
> o A set of one or more protocol extensions requirements documents,
> o Inter-operability reports pertaining to the implementation of =
extensions
>  supporting <Name-TBD>.
> _______________________________________________
> status mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/status

From: <[email-masked]>
To: <[email-masked]>, <[email-masked]>, <[email-masked]>
Date: Wed, 18 Sep 2013 10:13:14 +0200
Accept-Language: en-US, de-DE
acceptlanguage: en-US, de-DE
Cc: [email-masked], [email-masked], [email-masked]
Subject: Re: [Status] TBD Charter - ready of RTG AD review yes/no

Hello John, Greg and Rob,

John, thanks for your draft, which I support.

I recognise the point raised by Greg, but currently have
no preference whether to pick Gregs or Robs proposed text.
I'd prefer something short and generic maintaining the
spirit that the source node maintains at least standard
routing state and additional routing state may be present
locally or in other path computation systems outside of
the <Name-TBD> region (as no packets are steered through
centralised or distributed path computation elements,
that statement shouldn't be wrong).

Regards,

Ruediger

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of=
 Robert Raszuk
Sent: Wednesday, September 18, 2013 3:03 AM
To: Gregory Mirsky
Cc: John G.Scudder; Adrian Farrel; [email-masked]; [email-masked]
Subject: Re: [Status] TBD Charter - ready of RTG AD review yes/no

Hi Gregory,

Wouldn't it be simpler to say that state is not kept in those network
elements which are acting as transit nodes rather then enumerating all
elements which may impose headers or compute paths ?

Thx,
R.

On Wed, Sep 18, 2013 at 1:36 AM, Gregory Mirsky
<[email-masked]> wrote:
> Hi John, et. al,
> I think that because of second paragraph, "... support both centralized a=
nd distributed path computation", a change is needed to specify that state =
must be maintained not necessarily at the source device but at the path com=
puting device (closing of the first sentence of the first paragraph).
>
>         Regards,
>                 Greg
>
> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf =
Of John G.Scudder
> Sent: Tuesday, September 17, 2013 7:22 AM
> To: [email-masked]
> Cc: Adrian Farrel; [email-masked]
> Subject: Re: [Status] TBD Charter - ready of RTG AD review yes/no
>
> All,
>
> Here's another attempt. It tries to address the 'architecture' issue I ra=
ised earlier, as well as incorporate Mark Townsley, Bruno Decraene and Rob =
Shakir's comments. With luck the change from '<Name-TBD> domain' to '<Name-=
TBD> region' relieves the ambiguity that was present in earlier versions.
>
> --John
>
> ---------------------------------------------------------
> Name: <TBD>
>
> The <Name-TBD> working group will define procedures that will allow a nod=
e to steer a packet between any source and destination through a <Name-TBD>=
 region on any path without requiring state to be maintained by transited n=
odes, but rather at the source device.  A <Name-TBD> region is a network co=
mprised of nodes (which may be of any type, including routers and appliance=
s) that share the following trust model: any node in the <Name-TBD> region =
is trusted to steer a packet through any of the other nodes within the regi=
on. The <Name-TBD> region may comprise one or more ASes, or even less than =
a single AS. Although a region may comprise more than one AS, initial work =
will focus on the intra-domain, that is, single AS, scenario.
>
> The procedures should support both centralised and distributed path compu=
tation. The procedures should also cover support for OAM functions.
>
> Where use cases are documented, care should be taken to define the data p=
lane requirements for the environment within which they are to be implement=
ed. The procedures should avoid modifications to the MPLS data plane, in or=
der to remain compatible with existing extensive deployments of MPLS. It is=
 anticipated that the procedures may require modifications to the IPv6 data=
 plane.  While the initial focus of the <Name-TBD> WG is on the intra-domai=
n deployment scenarios (see below), the modifications to the IPv6 data plan=
e must support both intra and inter-domain deployment scenarios.
>
> The <Name-TBD> working group is chartered for the following (ordered) lis=
t of items:
>
> o Identification and evaluation of use cases for which there
>   is consensus within the WG.
> o Definition of new procedures, driven by the use cases and underlying
>   technology. The new procedures must cover security considerations
>   (including the relationship between networks forming the <Name-TBD>
>   region) and allow for solutions which substantially improve upon
>   current technologies by defining requirements, extensions, or new
>   functionality in existing routing, management or other protocols.
> o Determine whether the above mentioned procedures require
>   modification/changes to the existing MPLS architecture, and
>   if so, then document such modifications/changes.
> o Determine whether the above mentioned procedures require
>   modification/changes to the existing IPv6 architecture, and
>   if so, then document such modifications/changes.
> o The <Name-TBD> working group will then develop solutions, focusing
>   initially on intra-domain deployment scenarios. Where such
>   solutions utilize existing protocols (IS-IS, OSPF, BGP, PCE) this will
>   be done in conjunction with the responsible IETF working group. Work
>   on new protocols may be carried out by the <Name-TBD> working group.
>
> The working group will develop the following documents:
>
> o One or more documents describing <Name-TBD> use cases, o Specification =
of new procedures to support <Name-TBD> use cases, o Changes to MPLS archit=
ecture, if needed o Changes to IPv6 architecture, if needed o Document inte=
rworking and co-existence between the new procedures
>   and the existing MPLS signaling protocols (LDP, RSVP-TE, BGP), o Docume=
nt impact (if any) of any proposed IPv6 data plane modifications
>   on existing deployment of IPv6,
> o A set of one or more protocol extensions requirements documents, o Inte=
r-operability reports pertaining to the implementation of extensions
>   supporting <Name-TBD>.
> _______________________________________________
> status mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/status
> _______________________________________________
> status mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/status
_______________________________________________
status mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/status

Sender: [email-masked]
Date: Wed, 18 Sep 2013 03:03:03 +0200
From: Robert Raszuk <[email-masked]>
To: Gregory Mirsky <[email-masked]>
Cc: "John G.Scudder" <[email-masked]>, Adrian Farrel <[email-masked]>, "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>
Subject: Re: [Status] TBD Charter - ready of RTG AD review yes/no

Hi Gregory,

Wouldn't it be simpler to say that state is not kept in those network
elements which are acting as transit nodes rather then enumerating all
elements which may impose headers or compute paths ?

Thx,
R.

On Wed, Sep 18, 2013 at 1:36 AM, Gregory Mirsky
<[email-masked]> wrote:
> Hi John, et. al,
> I think that because of second paragraph, "... support both centralized a=
nd distributed path computation", a change is needed to specify that state =
must be maintained not necessarily at the source device but at the path com=
puting device (closing of the first sentence of the first paragraph).
>
>         Regards,
>                 Greg
>
> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf =
Of John G.Scudder
> Sent: Tuesday, September 17, 2013 7:22 AM
> To: [email-masked]
> Cc: Adrian Farrel; [email-masked]
> Subject: Re: [Status] TBD Charter - ready of RTG AD review yes/no
>
> All,
>
> Here's another attempt. It tries to address the 'architecture' issue I ra=
ised earlier, as well as incorporate Mark Townsley, Bruno Decraene and Rob =
Shakir's comments. With luck the change from '<Name-TBD> domain' to '<Name-=
TBD> region' relieves the ambiguity that was present in earlier versions.
>
> --John
>
> ---------------------------------------------------------
> Name: <TBD>
>
> The <Name-TBD> working group will define procedures that will allow a nod=
e to steer a packet between any source and destination through a <Name-TBD>=
 region on any path without requiring state to be maintained by transited n=
odes, but rather at the source device.  A <Name-TBD> region is a network co=
mprised of nodes (which may be of any type, including routers and appliance=
s) that share the following trust model: any node in the <Name-TBD> region =
is trusted to steer a packet through any of the other nodes within the regi=
on. The <Name-TBD> region may comprise one or more ASes, or even less than =
a single AS. Although a region may comprise more than one AS, initial work =
will focus on the intra-domain, that is, single AS, scenario.
>
> The procedures should support both centralised and distributed path compu=
tation. The procedures should also cover support for OAM functions.
>
> Where use cases are documented, care should be taken to define the data p=
lane requirements for the environment within which they are to be implement=
ed. The procedures should avoid modifications to the MPLS data plane, in or=
der to remain compatible with existing extensive deployments of MPLS. It is=
 anticipated that the procedures may require modifications to the IPv6 data=
 plane.  While the initial focus of the <Name-TBD> WG is on the intra-domai=
n deployment scenarios (see below), the modifications to the IPv6 data plan=
e must support both intra and inter-domain deployment scenarios.
>
> The <Name-TBD> working group is chartered for the following (ordered) lis=
t of items:
>
> o Identification and evaluation of use cases for which there
>   is consensus within the WG.
> o Definition of new procedures, driven by the use cases and underlying
>   technology. The new procedures must cover security considerations
>   (including the relationship between networks forming the <Name-TBD>
>   region) and allow for solutions which substantially improve upon
>   current technologies by defining requirements, extensions, or new
>   functionality in existing routing, management or other protocols.
> o Determine whether the above mentioned procedures require
>   modification/changes to the existing MPLS architecture, and
>   if so, then document such modifications/changes.
> o Determine whether the above mentioned procedures require
>   modification/changes to the existing IPv6 architecture, and
>   if so, then document such modifications/changes.
> o The <Name-TBD> working group will then develop solutions, focusing
>   initially on intra-domain deployment scenarios. Where such
>   solutions utilize existing protocols (IS-IS, OSPF, BGP, PCE) this will
>   be done in conjunction with the responsible IETF working group. Work
>   on new protocols may be carried out by the <Name-TBD> working group.
>
> The working group will develop the following documents:
>
> o One or more documents describing <Name-TBD> use cases, o Specification =
of new procedures to support <Name-TBD> use cases, o Changes to MPLS archit=
ecture, if needed o Changes to IPv6 architecture, if needed o Document inte=
rworking and co-existence between the new procedures
>   and the existing MPLS signaling protocols (LDP, RSVP-TE, BGP), o Docume=
nt impact (if any) of any proposed IPv6 data plane modifications
>   on existing deployment of IPv6,
> o A set of one or more protocol extensions requirements documents, o Inte=
r-operability reports pertaining to the implementation of extensions
>   supporting <Name-TBD>.
> _______________________________________________
> status mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/status
> _______________________________________________
> status mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/status

From: Gregory Mirsky <[email-masked]>
To: John G.Scudder <[email-masked]>, "[email-masked]" <[email-masked]>
Date: Tue, 17 Sep 2013 23:36:31 +0000
Accept-Language: en-US
Cc: Adrian Farrel <[email-masked]>, "[email-masked]" <[email-masked]>
Subject: Re: [Status] TBD Charter - ready of RTG AD review yes/no

Hi John, et. al,
I think that because of second paragraph, "... support both centralized and=
 distributed path computation", a change is needed to specify that state mu=
st be maintained not necessarily at the source device but at the path compu=
ting device (closing of the first sentence of the first paragraph).

	Regards,
		Greg

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of=
 John G.Scudder
Sent: Tuesday, September 17, 2013 7:22 AM
To: [email-masked]
Cc: Adrian Farrel; [email-masked]
Subject: Re: [Status] TBD Charter - ready of RTG AD review yes/no

All,

Here's another attempt. It tries to address the 'architecture' issue I rais=
ed earlier, as well as incorporate Mark Townsley, Bruno Decraene and Rob Sh=
akir's comments. With luck the change from '<Name-TBD> domain' to '<Name-TB=
D> region' relieves the ambiguity that was present in earlier versions.

--John

---------------------------------------------------------
Name: <TBD>

The <Name-TBD> working group will define procedures that will allow a node =
to steer a packet between any source and destination through a <Name-TBD> r=
egion on any path without requiring state to be maintained by transited nod=
es, but rather at the source device.  A <Name-TBD> region is a network comp=
rised of nodes (which may be of any type, including routers and appliances)=
 that share the following trust model: any node in the <Name-TBD> region is=
 trusted to steer a packet through any of the other nodes within the region=
. The <Name-TBD> region may comprise one or more ASes, or even less than a =
single AS. Although a region may comprise more than one AS, initial work wi=
ll focus on the intra-domain, that is, single AS, scenario.

The procedures should support both centralised and distributed path computa=
tion. The procedures should also cover support for OAM functions.

Where use cases are documented, care should be taken to define the data pla=
ne requirements for the environment within which they are to be implemented=
. The procedures should avoid modifications to the MPLS data plane, in orde=
r to remain compatible with existing extensive deployments of MPLS. It is a=
nticipated that the procedures may require modifications to the IPv6 data p=
lane.  While the initial focus of the <Name-TBD> WG is on the intra-domain =
deployment scenarios (see below), the modifications to the IPv6 data plane =
must support both intra and inter-domain deployment scenarios.

The <Name-TBD> working group is chartered for the following (ordered) list =
of items:

o Identification and evaluation of use cases for which there
  is consensus within the WG.
o Definition of new procedures, driven by the use cases and underlying
  technology. The new procedures must cover security considerations
  (including the relationship between networks forming the <Name-TBD>
  region) and allow for solutions which substantially improve upon
  current technologies by defining requirements, extensions, or new
  functionality in existing routing, management or other protocols.
o Determine whether the above mentioned procedures require
  modification/changes to the existing MPLS architecture, and
  if so, then document such modifications/changes.
o Determine whether the above mentioned procedures require
  modification/changes to the existing IPv6 architecture, and
  if so, then document such modifications/changes.
o The <Name-TBD> working group will then develop solutions, focusing
  initially on intra-domain deployment scenarios. Where such
  solutions utilize existing protocols (IS-IS, OSPF, BGP, PCE) this will
  be done in conjunction with the responsible IETF working group. Work
  on new protocols may be carried out by the <Name-TBD> working group.

The working group will develop the following documents:

o One or more documents describing <Name-TBD> use cases, o Specification of=
 new procedures to support <Name-TBD> use cases, o Changes to MPLS architec=
ture, if needed o Changes to IPv6 architecture, if needed o Document interw=
orking and co-existence between the new procedures
  and the existing MPLS signaling protocols (LDP, RSVP-TE, BGP), o Document=
 impact (if any) of any proposed IPv6 data plane modifications
  on existing deployment of IPv6,
o A set of one or more protocol extensions requirements documents, o Inter-=
operability reports pertaining to the implementation of extensions
  supporting <Name-TBD>.
_______________________________________________
status mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/status

From: John G.Scudder <[email-masked]>
Date: Tue, 17 Sep 2013 10:21:36 -0400
To: <[email-masked]>
Cc: Adrian Farrel <[email-masked]>, "[email-masked]" <[email-masked]>
Subject: Re: [Status] TBD Charter - ready of RTG AD review yes/no

All,

Here's another attempt. It tries to address the 'architecture' issue I =
raised earlier, as well as incorporate Mark Townsley, Bruno Decraene and =
Rob Shakir's comments. With luck the change from '<Name-TBD> domain' to =
'<Name-TBD> region' relieves the ambiguity that was present in earlier =
versions.

--John

---------------------------------------------------------
Name: <TBD>

The <Name-TBD> working group will define procedures that will allow
a node to steer a packet between any source and destination through
a <Name-TBD> region on any path without requiring state to be
maintained by transited nodes, but rather at the source device.  A
<Name-TBD> region is a network comprised of nodes (which may be of
any type, including routers and appliances) that share the following
trust model: any node in the <Name-TBD> region is trusted to steer=20
a packet through any of the other nodes within the region. The=20
<Name-TBD> region may comprise one or more ASes, or even less than a=20
single AS. Although a region may comprise more than one AS, initial=20
work will focus on the intra-domain, that is, single AS, scenario.

The procedures should support both centralised and distributed path
computation. The procedures should also cover support for OAM
functions.

Where use cases are documented, care should be taken to define the
data plane requirements for the environment within which they are
to be implemented. The procedures should avoid modifications to
the MPLS data plane, in order to remain compatible with existing
extensive deployments of MPLS. It is anticipated that the procedures
may require modifications to the IPv6 data plane.  While the initial
focus of the <Name-TBD> WG is on the intra-domain deployment scenarios
(see below), the modifications to the IPv6 data plane must support
both intra and inter-domain deployment scenarios.

The <Name-TBD> working group is chartered for the following (ordered)
list of items:

o Identification and evaluation of use cases for which there=20
  is consensus within the WG.
o Definition of new procedures, driven by the use cases and underlying=20=

  technology. The new procedures must cover security considerations=20
  (including the relationship between networks forming the <Name-TBD>=20
  region) and allow for solutions which substantially improve upon=20
  current technologies by defining requirements, extensions, or new
  functionality in existing routing, management or other protocols.
o Determine whether the above mentioned procedures require
  modification/changes to the existing MPLS architecture, and
  if so, then document such modifications/changes.
o Determine whether the above mentioned procedures require
  modification/changes to the existing IPv6 architecture, and
  if so, then document such modifications/changes.
o The <Name-TBD> working group will then develop solutions, focusing
  initially on intra-domain deployment scenarios. Where such
  solutions utilize existing protocols (IS-IS, OSPF, BGP, PCE) this will
  be done in conjunction with the responsible IETF working group. Work
  on new protocols may be carried out by the <Name-TBD> working group.

The working group will develop the following documents:

o One or more documents describing <Name-TBD> use cases,
o Specification of new procedures to support <Name-TBD> use cases,
o Changes to MPLS architecture, if needed
o Changes to IPv6 architecture, if needed
o Document interworking and co-existence between the new procedures
  and the existing MPLS signaling protocols (LDP, RSVP-TE, BGP),
o Document impact (if any) of any proposed IPv6 data plane modifications =
=20
  on existing deployment of IPv6,
o A set of one or more protocol extensions requirements documents,
o Inter-operability reports pertaining to the implementation of =
extensions
  supporting <Name-TBD>.=

From: John E Drake <[email-masked]>
To: John Scudder <[email-masked]>, "[email-masked]" <[email-masked]>
Date: Mon, 16 Sep 2013 14:50:56 +0000
Accept-Language: en-US
Cc: Adrian Farrel <[email-masked]>, "[email-masked]" <[email-masked]>
Subject: Re: [Status] TBD Charter - ready of RTG AD review yes/no

John,

Would it make sense to change the word 'architecture' to the word 'paradigm=
' in your proposed charter text, below?

Yours Irrespectively,

John

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf
> Of John G. Scudder
> Sent: Sunday, September 15, 2013 2:10 PM
> To: [email-masked]
> Cc: Adrian Farrel; [email-masked]
> Subject: Re: [Status] TBD Charter - ready of RTG AD review yes/no
>=20
> Stewart,
>=20
> I have a number of mostly-editorial comments. They're in line below. Ther=
e is
> one substantive but relatively small change, which is called out. I've
> appended a version of the draft charter that consolidates my proposed edi=
ts,
> at the bottom.
>=20
> Going through the exercise of doing this has reminded me of one significa=
nt
> concern, though. The first work item for the WG in the proposed charter i=
s:
>=20
>  o Identification of use-cases for the <Name-TBD> architecture for which
>    there is consensus within the WG.
>=20
> This leads to the simple question: until we've identified use cases, how =
can
> we say we need a new architecture? We are presupposing the outcome. If
> the agreed use cases end up being things that are supportable within the
> existing MPLS architecture, that is great. Note I'm not saying the use ca=
ses
> shouldn't be addressed, merely that their solutions may, or may not, rise=
 to
> the level of "architecture". I would be interested in discussion of this
> question before we close on a charter.
>=20
> The rest is in line below.
>=20
> On Sep 13, 2013, at 11:24 AM, Stewart Bryant <[email-masked]> wrote:
>=20
> > Thanks to those that have worked on pulling together the charter text.
> >
> > I now need to check whether there is consensus that this represents
> > the right starting point for the Routing ADs to engage with the list
> > and polish it to the point where we are confident that it will gain
> > the approval of the IESG.
> >
> > Some notes on timeline are appropriate. In order to meet as a WG in
> > Vancouver this needs to be approved for external review at the IESG
> > telechat  on 10th October.
> > This means that we have to add it to the agenda by 26th September.
> > This means that we (the Routing ADs) need to have a view that the text
> > of 26th September is likely to be acceptable to both the community and
> > the IESG.
> > It also mean an active dialog with members of the IESG regarding
> > review comments raised in the period up to 10th October.
> >
> > For reference, I am about to put a placeholder for this on the BOF
> > page, in order for an agenda slot to be reserved for this work,
> > hopefully to meet as a WG, but otherwise to meet to finish of the
> > charter.
> >
> > So back to the question, is there consensus that text below is now at
> > the point where the RTG ADs should actively engage to get it ready for
> > IESG approval
> > - yes/no?
> >
> > Thanks
> >
> > Stewart
> >
> > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
> >
> > Name: <TBD>
> >
> > A number of use cases, including:
> >  o Path computation based on awareness of utilisation or performance
> >    data, within both centralised and distributed environments,  o
> > Multi-topology routing (dual planes, disjoint trees),  o
> > Simplification and reduction of signalling,  o Combined application
> > and network-layer path specification.
> >  o Full coverage LFA FRR,
> >  o Topology Aware OAM,
> > have triggered work on the definition of a new architecture and protoco=
l
> extensions, allowing nodes to steer packets through a network, allowing
> combination of well-known shortest-path based routing paradigms with
> source or explicit routing methods. Some of the extensions allowing steer=
ing
> of packets in this manner have already been implemented.
>=20
> The foregoing does/did add something to the mailing list discussion, but =
I
> think should be omitted from the charter. After all, the first work item =
listed
> in the charter is exactly to produce a list of "use-cases ... for which t=
here is
> consensus". By definition there can't be any consensus in the WG yet sinc=
e
> there is no WG yet. This is an easy edit; the charter reads just fine sta=
rting
> from the below paragraph and there are no normative (as it were) changes.
>=20
> (Also, an editorial nit: "use case" is conventionally not hyphenated -- a
> search-and-replace will fix this.)
>=20
> > The <Name-TBD> working group will define an architecture allowing a nod=
e
> to steer a packet through a network, or set of networks, on any path with=
out
> requiring state to be maintained by transited nodes (but rather at the so=
urce
> device). The source node may send any packet along a path within the
> <Name-TBD> domain through specifying the identifiers referring to this pa=
th.
> Subsequent downstream nodes along the path within the <Name-TBD>
> domain will forward packets according to the instructions inserted by the
> head-end.
> >
> > Within the <Name-TBD> architecture, a node may be of any type -
> including routers and appliances. A set of such nodes sharing a common tr=
ust
> model form a <Name-TBD> domain. The architecture defined by this working
> group will allow steering of packets between any source and destination
> node within the <Name-TBD> domain, which may be formed of one or more
> networks, on any path (shortest, non-shortest, explicit, or based on othe=
r
> resources or characteristics specified by segment identifiers).
>=20
> The two forgoing paragraphs have a lot of redundancy, probably due to the
> multiple revision cycles they've been through. Here is a potential rewrit=
e
> merging the two but attempting to maintain all the content:
>=20
> The <Name-TBD> working group will define an architecture that will allow =
a
> node to steer a packet between any source and destination through a
> <Name-TBD> domain on any path without requiring state to be maintained
> by transited nodes, but rather at the source device. A <Name-TBD> domain
> is a network or set of networks comprised of nodes (which may be of any
> type, including routers and appliances) that share a common trust model.
> The path may be shortest, non-shortest, explicit, or based on other
> resources or characteristics specified by segment identifiers.
>=20
> Some comments on this --
>=20
> - I'm not actually sure what "set of networks" really adds. AFAIK it has =
no
> well-defined meaning distinct from that of "network".
> - I don't think the final sentence actually adds anything since the first
> sentence says "any path" and "any" takes in the entire universe of
> possibilities already. The final sentence also uses the term "segment
> identifiers" which is not defined in the charter.
>=20
> IMO neither of these actually detracts (other than the undefined term), b=
ut
> neither do they add, so my preference would be to leave them out (I
> generally favor the "perfection is achieved, not when there is nothing mo=
re
> to add, but when there is nothing left to take away" heuristic). So:
>=20
> The <Name-TBD> working group will define an architecture that will allow =
a
> node to steer a packet between any source and destination through a
> <Name-TBD> domain on any path without requiring state to be maintained
> by transited nodes, but rather at the source device. A <Name-TBD> domain
> is a network comprised of nodes (which may be of any type, including
> routers and appliances) that share a common trust model.
>=20
> I actually think "which may be of any type, including routers and applian=
ces"
> is in the same category (it's implicit) but I realize that others will pr=
obably
> disagree so I haven't proposed eliding it. I'd be happy to though, if I a=
m
> mistaken.
>=20
> > The <Name-TBD> architecture should support both centralised and
> distributed path computation - through both existing routing protocols (I=
GP,
> BGP) and new approaches to such path calculation. The architecture should
> also support OAM functions.
>=20
> The first sentence is puzzlingly broad, especially when you get to "... a=
nd new
> approaches to path calculation." The best I can parse it is "we haven't
> decided how to do this yet but everything should be on the table". I thin=
k it
> could be trimmed to "The <Name-TBD> architecture should support both
> centralised and distributed path computation" without loss of generality.
>=20
> > The <Name-TBD> architecture has been postulated to be applicable to
> > multiple data planes (e.g., MPLS, IPv6), and hence
>=20
> The paragraphs preceding this one state that the WG will define the <Name=
-
> TBD> architecture. This means that by definition there isn't a <Name-TBD>
> architecture yet. As such I don't see how it can be postulated to be much=
 of
> anything, and would suggest that the foregoing clause be cut. I think tha=
t
> again, this can be done without loss of generality since the following te=
xt
> captures the intent.
>=20
> > the working group should strive to create a single <Name-TBD> framework
> which maintains data plane independence where possible. Where use cases
> are documented, care should be taken to define the data plane
> requirements for the environment within which they are to be
> implemented. The <Name-TBD> architecture should avoid modifications to
> the MPLS data-plane, in order to remain compatible with existing extensiv=
e
> deployments of MPLS.
>=20
> I suggest adding "It is anticipated the <Name-TBD> architecture may need =
to
> propose modifications to the IPv6 data plane." (One could use "extensions=
"
> in place of "modifications", though I prefer it as written.) I also sugge=
st that a
> work item be added,
>=20
>   o Document impact (if any) of any proposed IPv6 data plane modification=
s
>     on existing deployment of IPv6.
>=20
> I believe this is the only substantive change I've proposed, the rest bei=
ng
> editorial.
>=20
> > The <Name-TBD> working group is chartered for the following (ordered)
> list of items:
> >  o Identification of use-cases for the <Name-TBD> architecture for whic=
h
> >    there is consensus within the WG.
> >  o Definition of an architectural framework, which must cover
> >    security considerations (including the relationship between networks
> >    forming the <Name-TBD> domain).
> >  o Having identified use-cases, and developed a framework, the WG will
> >    work on proposing a new architectures which substantially improve
>=20
> "a new architecture that substantially improves upon"
>=20
> >    current technologies and define requirements for extensions or new
> >    functionality in existing routing protocols and/or I2RS protocols.
>=20
> I'm a little confused why all routing protocols would be taken in but onl=
y i2rs
> among management protocols, and besides isn't it still TBD if i2rs will e=
ven
> end up defining a protocol? Thus, how about "existing routing and
> management protocols"?
>=20
> >  o The <Name-TBD> working group will then develop solutions - focusing
> >    initially on intra-domain forwarding implementations. Where such
> >    solutions utilise existing protocols (IS-IS, OSPF, BGP, PCE) this wi=
ll
> >    be done in conjunction with the responsible IETF working group. Work
> >    on new protocols may be carried out by the <Name-TBD> working group.
> >    The working group will develop the following documents:
> >  o One or more documents describing <Name-TBD> use cases,  o A
> > <Name-TBD> architecture,  o A set of one or more protocol extensions
> > requirements documents,  o Inter-operability reports pertaining to the
> > implementation of extensions
> >    supporting <Name-TBD>.
>=20
> Finally I have a question, or observation: Where we are talking about
> modifying/extending a data plane (IPv6) there may be implications to inte=
r-
> domain forwarding. Thus the initial focus on intra-domain forwarding, abo=
ve,
> is a little concerning -- one can easily imagine a sequence like
>=20
> - Define intra-domain forwarding,
> - Define new v6 data plane,
> - Publish specs,
> - Recharter to include inter-domain,
> - Define inter-domain forwarding,
> - Oops, we need to further extend the v6 data plane.
>=20
> Since the cost of extending the v6 data plane may end up being non-trivia=
l, it
> seems as though it would be desirable to avoid this kind of iteration. Do
> others agree and if so how should we capture this in the charter?
>=20
> Thanks,
>=20
> --John
>=20
> Consolidated edits below:
>=20
> ------------------
>=20
> Name: <TBD>
>=20
> The <Name-TBD> working group will define an architecture that will allow =
a
> node to steer a packet between any source and destination through a
> <Name-TBD> domain on any path without requiring state to be maintained
> by transited nodes, but rather at the source device. A <Name-TBD> domain
> is a network comprised of nodes (which may be of any type, including
> routers and appliances) that share a common trust model.
>=20
> The <Name-TBD> architecture should support both centralised and
> distributed path computation. The architecture should also support OAM
> functions.
>=20
> The working group should strive to create a single <Name-TBD> framework
> which maintains data plane independence where possible. Where use cases
> are documented, care should be taken to define the data plane
> requirements for the environment within which they are to be
> implemented. The <Name-TBD> architecture should avoid modifications to
> the MPLS data-plane, in order to remain compatible with existing extensiv=
e
> deployments of MPLS. It is anticipated the <Name-TBD> architecture may
> need to propose modifications to the IPv6 data plane.
>=20
> The <Name-TBD> working group is chartered for the following (ordered) lis=
t
> of items:
>  o Identification of use-cases for the <Name-TBD> architecture for which
>    there is consensus within the WG.
>  o Definition of an architectural framework, which must cover
>    security considerations (including the relationship between networks
>    forming the <Name-TBD> domain).
>  o Having identified use-cases, and developed a framework, the WG will
>    work on proposing a new architectures which substantially improve
>    current technologies and define requirements for extensions or new
>    functionality in existing routing protocols and/or I2RS protocols.
>  o The <Name-TBD> working group will then develop solutions - focusing
>    initially on intra-domain forwarding implementations. Where such
>    solutions utilise existing protocols (IS-IS, OSPF, BGP, PCE) this will
>    be done in conjunction with the responsible IETF working group. Work
>    on new protocols may be carried out by the <Name-TBD> working group.
>    The working group will develop the following documents:
>  o One or more documents describing <Name-TBD> use cases,  o A <Name-
> TBD> architecture,  o Document impact (if any) of any proposed IPv6 data
> plane modifications
>    on existing deployment of IPv6,
>  o A set of one or more protocol extensions requirements documents,  o
> Inter-operability reports pertaining to the implementation of extensions
>    supporting <Name-TBD>.
>=20
> ------------------
> _______________________________________________
> status mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/status
>=20

From: "Alvaro Retana (aretana)" <[email-masked]>
To: Rob Shakir <[email-masked]>, "John G. Scudder" <[email-masked]>
Date: Mon, 16 Sep 2013 13:30:17 +0000
Accept-Language: en-US
Cc: Adrian Farrel <[email-masked]>, "[email-masked]" <[email-masked]>, "Stewart Bryant \(stbryant\)" <[email-masked]>
Subject: Re: [Status] TBD Charter - ready of RTG AD review yes/no

On 9/16/13 4:18 AM, "Rob Shakir" <[email-masked]> wrote:

Rob:

Hi!

>>
>>- I don't think the final sentence actually adds anything since the
>>first sentence says "any path" and "any" takes in the entire universe of
>>possibilities already. The final sentence also uses the term "segment
>>identifiers" which is not defined in the charter.
>>IMO neither of these actually detracts (other than the undefined term),
>>but neither do they add, so my preference would be to leave them out (I
>>generally favor the "perfection is achieved, not when there is nothing
>>more to add, but when there is nothing left to take away" heuristic). So:
>>The <Name-TBD> working group will define an architecture that will allow
>>a node to steer a packet between any source and destination through a
>><Name-TBD> domain on any path without requiring state to be maintained
>>by transited nodes, but rather at the source device. A <Name-TBD> domain
>>is a network comprised of nodes (which may be of any type, including
>>routers and appliances) that share a common trust model.
>>I actually think "which may be of any type, including routers and
>>appliances" is in the same category (it's implicit) but I realize that
>>others will probably disagree so I haven't proposed eliding it. I'd be
>>happy to though, if I am mistaken.
>
>rjs> In both these cases, the intention of the wording is to provide some
>form of example of the kind of functionality that is required from the
>new architecture.
>
>rjs> If we lose the first paragraph which gives a set of example
>use-cases for this technology, then I think it would be good to include
>the types of nodes/paths that are envisaged. I think this helps support
>the distinction between a domain-wide protocol to determine the route,
>and a head-end being able to pick an arbitrary path without any knowledge
>of the transit nodes as to the means by which it was calculated.

I agree with John on this.  While the examples seem to help clarify, that
is what the use cases (the complete description, not just the list) are
for: to explicitly tell us (the WG) what needs to be solved..and that
should be the first chartered step anyway.

My 1c.

Alvaro.

From: <[email-masked]>
To: "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>
Date: Mon, 16 Sep 2013 08:41:19 +0000
Accept-Language: fr-FR, en-US
Cc: Adrian Farrel <[email-masked]>
Subject: Re: [Status] TBD Charter - ready of RTG AD review yes/no

Hi,

>    The working group will develop the following documents:
>  o One or more documents describing <Name-TBD> use cases,
>  o A <Name-TBD> architecture,
>  o Document impact (if any) of any proposed IPv6 data plane modifications=
 on existing deployment of IPv6,
>  o A set of one or more protocol extensions requirements documents,
>  o Inter-operability reports pertaining to the implementation of extensio=
ns supporting <Name-TBD>.

There may be a need for a specific MPLS document, to define MPLS specific a=
spects, in particular the interworking with existing MPLS signaling protoco=
ls (LDP, RSVP-TE) (during the transition period).
It's not clear to me where such MPLS specific work will be done:
- MPLS WG? But there is no expected protocol extension in the MPLS dataplan=
e, MPLS architecture, LDP and RSVP-TE. Hence "A set of one or more protocol=
 extensions requirements documents" may not apply.
- <Name-TBD> WG? But there is no mention of an MPLS specific document (whil=
e during the BOF, "There was overwhelming support for work on MPLS Source R=
outing (SR)")

Regarding the home of such a document, IMHO I would favor the <Name-TBD> WG=
 where there is a priori a better chance for combined MPLS & <Name-TBD> kno=
wledge.

Regards,
Bruno

>-----Original Message-----
>From: [email-masked] [mailto:[email-masked]] On Behalf Of
>Stewart Bryant
>Sent: Friday, September 13, 2013 5:25 PM
>To: [email-masked]
>Cc: Adrian Farrel
>Subject: [Status] TBD Charter - ready of RTG AD review yes/no
>
>Thanks to those that have worked on pulling together the
>charter text.
>
>I now need to check whether there is consensus that this
>represents the right starting point for the Routing ADs
>to engage with the list and polish it to the point where
>we are confident that it will gain the approval of the IESG.
>
>Some notes on timeline are appropriate. In order to meet
>as a WG in Vancouver this needs to be approved for
>external review at the IESG telechat  on 10th October.
>This means that we have to add it to the agenda by 26th
>September. This means that we (the Routing ADs) need
>to have a view that the text of 26th September is likely
>to be acceptable to both the community and the IESG.
>It also mean an active dialog with members of the IESG
>regarding review comments raised in the period up to
>10th October.
>
>For reference, I am about to put a placeholder for this
>on the BOF page, in order for an agenda slot to be
>reserved for this work, hopefully to meet as a WG,
>but otherwise to meet to finish of the charter.
>
>So back to the question, is there consensus that text
>below is now at the point where the RTG ADs should
>actively engage to get it ready for IESG approval
>- yes/no?
>
>Thanks
>
>Stewart
>
>=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
>
>Name: <TBD>
>
>A number of use cases, including:
>     o Path computation based on awareness of utilisation or performance
>       data, within both centralised and distributed environments,
>     o Multi-topology routing (dual planes, disjoint trees),
>     o Simplification and reduction of signalling,
>     o Combined application and network-layer path specification.
>     o Full coverage LFA FRR,
>     o Topology Aware OAM,
>have triggered work on the definition of a new architecture and protocol
>extensions, allowing nodes to steer packets through a network, allowing
>combination of well-known shortest-path based routing paradigms with source
>or explicit routing methods. Some of the extensions allowing steering of
>packets in this manner have already been implemented.
>
>The <Name-TBD> working group will define an architecture allowing a node to
>steer a packet through a network, or set of networks, on any path without
>requiring state to be maintained by transited nodes (but rather at the
>source device). The source node may send any packet along a path within the
><Name-TBD> domain through specifying the identifiers referring to this pat=
h.
>Subsequent downstream nodes along the path within the <Name-TBD> domain wi=
ll
>forward packets according to the instructions inserted by the head-end.
>
>Within the <Name-TBD> architecture, a node may be of any type - including
>routers and appliances. A set of such nodes sharing a common trust model
>form a <Name-TBD> domain. The architecture defined by this working group
>will allow steering of packets between any source and destination node
>within the <Name-TBD> domain, which may be formed of one or more networks,
>on any path (shortest, non-shortest, explicit, or based on other resources
>or characteristics specified by segment identifiers).
>
>The <Name-TBD> architecture should support both centralised and distributed
>path computation - through both existing routing protocols (IGP, BGP) and
>new approaches to such path calculation. The architecture should also
>support OAM functions.
>
>The <Name-TBD> architecture has been postulated to be applicable to multip=
le
>data planes (e.g., MPLS, IPv6), and hence the working group should strive =
to
>create a single <Name-TBD> framework which maintains data plane independen=
ce
>where possible. Where use cases are documented, care should be taken to
>define the data plane requirements for the environment within which they a=
re
>to be implemented. The <Name-TBD> architecture should avoid modifications =
to
>the MPLS data-plane, in order to remain compatible with existing extensive
>deployments of MPLS.
>
>The <Name-TBD> working group is chartered for the following (ordered) list
>of items:
>     o Identification of use-cases for the <Name-TBD> architecture for whi=
ch
>       there is consensus within the WG.
>     o Definition of an architectural framework, which must cover
>       security considerations (including the relationship between networks
>       forming the <Name-TBD> domain).
>     o Having identified use-cases, and developed a framework, the WG will
>       work on proposing a new architectures which substantially improve
>       current technologies and define requirements for extensions or new
>       functionality in existing routing protocols and/or I2RS protocols.
>     o The <Name-TBD> working group will then develop solutions - focusing
>       initially on intra-domain forwarding implementations. Where such
>       solutions utilise existing protocols (IS-IS, OSPF, BGP, PCE) this
>will
>       be done in conjunction with the responsible IETF working group. Work
>       on new protocols may be carried out by the <Name-TBD> working group.
>
>The working group will develop the following documents:
>     o One or more documents describing <Name-TBD> use cases,
>     o A <Name-TBD> architecture,
>     o A set of one or more protocol extensions requirements documents,
>     o Inter-operability reports pertaining to the implementation of
>extensions
>       supporting <Name-TBD>.
>
>
>=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
>
>_______________________________________________
>status mailing list
>[email-masked]
>https://www.ietf.org/mailman/listinfo/status

___________________________________________________________________________=
______________________________________________

Ce message et ses pieces jointes peuvent contenir des informations confiden=
tielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu=
 ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages el=
ectroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou =
falsifie. Merci.

This message and its attachments may contain confidential or privileged inf=
ormation that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and dele=
te this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been =
modified, changed or falsified.
Thank you.

From: Rob Shakir <[email-masked]>
Date: Mon, 16 Sep 2013 09:18:38 +0100
To: John G. Scudder <[email-masked]>
Cc: Adrian Farrel <[email-masked]>, "[email-masked]" <[email-masked]>, [email-masked]
Subject: Re: [Status] TBD Charter - ready of RTG AD review yes/no

Hi John,

A few comments in-line, marked rjs>.

On 15 Sep 2013, at 22:09, John G. Scudder <[email-masked]> wrote:

>> [=85snip=85]
>=20
> The two forgoing paragraphs have a lot of redundancy, probably due to =
the multiple revision cycles they've been through. Here is a potential =
rewrite merging the two but attempting to maintain all the content:
>=20
> The <Name-TBD> working group will define an architecture that will =
allow a node to steer a packet between any source and destination =
through a <Name-TBD> domain on any path without requiring state to be =
maintained by transited nodes, but rather at the source device. A =
<Name-TBD> domain is a network or set of networks comprised of nodes =
(which may be of any type, including routers and appliances) that share =
a common trust model. The path may be shortest, non-shortest, explicit, =
or based on other resources or characteristics specified by segment =
identifiers.
>=20
> Some comments on this --
>=20
> - I'm not actually sure what "set of networks" really adds. AFAIK it =
has no well-defined meaning distinct from that of "network".

rjs> I think that "set of networks" is required here -- if we consider =
this from a wider view than purely=20
technical (e.g., operational or administrative separation), then the =
overall <Name-TBD> domain may be made up of multiple different =
underlying separate administrative entities ("networks"). The key thing =
(for me) is that these networks have a model whereby the source can be =
wholly trusted to steer a packet through the domain.

> - I don't think the final sentence actually adds anything since the =
first sentence says "any path" and "any" takes in the entire universe of =
possibilities already. The final sentence also uses the term "segment =
identifiers" which is not defined in the charter.
>=20
> IMO neither of these actually detracts (other than the undefined =
term), but neither do they add, so my preference would be to leave them =
out (I generally favor the "perfection is achieved, not when there is =
nothing more to add, but when there is nothing left to take away" =
heuristic). So:
>=20
> The <Name-TBD> working group will define an architecture that will =
allow a node to steer a packet between any source and destination =
through a <Name-TBD> domain on any path without requiring state to be =
maintained by transited nodes, but rather at the source device. A =
<Name-TBD> domain is a network comprised of nodes (which may be of any =
type, including routers and appliances) that share a common trust model.
>=20
> I actually think "which may be of any type, including routers and =
appliances" is in the same category (it's implicit) but I realize that =
others will probably disagree so I haven't proposed eliding it. I'd be =
happy to though, if I am mistaken.

rjs> In both these cases, the intention of the wording is to provide =
some form of example of the kind of functionality that is required from =
the new architecture.

rjs> If we lose the first paragraph which gives a set of example =
use-cases for this technology, then I think it would be good to include =
the types of nodes/paths that are envisaged. I think this helps support =
the distinction between a domain-wide protocol to determine the route, =
and a head-end being able to pick an arbitrary path without any =
knowledge of the transit nodes as to the means by which it was =
calculated.

>=20
>> The <Name-TBD> architecture should support both centralised and =
distributed path computation - through both existing routing protocols =
(IGP, BGP) and new approaches to such path calculation. The architecture =
should also support OAM functions.
>=20
> The first sentence is puzzlingly broad, especially when you get to =
"... and new approaches to path calculation." The best I can parse it is =
"we haven't decided how to do this yet but everything should be on the =
table". I think it could be trimmed to "The <Name-TBD> architecture =
should support both centralised and distributed path computation" =
without loss of generality.

rjs> I'm OK with this, the intention was to try and ensure that there is =
no direct tie only to today's protocols/approaches to this (so that we =
can retain the generality of the data plane instantiation).

>=20
>> The <Name-TBD> architecture has been postulated to be applicable to =
multiple data planes (e.g., MPLS, IPv6), and hence=20
>=20
> The paragraphs preceding this one state that the WG will define the =
<Name-TBD> architecture. This means that by definition there isn't a =
<Name-TBD> architecture yet. As such I don't see how it can be =
postulated to be much of anything, and would suggest that the foregoing =
clause be cut. I think that again, this can be done without loss of =
generality since the following text captures the intent.

rjs> I don't agree with cutting this sentence in its entirety.

rjs> I would suggest:

"Mechanisms allowing a source node to steer a packet through an =
arbitrary set of nodes/links (without transit modes maintaining state) =
have been postulated to be applicable to multiple data planes (e.g., =
MPLS, IPv6), and hence=85"

rjs> the reason being that we have already had debate (on this list) as =
to what data planes are of interest for the drafts which triggered the =
BoF. The problem you highlighted is that there is perhaps the jump that =
infers that these proposals may form the architecture - which may not be =
the case, so I'm happy to remove the "The <Name-TBD> architecture=85".  =
However, I would like to ensure that there is something in the charter =
that captures that there are operators who are interested in >1 data =
plane.

>=20
>> the working group should strive to create a single <Name-TBD> =
framework which maintains data plane independence where possible. Where =
use cases are documented, care should be taken to define the data plane =
requirements for the environment within which they are to be =
implemented. The <Name-TBD> architecture should avoid modifications to =
the MPLS data-plane, in order to remain compatible with existing =
extensive deployments of MPLS.
>=20
> I suggest adding "It is anticipated the <Name-TBD> architecture may =
need to propose modifications to the IPv6 data plane." (One could use =
"extensions" in place of "modifications", though I prefer it as =
written.) I also suggest that a work item be added,
>=20
>  o Document impact (if any) of any proposed IPv6 data plane =
modifications =20
>    on existing deployment of IPv6.
>=20
> I believe this is the only substantive change I've proposed, the rest =
being editorial.

rjs> I don't see an issue with including this.

>=20
>> The <Name-TBD> working group is chartered for the following (ordered) =
list of items:
>> o Identification of use-cases for the <Name-TBD> architecture for =
which
>>   there is consensus within the WG.
>> o Definition of an architectural framework, which must cover
>>   security considerations (including the relationship between =
networks
>>   forming the <Name-TBD> domain).
>> o Having identified use-cases, and developed a framework, the WG will
>>   work on proposing a new architectures which substantially improve
>=20
> "a new architecture that substantially improves upon"
>=20
>>   current technologies and define requirements for extensions or new
>>   functionality in existing routing protocols and/or I2RS protocols.
>=20
> I'm a little confused why all routing protocols would be taken in but =
only i2rs among management protocols, and besides isn't it still TBD if =
i2rs will even end up defining a protocol? Thus, how about "existing =
routing and management protocols"?

rjs> Again, I'm OK with this.

>=20
>> o The <Name-TBD> working group will then develop solutions - focusing
>>   initially on intra-domain forwarding implementations. Where such
>>   solutions utilise existing protocols (IS-IS, OSPF, BGP, PCE) this =
will
>>   be done in conjunction with the responsible IETF working group. =
Work
>>   on new protocols may be carried out by the <Name-TBD> working =
group.
>>   The working group will develop the following documents:
>> o One or more documents describing <Name-TBD> use cases,
>> o A <Name-TBD> architecture,
>> o A set of one or more protocol extensions requirements documents,
>> o Inter-operability reports pertaining to the implementation of =
extensions
>>   supporting <Name-TBD>.
>=20
> Finally I have a question, or observation: Where we are talking about =
modifying/extending a data plane (IPv6) there may be implications to =
inter-domain forwarding. Thus the initial focus on intra-domain =
forwarding, above, is a little concerning -- one can easily imagine a =
sequence like
>=20
> - Define intra-domain forwarding,
> - Define new v6 data plane,
> - Publish specs,
> - Recharter to include inter-domain,=20
> - Define inter-domain forwarding,
> - Oops, we need to further extend the v6 data plane.
>=20
> Since the cost of extending the v6 data plane may end up being =
non-trivial, it seems as though it would be desirable to avoid this kind =
of iteration. Do others agree and if so how should we capture this in =
the charter?

rjs> Is this not down to what the definition of "domain" is (see: =
"network" vs. "set of networks" discussion above). Do we envisage that =
intra-*<Name-TBD>-domain* forwarding will really be radically different =
to inter-"<Name-TBD>-domain"? The key difference between the two would =
appear to me to be trust model, rather than anything else?

rjs> One possible fix is to strike the wording which asks for focus on =
intra-domain forwarding -- however, if we look at the use-cases that =
triggered this work, there does not appear (to me) to be any that really =
asks for inter-domain yet, so I can't support having to address the =
plethora of issues that exist when extending source-routing into =
environments that do not have a common trust model before we can proceed =
with anything to do with intra-domain forwarding (where there are a =
number of well-established use-cases).

Cheers,
r.

> Thanks,
>=20
> --John
>=20
> Consolidated edits below:
>=20
> ------------------
>=20
> Name: <TBD>
>=20
> The <Name-TBD> working group will define an architecture that will =
allow a node to steer a packet between any source and destination =
through a <Name-TBD> domain on any path without requiring state to be =
maintained by transited nodes, but rather at the source device. A =
<Name-TBD> domain is a network comprised of nodes (which may be of any =
type, including routers and appliances) that share a common trust model.
>=20
> The <Name-TBD> architecture should support both centralised and =
distributed path computation. The architecture should also support OAM =
functions.
>=20
> The working group should strive to create a single <Name-TBD> =
framework which maintains data plane independence where possible. Where =
use cases are documented, care should be taken to define the data plane =
requirements for the environment within which they are to be =
implemented. The <Name-TBD> architecture should avoid modifications to =
the MPLS data-plane, in order to remain compatible with existing =
extensive deployments of MPLS. It is anticipated the <Name-TBD> =
architecture may need to propose modifications to the IPv6 data plane.
>=20
> The <Name-TBD> working group is chartered for the following (ordered) =
list of items:
> o Identification of use-cases for the <Name-TBD> architecture for =
which
>   there is consensus within the WG.
> o Definition of an architectural framework, which must cover
>   security considerations (including the relationship between networks
>   forming the <Name-TBD> domain).
> o Having identified use-cases, and developed a framework, the WG will
>   work on proposing a new architectures which substantially improve
>   current technologies and define requirements for extensions or new
>   functionality in existing routing protocols and/or I2RS protocols.
> o The <Name-TBD> working group will then develop solutions - focusing
>   initially on intra-domain forwarding implementations. Where such
>   solutions utilise existing protocols (IS-IS, OSPF, BGP, PCE) this =
will
>   be done in conjunction with the responsible IETF working group. Work
>   on new protocols may be carried out by the <Name-TBD> working group.
>   The working group will develop the following documents:
> o One or more documents describing <Name-TBD> use cases,
> o A <Name-TBD> architecture,
> o Document impact (if any) of any proposed IPv6 data plane =
modifications =20
>   on existing deployment of IPv6,
> o A set of one or more protocol extensions requirements documents,
> o Inter-operability reports pertaining to the implementation of =
extensions
>   supporting <Name-TBD>.
>=20
> ------------------
> _______________________________________________
> status mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/status

From: Mark Townsley <[email-masked]>
Date: Mon, 16 Sep 2013 03:22:52 +0200
To: John G. Scudder <[email-masked]>
Cc: Adrian Farrel <[email-masked]>, "[email-masked]" <[email-masked]>, [email-masked]
Subject: Re: [Status] TBD Charter - ready of RTG AD review yes/no

On Sep 15, 2013, at 11:09 PM, John G. Scudder wrote:

> Stewart,
>=20
> I have a number of mostly-editorial comments. They're in line below. =
There is one substantive but relatively small change, which is called =
out. I've appended a version of the draft charter that consolidates my =
proposed edits, at the bottom.
>=20
> Going through the exercise of doing this has reminded me of one =
significant concern, though. The first work item for the WG in the =
proposed charter is:
>=20
> o Identification of use-cases for the <Name-TBD> architecture for =
which
>   there is consensus within the WG.
>=20
> This leads to the simple question: until we've identified use cases, =
how can we say we need a new architecture? We are presupposing the =
outcome. If the agreed use cases end up being things that are =
supportable within the existing MPLS architecture, that is great. Note =
I'm not saying the use cases shouldn't be addressed, merely that their =
solutions may, or may not, rise to the level of "architecture". I would =
be interested in discussion of this question before we close on a =
charter.

Also, there is the suggestion in the current text that "new =
architectures" will "substantially improve current technologies" .. I =
don't see how an architecture on its own can do a thing to improve =
current technology, it only provides a framework to operate in so that =
technological improvements can be made. Let me suggest some text to be =
completely clear (which also incorporates another suggestion from John =
Scudder)

OLD:

The <Name-TBD> working group is chartered for the following (ordered) =
list of items:
   o Identification of use-cases for the <Name-TBD> architecture for =
which
     there is consensus within the WG.
   o Definition of an architectural framework, which must cover
     security considerations (including the relationship between =
networks
     forming the <Name-TBD> domain).
   o Having identified use-cases, and developed a framework, the WG will
     work on proposing a new architectures which substantially improve
     current technologies and define requirements for extensions or new
     functionality in existing routing protocols and/or I2RS protocols.

NEW:

The <Name-TBD> working group is chartered for the following items:

o Identification and evaluation of <Name-TBD> use-cases =20
o Definition of a <Name-TBD> Architecture, driven by the use cases and =
underlying technology=20
o The <Name-TBD> Architecture must cover security considerations =
(including the relationship between networks forming the <Name-TBD> =
domain) and allow for solutions which substantially improve upon current =
technologies by defining requirements, extensions, or new functionality =
in existing routing, l2rs or other protocols.

Thanks,

- Mark

>=20
> The rest is in line below.
>=20
> On Sep 13, 2013, at 11:24 AM, Stewart Bryant <[email-masked]> =
wrote:
>=20
>> Thanks to those that have worked on pulling together the
>> charter text.
>>=20
>> I now need to check whether there is consensus that this
>> represents the right starting point for the Routing ADs
>> to engage with the list and polish it to the point where
>> we are confident that it will gain the approval of the IESG.
>>=20
>> Some notes on timeline are appropriate. In order to meet
>> as a WG in Vancouver this needs to be approved for
>> external review at the IESG telechat  on 10th October.
>> This means that we have to add it to the agenda by 26th
>> September. This means that we (the Routing ADs) need
>> to have a view that the text of 26th September is likely
>> to be acceptable to both the community and the IESG.
>> It also mean an active dialog with members of the IESG
>> regarding review comments raised in the period up to
>> 10th October.
>>=20
>> For reference, I am about to put a placeholder for this
>> on the BOF page, in order for an agenda slot to be
>> reserved for this work, hopefully to meet as a WG,
>> but otherwise to meet to finish of the charter.
>>=20
>> So back to the question, is there consensus that text
>> below is now at the point where the RTG ADs should
>> actively engage to get it ready for IESG approval
>> - yes/no?
>>=20
>> Thanks
>>=20
>> Stewart
>>=20
>> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
>>=20
>> Name: <TBD>
>>=20
>> A number of use cases, including:
>> o Path computation based on awareness of utilisation or performance
>>   data, within both centralised and distributed environments,
>> o Multi-topology routing (dual planes, disjoint trees),
>> o Simplification and reduction of signalling,
>> o Combined application and network-layer path specification.
>> o Full coverage LFA FRR,
>> o Topology Aware OAM,
>> have triggered work on the definition of a new architecture and =
protocol extensions, allowing nodes to steer packets through a network, =
allowing combination of well-known shortest-path based routing paradigms =
with source or explicit routing methods. Some of the extensions allowing =
steering of packets in this manner have already been implemented.
>=20
> The foregoing does/did add something to the mailing list discussion, =
but I think should be omitted from the charter. After all, the first =
work item listed in the charter is exactly to produce a list of =
"use-cases ... for which there is consensus". By definition there can't =
be any consensus in the WG yet since there is no WG yet. This is an easy =
edit; the charter reads just fine starting from the below paragraph and =
there are no normative (as it were) changes.
>=20
> (Also, an editorial nit: "use case" is conventionally not hyphenated =
-- a search-and-replace will fix this.)
>=20
>> The <Name-TBD> working group will define an architecture allowing a =
node to steer a packet through a network, or set of networks, on any =
path without requiring state to be maintained by transited nodes (but =
rather at the source device). The source node may send any packet along =
a path within the <Name-TBD> domain through specifying the identifiers =
referring to this path. Subsequent downstream nodes along the path =
within the <Name-TBD> domain will forward packets according to the =
instructions inserted by the head-end.
>>=20
>> Within the <Name-TBD> architecture, a node may be of any type - =
including routers and appliances. A set of such nodes sharing a common =
trust model form a <Name-TBD> domain. The architecture defined by this =
working group will allow steering of packets between any source and =
destination node within the <Name-TBD> domain, which may be formed of =
one or more networks, on any path (shortest, non-shortest, explicit, or =
based on other resources or characteristics specified by segment =
identifiers).
>=20
> The two forgoing paragraphs have a lot of redundancy, probably due to =
the multiple revision cycles they've been through. Here is a potential =
rewrite merging the two but attempting to maintain all the content:
>=20
> The <Name-TBD> working group will define an architecture that will =
allow a node to steer a packet between any source and destination =
through a <Name-TBD> domain on any path without requiring state to be =
maintained by transited nodes, but rather at the source device. A =
<Name-TBD> domain is a network or set of networks comprised of nodes =
(which may be of any type, including routers and appliances) that share =
a common trust model. The path may be shortest, non-shortest, explicit, =
or based on other resources or characteristics specified by segment =
identifiers.
>=20
> Some comments on this --
>=20
> - I'm not actually sure what "set of networks" really adds. AFAIK it =
has no well-defined meaning distinct from that of "network".
> - I don't think the final sentence actually adds anything since the =
first sentence says "any path" and "any" takes in the entire universe of =
possibilities already. The final sentence also uses the term "segment =
identifiers" which is not defined in the charter.
>=20
> IMO neither of these actually detracts (other than the undefined =
term), but neither do they add, so my preference would be to leave them =
out (I generally favor the "perfection is achieved, not when there is =
nothing more to add, but when there is nothing left to take away" =
heuristic). So:
>=20
> The <Name-TBD> working group will define an architecture that will =
allow a node to steer a packet between any source and destination =
through a <Name-TBD> domain on any path without requiring state to be =
maintained by transited nodes, but rather at the source device. A =
<Name-TBD> domain is a network comprised of nodes (which may be of any =
type, including routers and appliances) that share a common trust model.
>=20
> I actually think "which may be of any type, including routers and =
appliances" is in the same category (it's implicit) but I realize that =
others will probably disagree so I haven't proposed eliding it. I'd be =
happy to though, if I am mistaken.
>=20
>> The <Name-TBD> architecture should support both centralised and =
distributed path computation - through both existing routing protocols =
(IGP, BGP) and new approaches to such path calculation. The architecture =
should also support OAM functions.
>=20
> The first sentence is puzzlingly broad, especially when you get to =
"... and new approaches to path calculation." The best I can parse it is =
"we haven't decided how to do this yet but everything should be on the =
table". I think it could be trimmed to "The <Name-TBD> architecture =
should support both centralised and distributed path computation" =
without loss of generality.
>=20
>> The <Name-TBD> architecture has been postulated to be applicable to =
multiple data planes (e.g., MPLS, IPv6), and hence=20
>=20
> The paragraphs preceding this one state that the WG will define the =
<Name-TBD> architecture. This means that by definition there isn't a =
<Name-TBD> architecture yet. As such I don't see how it can be =
postulated to be much of anything, and would suggest that the foregoing =
clause be cut. I think that again, this can be done without loss of =
generality since the following text captures the intent.
>=20
>> the working group should strive to create a single <Name-TBD> =
framework which maintains data plane independence where possible. Where =
use cases are documented, care should be taken to define the data plane =
requirements for the environment within which they are to be =
implemented. The <Name-TBD> architecture should avoid modifications to =
the MPLS data-plane, in order to remain compatible with existing =
extensive deployments of MPLS.
>=20
> I suggest adding "It is anticipated the <Name-TBD> architecture may =
need to propose modifications to the IPv6 data plane." (One could use =
"extensions" in place of "modifications", though I prefer it as =
written.) I also suggest that a work item be added,
>=20
>  o Document impact (if any) of any proposed IPv6 data plane =
modifications =20
>    on existing deployment of IPv6.
>=20
> I believe this is the only substantive change I've proposed, the rest =
being editorial.
>=20
>> The <Name-TBD> working group is chartered for the following (ordered) =
list of items:
>> o Identification of use-cases for the <Name-TBD> architecture for =
which
>>   there is consensus within the WG.
>> o Definition of an architectural framework, which must cover
>>   security considerations (including the relationship between =
networks
>>   forming the <Name-TBD> domain).
>> o Having identified use-cases, and developed a framework, the WG will
>>   work on proposing a new architectures which substantially improve
>=20
> "a new architecture that substantially improves upon"
>=20
>>   current technologies and define requirements for extensions or new
>>   functionality in existing routing protocols and/or I2RS protocols.
>=20
> I'm a little confused why all routing protocols would be taken in but =
only i2rs among management protocols, and besides isn't it still TBD if =
i2rs will even end up defining a protocol? Thus, how about "existing =
routing and management protocols"?
>=20
>> o The <Name-TBD> working group will then develop solutions - focusing
>>   initially on intra-domain forwarding implementations. Where such
>>   solutions utilise existing protocols (IS-IS, OSPF, BGP, PCE) this =
will
>>   be done in conjunction with the responsible IETF working group. =
Work
>>   on new protocols may be carried out by the <Name-TBD> working =
group.
>>   The working group will develop the following documents:
>> o One or more documents describing <Name-TBD> use cases,
>> o A <Name-TBD> architecture,
>> o A set of one or more protocol extensions requirements documents,
>> o Inter-operability reports pertaining to the implementation of =
extensions
>>   supporting <Name-TBD>.
>=20
> Finally I have a question, or observation: Where we are talking about =
modifying/extending a data plane (IPv6) there may be implications to =
inter-domain forwarding. Thus the initial focus on intra-domain =
forwarding, above, is a little concerning -- one can easily imagine a =
sequence like
>=20
> - Define intra-domain forwarding,
> - Define new v6 data plane,
> - Publish specs,
> - Recharter to include inter-domain,=20
> - Define inter-domain forwarding,
> - Oops, we need to further extend the v6 data plane.
>=20
> Since the cost of extending the v6 data plane may end up being =
non-trivial, it seems as though it would be desirable to avoid this kind =
of iteration. Do others agree and if so how should we capture this in =
the charter?
>=20
> Thanks,
>=20
> --John
>=20
> Consolidated edits below:
>=20
> ------------------
>=20
> Name: <TBD>
>=20
> The <Name-TBD> working group will define an architecture that will =
allow a node to steer a packet between any source and destination =
through a <Name-TBD> domain on any path without requiring state to be =
maintained by transited nodes, but rather at the source device. A =
<Name-TBD> domain is a network comprised of nodes (which may be of any =
type, including routers and appliances) that share a common trust model.
>=20
> The <Name-TBD> architecture should support both centralised and =
distributed path computation. The architecture should also support OAM =
functions.
>=20
> The working group should strive to create a single <Name-TBD> =
framework which maintains data plane independence where possible. Where =
use cases are documented, care should be taken to define the data plane =
requirements for the environment within which they are to be =
implemented. The <Name-TBD> architecture should avoid modifications to =
the MPLS data-plane, in order to remain compatible with existing =
extensive deployments of MPLS. It is anticipated the <Name-TBD> =
architecture may need to propose modifications to the IPv6 data plane.
>=20
> The <Name-TBD> working group is chartered for the following (ordered) =
list of items:
> o Identification of use-cases for the <Name-TBD> architecture for =
which
>   there is consensus within the WG.
> o Definition of an architectural framework, which must cover
>   security considerations (including the relationship between networks
>   forming the <Name-TBD> domain).
> o Having identified use-cases, and developed a framework, the WG will
>   work on proposing a new architectures which substantially improve
>   current technologies and define requirements for extensions or new
>   functionality in existing routing protocols and/or I2RS protocols.
> o The <Name-TBD> working group will then develop solutions - focusing
>   initially on intra-domain forwarding implementations. Where such
>   solutions utilise existing protocols (IS-IS, OSPF, BGP, PCE) this =
will
>   be done in conjunction with the responsible IETF working group. Work
>   on new protocols may be carried out by the <Name-TBD> working group.
>   The working group will develop the following documents:
> o One or more documents describing <Name-TBD> use cases,
> o A <Name-TBD> architecture,
> o Document impact (if any) of any proposed IPv6 data plane =
modifications =20
>   on existing deployment of IPv6,
> o A set of one or more protocol extensions requirements documents,
> o Inter-operability reports pertaining to the implementation of =
extensions
>   supporting <Name-TBD>.
>=20
> ------------------
> _______________________________________________
> status mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/status

From: "Alvaro Retana (aretana)" <[email-masked]>
To: Mark Townsley <[email-masked]>
Date: Mon, 16 Sep 2013 01:07:45 +0000
Accept-Language: en-US
Cc: Adrian Farrel <[email-masked]>, "[email-masked]" <[email-masked]>, "Stewart Bryant \(stbryant\)" <[email-masked]>
Subject: Re: [Status] TBD Charter - ready of RTG AD review yes/no

That works for me.  The point was more about pointing at the differences.

Thanks!

Alvaro.

Sent from my iPhone

On Sep 15, 2013, at 9:00 PM, "Mark Townsley" <[email-masked]> wrote:

> I hope we are not setting ourselves up for an architectural framework *an=
d* architecture document though (on top of the obligatory use-case document=
s). One architecture document (which itself certainly would need to provide=
 a solution framework) should suffice. I understand how the charter as writ=
ten leads the reader on to think these are separate, let's fix that instead=
.

From: Mark Townsley <[email-masked]>
Date: Mon, 16 Sep 2013 03:00:11 +0200
To: Alvaro Retana (aretana) <[email-masked]>
Cc: Adrian Farrel <[email-masked]>, "[email-masked]" <[email-masked]>, "Stewart Bryant \(stbryant\)" <[email-masked]>
Subject: Re: [Status] TBD Charter - ready of RTG AD review yes/no

On Sep 16, 2013, at 12:51 AM, Alvaro Retana (aretana) wrote:

>>=20
>> The working group will develop the following documents:
>>    o One or more documents describing <Name-TBD> use cases,
>>    o A <Name-TBD> architecture,
>>    o A set of one or more protocol extensions requirements documents,
>>    o Inter-operability reports pertaining to the implementation of
>> extensions
>>      supporting <Name-TBD>.
>=20
> Comparing the list of items to the documents, I think we're missing an
> architectural framework document.

I hope we are not setting ourselves up for an architectural framework =
*and* architecture document though (on top of the obligatory use-case =
documents). One architecture document (which itself certainly would need =
to provide a solution framework) should suffice. I understand how the =
charter as written leads the reader on to think these are separate, =
let's fix that instead.

- Mark=20

>=20
> Thanks!
>=20
> Alvaro.
>=20
> _______________________________________________
> status mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/status

From: "Alvaro Retana (aretana)" <[email-masked]>
To: "Stewart Bryant (stbryant)" <[email-masked]>, "[email-masked]" <[email-masked]>
Date: Sun, 15 Sep 2013 22:51:45 +0000
Accept-Language: en-US
Cc: Adrian Farrel <[email-masked]>
Subject: Re: [Status] TBD Charter - ready of RTG AD review yes/no

On 9/13/13 9:24 AM, "Stewart Bryant (stbryant)" <[email-masked]> wrote:

Stewart:

Hi!

Just a couple of comments:

...
>The <Name-TBD> working group is chartered for the following (ordered)
>list of items:

What do we mean by "ordered"?

I guess that it is just referring to the "natural" order of things: define
use cases, architecture, solutions, etc..which is obvious to me.  I may
have not been paying close attention, but I haven't seen "ordered"
mentioned in other WG charters.

There was some discussion on the list about the order of events and the
milestones between them.  I just want to make sure that "ordered" does not
have different meanings to different people.

>     o Identification of use-cases for the <Name-TBD> architecture for
>which
>       there is consensus within the WG.
>     o Definition of an architectural framework, which must cover
>       security considerations (including the relationship between
>networks
>       forming the <Name-TBD> domain).
>     o Having identified use-cases, and developed a framework, the WG will
>       work on proposing a new architectures which substantially improve
>       current technologies and define requirements for extensions or new
>       functionality in existing routing protocols and/or I2RS protocols.
>     o The <Name-TBD> working group will then develop solutions - focusing
>       initially on intra-domain forwarding implementations. Where such
>       solutions utilise existing protocols (IS-IS, OSPF, BGP, PCE) this
>will
>       be done in conjunction with the responsible IETF working group.
>Work
>       on new protocols may be carried out by the <Name-TBD> working
>group.
>      =20
>The working group will develop the following documents:
>     o One or more documents describing <Name-TBD> use cases,
>     o A <Name-TBD> architecture,
>     o A set of one or more protocol extensions requirements documents,
>     o Inter-operability reports pertaining to the implementation of
>extensions
>       supporting <Name-TBD>.

Comparing the list of items to the documents, I think we're missing an
architectural framework document.

Thanks!

Alvaro.

From: "John G. Scudder" <[email-masked]>
Date: Sun, 15 Sep 2013 17:09:34 -0400
To: <[email-masked]>
Cc: Adrian Farrel <[email-masked]>, "[email-masked]" <[email-masked]>
Subject: Re: [Status] TBD Charter - ready of RTG AD review yes/no

Stewart,

I have a number of mostly-editorial comments. They're in line below. =
There is one substantive but relatively small change, which is called =
out. I've appended a version of the draft charter that consolidates my =
proposed edits, at the bottom.

Going through the exercise of doing this has reminded me of one =
significant concern, though. The first work item for the WG in the =
proposed charter is:

 o Identification of use-cases for the <Name-TBD> architecture for which
   there is consensus within the WG.

This leads to the simple question: until we've identified use cases, how =
can we say we need a new architecture? We are presupposing the outcome. =
If the agreed use cases end up being things that are supportable within =
the existing MPLS architecture, that is great. Note I'm not saying the =
use cases shouldn't be addressed, merely that their solutions may, or =
may not, rise to the level of "architecture". I would be interested in =
discussion of this question before we close on a charter.

The rest is in line below.

On Sep 13, 2013, at 11:24 AM, Stewart Bryant <[email-masked]> wrote:

> Thanks to those that have worked on pulling together the
> charter text.
>=20
> I now need to check whether there is consensus that this
> represents the right starting point for the Routing ADs
> to engage with the list and polish it to the point where
> we are confident that it will gain the approval of the IESG.
>=20
> Some notes on timeline are appropriate. In order to meet
> as a WG in Vancouver this needs to be approved for
> external review at the IESG telechat  on 10th October.
> This means that we have to add it to the agenda by 26th
> September. This means that we (the Routing ADs) need
> to have a view that the text of 26th September is likely
> to be acceptable to both the community and the IESG.
> It also mean an active dialog with members of the IESG
> regarding review comments raised in the period up to
> 10th October.
>=20
> For reference, I am about to put a placeholder for this
> on the BOF page, in order for an agenda slot to be
> reserved for this work, hopefully to meet as a WG,
> but otherwise to meet to finish of the charter.
>=20
> So back to the question, is there consensus that text
> below is now at the point where the RTG ADs should
> actively engage to get it ready for IESG approval
> - yes/no?
>=20
> Thanks
>=20
> Stewart
>=20
> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
>=20
> Name: <TBD>
>=20
> A number of use cases, including:
>  o Path computation based on awareness of utilisation or performance
>    data, within both centralised and distributed environments,
>  o Multi-topology routing (dual planes, disjoint trees),
>  o Simplification and reduction of signalling,
>  o Combined application and network-layer path specification.
>  o Full coverage LFA FRR,
>  o Topology Aware OAM,
> have triggered work on the definition of a new architecture and =
protocol extensions, allowing nodes to steer packets through a network, =
allowing combination of well-known shortest-path based routing paradigms =
with source or explicit routing methods. Some of the extensions allowing =
steering of packets in this manner have already been implemented.

The foregoing does/did add something to the mailing list discussion, but =
I think should be omitted from the charter. After all, the first work =
item listed in the charter is exactly to produce a list of "use-cases =
... for which there is consensus". By definition there can't be any =
consensus in the WG yet since there is no WG yet. This is an easy edit; =
the charter reads just fine starting from the below paragraph and there =
are no normative (as it were) changes.

(Also, an editorial nit: "use case" is conventionally not hyphenated -- =
a search-and-replace will fix this.)

> The <Name-TBD> working group will define an architecture allowing a =
node to steer a packet through a network, or set of networks, on any =
path without requiring state to be maintained by transited nodes (but =
rather at the source device). The source node may send any packet along =
a path within the <Name-TBD> domain through specifying the identifiers =
referring to this path. Subsequent downstream nodes along the path =
within the <Name-TBD> domain will forward packets according to the =
instructions inserted by the head-end.
>=20
> Within the <Name-TBD> architecture, a node may be of any type - =
including routers and appliances. A set of such nodes sharing a common =
trust model form a <Name-TBD> domain. The architecture defined by this =
working group will allow steering of packets between any source and =
destination node within the <Name-TBD> domain, which may be formed of =
one or more networks, on any path (shortest, non-shortest, explicit, or =
based on other resources or characteristics specified by segment =
identifiers).

The two forgoing paragraphs have a lot of redundancy, probably due to =
the multiple revision cycles they've been through. Here is a potential =
rewrite merging the two but attempting to maintain all the content:

The <Name-TBD> working group will define an architecture that will allow =
a node to steer a packet between any source and destination through a =
<Name-TBD> domain on any path without requiring state to be maintained =
by transited nodes, but rather at the source device. A <Name-TBD> domain =
is a network or set of networks comprised of nodes (which may be of any =
type, including routers and appliances) that share a common trust model. =
The path may be shortest, non-shortest, explicit, or based on other =
resources or characteristics specified by segment identifiers.

Some comments on this --

- I'm not actually sure what "set of networks" really adds. AFAIK it has =
no well-defined meaning distinct from that of "network".
- I don't think the final sentence actually adds anything since the =
first sentence says "any path" and "any" takes in the entire universe of =
possibilities already. The final sentence also uses the term "segment =
identifiers" which is not defined in the charter.

IMO neither of these actually detracts (other than the undefined term), =
but neither do they add, so my preference would be to leave them out (I =
generally favor the "perfection is achieved, not when there is nothing =
more to add, but when there is nothing left to take away" heuristic). =
So:

The <Name-TBD> working group will define an architecture that will allow =
a node to steer a packet between any source and destination through a =
<Name-TBD> domain on any path without requiring state to be maintained =
by transited nodes, but rather at the source device. A <Name-TBD> domain =
is a network comprised of nodes (which may be of any type, including =
routers and appliances) that share a common trust model.

I actually think "which may be of any type, including routers and =
appliances" is in the same category (it's implicit) but I realize that =
others will probably disagree so I haven't proposed eliding it. I'd be =
happy to though, if I am mistaken.

> The <Name-TBD> architecture should support both centralised and =
distributed path computation - through both existing routing protocols =
(IGP, BGP) and new approaches to such path calculation. The architecture =
should also support OAM functions.

The first sentence is puzzlingly broad, especially when you get to "... =
and new approaches to path calculation." The best I can parse it is "we =
haven't decided how to do this yet but everything should be on the =
table". I think it could be trimmed to "The <Name-TBD> architecture =
should support both centralised and distributed path computation" =
without loss of generality.

> The <Name-TBD> architecture has been postulated to be applicable to =
multiple data planes (e.g., MPLS, IPv6), and hence=20

The paragraphs preceding this one state that the WG will define the =
<Name-TBD> architecture. This means that by definition there isn't a =
<Name-TBD> architecture yet. As such I don't see how it can be =
postulated to be much of anything, and would suggest that the foregoing =
clause be cut. I think that again, this can be done without loss of =
generality since the following text captures the intent.

> the working group should strive to create a single <Name-TBD> =
framework which maintains data plane independence where possible. Where =
use cases are documented, care should be taken to define the data plane =
requirements for the environment within which they are to be =
implemented. The <Name-TBD> architecture should avoid modifications to =
the MPLS data-plane, in order to remain compatible with existing =
extensive deployments of MPLS.

I suggest adding "It is anticipated the <Name-TBD> architecture may need =
to propose modifications to the IPv6 data plane." (One could use =
"extensions" in place of "modifications", though I prefer it as =
written.) I also suggest that a work item be added,

  o Document impact (if any) of any proposed IPv6 data plane =
modifications =20
    on existing deployment of IPv6.

I believe this is the only substantive change I've proposed, the rest =
being editorial.

> The <Name-TBD> working group is chartered for the following (ordered) =
list of items:
>  o Identification of use-cases for the <Name-TBD> architecture for =
which
>    there is consensus within the WG.
>  o Definition of an architectural framework, which must cover
>    security considerations (including the relationship between =
networks
>    forming the <Name-TBD> domain).
>  o Having identified use-cases, and developed a framework, the WG will
>    work on proposing a new architectures which substantially improve

"a new architecture that substantially improves upon"

>    current technologies and define requirements for extensions or new
>    functionality in existing routing protocols and/or I2RS protocols.

I'm a little confused why all routing protocols would be taken in but =
only i2rs among management protocols, and besides isn't it still TBD if =
i2rs will even end up defining a protocol? Thus, how about "existing =
routing and management protocols"?

>  o The <Name-TBD> working group will then develop solutions - focusing
>    initially on intra-domain forwarding implementations. Where such
>    solutions utilise existing protocols (IS-IS, OSPF, BGP, PCE) this =
will
>    be done in conjunction with the responsible IETF working group. =
Work
>    on new protocols may be carried out by the <Name-TBD> working =
group.
>    The working group will develop the following documents:
>  o One or more documents describing <Name-TBD> use cases,
>  o A <Name-TBD> architecture,
>  o A set of one or more protocol extensions requirements documents,
>  o Inter-operability reports pertaining to the implementation of =
extensions
>    supporting <Name-TBD>.

Finally I have a question, or observation: Where we are talking about =
modifying/extending a data plane (IPv6) there may be implications to =
inter-domain forwarding. Thus the initial focus on intra-domain =
forwarding, above, is a little concerning -- one can easily imagine a =
sequence like

- Define intra-domain forwarding,
- Define new v6 data plane,
- Publish specs,
- Recharter to include inter-domain,=20
- Define inter-domain forwarding,
- Oops, we need to further extend the v6 data plane.

Since the cost of extending the v6 data plane may end up being =
non-trivial, it seems as though it would be desirable to avoid this kind =
of iteration. Do others agree and if so how should we capture this in =
the charter?

Thanks,

--John

Consolidated edits below:

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

Name: <TBD>

The <Name-TBD> working group will define an architecture that will allow =
a node to steer a packet between any source and destination through a =
<Name-TBD> domain on any path without requiring state to be maintained =
by transited nodes, but rather at the source device. A <Name-TBD> domain =
is a network comprised of nodes (which may be of any type, including =
routers and appliances) that share a common trust model.

The <Name-TBD> architecture should support both centralised and =
distributed path computation. The architecture should also support OAM =
functions.

The working group should strive to create a single <Name-TBD> framework =
which maintains data plane independence where possible. Where use cases =
are documented, care should be taken to define the data plane =
requirements for the environment within which they are to be =
implemented. The <Name-TBD> architecture should avoid modifications to =
the MPLS data-plane, in order to remain compatible with existing =
extensive deployments of MPLS. It is anticipated the <Name-TBD> =
architecture may need to propose modifications to the IPv6 data plane.

The <Name-TBD> working group is chartered for the following (ordered) =
list of items:
 o Identification of use-cases for the <Name-TBD> architecture for which
   there is consensus within the WG.
 o Definition of an architectural framework, which must cover
   security considerations (including the relationship between networks
   forming the <Name-TBD> domain).
 o Having identified use-cases, and developed a framework, the WG will
   work on proposing a new architectures which substantially improve
   current technologies and define requirements for extensions or new
   functionality in existing routing protocols and/or I2RS protocols.
 o The <Name-TBD> working group will then develop solutions - focusing
   initially on intra-domain forwarding implementations. Where such
   solutions utilise existing protocols (IS-IS, OSPF, BGP, PCE) this =
will
   be done in conjunction with the responsible IETF working group. Work
   on new protocols may be carried out by the <Name-TBD> working group.
   The working group will develop the following documents:
 o One or more documents describing <Name-TBD> use cases,
 o A <Name-TBD> architecture,
 o Document impact (if any) of any proposed IPv6 data plane =
modifications =20
   on existing deployment of IPv6,
 o A set of one or more protocol extensions requirements documents,
 o Inter-operability reports pertaining to the implementation of =
extensions
   supporting <Name-TBD>.

------------------=

Sender: [email-masked]
Date: Fri, 13 Sep 2013 20:14:01 +0200
From: Robert Raszuk <[email-masked]>
To: [email-masked]
Cc: Adrian Farrel <[email-masked]>, "[email-masked]" <[email-masked]>
Subject: Re: [Status] TBD Charter - ready of RTG AD review yes/no

> - yes/no?

Yes.

Thx,
R.

Date: Fri, 13 Sep 2013 14:13:35 -0400
From: Victor Kuarsingh <[email-masked]>
To: "Stefano Previdi (sprevidi)" <[email-masked]>
Cc: Stephane Litkowski <[email-masked]>, Xuxiaohu <[email-masked]>, Rob Shakir <[email-masked]>, "[email-masked]" <[email-masked]>, Hannes Gredler <[email-masked]>
Subject: Re: [Status] Good charter proposals from Hannes and Stefano : try to merge ...

--f46d0438eb6d19653f04e647d07c
Content-Type: text/plain; charset=ISO-8859-1

Stefano/Xiaohu,

On Wed, Sep 11, 2013 at 6:37 AM, Stefano Previdi (sprevidi) <
[email-masked]> wrote:

>
> >
> > I don't think it's suitable to mention developing IPv6 specific SR
> mechanism in the current charter unless there is no requirement for any
> change to the existing IPv6 data plane.
>
> > According to the following statements quoted from
> http://tools.ietf.org/html/draft-filsfils-rtgwg-segment-routing-00#page-9,
> "...The source route is encoded as an ordered list of segments instead of
> IP addresses..." If so, why not directly use an ordered list of labels
> (i.e., MPLS label stack) to do that (see
> http://www.ietf.org/mail-archive/web/status/current/msg00165.html)?
>
>
> v6 dataplane allows more effective source route capability by
> leveraging extensions headers. Hence the proposal that will
> consist of defining a new Extension Header for SR where the
> segment list is encoded and _preserved_ throughout the path.
>
> So, I do strongly believe we have to work on v6 and since we're
> in the definition of a charter (i.e.: not the detailed review
> of the solutions) I believe v6 should be part of it.
>
>
[VK].  I strongly agree that we should be including v6 work within the

charter.  As noted at the BoF in Berlin, I made similar comments (along

with at least one other operator) of the need for this.

I think discounting a v6 data plan option at this point is premature and

will be ignoring input from operators which provided use case(s).

We should include it.

Regards,

Victor K

> Thanks.
> s.
>
>
>
>

--f46d0438eb6d19653f04e647d07c
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">Stefano/Xiaohu,<div class=3D"gmail_extra"><br><br><div cla=
ss=3D"gmail_quote">On Wed, Sep 11, 2013 at 6:37 AM, Stefano Previdi (sprevi=
di) <span dir=3D"ltr">&lt;<a href=3D"mailto:[email-masked]" target=3D"_=
blank">[email-masked]</a>&gt;</span> wrote:<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-=
left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;p=
adding-left:1ex"><br>
&gt;<br>
&gt; I don&#39;t think it&#39;s suitable to mention developing IPv6 specifi=
c SR mechanism in the current charter unless there is no requirement for an=
y change to the existing IPv6 data plane.<br>
<br>
&gt; According to the following statements quoted from <a href=3D"http://to=
ols.ietf.org/html/draft-filsfils-rtgwg-segment-routing-00#page-9" target=3D=
"_blank">http://tools.ietf.org/html/draft-filsfils-rtgwg-segment-routing-00=
#page-9</a>, &quot;...The source route is encoded as an ordered list of seg=
ments instead of IP addresses...&quot; If so, why not directly use an order=
ed list of labels (i.e., MPLS label stack) to do that (see <a href=3D"http:=
//www.ietf.org/mail-archive/web/status/current/msg00165.html" target=3D"_bl=
ank">http://www.ietf.org/mail-archive/web/status/current/msg00165.html</a>)=
?<br>

<br>
<br>
v6 dataplane allows more effective source route capability by<br>
leveraging extensions headers. Hence the proposal that will<br>
consist of defining a new Extension Header for SR where the<br>
segment list is encoded and _preserved_ throughout the path.<br>
<br>
So, I do strongly believe we have to work on v6 and since we&#39;re<br>
in the definition of a charter (i.e.: not the detailed review<br>
of the solutions) I believe v6 should be part of it.<br>
<br></blockquote><div><br></div><div>

<p class=3D"">[VK].=A0=A0I strongly agree that we should be including v6 wo=
rk within the</p><p class=3D"">charter.=A0=A0As noted at the BoF in Berlin,=
 I made similar comments (along</p><p class=3D"">with at least one other op=
erator) of the need for this.</p>
<p class=3D""><br></p><p class=3D"">I think discounting a v6 data plan opti=
on at this point is premature and</p><p class=3D"">will be ignoring input f=
rom operators which provided use case(s).</p><p class=3D""><br></p><p class=
=3D"">
We should include it.</p><p class=3D""><br></p><p class=3D"">Regards,</p><p=
 class=3D""><br></p><p class=3D"">

</p><p class=3D"">Victor K</p></div><div><br></div><div><br></div><div>=A0<=
/div><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;bo=
rder-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:so=
lid;padding-left:1ex">

Thanks.<br>
s.<br>
<br>
<br><br>
</blockquote></div><br></div></div>

--f46d0438eb6d19653f04e647d07c--

From: "Stefano Previdi (sprevidi)" <[email-masked]>
To: "Stewart Bryant (stbryant)" <[email-masked]>
Date: Fri, 13 Sep 2013 17:53:33 +0000
Accept-Language: en-US
Cc: Adrian Farrel <[email-masked]>, "[email-masked]" <[email-masked]>
Subject: Re: [Status] TBD Charter - ready of RTG AD review yes/no

On Sep 13, 2013, at 5:24 PM, Stewart Bryant wrote:
>=20
> So back to the question, is there consensus that text
> below is now at the point where the RTG ADs should
> actively engage to get it ready for IESG approval
> - yes/no?

yes.

s.

>=20
> Thanks
>=20
> Stewart
>=20
> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
>=20
> Name: <TBD>
>=20
> A number of use cases, including:
>    o Path computation based on awareness of utilisation or performance
>      data, within both centralised and distributed environments,
>    o Multi-topology routing (dual planes, disjoint trees),
>    o Simplification and reduction of signalling,
>    o Combined application and network-layer path specification.
>    o Full coverage LFA FRR,
>    o Topology Aware OAM,
> have triggered work on the definition of a new architecture and protocol =
extensions, allowing nodes to steer packets through a network, allowing com=
bination of well-known shortest-path based routing paradigms with source or=
 explicit routing methods. Some of the extensions allowing steering of pack=
ets in this manner have already been implemented.
>=20
> The <Name-TBD> working group will define an architecture allowing a node =
to steer a packet through a network, or set of networks, on any path withou=
t requiring state to be maintained by transited nodes (but rather at the so=
urce device). The source node may send any packet along a path within the <=
Name-TBD> domain through specifying the identifiers referring to this path.=
 Subsequent downstream nodes along the path within the <Name-TBD> domain wi=
ll forward packets according to the instructions inserted by the head-end.
>=20
> Within the <Name-TBD> architecture, a node may be of any type - including=
 routers and appliances. A set of such nodes sharing a common trust model f=
orm a <Name-TBD> domain. The architecture defined by this working group wil=
l allow steering of packets between any source and destination node within =
the <Name-TBD> domain, which may be formed of one or more networks, on any =
path (shortest, non-shortest, explicit, or based on other resources or char=
acteristics specified by segment identifiers).
>=20
> The <Name-TBD> architecture should support both centralised and distribut=
ed path computation - through both existing routing protocols (IGP, BGP) an=
d new approaches to such path calculation. The architecture should also sup=
port OAM functions.
>=20
> The <Name-TBD> architecture has been postulated to be applicable to multi=
ple data planes (e.g., MPLS, IPv6), and hence the working group should stri=
ve to create a single <Name-TBD> framework which maintains data plane indep=
endence where possible. Where use cases are documented, care should be take=
n to define the data plane requirements for the environment within which th=
ey are to be implemented. The <Name-TBD> architecture should avoid modifica=
tions to the MPLS data-plane, in order to remain compatible with existing e=
xtensive deployments of MPLS.
>=20
> The <Name-TBD> working group is chartered for the following (ordered) lis=
t of items:
>    o Identification of use-cases for the <Name-TBD> architecture for whic=
h
>      there is consensus within the WG.
>    o Definition of an architectural framework, which must cover
>      security considerations (including the relationship between networks
>      forming the <Name-TBD> domain).
>    o Having identified use-cases, and developed a framework, the WG will
>      work on proposing a new architectures which substantially improve
>      current technologies and define requirements for extensions or new
>      functionality in existing routing protocols and/or I2RS protocols.
>    o The <Name-TBD> working group will then develop solutions - focusing
>      initially on intra-domain forwarding implementations. Where such
>      solutions utilise existing protocols (IS-IS, OSPF, BGP, PCE) this wi=
ll
>      be done in conjunction with the responsible IETF working group. Work
>      on new protocols may be carried out by the <Name-TBD> working group.
>      The working group will develop the following documents:
>    o One or more documents describing <Name-TBD> use cases,
>    o A <Name-TBD> architecture,
>    o A set of one or more protocol extensions requirements documents,
>    o Inter-operability reports pertaining to the implementation of extens=
ions
>      supporting <Name-TBD>.
>     =20
> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
>=20
> _______________________________________________
> status mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/status

From: Rob Shakir <[email-masked]>
Date: Fri, 13 Sep 2013 16:40:25 +0100
To: [email-masked]
Cc: Adrian Farrel <[email-masked]>, "[email-masked]" <[email-masked]>
Subject: Re: [Status] TBD Charter - ready of RTG AD review yes/no

Hi Stewart,

On 13 Sep 2013, at 16:24, Stewart Bryant <[email-masked]> wrote:

> So back to the question, is there consensus that text
> below is now at the point where the RTG ADs should
> actively engage to get it ready for IESG approval
> - yes/no?

Thanks, I believe that this charter is ready for the examination of the =
routing ADs, and forward for IESG approval.

Kind regards,
r.=20=

Date: Fri, 13 Sep 2013 16:24:35 +0100
From: Stewart Bryant <[email-masked]>
To: "[email-masked]" <[email-masked]>
Cc: Adrian Farrel <[email-masked]>
Subject: [Status] TBD Charter - ready of RTG AD review yes/no
Reply-To: [email-masked]

Thanks to those that have worked on pulling together the
charter text.

I now need to check whether there is consensus that this
represents the right starting point for the Routing ADs
to engage with the list and polish it to the point where
we are confident that it will gain the approval of the IESG.

Some notes on timeline are appropriate. In order to meet
as a WG in Vancouver this needs to be approved for
external review at the IESG telechat  on 10th October.
This means that we have to add it to the agenda by 26th
September. This means that we (the Routing ADs) need
to have a view that the text of 26th September is likely
to be acceptable to both the community and the IESG.
It also mean an active dialog with members of the IESG
regarding review comments raised in the period up to
10th October.

For reference, I am about to put a placeholder for this
on the BOF page, in order for an agenda slot to be
reserved for this work, hopefully to meet as a WG,
but otherwise to meet to finish of the charter.

So back to the question, is there consensus that text
below is now at the point where the RTG ADs should
actively engage to get it ready for IESG approval
- yes/no?

Thanks

Stewart

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

Name: <TBD>

A number of use cases, including:
     o Path computation based on awareness of utilisation or performance
       data, within both centralised and distributed environments,
     o Multi-topology routing (dual planes, disjoint trees),
     o Simplification and reduction of signalling,
     o Combined application and network-layer path specification.
     o Full coverage LFA FRR,
     o Topology Aware OAM,
have triggered work on the definition of a new architecture and protocol extensions, allowing nodes to steer packets through a network, allowing combination of well-known shortest-path based routing paradigms with source or explicit routing methods. Some of the extensions allowing steering of packets in this manner have already been implemented.

The <Name-TBD> working group will define an architecture allowing a node to steer a packet through a network, or set of networks, on any path without requiring state to be maintained by transited nodes (but rather at the source device). The source node may send any packet along a path within the <Name-TBD> domain through specifying the identifiers referring to this path. Subsequent downstream nodes along the path within the <Name-TBD> domain will forward packets according to the instructions inserted by the head-end.

Within the <Name-TBD> architecture, a node may be of any type - including routers and appliances. A set of such nodes sharing a common trust model form a <Name-TBD> domain. The architecture defined by this working group will allow steering of packets between any source and destination node within the <Name-TBD> domain, which may be formed of one or more networks, on any path (shortest, non-shortest, explicit, or based on other resources or characteristics specified by segment identifiers).

The <Name-TBD> architecture should support both centralised and distributed path computation - through both existing routing protocols (IGP, BGP) and new approaches to such path calculation. The architecture should also support OAM functions.

The <Name-TBD> architecture has been postulated to be applicable to multiple data planes (e.g., MPLS, IPv6), and hence the working group should strive to create a single <Name-TBD> framework which maintains data plane independence where possible. Where use cases are documented, care should be taken to define the data plane requirements for the environment within which they are to be implemented. The <Name-TBD> architecture should avoid modifications to the MPLS data-plane, in order to remain compatible with existing extensive deployments of MPLS.

The <Name-TBD> working group is chartered for the following (ordered) list of items:
     o Identification of use-cases for the <Name-TBD> architecture for which
       there is consensus within the WG.
     o Definition of an architectural framework, which must cover
       security considerations (including the relationship between networks
       forming the <Name-TBD> domain).
     o Having identified use-cases, and developed a framework, the WG will
       work on proposing a new architectures which substantially improve
       current technologies and define requirements for extensions or new
       functionality in existing routing protocols and/or I2RS protocols.
     o The <Name-TBD> working group will then develop solutions - focusing
       initially on intra-domain forwarding implementations. Where such
       solutions utilise existing protocols (IS-IS, OSPF, BGP, PCE) this will
       be done in conjunction with the responsible IETF working group. Work
       on new protocols may be carried out by the <Name-TBD> working group.
       
The working group will develop the following documents:
     o One or more documents describing <Name-TBD> use cases,
     o A <Name-TBD> architecture,
     o A set of one or more protocol extensions requirements documents,
     o Inter-operability reports pertaining to the implementation of extensions
       supporting <Name-TBD>.

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

From: AshwoodsmithPeter <[email-masked]>
To: "[email-masked]" <[email-masked]>
Date: Fri, 13 Sep 2013 13:40:04 +0000
Accept-Language: en-US, zh-CN
Subject: Re: [Status] Updated Merged Charter.

Fine, as long as that's not used as an argument that something has already =
been implemented and therefore can't be changed.

Peter

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of=
 Stefano Previdi (sprevidi)
Sent: Friday, September 13, 2013 9:28 AM
To: AshwoodsmithPeter
Cc: [email-masked]
Subject: Re: [Status] Updated Merged Charter.

Hi Peter,

On Sep 13, 2013, at 3:23 PM, AshwoodsmithPeter wrote:
> Support,
>=20
> However suggest that "Some of the extensions allowing steering of packets=
 in this manner have already been implemented" is not really relevant to th=
e charter as consensus and working code is a back end requirement.

indeed. However, it's a way to illustrate that requirements (even if=20
not yet documented) do exist. Obviously, they must be documented=20
appropriately and we are working on it.

Thanks for your support.
s.

>=20
> Peter
>=20
> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf =
Of [email-masked]
> Sent: Friday, September 13, 2013 2:17 AM
> To: [email-masked]; [email-masked]; [email-masked]
> Cc: [email-masked]
> Subject: Re: [Status] Updated Merged Charter.
>=20
> Rob, Stephane and Robert,
>=20
> thanks again for your constructive input. I support your proposal.
>=20
> Regards,
>=20
> Ruediger
>=20
>=20
> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf =
Of Rob Shakir
> Sent: Friday, September 13, 2013 12:23 AM
> To: Robert Raszuk
> Cc: Hannes Gredler; [email-masked]; sprevidi; <stephane.litkowski@orange=
.com>
> Subject: Re: [Status] Updated Merged Charter.
>=20
>=20
> On 12 Sep 2013, at 23:19, Robert Raszuk <[email-masked]> wrote:
>=20
>> Apologies ... fixed the below due to copy error:
>>=20
>>> I would recommend to rephrase the above:
>>>=20
>>> o Having identified use-cases, and developed a framework, the WG will
>>> work on proposing a new architectures which substantially improve
>>> current technologies and define requirements for extensions or new
>>> functionality in existing routing protocols and/or I2RS protocol.
>=20
> Hi Robert,
>=20
> Sure - I have no problems with this. I think the key is to ensure that we=
 are working on problems that need solutions, either through omissions of c=
urrent technologies, or where there is scope for improvement. I'll merge th=
e change.
>=20
> On the p2p/p2mp case, I'm not clear that we need to explicitly define thi=
s in the charter. The text currently makes no reference to the type of path=
, since these should be defined within the use case documents IMHO.
>=20
> Updated text is below.
>=20
> Thanks,
> r.
>=20
> Name: <TBD>
>=20
> A number of use cases, including:
>    o Path computation based on awareness of utilisation or performance
>      data, within both centralised and distributed environments,
>    o Multi-topology routing (dual planes, disjoint trees),
>    o Simplification and reduction of signalling,
>    o Combined application and network-layer path specification.
>    o Full coverage LFA FRR,
>    o Topology Aware OAM,
> have triggered work on the definition of a new architecture and protocol =
extensions, allowing nodes to steer packets through a network, allowing com=
bination of well-known shortest-path based routing paradigms with source or=
 explicit routing methods. Some of the extensions allowing steering of pack=
ets in this manner have already been implemented.
>=20
> The <Name-TBD> working group will define an architecture allowing a node =
to steer a packet through a network, or set of networks, on any path withou=
t requiring state to be maintained by transited nodes (but rather at the so=
urce device). The source node may send any packet along a path within the <=
Name-TBD> domain through specifying the identifiers referring to this path.=
 Subsequent downstream nodes along the path within the <Name-TBD> domain wi=
ll forward packets according to the instructions inserted by the head-end.
>=20
> Within the <Name-TBD> architecture, a node may be of any type - including=
 routers and appliances. A set of such nodes sharing a common trust model f=
orm a <Name-TBD> domain. The architecture defined by this working group wil=
l allow steering of packets between any source and destination node within =
the <Name-TBD> domain, which may be formed of one or more networks, on any =
path (shortest, non-shortest, explicit, or based on other resources or char=
acteristics specified by segment identifiers).
>=20
> The <Name-TBD> architecture should support both centralised and distribut=
ed path computation - through both existing routing protocols (IGP, BGP) an=
d new approaches to such path calculation. The architecture should also sup=
port OAM functions.
>=20
> The <Name-TBD> architecture has been postulated to be applicable to multi=
ple data planes (e.g., MPLS, IPv6), and hence the working group should stri=
ve to create a single <Name-TBD> framework which maintains data plane indep=
endence where possible. Where use cases are documented, care should be take=
n to define the data plane requirements for the environment within which th=
ey are to be implemented. The <Name-TBD> architecture should avoid modifica=
tions to the MPLS data-plane, in order to remain compatible with existing e=
xtensive deployments of MPLS.
>=20
> The <Name-TBD> working group is chartered for the following (ordered) lis=
t of items:
>    o Identification of use-cases for the <Name-TBD> architecture for whic=
h
>      there is consensus within the WG.
>    o Definition of an architectural framework, which must cover
>      security considerations (including the relationship between networks
>      forming the <Name-TBD> domain).
>    o Having identified use-cases, and developed a framework, the WG will
>      work on proposing a new architectures which substantially improve
>      current technologies and define requirements for extensions or new
>      functionality in existing routing protocols and/or I2RS protocols.
>    o The <Name-TBD> working group will then develop solutions - focusing
>      initially on intra-domain forwarding implementations. Where such
>      solutions utilise existing protocols (IS-IS, OSPF, BGP, PCE) this wi=
ll
>      be done in conjunction with the responsible IETF working group. Work
>      on new protocols may be carried out by the <Name-TBD> working group.
>=20
> The working group will develop the following documents:
>    o One or more documents describing <Name-TBD> use cases,
>    o A <Name-TBD> architecture,
>    o A set of one or more protocol extensions requirements documents,
>    o Inter-operability reports pertaining to the implementation of extens=
ions
>      supporting <Name-TBD>.
>=20
>=20
> _______________________________________________
> status mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/status
> _______________________________________________
> status mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/status
> _______________________________________________
> status mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/status

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

From: "Stefano Previdi (sprevidi)" <[email-masked]>
To: AshwoodsmithPeter <[email-masked]>
Date: Fri, 13 Sep 2013 13:27:55 +0000
Accept-Language: en-US
Cc: "[email-masked]" <[email-masked]>
Subject: Re: [Status] Updated Merged Charter.

Hi Peter,

On Sep 13, 2013, at 3:23 PM, AshwoodsmithPeter wrote:
> Support,
>=20
> However suggest that "Some of the extensions allowing steering of packets=
 in this manner have already been implemented" is not really relevant to th=
e charter as consensus and working code is a back end requirement.

indeed. However, it's a way to illustrate that requirements (even if=20
not yet documented) do exist. Obviously, they must be documented=20
appropriately and we are working on it.

Thanks for your support.
s.

>=20
> Peter
>=20
> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf =
Of [email-masked]
> Sent: Friday, September 13, 2013 2:17 AM
> To: [email-masked]; [email-masked]; [email-masked]
> Cc: [email-masked]
> Subject: Re: [Status] Updated Merged Charter.
>=20
> Rob, Stephane and Robert,
>=20
> thanks again for your constructive input. I support your proposal.
>=20
> Regards,
>=20
> Ruediger
>=20
>=20
> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf =
Of Rob Shakir
> Sent: Friday, September 13, 2013 12:23 AM
> To: Robert Raszuk
> Cc: Hannes Gredler; [email-masked]; sprevidi; <stephane.litkowski@orange=
.com>
> Subject: Re: [Status] Updated Merged Charter.
>=20
>=20
> On 12 Sep 2013, at 23:19, Robert Raszuk <[email-masked]> wrote:
>=20
>> Apologies ... fixed the below due to copy error:
>>=20
>>> I would recommend to rephrase the above:
>>>=20
>>> o Having identified use-cases, and developed a framework, the WG will
>>> work on proposing a new architectures which substantially improve
>>> current technologies and define requirements for extensions or new
>>> functionality in existing routing protocols and/or I2RS protocol.
>=20
> Hi Robert,
>=20
> Sure - I have no problems with this. I think the key is to ensure that we=
 are working on problems that need solutions, either through omissions of c=
urrent technologies, or where there is scope for improvement. I'll merge th=
e change.
>=20
> On the p2p/p2mp case, I'm not clear that we need to explicitly define thi=
s in the charter. The text currently makes no reference to the type of path=
, since these should be defined within the use case documents IMHO.
>=20
> Updated text is below.
>=20
> Thanks,
> r.
>=20
> Name: <TBD>
>=20
> A number of use cases, including:
>    o Path computation based on awareness of utilisation or performance
>      data, within both centralised and distributed environments,
>    o Multi-topology routing (dual planes, disjoint trees),
>    o Simplification and reduction of signalling,
>    o Combined application and network-layer path specification.
>    o Full coverage LFA FRR,
>    o Topology Aware OAM,
> have triggered work on the definition of a new architecture and protocol =
extensions, allowing nodes to steer packets through a network, allowing com=
bination of well-known shortest-path based routing paradigms with source or=
 explicit routing methods. Some of the extensions allowing steering of pack=
ets in this manner have already been implemented.
>=20
> The <Name-TBD> working group will define an architecture allowing a node =
to steer a packet through a network, or set of networks, on any path withou=
t requiring state to be maintained by transited nodes (but rather at the so=
urce device). The source node may send any packet along a path within the <=
Name-TBD> domain through specifying the identifiers referring to this path.=
 Subsequent downstream nodes along the path within the <Name-TBD> domain wi=
ll forward packets according to the instructions inserted by the head-end.
>=20
> Within the <Name-TBD> architecture, a node may be of any type - including=
 routers and appliances. A set of such nodes sharing a common trust model f=
orm a <Name-TBD> domain. The architecture defined by this working group wil=
l allow steering of packets between any source and destination node within =
the <Name-TBD> domain, which may be formed of one or more networks, on any =
path (shortest, non-shortest, explicit, or based on other resources or char=
acteristics specified by segment identifiers).
>=20
> The <Name-TBD> architecture should support both centralised and distribut=
ed path computation - through both existing routing protocols (IGP, BGP) an=
d new approaches to such path calculation. The architecture should also sup=
port OAM functions.
>=20
> The <Name-TBD> architecture has been postulated to be applicable to multi=
ple data planes (e.g., MPLS, IPv6), and hence the working group should stri=
ve to create a single <Name-TBD> framework which maintains data plane indep=
endence where possible. Where use cases are documented, care should be take=
n to define the data plane requirements for the environment within which th=
ey are to be implemented. The <Name-TBD> architecture should avoid modifica=
tions to the MPLS data-plane, in order to remain compatible with existing e=
xtensive deployments of MPLS.
>=20
> The <Name-TBD> working group is chartered for the following (ordered) lis=
t of items:
>    o Identification of use-cases for the <Name-TBD> architecture for whic=
h
>      there is consensus within the WG.
>    o Definition of an architectural framework, which must cover
>      security considerations (including the relationship between networks
>      forming the <Name-TBD> domain).
>    o Having identified use-cases, and developed a framework, the WG will
>      work on proposing a new architectures which substantially improve
>      current technologies and define requirements for extensions or new
>      functionality in existing routing protocols and/or I2RS protocols.
>    o The <Name-TBD> working group will then develop solutions - focusing
>      initially on intra-domain forwarding implementations. Where such
>      solutions utilise existing protocols (IS-IS, OSPF, BGP, PCE) this wi=
ll
>      be done in conjunction with the responsible IETF working group. Work
>      on new protocols may be carried out by the <Name-TBD> working group.
>=20
> The working group will develop the following documents:
>    o One or more documents describing <Name-TBD> use cases,
>    o A <Name-TBD> architecture,
>    o A set of one or more protocol extensions requirements documents,
>    o Inter-operability reports pertaining to the implementation of extens=
ions
>      supporting <Name-TBD>.
>=20
>=20
> _______________________________________________
> status mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/status
> _______________________________________________
> status mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/status
> _______________________________________________
> status mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/status

From: AshwoodsmithPeter <[email-masked]>
To: "[email-masked]" <[email-masked]>
Date: Fri, 13 Sep 2013 13:23:52 +0000
Accept-Language: en-US, zh-CN
Subject: Re: [Status] Updated Merged Charter.

Support,

However suggest that "Some of the extensions allowing steering of packets i=
n this manner have already been implemented" is not really relevant to the =
charter as consensus and working code is a back end requirement.

Peter

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of=
 [email-masked]
Sent: Friday, September 13, 2013 2:17 AM
To: [email-masked]; [email-masked]; [email-masked]
Cc: [email-masked]
Subject: Re: [Status] Updated Merged Charter.

Rob, Stephane and Robert,

thanks again for your constructive input. I support your proposal.

Regards,

Ruediger

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of=
 Rob Shakir
Sent: Friday, September 13, 2013 12:23 AM
To: Robert Raszuk
Cc: Hannes Gredler; [email-masked]; sprevidi; <[email-masked]=
om>
Subject: Re: [Status] Updated Merged Charter.

On 12 Sep 2013, at 23:19, Robert Raszuk <[email-masked]> wrote:

> Apologies ... fixed the below due to copy error:
>
>> I would recommend to rephrase the above:
>>
>> o Having identified use-cases, and developed a framework, the WG will
>> work on proposing a new architectures which substantially improve
>> current technologies and define requirements for extensions or new
>> functionality in existing routing protocols and/or I2RS protocol.

Hi Robert,

Sure - I have no problems with this. I think the key is to ensure that we a=
re working on problems that need solutions, either through omissions of cur=
rent technologies, or where there is scope for improvement. I'll merge the =
change.

On the p2p/p2mp case, I'm not clear that we need to explicitly define this =
in the charter. The text currently makes no reference to the type of path, =
since these should be defined within the use case documents IMHO.

Updated text is below.

Thanks,
r.

Name: <TBD>

A number of use cases, including:
    o Path computation based on awareness of utilisation or performance
      data, within both centralised and distributed environments,
    o Multi-topology routing (dual planes, disjoint trees),
    o Simplification and reduction of signalling,
    o Combined application and network-layer path specification.
    o Full coverage LFA FRR,
    o Topology Aware OAM,
have triggered work on the definition of a new architecture and protocol ex=
tensions, allowing nodes to steer packets through a network, allowing combi=
nation of well-known shortest-path based routing paradigms with source or e=
xplicit routing methods. Some of the extensions allowing steering of packet=
s in this manner have already been implemented.

The <Name-TBD> working group will define an architecture allowing a node to=
 steer a packet through a network, or set of networks, on any path without =
requiring state to be maintained by transited nodes (but rather at the sour=
ce device). The source node may send any packet along a path within the <Na=
me-TBD> domain through specifying the identifiers referring to this path. S=
ubsequent downstream nodes along the path within the <Name-TBD> domain will=
 forward packets according to the instructions inserted by the head-end.

Within the <Name-TBD> architecture, a node may be of any type - including r=
outers and appliances. A set of such nodes sharing a common trust model for=
m a <Name-TBD> domain. The architecture defined by this working group will =
allow steering of packets between any source and destination node within th=
e <Name-TBD> domain, which may be formed of one or more networks, on any pa=
th (shortest, non-shortest, explicit, or based on other resources or charac=
teristics specified by segment identifiers).

The <Name-TBD> architecture should support both centralised and distributed=
 path computation - through both existing routing protocols (IGP, BGP) and =
new approaches to such path calculation. The architecture should also suppo=
rt OAM functions.

The <Name-TBD> architecture has been postulated to be applicable to multipl=
e data planes (e.g., MPLS, IPv6), and hence the working group should strive=
 to create a single <Name-TBD> framework which maintains data plane indepen=
dence where possible. Where use cases are documented, care should be taken =
to define the data plane requirements for the environment within which they=
 are to be implemented. The <Name-TBD> architecture should avoid modificati=
ons to the MPLS data-plane, in order to remain compatible with existing ext=
ensive deployments of MPLS.

The <Name-TBD> working group is chartered for the following (ordered) list =
of items:
    o Identification of use-cases for the <Name-TBD> architecture for which
      there is consensus within the WG.
    o Definition of an architectural framework, which must cover
      security considerations (including the relationship between networks
      forming the <Name-TBD> domain).
    o Having identified use-cases, and developed a framework, the WG will
      work on proposing a new architectures which substantially improve
      current technologies and define requirements for extensions or new
      functionality in existing routing protocols and/or I2RS protocols.
    o The <Name-TBD> working group will then develop solutions - focusing
      initially on intra-domain forwarding implementations. Where such
      solutions utilise existing protocols (IS-IS, OSPF, BGP, PCE) this wil=
l
      be done in conjunction with the responsible IETF working group. Work
      on new protocols may be carried out by the <Name-TBD> working group.

The working group will develop the following documents:
    o One or more documents describing <Name-TBD> use cases,
    o A <Name-TBD> architecture,
    o A set of one or more protocol extensions requirements documents,
    o Inter-operability reports pertaining to the implementation of extensi=
ons
      supporting <Name-TBD>.

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

From: "Field, Brian" <[email-masked]>
To: "Stefano Previdi (sprevidi)" <[email-masked]>, Rob Shakir <[email-masked]>
Date: Fri, 13 Sep 2013 11:50:13 +0000
Accept-Language: en-US
Cc: "[email-masked]" <[email-masked]>, Hannes Gredler <[email-masked]>, Robert Raszuk <[email-masked]>, "Clarence Filsfils \(cfilsfil\)" <[email-masked]>, Stephane Litkowski <[email-masked]>
Subject: Re: [Status] Updated Merged Charter.

I support the updated charter as proposed by Rob and I am particularly
interested in an end-to-end IPv6 solution.

Brian

On 9/13/13 4:07 AM, "Stefano Previdi (sprevidi)" <[email-masked]>
wrote:

>Hi Rob, Stephane, Robert,
>
>Thanks for the effort. I think we're in the good direction.
>
>I support your proposal of updated charter and I'd propose "SEGROUTE"
>as WG name since it reflects pretty well the architecture that has
>been proposed (SR) and it's inline with RFC2460 which uses "segments"
>and "ordered list of segments" terminology in the framework of source
>routing (section 4.4).
>
>
>s.
>
>
>On Sep 13, 2013, at 12:23 AM, Rob Shakir wrote:
>
>>=20
>> On 12 Sep 2013, at 23:19, Robert Raszuk <[email-masked]> wrote:
>>=20
>>> Apologies ... fixed the below due to copy error:
>>>=20
>>>> I would recommend to rephrase the above:
>>>>=20
>>>> o Having identified use-cases, and developed a framework, the WG will
>>>> work on proposing a new architectures which substantially improve
>>>> current technologies and define requirements for extensions or new
>>>> functionality in existing routing protocols and/or I2RS protocol.
>>=20
>> Hi Robert,
>>=20
>> Sure - I have no problems with this. I think the key is to ensure that
>>we are working on problems that need solutions, either through omissions
>>of current technologies, or where there is scope for improvement. I'll
>>merge the change.
>>=20
>> On the p2p/p2mp case, I'm not clear that we need to explicitly define
>>this in the charter. The text currently makes no reference to the type
>>of path, since these should be defined within the use case documents
>>IMHO.
>>=20
>> Updated text is below.
>>=20
>> Thanks,
>> r.
>>=20
>> Name: <TBD>
>>=20
>> A number of use cases, including:
>>    o Path computation based on awareness of utilisation or performance
>>      data, within both centralised and distributed environments,
>>    o Multi-topology routing (dual planes, disjoint trees),
>>    o Simplification and reduction of signalling,
>>    o Combined application and network-layer path specification.
>>    o Full coverage LFA FRR,
>>    o Topology Aware OAM,
>> have triggered work on the definition of a new architecture and
>>protocol extensions, allowing nodes to steer packets through a network,
>>allowing combination of well-known shortest-path based routing paradigms
>>with source or explicit routing methods. Some of the extensions allowing
>>steering of packets in this manner have already been implemented.
>>=20
>> The <Name-TBD> working group will define an architecture allowing a
>>node to steer a packet through a network, or set of networks, on any
>>path without requiring state to be maintained by transited nodes (but
>>rather at the source device). The source node may send any packet along
>>a path within the <Name-TBD> domain through specifying the identifiers
>>referring to this path. Subsequent downstream nodes along the path
>>within the <Name-TBD> domain will forward packets according to the
>>instructions inserted by the head-end.
>>=20
>> Within the <Name-TBD> architecture, a node may be of any type -
>>including routers and appliances. A set of such nodes sharing a common
>>trust model form a <Name-TBD> domain. The architecture defined by this
>>working group will allow steering of packets between any source and
>>destination node within the <Name-TBD> domain, which may be formed of
>>one or more networks, on any path (shortest, non-shortest, explicit, or
>>based on other resources or characteristics specified by segment
>>identifiers).
>>=20
>> The <Name-TBD> architecture should support both centralised and
>>distributed path computation - through both existing routing protocols
>>(IGP, BGP) and new approaches to such path calculation. The architecture
>>should also support OAM functions.
>>=20
>> The <Name-TBD> architecture has been postulated to be applicable to
>>multiple data planes (e.g., MPLS, IPv6), and hence the working group
>>should strive to create a single <Name-TBD> framework which maintains
>>data plane independence where possible. Where use cases are documented,
>>care should be taken to define the data plane requirements for the
>>environment within which they are to be implemented. The <Name-TBD>
>>architecture should avoid modifications to the MPLS data-plane, in order
>>to remain compatible with existing extensive deployments of MPLS.
>>=20
>> The <Name-TBD> working group is chartered for the following (ordered)
>>list of items:
>>    o Identification of use-cases for the <Name-TBD> architecture for
>>which
>>      there is consensus within the WG.
>>    o Definition of an architectural framework, which must cover
>>      security considerations (including the relationship between
>>networks
>>      forming the <Name-TBD> domain).
>>    o Having identified use-cases, and developed a framework, the WG will
>>      work on proposing a new architectures which substantially improve
>>      current technologies and define requirements for extensions or new
>>      functionality in existing routing protocols and/or I2RS protocols.
>>    =20
>>    o The <Name-TBD> working group will then develop solutions -
>>focusing=20
>>      initially on intra-domain forwarding implementations. Where such
>>      solutions utilise existing protocols (IS-IS, OSPF, BGP, PCE) this
>>will
>>      be done in conjunction with the responsible IETF working group.
>>Work
>>      on new protocols may be carried out by the <Name-TBD> working
>>group.
>>=20
>> The working group will develop the following documents:
>>    o One or more documents describing <Name-TBD> use cases,
>>    o A <Name-TBD> architecture,
>>    o A set of one or more protocol extensions requirements documents,
>>    o Inter-operability reports pertaining to the implementation of
>>extensions
>>      supporting <Name-TBD>.
>>=20
>>=20
>
>_______________________________________________
>status mailing list
>[email-masked]
>https://www.ietf.org/mailman/listinfo/status

From: "Stefano Previdi (sprevidi)" <[email-masked]>
To: Rob Shakir <[email-masked]>
Date: Fri, 13 Sep 2013 10:07:45 +0000
Accept-Language: en-US
Cc: Hannes Gredler <[email-masked]>, Stephane Litkowski <[email-masked]>, "Clarence Filsfils \(cfilsfil\)" <[email-masked]>, Robert Raszuk <[email-masked]>, "[email-masked]" <[email-masked]>
Subject: Re: [Status] Updated Merged Charter.

Hi Rob, Stephane, Robert,

Thanks for the effort. I think we're in the good direction.

I support your proposal of updated charter and I'd propose "SEGROUTE"=20
as WG name since it reflects pretty well the architecture that has=20
been proposed (SR) and it's inline with RFC2460 which uses "segments"=20
and "ordered list of segments" terminology in the framework of source=20
routing (section 4.4).

s.

On Sep 13, 2013, at 12:23 AM, Rob Shakir wrote:

>=20
> On 12 Sep 2013, at 23:19, Robert Raszuk <[email-masked]> wrote:
>=20
>> Apologies ... fixed the below due to copy error:
>>=20
>>> I would recommend to rephrase the above:
>>>=20
>>> o Having identified use-cases, and developed a framework, the WG will
>>> work on proposing a new architectures which substantially improve
>>> current technologies and define requirements for extensions or new
>>> functionality in existing routing protocols and/or I2RS protocol.
>=20
> Hi Robert,
>=20
> Sure - I have no problems with this. I think the key is to ensure that we=
 are working on problems that need solutions, either through omissions of c=
urrent technologies, or where there is scope for improvement. I'll merge th=
e change.
>=20
> On the p2p/p2mp case, I'm not clear that we need to explicitly define thi=
s in the charter. The text currently makes no reference to the type of path=
, since these should be defined within the use case documents IMHO.
>=20
> Updated text is below.
>=20
> Thanks,
> r.
>=20
> Name: <TBD>
>=20
> A number of use cases, including:
>    o Path computation based on awareness of utilisation or performance
>      data, within both centralised and distributed environments,
>    o Multi-topology routing (dual planes, disjoint trees),
>    o Simplification and reduction of signalling,
>    o Combined application and network-layer path specification.
>    o Full coverage LFA FRR,
>    o Topology Aware OAM, =20
> have triggered work on the definition of a new architecture and protocol =
extensions, allowing nodes to steer packets through a network, allowing com=
bination of well-known shortest-path based routing paradigms with source or=
 explicit routing methods. Some of the extensions allowing steering of pack=
ets in this manner have already been implemented.
>=20
> The <Name-TBD> working group will define an architecture allowing a node =
to steer a packet through a network, or set of networks, on any path withou=
t requiring state to be maintained by transited nodes (but rather at the so=
urce device). The source node may send any packet along a path within the <=
Name-TBD> domain through specifying the identifiers referring to this path.=
 Subsequent downstream nodes along the path within the <Name-TBD> domain wi=
ll forward packets according to the instructions inserted by the head-end.
>=20
> Within the <Name-TBD> architecture, a node may be of any type - including=
 routers and appliances. A set of such nodes sharing a common trust model f=
orm a <Name-TBD> domain. The architecture defined by this working group wil=
l allow steering of packets between any source and destination node within =
the <Name-TBD> domain, which may be formed of one or more networks, on any =
path (shortest, non-shortest, explicit, or based on other resources or char=
acteristics specified by segment identifiers).
>=20
> The <Name-TBD> architecture should support both centralised and distribut=
ed path computation - through both existing routing protocols (IGP, BGP) an=
d new approaches to such path calculation. The architecture should also sup=
port OAM functions.
>=20
> The <Name-TBD> architecture has been postulated to be applicable to multi=
ple data planes (e.g., MPLS, IPv6), and hence the working group should stri=
ve to create a single <Name-TBD> framework which maintains data plane indep=
endence where possible. Where use cases are documented, care should be take=
n to define the data plane requirements for the environment within which th=
ey are to be implemented. The <Name-TBD> architecture should avoid modifica=
tions to the MPLS data-plane, in order to remain compatible with existing e=
xtensive deployments of MPLS.
>=20
> The <Name-TBD> working group is chartered for the following (ordered) lis=
t of items:
>    o Identification of use-cases for the <Name-TBD> architecture for whic=
h
>      there is consensus within the WG.
>    o Definition of an architectural framework, which must cover
>      security considerations (including the relationship between networks
>      forming the <Name-TBD> domain).     =20
>    o Having identified use-cases, and developed a framework, the WG will
>      work on proposing a new architectures which substantially improve
>      current technologies and define requirements for extensions or new
>      functionality in existing routing protocols and/or I2RS protocols.  =
   =20
>    o The <Name-TBD> working group will then develop solutions - focusing=
=20
>      initially on intra-domain forwarding implementations. Where such
>      solutions utilise existing protocols (IS-IS, OSPF, BGP, PCE) this wi=
ll
>      be done in conjunction with the responsible IETF working group. Work
>      on new protocols may be carried out by the <Name-TBD> working group.
>=20
> The working group will develop the following documents:
>    o One or more documents describing <Name-TBD> use cases,
>    o A <Name-TBD> architecture,
>    o A set of one or more protocol extensions requirements documents,
>    o Inter-operability reports pertaining to the implementation of extens=
ions
>      supporting <Name-TBD>.
>=20
>=20

From: <[email-masked]>
To: <[email-masked]>, <[email-masked]>, <[email-masked]>
Date: Fri, 13 Sep 2013 08:16:32 +0200
Accept-Language: en-US, de-DE
acceptlanguage: en-US, de-DE
Cc: [email-masked]
Subject: Re: [Status] Updated Merged Charter.

Rob, Stephane and Robert,

thanks again for your constructive input. I support your proposal.

Regards,

Ruediger

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of=
 Rob Shakir
Sent: Friday, September 13, 2013 12:23 AM
To: Robert Raszuk
Cc: Hannes Gredler; [email-masked]; sprevidi; <[email-masked]=
om>
Subject: Re: [Status] Updated Merged Charter.

On 12 Sep 2013, at 23:19, Robert Raszuk <[email-masked]> wrote:

> Apologies ... fixed the below due to copy error:
>
>> I would recommend to rephrase the above:
>>
>> o Having identified use-cases, and developed a framework, the WG will
>> work on proposing a new architectures which substantially improve
>> current technologies and define requirements for extensions or new
>> functionality in existing routing protocols and/or I2RS protocol.

Hi Robert,

Sure - I have no problems with this. I think the key is to ensure that we a=
re working on problems that need solutions, either through omissions of cur=
rent technologies, or where there is scope for improvement. I'll merge the =
change.

On the p2p/p2mp case, I'm not clear that we need to explicitly define this =
in the charter. The text currently makes no reference to the type of path, =
since these should be defined within the use case documents IMHO.

Updated text is below.

Thanks,
r.

Name: <TBD>

A number of use cases, including:
    o Path computation based on awareness of utilisation or performance
      data, within both centralised and distributed environments,
    o Multi-topology routing (dual planes, disjoint trees),
    o Simplification and reduction of signalling,
    o Combined application and network-layer path specification.
    o Full coverage LFA FRR,
    o Topology Aware OAM,
have triggered work on the definition of a new architecture and protocol ex=
tensions, allowing nodes to steer packets through a network, allowing combi=
nation of well-known shortest-path based routing paradigms with source or e=
xplicit routing methods. Some of the extensions allowing steering of packet=
s in this manner have already been implemented.

The <Name-TBD> working group will define an architecture allowing a node to=
 steer a packet through a network, or set of networks, on any path without =
requiring state to be maintained by transited nodes (but rather at the sour=
ce device). The source node may send any packet along a path within the <Na=
me-TBD> domain through specifying the identifiers referring to this path. S=
ubsequent downstream nodes along the path within the <Name-TBD> domain will=
 forward packets according to the instructions inserted by the head-end.

Within the <Name-TBD> architecture, a node may be of any type - including r=
outers and appliances. A set of such nodes sharing a common trust model for=
m a <Name-TBD> domain. The architecture defined by this working group will =
allow steering of packets between any source and destination node within th=
e <Name-TBD> domain, which may be formed of one or more networks, on any pa=
th (shortest, non-shortest, explicit, or based on other resources or charac=
teristics specified by segment identifiers).

The <Name-TBD> architecture should support both centralised and distributed=
 path computation - through both existing routing protocols (IGP, BGP) and =
new approaches to such path calculation. The architecture should also suppo=
rt OAM functions.

The <Name-TBD> architecture has been postulated to be applicable to multipl=
e data planes (e.g., MPLS, IPv6), and hence the working group should strive=
 to create a single <Name-TBD> framework which maintains data plane indepen=
dence where possible. Where use cases are documented, care should be taken =
to define the data plane requirements for the environment within which they=
 are to be implemented. The <Name-TBD> architecture should avoid modificati=
ons to the MPLS data-plane, in order to remain compatible with existing ext=
ensive deployments of MPLS.

The <Name-TBD> working group is chartered for the following (ordered) list =
of items:
    o Identification of use-cases for the <Name-TBD> architecture for which
      there is consensus within the WG.
    o Definition of an architectural framework, which must cover
      security considerations (including the relationship between networks
      forming the <Name-TBD> domain).
    o Having identified use-cases, and developed a framework, the WG will
      work on proposing a new architectures which substantially improve
      current technologies and define requirements for extensions or new
      functionality in existing routing protocols and/or I2RS protocols.
    o The <Name-TBD> working group will then develop solutions - focusing
      initially on intra-domain forwarding implementations. Where such
      solutions utilise existing protocols (IS-IS, OSPF, BGP, PCE) this wil=
l
      be done in conjunction with the responsible IETF working group. Work
      on new protocols may be carried out by the <Name-TBD> working group.

The working group will develop the following documents:
    o One or more documents describing <Name-TBD> use cases,
    o A <Name-TBD> architecture,
    o A set of one or more protocol extensions requirements documents,
    o Inter-operability reports pertaining to the implementation of extensi=
ons
      supporting <Name-TBD>.

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

From: Xuxiaohu <[email-masked]>
To: Rob Shakir <[email-masked]>, "[email-masked]" <[email-masked]>, "Hannes Gredler" <[email-masked]>, sprevidi <[email-masked]>
Date: Fri, 13 Sep 2013 02:55:39 +0000
Accept-Language: zh-CN, en-US
Cc: "<[email-masked]>" <[email-masked]>
Subject: [Status] =?gb2312?b?tPC4tDogIFVwZGF0ZWQgTWVyZ2VkIENoYXJ0ZXIu?=

From: Rob Shakir <[email-masked]>
Date: Thu, 12 Sep 2013 23:23:07 +0100
To: Robert Raszuk <[email-masked]>
Cc: Hannes Gredler <[email-masked]>, "[email-masked]" <[email-masked]>, sprevidi <[email-masked]>, "<[email-masked]>" <[email-masked]>
Subject: Re: [Status] Updated Merged Charter.

On 12 Sep 2013, at 23:19, Robert Raszuk <[email-masked]> wrote:

> Apologies ... fixed the below due to copy error:
>=20
>> I would recommend to rephrase the above:
>>=20
>> o Having identified use-cases, and developed a framework, the WG will
>> work on proposing a new architectures which substantially improve
>> current technologies and define requirements for extensions or new
>> functionality in existing routing protocols and/or I2RS protocol.

Hi Robert,

Sure - I have no problems with this. I think the key is to ensure that =
we are working on problems that need solutions, either through omissions =
of current technologies, or where there is scope for improvement. I'll =
merge the change.

On the p2p/p2mp case, I'm not clear that we need to explicitly define =
this in the charter. The text currently makes no reference to the type =
of path, since these should be defined within the use case documents =
IMHO.

Updated text is below.

Thanks,
r.

Name: <TBD>

A number of use cases, including:
    o Path computation based on awareness of utilisation or performance
      data, within both centralised and distributed environments,
    o Multi-topology routing (dual planes, disjoint trees),
    o Simplification and reduction of signalling,
    o Combined application and network-layer path specification.
    o Full coverage LFA FRR,
    o Topology Aware OAM, =20
have triggered work on the definition of a new architecture and protocol =
extensions, allowing nodes to steer packets through a network, allowing =
combination of well-known shortest-path based routing paradigms with =
source or explicit routing methods. Some of the extensions allowing =
steering of packets in this manner have already been implemented.

The <Name-TBD> working group will define an architecture allowing a node =
to steer a packet through a network, or set of networks, on any path =
without requiring state to be maintained by transited nodes (but rather =
at the source device). The source node may send any packet along a path =
within the <Name-TBD> domain through specifying the identifiers =
referring to this path. Subsequent downstream nodes along the path =
within the <Name-TBD> domain will forward packets according to the =
instructions inserted by the head-end.

Within the <Name-TBD> architecture, a node may be of any type - =
including routers and appliances. A set of such nodes sharing a common =
trust model form a <Name-TBD> domain. The architecture defined by this =
working group will allow steering of packets between any source and =
destination node within the <Name-TBD> domain, which may be formed of =
one or more networks, on any path (shortest, non-shortest, explicit, or =
based on other resources or characteristics specified by segment =
identifiers).

The <Name-TBD> architecture should support both centralised and =
distributed path computation - through both existing routing protocols =
(IGP, BGP) and new approaches to such path calculation. The architecture =
should also support OAM functions.

The <Name-TBD> architecture has been postulated to be applicable to =
multiple data planes (e.g., MPLS, IPv6), and hence the working group =
should strive to create a single <Name-TBD> framework which maintains =
data plane independence where possible. Where use cases are documented, =
care should be taken to define the data plane requirements for the =
environment within which they are to be implemented. The <Name-TBD> =
architecture should avoid modifications to the MPLS data-plane, in order =
to remain compatible with existing extensive deployments of MPLS.

The <Name-TBD> working group is chartered for the following (ordered) =
list of items:
    o Identification of use-cases for the <Name-TBD> architecture for =
which
      there is consensus within the WG.
    o Definition of an architectural framework, which must cover
      security considerations (including the relationship between =
networks
      forming the <Name-TBD> domain).     =20
    o Having identified use-cases, and developed a framework, the WG =
will
      work on proposing a new architectures which substantially improve
      current technologies and define requirements for extensions or new
      functionality in existing routing protocols and/or I2RS protocols. =
    =20
    o The <Name-TBD> working group will then develop solutions - =
focusing=20
      initially on intra-domain forwarding implementations. Where such
      solutions utilise existing protocols (IS-IS, OSPF, BGP, PCE) this =
will
      be done in conjunction with the responsible IETF working group. =
Work
      on new protocols may be carried out by the <Name-TBD> working =
group.
     =20
The working group will develop the following documents:
    o One or more documents describing <Name-TBD> use cases,
    o A <Name-TBD> architecture,
    o A set of one or more protocol extensions requirements documents,
    o Inter-operability reports pertaining to the implementation of =
extensions
      supporting <Name-TBD>.
     =20

Sender: [email-masked]
Date: Fri, 13 Sep 2013 00:19:33 +0200
From: Robert Raszuk <[email-masked]>
To: Rob Shakir <[email-masked]>
Cc: Hannes Gredler <[email-masked]>, "[email-masked]" <[email-masked]>, sprevidi <[email-masked]>, "<[email-masked]>" <[email-masked]>
Subject: Re: [Status] Updated Merged Charter.

Apologies ... fixed the below due to copy error:

> I would recommend to rephrase the above:
>
> o Having identified use-cases, and developed a framework, the WG will
> work on proposing a new architectures which substantially improve
> current technologies and define requirements for extensions or new
> functionality in existing routing protocols and/or I2RS protocol.

r.

Sender: [email-masked]
Date: Thu, 12 Sep 2013 23:55:49 +0200
From: Robert Raszuk <[email-masked]>
To: Rob Shakir <[email-masked]>
Cc: Hannes Gredler <[email-masked]>, "[email-masked]" <[email-masked]>, sprevidi <[email-masked]>, "<[email-masked]>" <[email-masked]>
Subject: Re: [Status] Updated Merged Charter.

Hi Rob,

Let me provide two comments to your proposal:

> A number of use cases, including:
>
>     o Path computation based on awareness of utilisation or performance
>       data, within both centralised and distributed environments,

I think the above is a very important statement. In fact perhaps we
could explicitly mentioned there that such paths could be p2p as well
as p2mp.

>     o Having identified use-cases, and developed a framework, the WG will
>       identify gaps in currently available technologies, and define
>       requirements for extensions or new functionality that is required.

As said before I disagree that we need to work off "gaps". Imagine if
we all in IETF/networking would be walled to work off *gaps* we will
be still improving FDDI, Token Ring, ATM and Frame Relay technologies.
You can do a lot with RSVP-TE .. but there is not only control plane
complexity associated with this, but also unnecessary state. Same for
LDP.

I would recommend to rephrase the above:

o Having identified use-cases, and developed a framework, the WG will
work on proposing a new architectures which substantially improve
current technologies identify gaps in currently available technologies
and define requirements for extensions or new functionality in
existing routing protocols and/or I2RS protocol.

Best regards,
R.

From: Rob Shakir <[email-masked]>
Date: Thu, 12 Sep 2013 22:11:49 +0100
To: "[email-masked]" <[email-masked]>, Hannes Gredler <[email-masked]>, sprevidi <[email-masked]>
Cc: "<[email-masked]>" <[email-masked]>
Subject: [Status] Updated Merged Charter.

Hi STATUS, Hannes, Stefano,

Following some discussion with Stephane, I tried to consolidate the =
wording from the various threads into one charter proposal, which can be =
found below this message.

I would specifically draw your attention to the following paragraph:

> The <Name-TBD> architecture has been postulated to be applicable to =
multiple data planes (e.g., MPLS,=20
> IPv6), and hence the working group should strive to create a single =
<Name-TBD> framework which=20
> maintains data plane independence where possible. Where use cases are =
documented, care should be taken=20
> to define the data plane requirements for the environment within which =
they are to be implemented. The > <Name-TBD> architecture should avoid =
modifications to the MPLS data-plane, in order to remain=20
> compatible with existing extensive deployments of MPLS.

There are of course a number of different opinions relating to the =
network deployments in which different operators would like to deploy =
the technology that will be developed by this effort. In my humble =
opinion, the debates as to the exact requirements can (and should) be =
done in the working group as we develop on the use cases. I have =
therefore tried to make sure that the wording in the charter does not =
pre-judge the result of such debates, but does not close the door on =
them in the future (should consensus exist to work on them). I believe =
this also captures the points relating to data-planes that the ADs noted =
in the evaluation of the BoF.

Your feedback on this proposal would be very much appreciated (and =
thanks to Stephane for his initial proposal and help with this)!

Kind regards,
r.

Name: <TBD>

A number of use cases, including:
    o Path computation based on awareness of utilisation or performance
      data, within both centralised and distributed environments,
    o Multi-topology routing (dual planes, disjoint trees),
    o Simplification and reduction of signalling,
    o Combined application and network-layer path specification.
    o Full coverage LFA FRR,
    o Topology Aware OAM, =20
have triggered work on the definition of a new architecture and protocol =
extensions, allowing nodes to steer packets through a network, allowing =
combination of well-known shortest-path based routing paradigms with =
source or explicit routing methods. Some of the extensions allowing =
steering of packets in this manner have already been implemented.

The <Name-TBD> working group will define an architecture allowing a node =
to steer a packet through a network, or set of networks, on any path =
without requiring state to be maintained by transited nodes (but rather =
at the source device). The source node may send any packet along a path =
within the <Name-TBD> domain through specifying the identifiers =
referring to this path. Subsequent downstream nodes along the path =
within the <Name-TBD> domain will forward packets according to the =
instructions inserted by the head-end.

Within the <Name-TBD> architecture, a node may be of any type - =
including routers and appliances. A set of such nodes sharing a common =
trust model form a <Name-TBD> domain. The architecture defined by this =
working group will allow steering of packets between any source and =
destination node within the <Name-TBD> domain, which may be formed of =
one or more networks, on any path (shortest, non-shortest, explicit, or =
based on other resources or characteristics specified by segment =
identifiers).

The <Name-TBD> architecture should support both centralised and =
distributed path computation - through both existing routing protocols =
(IGP, BGP) and new approaches to such path calculation. The architecture =
should also support OAM functions.

The <Name-TBD> architecture has been postulated to be applicable to =
multiple data planes (e.g., MPLS, IPv6), and hence the working group =
should strive to create a single <Name-TBD> framework which maintains =
data plane independence where possible. Where use cases are documented, =
care should be taken to define the data plane requirements for the =
environment within which they are to be implemented. The <Name-TBD> =
architecture should avoid modifications to the MPLS data-plane, in order =
to remain compatible with existing extensive deployments of MPLS.

The <Name-TBD> working group is chartered for the following (ordered) =
list of items:
    o Identification of use-cases for the <Name-TBD> architecture for =
which
      there is consensus within the WG.
    o Definition of an architectural framework, which must cover
      security considerations (including the relationship between =
networks
      forming the <Name-TBD> domain).
    o Having identified use-cases, and developed a framework, the WG =
will
      identify gaps in currently available technologies, and define
      requirements for extensions or new functionality that is required.
    o The <Name-TBD> working group will then develop solutions - =
focusing=20
      initially on intra-domain forwarding implementations. Where such
      solutions utilise existing protocols (IS-IS, OSPF, BGP, PCE) this =
will
      be done in conjunction with the responsible IETF working group. =
Work
      on new protocols may be carried out by the <Name-TBD> working =
group.
     =20
The working group will develop the following documents:
    o One or more documents describing <Name-TBD> use cases,
    o A <Name-TBD> architecture,
    o A set of one or more protocol extensions requirements documents,
    o Inter-operability reports pertaining to the implementation of =
extensions
      supporting <Name-TBD>.
     =20

From: AshwoodsmithPeter <[email-masked]>
To: "[email-masked]" <[email-masked]>
Date: Thu, 12 Sep 2013 19:46:52 +0000
Accept-Language: en-US, zh-CN
Subject: Re: [Status] Good charter proposals from Hannes and Stefano : try to merge ...

From: John E Drake <[email-masked]>
To: AshwoodsmithPeter <[email-masked]>, "[email-masked]" <[email-masked]>
Date: Thu, 12 Sep 2013 16:43:36 +0000
Accept-Language: en-US
Subject: Re: [Status] Good charter proposals from Hannes and Stefano : try to merge ...

From: AshwoodsmithPeter <[email-masked]>
To: "[email-masked]" <[email-masked]>
Date: Thu, 12 Sep 2013 16:08:27 +0000
Accept-Language: en-US, zh-CN
Subject: Re: [Status] Good charter proposals from Hannes and Stefano : try to merge ...

From: "Stefano Previdi (sprevidi)" <[email-masked]>
To: Hannes Gredler <[email-masked]>, Alia Atlas <[email-masked]>
Date: Thu, 12 Sep 2013 15:14:18 +0000
Accept-Language: en-US
Cc: "[email-masked]" <[email-masked]>
Subject: Re: [Status] Good charter proposals from Hannes and Stefano : try	to merge ...

Alia, Hannes,

On Sep 12, 2013, at 4:45 PM, Hannes Gredler wrote:
>=20
> HG> as per your email below i was under the impression that 'soon' is 'so=
oner' -
>    and having a spec is precursor for doing interop testing. -
>    looks like that you are not there yet.

> Finally, work on drafts and discussions should happen between meetings to=
o.  It's much easier to focus on
> specific drafts and issues when everything else in the IETF isn't happeni=
ng.   Deciding to focus only on the deadlines
> associated with IETF meetings is part of what slows the IETF down.  I bel=
ieve that isn't your goal here...  Getting
> continuous work is something that I, for instance, am trying to stress in=
 I2RS.

the implementations interop tests are based on mpls data-plane.

What I'd like to see in the charter is that the control plane must/should=20
be agnostic to data-plane instantiation so to support mpls and v6.

Note that we already have the SR-ISIS draft which _is_ data-plane agnostic.

Same in the mechanisms can be constructed, i.e., not bound to solely IGP=20
but rather give the ability to other components to construct paths using=20
segments.

My time availability doesn't allow me to go faster so I will submit SR-v6=20
use-cases SR-IPv6 Extension Header and hopefully I'll be allowed to present=
=20
them both at next meeting.

s.

From: John E Drake <[email-masked]>
To: "Stefano Previdi (sprevidi)" <[email-masked]>
Date: Thu, 12 Sep 2013 14:55:34 +0000
Accept-Language: en-US
Cc: Stephane Litkowski <[email-masked]>, Xuxiaohu <[email-masked]>, Rob Shakir <[email-masked]>, "[email-masked]" <[email-masked]>, Hannes Gredler <[email-masked]>
Subject: Re: [Status] Good charter proposals from Hannes and Stefano : try to merge ...

From: Hannes Gredler <[email-masked]>
Date: Thu, 12 Sep 2013 16:45:05 +0200
To: Stefano Previdi <[email-masked]>
Cc: Stephane Litkowski <[email-masked]>, Xuxiaohu <[email-masked]>, Rob Shakir <[email-masked]>, "[email-masked]" <[email-masked]>
Subject: Re: [Status] Good charter proposals from Hannes and Stefano : try to merge ...

stefano,

On Sep 12, 2013, at 4:10 PM, Stefano Previdi (sprevidi) wrote:

>=20
> On Sep 12, 2013, at 3:23 PM, Hannes Gredler wrote:
>=20
>> hi stefano,
>>=20
>> can you *share* your proposed 'extension header' spec ?
>=20
>=20
> when ready, yes. It's going to be submitted by Vancouver meeting.
                                                ^^^^^^^^^^^^^^^^^^

HG> as per your email below i was under the impression that 'soon' is =
'sooner' -
    and having a spec is precursor for doing interop testing. -
    looks like that you are not there yet.

---
On Sep 10, 2013, at 6:58 PM, Stefano Previdi (sprevidi) wrote:

     [ =85 ]
     As I mentioned in my charter proposal, we do have
     implementations and multi-vendor interoperability tests will
     happen soon. So, I just want to be sure we don't ignore this
     reality.
---

     in summary:
     the list hasn't seen a good case for both service-chaining
     and why we need another data plane in support for this.

     i concur therefore with stephane that we shall add exploration
     if those things are needed in the charter, but its a bit premature
     (also in lieu of written down use-cases and proposals) to make it
     mandatory to include now.

> In the mean time, I believe we can still talk about the charter=20
> or is the rule that we have to spec out all details first ?

HG> there is a difference between:

"i want the charter to look like this,
because this is what i am currently developing"

   and

"lets work on question(s) <a,b,c> in an open-forum and the
answers are going to shape what changes we need to existing
protocols and forwarding paradigms"

/hannes

> such that ASIC/hardware people can assess themselves:
>>=20
>>=20
>> 1. what are the implications wrt to deployed hardware
>> 2. if there is a forwarding penalty
>>=20
>> /hannes
>>=20
>> On Sep 12, 2013, at 2:43 PM, Stefano Previdi (sprevidi) wrote:
>> [ =85 ]
>>>>>=20
>>>>> v6 dataplane allows more effective source route capability by
>>>>> leveraging extensions headers. Hence the proposal that will
>>>>> consist of defining a new Extension Header for SR where the
>>>>> segment list is encoded and _preserved_ throughout the path.
>>>>=20
>>>> What's the purpose of preserving the whole segment list throughout =
the path? In other words, isn't it enough to contain the information of =
ingress and egress nodes throughout the path?
>>>=20
>>>=20
>>> there are use cases, among which OAM, that will leverage the=20
>>> availability of the segment list. v6 has good native properties=20
>>> that allow to insert explicit/source routing paradigms in the=20
>>> forwarding plane. Most of SW/HW implementations today can handle=20
>>> this without incurring HW performance penalty.
>>>=20
>>> Thanks.
>>> s.
>>=20
>>=20
>=20
> _______________________________________________
> status mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/status
>=20
>=20

Date: Thu, 12 Sep 2013 10:28:29 -0400
From: Alia Atlas <[email-masked]>
To: "Stefano Previdi (sprevidi)" <[email-masked]>
Cc: Hannes Gredler <[email-masked]>, Xuxiaohu <[email-masked]>, Rob Shakir <[email-masked]>, "[email-masked]" <[email-masked]>, Stephane Litkowski <[email-masked]>
Subject: Re: [Status] Good charter proposals from Hannes and Stefano : try to merge ...

--047d7bd76bb245fa5004e6308ddf
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: quoted-printable

Stefano,

On Thu, Sep 12, 2013 at 10:10 AM, Stefano Previdi (sprevidi) <
[email-masked]> wrote:

>
> On Sep 12, 2013, at 3:23 PM, Hannes Gredler wrote:
>
> > hi stefano,
> >
> > can you *share* your proposed 'extension header' spec ?
>
>
> when ready, yes. It's going to be submitted by Vancouver meeting.
> In the mean time, I believe we can still talk about the charter
> or is the rule that we have to spec out all details first ?
>

When you both claim
" Most of SW/HW implementations today can handle this without incurring HW
performance penalty."
and that there is interoperability testing planned for an unstandardized
version and not wanting to wait
to document use-cases that would require it, then - yes - a certain degree
of transparency is desirable.

Personally, having it work both ways
   a) all ready, interoperable, no HW penalties (on any hardware?), and
needed
   b) not ready to fully document use-cases requiring it nor the proposed
header extensions

seems like remarkable double-think. To expect everyone to accept your
assertions of (a) without any of (b)
seems unusually absurd.

If you don't even have a draft documenting the proposed 'extension header'
spec, then the claim that it
works without penalty on all HW seems like an astonishing stretch.

Finally, work on drafts and discussions should happen between meetings too.
 It's much easier to focus on
specific drafts and issues when everything else in the IETF isn't
happening.   Deciding to focus only on the deadlines
associated with IETF meetings is part of what slows the IETF down.  I
believe that isn't your goal here...  Getting
continuous work is something that I, for instance, am trying to stress in
I2RS.

Regards,
Alia

> s.
>
>
> > such that ASIC/hardware people can assess themselves:
> >
> > 1. what are the implications wrt to deployed hardware
> > 2. if there is a forwarding penalty
> >
> > /hannes
> >
> > On Sep 12, 2013, at 2:43 PM, Stefano Previdi (sprevidi) wrote:
> > [ =85 ]
> >>>>
> >>>> v6 dataplane allows more effective source route capability by
> >>>> leveraging extensions headers. Hence the proposal that will
> >>>> consist of defining a new Extension Header for SR where the
> >>>> segment list is encoded and _preserved_ throughout the path.
> >>>
> >>> What's the purpose of preserving the whole segment list throughout th=
e
> path? In other words, isn't it enough to contain the information of ingre=
ss
> and egress nodes throughout the path?
> >>
> >>
> >> there are use cases, among which OAM, that will leverage the
> >> availability of the segment list. v6 has good native properties
> >> that allow to insert explicit/source routing paradigms in the
> >> forwarding plane. Most of SW/HW implementations today can handle
> >> this without incurring HW performance penalty.
> >>
> >> Thanks.
> >> s.
> >
> >
>
> _______________________________________________
> status mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/status
>

--047d7bd76bb245fa5004e6308ddf
Content-Type: text/html; charset=windows-1252
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">Stefano,<div class=3D"gmail_extra"><br><div class=3D"gmail=
_quote">On Thu, Sep 12, 2013 at 10:10 AM, Stefano Previdi (sprevidi) <span =
dir=3D"ltr">&lt;<a href=3D"mailto:[email-masked]" target=3D"_blank">spr=
[email-masked]</a>&gt;</span> wrote:<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-=
left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;p=
adding-left:1ex"><div class=3D"im"><br>
On Sep 12, 2013, at 3:23 PM, Hannes Gredler wrote:<br>
<br>
&gt; hi stefano,<br>
&gt;<br>
&gt; can you *share* your proposed &#39;extension header&#39; spec ?<br>
<br>
<br>
</div>when ready, yes. It&#39;s going to be submitted by Vancouver meeting.=
<br>
In the mean time, I believe we can still talk about the charter<br>
or is the rule that we have to spec out all details first ?<br></blockquote=
><div><br></div><div>When you both claim</div><div>&quot;<span style=3D"col=
or:rgb(80,0,80);font-family:arial,sans-serif;font-size:13px">=A0</span><spa=
n style=3D"color:rgb(80,0,80);font-family:arial,sans-serif;font-size:13px">=
Most of SW/HW implementations today can handle=A0</span><span style=3D"colo=
r:rgb(80,0,80);font-family:arial,sans-serif;font-size:13px">this without in=
curring HW performance penalty.&quot;</span></div>
<div>and that there is interoperability testing planned for an unstandardiz=
ed version and not wanting to wait</div><div>to document use-cases that wou=
ld require it, then - yes - a certain degree of transparency is desirable.<=
/div>
<div><br></div><div>Personally, having it work both ways=A0</div><div>=A0 =
=A0a) all ready, interoperable, no HW penalties (on any hardware?), and nee=
ded</div><div>=A0 =A0b) not ready to fully document use-cases requiring it =
nor the proposed header extensions</div>
<div><br></div><div>seems like remarkable double-think. To expect everyone =
to accept your assertions of (a) without any of (b)</div><div>seems unusual=
ly absurd.</div><div><br></div><div>If you don&#39;t even have a draft docu=
menting the proposed &#39;extension header&#39; spec, then the claim that i=
t</div>
<div>works without penalty on all HW seems like an astonishing stretch.</di=
v><div><br></div><div>Finally, work on drafts and discussions should happen=
 between meetings too. =A0It&#39;s much easier to focus on</div><div>specif=
ic drafts and issues when everything else in the IETF isn&#39;t happening. =
=A0 Deciding to focus only on the deadlines</div>
<div>associated with IETF meetings is part of what slows the IETF down. =A0=
I believe that isn&#39;t your goal here... =A0Getting</div><div>continuous =
work is something that I, for instance, am trying to stress in I2RS.</div><=
div>
<br></div><div>Regards,</div><div>Alia</div><div><br></div><div><br></div><=
blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-l=
eft-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;pa=
dding-left:1ex">

<span class=3D""><font color=3D"#888888"><br>
s.<br>
</font></span><div class=3D""><div class=3D"h5"><br>
<br>
&gt; such that ASIC/hardware people can assess themselves:<br>
&gt;<br>
&gt; 1. what are the implications wrt to deployed hardware<br>
&gt; 2. if there is a forwarding penalty<br>
&gt;<br>
&gt; /hannes<br>
&gt;<br>
&gt; On Sep 12, 2013, at 2:43 PM, Stefano Previdi (sprevidi) wrote:<br>
&gt; [ =85 ]<br>
&gt;&gt;&gt;&gt;<br>
&gt;&gt;&gt;&gt; v6 dataplane allows more effective source route capability=
 by<br>
&gt;&gt;&gt;&gt; leveraging extensions headers. Hence the proposal that wil=
l<br>
&gt;&gt;&gt;&gt; consist of defining a new Extension Header for SR where th=
e<br>
&gt;&gt;&gt;&gt; segment list is encoded and _preserved_ throughout the pat=
h.<br>
&gt;&gt;&gt;<br>
&gt;&gt;&gt; What&#39;s the purpose of preserving the whole segment list th=
roughout the path? In other words, isn&#39;t it enough to contain the infor=
mation of ingress and egress nodes throughout the path?<br>
&gt;&gt;<br>
&gt;&gt;<br>
&gt;&gt; there are use cases, among which OAM, that will leverage the<br>
&gt;&gt; availability of the segment list. v6 has good native properties<br=
>
&gt;&gt; that allow to insert explicit/source routing paradigms in the<br>
&gt;&gt; forwarding plane. Most of SW/HW implementations today can handle<b=
r>
&gt;&gt; this without incurring HW performance penalty.<br>
&gt;&gt;<br>
&gt;&gt; Thanks.<br>
&gt;&gt; s.<br>
&gt;<br>
&gt;<br>
<br>
_______________________________________________<br>
status mailing list<br>
<a href=3D"mailto:[email-masked]">[email-masked]</a><br>
<a href=3D"https://www.ietf.org/mailman/listinfo/status" target=3D"_blank">=
https://www.ietf.org/mailman/listinfo/status</a><br>
</div></div></blockquote></div><br></div></div>

--047d7bd76bb245fa5004e6308ddf--

From: "Stefano Previdi (sprevidi)" <[email-masked]>
To: Hannes Gredler <[email-masked]>
Date: Thu, 12 Sep 2013 14:10:18 +0000
Accept-Language: en-US
Cc: Stephane Litkowski <[email-masked]>, Xuxiaohu <[email-masked]>, Rob Shakir <[email-masked]>, "[email-masked]" <[email-masked]>
Subject: Re: [Status] Good charter proposals from Hannes and Stefano : try to merge ...

On Sep 12, 2013, at 3:23 PM, Hannes Gredler wrote:

> hi stefano,
>=20
> can you *share* your proposed 'extension header' spec ?

when ready, yes. It's going to be submitted by Vancouver meeting.
In the mean time, I believe we can still talk about the charter=20
or is the rule that we have to spec out all details first ?

s.

> such that ASIC/hardware people can assess themselves:
>=20
> 1. what are the implications wrt to deployed hardware
> 2. if there is a forwarding penalty
>=20
> /hannes
>=20
> On Sep 12, 2013, at 2:43 PM, Stefano Previdi (sprevidi) wrote:
> [ =85 ]
>>>>=20
>>>> v6 dataplane allows more effective source route capability by
>>>> leveraging extensions headers. Hence the proposal that will
>>>> consist of defining a new Extension Header for SR where the
>>>> segment list is encoded and _preserved_ throughout the path.
>>>=20
>>> What's the purpose of preserving the whole segment list throughout the =
path? In other words, isn't it enough to contain the information of ingress=
 and egress nodes throughout the path?
>>=20
>>=20
>> there are use cases, among which OAM, that will leverage the=20
>> availability of the segment list. v6 has good native properties=20
>> that allow to insert explicit/source routing paradigms in the=20
>> forwarding plane. Most of SW/HW implementations today can handle=20
>> this without incurring HW performance penalty.
>>=20
>> Thanks.
>> s.
>=20
>=20

From: Hannes Gredler <[email-masked]>
Date: Thu, 12 Sep 2013 15:23:41 +0200
To: "Stefano Previdi (sprevidi)" <[email-masked]>
Cc: Stephane Litkowski <[email-masked]>, Xuxiaohu <[email-masked]>, Rob Shakir <[email-masked]>, "[email-masked]" <[email-masked]>
Subject: Re: [Status] Good charter proposals from Hannes and Stefano : try to merge ...

hi stefano,

can you *share* your proposed 'extension header' spec ?
such that ASIC/hardware people can assess themselves:

1. what are the implications wrt to deployed hardware
2. if there is a forwarding penalty

/hannes

On Sep 12, 2013, at 2:43 PM, Stefano Previdi (sprevidi) wrote:
[ =85 ]
>>>=20
>>> v6 dataplane allows more effective source route capability by
>>> leveraging extensions headers. Hence the proposal that will
>>> consist of defining a new Extension Header for SR where the
>>> segment list is encoded and _preserved_ throughout the path.
>>=20
>> What's the purpose of preserving the whole segment list throughout =
the path? In other words, isn't it enough to contain the information of =
ingress and egress nodes throughout the path?
>=20
>=20
> there are use cases, among which OAM, that will leverage the=20
> availability of the segment list. v6 has good native properties=20
> that allow to insert explicit/source routing paradigms in the=20
> forwarding plane. Most of SW/HW implementations today can handle=20
> this without incurring HW performance penalty.
>=20
> Thanks.
> s.

From: "Stefano Previdi (sprevidi)" <[email-masked]>
To: "John G. Scudder" <[email-masked]>
Date: Thu, 12 Sep 2013 12:53:12 +0000
Accept-Language: en-US
Cc: "<[email-masked]>" <[email-masked]>, Rob Shakir <[email-masked]>, "[email-masked]" <[email-masked]>, Hannes Gredler <[email-masked]>
Subject: Re: [Status] Good charter proposals from Hannes and Stefano : try	to merge ...

Hi John,

On Sep 11, 2013, at 8:32 PM, John G. Scudder wrote:
> Stephane,
>=20
> This seems like a very reasonable way forward to me and I think the last =
draft charter you posted is "about right".

I have some concerns.

At least, Id' like to see IPv6 explicitly mentioned.=20

s.

> In particular I want to support the idea that "the use case analysis ... =
will give us what we need to address exactly".=20
>=20
> --John
>=20
> On Sep 11, 2013, at 5:53 AM, [email-masked] wrote:
>=20
>> Hannes,
>>=20
>> Regarding "Service chaining", I would agree to not mention it directly i=
n the charter (it's not mentionned explictly in my last proposal) BUT I don=
't want to close the door to other "action types" than forwarding. That's w=
hy using the wording "node" , "steering packets" seems to be good because i=
t's large enough to address use cases that are not detailled today (for exa=
mple service chaining).
>>=20
>> So my approach would be , keep it large in definition using the proposed=
 wording and then the use case analysis (in the work items) will give us wh=
at we need to address exactly.
>>=20
>> Does it make sense for you to use this way ?
>>=20
>>=20
>> Thanks,
>>=20
>> Stephane
>>=20
>>=20
>>=20
>> -----Message d'origine-----
>> De : Hannes Gredler [mailto:[email-masked]]
>> Envoy=E9 : mercredi 11 septembre 2013 08:15
>> =C0 : Stefano Previdi
>> Cc : LITKOWSKI Stephane DTF/DERX; Rob Shakir; [email-masked]
>> Objet : Re: [Status] Good charter proposals from Hannes and Stefano : tr=
y to merge ...
>>=20
>> stefano,
>>=20
>> On Sep 10, 2013, at 7:34 PM, Stefano Previdi (sprevidi) wrote:
>>=20
>>> Hannes,
>>>=20
>>> On Sep 10, 2013, at 7:27 PM, Hannes Gredler wrote:
>>>> stefano,
>>>>=20
>>>> On Sep 10, 2013, at 6:58 PM, Stefano Previdi (sprevidi) wrote:
>>>>=20
>>>>>=20
>>>>> On Sep 10, 2013, at 1:25 PM, <[email-masked]> wrote:
>>>>>=20
>>>>>> Agree on all proposal except :
>>>>>>=20
>>>>>> "[SP] The architecture will support tunnel and non-tunnel paradigms
>>>>>> The architecture will support multiple dataplanes: MPLS and V6"
>>>>>>=20
>>>>>> I don't see the reason for this ... IMHO, the gap analysis and
>>>>>> requirements inventory will result on saying or not
>>>>>=20
>>>>>=20
>>>>> [SP] While I understand what brought the following statements
>>>>> in the proposed charter:
>>>>>   "Having identified use-cases, architecture and security,
>>>>>    the WG will identify gaps between currently available
>>>>>    technologies and use-case requirements.
>>>>>    The WG will then define requirements for extensions to
>>>>>    existing protocols or new protocols that address gaps
>>>>>    that are identified."
>>>>>=20
>>>>> I'd like to point out with better precision what are the
>>>>> directions we are ALREADY engaged into: dataplanes and
>>>>> paradigms. As I mentioned in my charter proposal, we do have
>>>>> implementations and multi-vendor interoperability tests will
>>>>> happen soon. So, I just want to be sure we don't ignore this
>>>>> reality.
>>>>=20
>>>> HG> just because you have an implementation for <foo> does not
>>>> HG> constitute
>>>> community interest. we are trying to build here a charter that
>>>> matches what a broader community wants. if the use-case that you're co=
ncerned
>>>> about (service-chaining and a new internet data plane #4) are compelli=
ng
>>>> enough the group will work on it, but mandating that into the charter,
>>>> without asking the though questions first seems a wrong start to me.
>>>=20
>>>=20
>>> [SP] Sorry to contradict but it's the exact opposite. If a group
>>>   of vendors decide to invest in implementations is because
>>>   they received, analyzed, processed a set of requirements
>>>   coming for operators who know pretty well what they do, what
>>>   they want to deploy and the technology they want the vendors
>>>   to deliver. This fits the definition of "community interest".
>>=20
>> HG> interestingly enough i haven't encountered a network operator so
>>   far who says 'i need SR for service chaining' nor
>>   we had somebody asking for this in the 'operator use case' slots
>>   in Berlin. - So who are they ? - can you manage such that
>>   they speak up and make their case ?
>>=20
>>>   My point is that I strongly _suggest_ IETF WG (any) not to
>>>   neglect these facts and not write a down a charter ...
>> [ ... ]
>>=20
>> HG> i'd like to have some proof point for your 'facts' prior
>>   to making 'service chaining' a charter item.
>>=20
>>>   Having said that, whoever does NOT believe in the benefit of
>>>   a newly proposed technology, is always free to not implement
>>>   it and to not deploy it.
>>=20
>> HG> that is fine and well understood, but since you have a desire to
>>   standardize your 'newly proposed technology' you also need to play
>>   a bit by the rules.
>>=20
>>>>>> : we must use tunnels and/or non tunnels, and the following dataplan=
es ... But I don't see the reason to put solutions directly in the charter =
...
>>>>>=20
>>>>>=20
>>>>> these are not solutions these are way to avoid boundaries in the
>>>>> framework.
>>>>>=20
>>>>> Thanks.
>>>>> s.
>>>>>=20
>>>>>=20
>>>>>> Could you explain your point ?
>>>>>>=20
>>>>>>=20
>>>>>> updated with the other comments :
>>>>>>=20
>>>>>> -------------------------------------------------------------------
>>>>>> Name: <TBD>
>>>>>> Charter:
>>>>>>=20
>>>>>>=20
>>>>>> Introduction
>>>>>> ------------
>>>>>> The following use cases:
>>>>>> . Path computation based on awareness of utilization or performance
>>>>>> data, within both centralized and distributed environments, . Multi-=
topology (dual planes, disjoint trees), . Simplification and reduction of s=
ignaling components (scaling), . Combined application and network layer pat=
h specification, . Full coverage LFA-FRR, . Topology Aware OAM, . etc.
>>>>>>=20
>>>>>> have triggered work on the definition of new architecture and protoc=
ol extensions allowing to combine well known shortest path based routing pa=
radigms with source/explicit routing methods. Some of these extensions have=
 been implemented already.
>>>>>>=20
>>>>>>=20
>>>>>> Objective
>>>>>> ---------
>>>>>>=20
>>>>>> Define an architecture where a node can steer a packet through a net=
work or set of networks (interdomain) on any path without requiring to main=
tain state along the path, other than in the ingress node.
>>>>>>=20
>>>>>> A node may be any type of device including routers or appliances.
>>>>>>=20
>>>>>> In this architecture, nodes sharing a common trust model form a <Nam=
e-TBD> domain. The architecture defined by this working group will allow a =
node to steer a packet between any source and destination node within the <=
Name-TBD> domain (formed of one or more networks), on any path (shortest, n=
on-shortest, explicit or based on other characteristics specified by segmen=
t identifiers).
>>>>>>=20
>>>>>> It may then send any packet that passes through it through any path
>>>>>> that it has specified and that is conform to the security rules.
>>>>>> Downstream nodes along the path within the <Name-TBD> domain
>>>>>> forward the packet by using the informations inserted by the node
>>>>>> at the head-end
>>>>>>=20
>>>>>> The architecture should support centralized and distributed path com=
putation.
>>>>>>=20
>>>>>> The architecture should support OAM functions.
>>>>>>=20
>>>>>> The architecture should allow different mechanisms through which  a
>>>>>> path is constructed. SR allows a variety of mechanisms, not
>>>>>> confined IGP/BGP path computation.
>>>>>>=20
>>>>>> As MPLS dataplane is largely deployed, the <Name-TBD> WG should avoi=
d any modification in the MPLS dataplane when defining the architecture.
>>>>>>=20
>>>>>>=20
>>>>>> Work items :
>>>>>> ------------------
>>>>>>=20
>>>>>> The <Name-TBD> working group is chartered for the following ordered =
list of work items:
>>>>>>=20
>>>>>> - The first goal of the WG is to identify use-cases.
>>>>>> - The WG will then define the architecture framework associated
>>>>>> with the security considerations. The architecture framework and
>>>>>> security considerations must address the relations between networks =
forming the <Name-TBD> domain (interAS).
>>>>>> - Having identified use-cases, architecture and security, the WG
>>>>>> will identify gaps between currently available technologies and
>>>>>> use-case requirements.
>>>>>> - The WG will then define requirements for extensions to existing
>>>>>> protocols or new protocols that address gaps that are identified.
>>>>>> - The WG will first focus on the intra-domain forwarding definition.
>>>>>>=20
>>>>>>=20
>>>>>> Documents :
>>>>>> ------------------
>>>>>> . Use Cases
>>>>>> . Architecture including security considerations
>>>>>> - Protocol extension requirements
>>>>>> . Interoperability Report
>>>>>>=20
>>>>>>=20
>>>>>> Required protocol extensions are carried out in working groups respo=
nsible (ISIS,OSPF,BGP,PCEP ...). Work on new protocols may be carried out b=
y the <Name-TBD> WG.
>>>>>>=20
>>>>>> -----Message d'origine-----
>>>>>> De : Stefano Previdi (sprevidi) [mailto:[email-masked]] Envoy=E9
>>>>>> : mardi 10 septembre 2013 12:30 =C0 : LITKOWSKI Stephane DTF/DERX;
>>>>>> Rob Shakir Cc : Hannes Gredler; [email-masked] Objet : Re:
>>>>>> [Status] Good charter proposals from Hannes and Stefano : try to mer=
ge ...
>>>>>>=20
>>>>>> Hi Stephane, Rob,
>>>>>>=20
>>>>>> one preliminary remark: I prefer to use he therm "node" rather than =
"router". Use cases, such as Service Chaining requires that terminology.
>>>>>>=20
>>>>>> some other comments below...
>>>>>>=20
>>>>>>=20
>>>>>> On Sep 10, 2013, at 11:19 AM, <[email-masked]> wrote:
>>>>>>> Souns good to me, (adding OAM also)
>>>>>>>=20
>>>>>>> New recap :
>>>>>>>=20
>>>>>>> ------------------------------------------------------------------
>>>>>>> -
>>>>>>> Name: <TBD>
>>>>>>> Charter:
>>>>>>>=20
>>>>>>>=20
>>>>>>> Introduction
>>>>>>> ------------
>>>>>>> The following use cases:
>>>>>>> . Path computation based on awareness of utilization or
>>>>>>> performance data, within both centralized and distributed environme=
nts, . Multi-topology (dual planes, disjoint trees), . Simplification and r=
eduction of signaling components (scaling), . Combined application and netw=
ork layer path specification, . Full coverage LFA-FRR, . Topology Aware OAM=
, . etc.
>>>>>>>=20
>>>>>>> have triggered work on the definition of new architecture and proto=
col extensions allowing to combine well known shortest path based routing p=
aradigms with source/explicit routing methods. Some of these extensions hav=
e been implemented already.
>>>>>>>=20
>>>>>>>=20
>>>>>>> Objective
>>>>>>> ---------
>>>>>>>=20
>>>>>>> Define an architecture where a node can steer a packet through a ne=
twork or set of networks (interdomain) on any path.
>>>>>>=20
>>>>>>=20
>>>>>> [SP] As stated above, I'm fine with the above definition but I
>>>>>> assume this includes service chaining and that by "network  or set
>>>>>> of networks" you intend "nodes" which may include  others things
>>>>>> than just routers.
>>>>>>=20
>>>>>> [SLI] Agree
>>>>>>=20
>>>>>>=20
>>>>>>> In this architecture, routers sharing a common trust model form a <=
Name-TBD> domain. The architecture defined by this working group will allow=
 a node to steer a packet between any source and destination node within th=
e <Name-TBD> domain (formed of one or more networks), on any path (shortest=
, non-shortest, explicit or based on other characteristics specified by seg=
ment identifiers).
>>>>>>=20
>>>>>>=20
>>>>>> [SP] without requiring to maintain state along the path, other
>>>>>> than in the ingress node.
>>>>>>=20
>>>>>> [SLI] Agree
>>>>>>=20
>>>>>>=20
>>>>>>> It may then send any packet that passes through it through any path=
 that it has specified and that is conform to the security rules. Downstrea=
m routers along the path within the <Name-TBD> domain forward the packet as=
 specified by the router at the head-end of the path.
>>>>>>=20
>>>>>>>=20
>>>>>>> The architecture should support centralized and distributed path co=
mputation.
>>>>>>>=20
>>>>>>> The architecture should support OAM functions.
>>>>>>=20
>>>>>>=20
>>>>>> [SP] The architecture should allow different mechanisms through
>>>>>> which  a path is constructed. SR allows a variety of mechanisms,
>>>>>> not  confined IGP/BGP path computation.
>>>>>>=20
>>>>>> [SLI] Agree
>>>>>>=20
>>>>>>> Work items :
>>>>>>> ------------------
>>>>>>>=20
>>>>>>> The <Name-TBD> working group is chartered for the following ordered=
 list of work items:
>>>>>>>=20
>>>>>>> - The first goal of the WG is to identify use-cases.
>>>>>>> - The WG will then define the architecture framework associated
>>>>>>> with the security considerations. The architecture framework and
>>>>>>> security considerations must address the relations between networks=
 forming the <Name-TBD> domain (interAS).
>>>>>>> - Having identified use-cases, architecture and security, the WG
>>>>>>> will identify gaps between currently available technologies and
>>>>>>> use-case requirements.
>>>>>>> - The WG will then define requirements for extensions to existing
>>>>>>> protocols or new protocols that address gaps that are identified.
>>>>>>> - The WG will first focus on the intra-domain forwarding definition=
.
>>>>>>=20
>>>>>>=20
>>>>>> [SP] The architecture will support tunnel and non-tunnel paradigms
>>>>>> The architecture will support multiple dataplanes: MPLS and V6
>>>>>>=20
>>>>>>=20
>>>>>> Thanks.
>>>>>> s.
>>>>>>=20
>>>>>>=20
>>>>>>> Documents :
>>>>>>> ------------------
>>>>>>> . Use Cases
>>>>>>> . Architecture including security considerations
>>>>>>> - Protocol extension requirements
>>>>>>> . Interoperability Report
>>>>>>>=20
>>>>>>>=20
>>>>>>> Protocol work may be carried out in this working group or in other =
working groups responsible for the protocols (ISIS,OSPF,BGP,PCEP ...), in c=
oordination with this WG, and in agreement with the WG chairs and responsib=
le ADs.
>>>>>>>=20
>>>>>>> -----Message d'origine-----
>>>>>>> De : Rob Shakir [mailto:[email-masked]] Envoy=E9 : mardi 10 septembre
>>>>>>> 2013 11:05 =C0 : LITKOWSKI Stephane DTF/DERX Cc : Hannes Gredler;
>>>>>>> Stefano Previdi (sprevidi); [email-masked] Objet
>>>>>>> : Re: [Status] Good charter proposals from Hannes and Stefano : try=
 to merge ...
>>>>>>>=20
>>>>>>> Hi Stephane,
>>>>>>>=20
>>>>>>> Thanks for this, looks good! Comments in-line marked rjs>.
>>>>>>>=20
>>>>>>> On 10 Sep 2013, at 08:50, <[email-masked]> wrote:
>>>>>>>=20
>>>>>>>> Hi all,
>>>>>>>>=20
>>>>>>>> I'm creating a new mail topic because the "Summary of STATUS BOF .=
.."
>>>>>>>> starts to be unreadable :)
>>>>>>>>=20
>>>>>>>> Hannes and Stefano send to us two charter proposals that sounds go=
od to me.
>>>>>>>>=20
>>>>>>>> The main difference between the two proposals is that Stefano prop=
ose a segment bound to any type of instruction (forwarding, application or =
service based) while Hannes is focusing on forwarding actions (which is the=
 first priority, and I think everybody agree on this).
>>>>>>>=20
>>>>>>> rjs> Agreed -- I think it would be useful to allow definitions of s=
egments to identify different types of "service", since there appear to be =
some use cases (e.g., the explicit exit selection case) which require a seg=
ment type describing something that is not explicitly IGP-based.
>>>>>>>=20
>>>>>>>>=20
>>>>>>>> It would be interresting to have a feedback from the mailinglist o=
n this specific point.
>>>>>>>>=20
>>>>>>>> IMHO, there is a strong interrest to explore the service actions b=
ound to segment in a second step keeping forwarding as a priority.
>>>>>>>>=20
>>>>>>>> Apart of this problem, here is a merge try of the two good proposa=
ls (I'm putting '<>' on hot topics :) ) :
>>>>>>>>=20
>>>>>>>>=20
>>>>>>>> -----------------------------------------------------------------
>>>>>>>> --
>>>>>>>> Name: <TBD>
>>>>>>>> Charter:
>>>>>>>>=20
>>>>>>>>=20
>>>>>>>> Introduction
>>>>>>>> ------------
>>>>>>>> The following use cases:
>>>>>>>> . Path computation based on awareness of utilization or
>>>>>>>> performance data, within both centralized and distributed environm=
ents, . Multi-topology (dual planes, disjoint trees), . Simplification and =
reduction of signaling components (scaling), . Combined application and net=
work layer path specification, . Full coverage LFA-FRR, . Topology Aware OA=
M, . etc.
>>>>>>>>=20
>>>>>>>> have triggered work on the definition of new architecture and prot=
ocol extensions allowing to combine well known shortest path based routing =
paradigms with source/explicit routing methods. Some of these extensions ha=
ve been implemented already.
>>>>>>>>=20
>>>>>>>>=20
>>>>>>>> Objective
>>>>>>>> ---------
>>>>>>>>=20
>>>>>>>> Define an architecture where a node can steer a packet through a n=
etwork or set of networks (interdomain) on any path (shortest, non shortest=
, explicit, <service or application>).
>>>>>>>>=20
>>>>>>>> In this architecture, routers are sharing a common trust model and=
 are forming a <Name-TBD> domain.
>>>>>>>> Within this domain, a node can specify a path between itself and a=
ny destination in the domain. <The path may be a forwarding path, a service=
 chaining path or a combination of both>.
>>>>>>>=20
>>>>>>> rjs> To clarify here, we define that our domain is under a common t=
rust model (essentially, under common administrative control?), but then go=
 on to talk about inter-domain elsewhere. Can we perhaps clarify (by defini=
ng a specific "<Name-TBD> domain" nomenclature) and say something like:
>>>>>>>=20
>>>>>>> "In this architecture, routers sharing a common trust model form a =
<Name-TBD> domain. The architecture defined by this working group will allo=
w a node to steer a packet between any source and destination node within t=
he <Name-TBD> domain (formed of one or more networks), on any path (shortes=
t, non-shortest, explicit or based on other characteristics specified by se=
gment identifiers)."
>>>>>>>=20
>>>>>>>> It may then send any packet that passes through it through any pat=
h that it has specified and that is conform to the security rules. Downstre=
am routers along the path within the <Name-TBD> domain forward the packet a=
s specified by the router at the head-end of the path.
>>>>>>>>=20
>>>>>>>> The architecture should support centralized and distributed path c=
omputation.
>>>>>>>>=20
>>>>>>>>=20
>>>>>>>> Work items :
>>>>>>>> ------------------
>>>>>>>>=20
>>>>>>>> The <Name-TBD> working group is chartered for the following ordere=
d list of work items:
>>>>>>>>=20
>>>>>>>> - The first goal of the WG is to identify use-cases.
>>>>>>>> - The WG will then define the architecture framework associated
>>>>>>>> with the security considerations. The architecture framework and
>>>>>>>> security considerations must address the relations between domains=
 (inter domain).
>>>>>>>=20
>>>>>>> rjs> And then here "networks forming the <Name-TBD> domain"?
>>>>>>>=20
>>>>>>> Thanks for the efforts,
>>>>>>> r.
>>>>>>>=20
>>>>>>>> - Having identified use-cases, architecture and security, the WG
>>>>>>>> will identify gaps between currently available technologies and
>>>>>>>> use-case requirements.
>>>>>>>> - The WG will then define requirements for extensions to existing
>>>>>>>> protocols or new protocols that address gaps that are identified.
>>>>>>>> - The WG will first focus on the intra-domain forwarding definitio=
n.
>>>>>>>>=20
>>>>>>>>=20
>>>>>>>> Documents :
>>>>>>>> ------------------
>>>>>>>> . Use Cases
>>>>>>>> . Architecture including security considerations
>>>>>>>> - Protocol extension requirements . Interoperability Report
>>>>>>>>=20
>>>>>>>>=20
>>>>>>>> Protocol work may be carried out in this working group or in other=
 working groups responsible for the protocols (ISIS,OSPF,BGP,PCEP ...), in =
coordination with this WG, and in agreement with the WG chairs and responsi=
ble ADs.
>>>>>>>>=20
>>>>>>>>=20
>>>>>>>>=20
>>>>>>>> Hope it helps to progress on the definition.
>>>>>>>>=20
>>>>>>>>=20
>>>>>>>> Stephane
>>>>>>>>=20
>>>>>>>>=20
>>>>>>>> -----Message d'origine-----
>>>>>>>> De : Hannes Gredler [mailto:[email-masked]] Envoy=E9 : vendred=
i
>>>>>>>> 6 septembre 2013 18:27 =C0 : LITKOWSKI Stephane DTF/DERX Cc :
>>>>>>>> [email-masked] Objet : Re: [Status] Summary of STATUS BOF and
>>>>>>>> the next steps
>>>>>>>>=20
>>>>>>>> hi stephane,
>>>>>>>>=20
>>>>>>>> here is a revised draft charter as per your comments.
>>>>>>>>=20
>>>>>>>> ---
>>>>>>>>=20
>>>>>>>> <Name-TBD> domain contains a set of routers with the following
>>>>>>>> characteristics:
>>>>>>>>=20
>>>>>>>> - They form a connected network
>>>>>>>> - They can forward traffic through any path within the network
>>>>>>>> using shortest path, or any other (e.g., an explicit) path
>>>>>>>> - They share a common trust model. In this model, any router
>>>>>>>> within the domain can specify a path between itself and any other
>>>>>>>> router  in the domain. It may then send any packet that passes
>>>>>>>> through it through any path that it has specified and that is
>>>>>>>> conform to the security rules. Downstream routers along the path
>>>>>>>> within the <Name-TBD>  domain forward the packet as specified by
>>>>>>>> the router at the head-end  of the path.
>>>>>>>>=20
>>>>>>>> The <Name-TBD> working group is chartered for the following ordere=
d list of work items:
>>>>>>>>=20
>>>>>>>> - The first goal of the WG is to identify use-cases.
>>>>>>>> - The WG will then define the architecture framework associated
>>>>>>>> with the security considerations. The architecture framework and
>>>>>>>> security considerations must address the relations between domains=
 (interdomain).
>>>>>>>> - Having identified use-cases, architecture and security, the WG
>>>>>>>> will identify gaps between currently available technologies and
>>>>>>>> use-case requirements.
>>>>>>>> - The WG will then define requirements for extensions to existing
>>>>>>>> protocols or new protocols that address gaps that are identified.
>>>>>>>> - The WG will first focus on the intra-domain forwarding definitio=
n.
>>>>>>>>=20
>>>>>>>> Protocol work may be carried out in this working group or in other=
 working groups responsible for the protocols, in coordination with this WG=
, and in agreement with the WG chairs and responsible ADs.
>>>>>>>> However, no protocol work will be adopted by a working group to ad=
dress the identified use-cases until the requirements document motivating t=
he protocol work has been sent to the IESG for publication as an RFC.
>>>>>>>>=20
>>>>>>>> ---
>>>>>>>>=20
>>>>>>>> /hannes
>>>>>>>>=20
>>>>>>>> On Sep 4, 2013, at 10:02 AM, <[email-masked]> <step=
[email-masked]> wrote:
>>>>>>>>=20
>>>>>>>>> Hannes,
>>>>>>>>>=20
>>>>>>>>> In case, we are using only directed forwarding (adjacency
>>>>>>>>> segment), could we still talk about tunneling ? (it's a very very=
 small tunnel) Moreover talking about "stacking" is really dataplane agnost=
ic (MPLS) ...
>>>>>>>>>=20
>>>>>>>>> In the proposed segment routing architectural concepts, segments =
are at the same "level" and pointer moves on the segment list, then the MPL=
S instantiation is performing this using stacking ...
>>>>>>>>>=20
>>>>>>>>> IMHO, if we use "Stacked Tunnels", we already talk about a chosen=
 solution and it's closing the door to something else  ...
>>>>>>>>>=20
>>>>>>>>> Finally, about the "routing" word, routing is essentially a "forw=
ard" action which may limit the scope of what we can do by using a segment =
list. Actions associated with a segment could be something else than forwar=
ding.
>>>>>>>>>=20
>>>>>>>>> Do we want in the charter to limit the scope to routing actions ?
>>>>>>>>>=20
>>>>>>>>> I have no solution today to propose for the naming, but I complet=
ely agree with Loa, to first focus on working on the charter, and define a =
clear scope of the work and then the name will be easier to find.
>>>>>>>>>=20
>>>>>>>>> Regarding your charter proposal :
>>>>>>>>>=20
>>>>>>>>> --------
>>>>>>>>>=20
>>>>>>>>> - They form a connected network
>>>>>>>>> [SLI] InterAS case must be included, but the WG can go step by st=
ep and first release intraAS, and then doing interAS (in relation with IDR =
??).
>>>>>>>>>=20
>>>>>>>>> - They can forward traffic through the shortest paths or paths
>>>>>>>>> other than the shortest (the latter called explicitly routed path=
s, or explicit paths)  [SLI] There is something else between SPT and Explic=
it path, you can define other algorithms than SPT to define a path, and it'=
s not explicit path. Moreover I come back to my comment, on do we want to l=
imit the scope to routing ? I would say no.
>>>>>>>>>=20
>>>>>>>>> - They share a common trust model. In this model, any router with=
in the ERD can specify an explicit path between itself and any other router=
 in the ERD. It can then send any packet that passes through it through any=
 path that it has specified.
>>>>>>>>> [SLI] Security considerations may have to be addressed in the
>>>>>>>>> charter , especially for the interAS case (trust yes, but not
>>>>>>>>> sure access to everything may not be good)
>>>>>>>>>=20
>>>>>>>>> Downstream routers within the ERD forward the packet as specified=
 by the router at the head-end of the path.
>>>>>>>>> [SLI] Yes, but any router in the middle may be able to change the=
 end to end explicit path.
>>>>>>>>>=20
>>>>>>>>>=20
>>>>>>>>>=20
>>>>>>>>> - The first goal of the STER WG is to identify use-cases for ERDs=
.
>>>>>>>>> - Having identified use-cases, the WG will identify gaps between =
currently available technologies and use-case requirements.
>>>>>>>>> - The WG will then define requirements for extensions to existing=
 protocols or new protocols that address gaps that are identified.
>>>>>>>>>=20
>>>>>>>>> [SLI] Agree, I would add :
>>>>>>>>> - defining the architecture framework
>>>>>>>>> - analysing the security considerisations
>>>>>>>>>=20
>>>>>>>>>=20
>>>>>>>>> ---------
>>>>>>>>>=20
>>>>>>>>>=20
>>>>>>>>> Here would be my proposal to extend yours :
>>>>>>>>>=20
>>>>>>>>> A <named to be defined> domain contains a set of routers with the=
 following characteristics:
>>>>>>>>>=20
>>>>>>>>> - They form a connected network
>>>>>>>>> - They can forward traffic through any path within the network
>>>>>>>>> using shortest path, non shortest path or explicit path
>>>>>>>>> - They may provide other types of services than forwarding and th=
ey can enforce service actions in the path.
>>>>>>>>> - They share a common trust model. In this model, any router with=
in the domain can specify a path between itself and any other router in the=
 domain. It may then send any packet that passes through it through any pat=
h that it has specified and that is conform to the security rules. Downstre=
am routers within the ERD forward the packet as specified by the router at =
the head-end of the path.
>>>>>>>>>=20
>>>>>>>>> The <name> working group is chartered for the following ordered l=
ist of work items:
>>>>>>>>>=20
>>>>>>>>> - The first goal of the WG is to identify use-cases.
>>>>>>>>> - The WG will then define the architecture framework associated w=
ith the security considerations. The architecture framework and security co=
nsiderations must address the relations between domains (interdomain).
>>>>>>>>> - Having identified use-cases, architecture and security, the WG =
will identify gaps between currently available technologies and use-case re=
quirements.
>>>>>>>>> - The WG will then define requirements for extensions to existing=
 protocols or new protocols that address gaps that are identified.
>>>>>>>>> - The WG will first focus on the intra-domain forwarding definiti=
on.
>>>>>>>>>=20
>>>>>>>>> Protocol work may be carried out in this working group or in othe=
r working groups responsible for the protocols, in coordination with this W=
G, and in agreement with the WG chairs and responsible ADs. However, no pro=
tocol work will be adopted by a working group to address the ERD use-cases =
until the requirements document motivating the protocol work has been sent =
to the IESG for publication as an RFC.
>>>>>>>>>=20
>>>>>>>>> -----Message d'origine-----
>>>>>>>>> De : [email-masked] [mailto:[email-masked]] De
>>>>>>>>> la part de Hannes Gredler Envoy=E9 : mardi 3 septembre 2013 18:31
>>>>>>>>> =C0 : Loa Andersson Cc : [email-masked] Objet : Re: [Status]
>>>>>>>>> Summary of STATUS BOF and the next steps
>>>>>>>>>=20
>>>>>>>>> good point - what about this charter proposal ?
>>>>>>>>>=20
>>>>>>>>> ---
>>>>>>>>>=20
>>>>>>>>> Stacked Tunnels for Explicit Routing (STER)
>>>>>>>>> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
>>>>>>>>>=20
>>>>>>>>> A explicit routing domain (ERD) contains a set of routers with th=
e following characteristics:
>>>>>>>>>=20
>>>>>>>>> - They form a connected network
>>>>>>>>> - They can forward traffic through the shortest paths or paths
>>>>>>>>> other than the shortest (the latter called explicitly routed
>>>>>>>>> paths, or explicit paths)
>>>>>>>>> - They share a common trust model. In this model, any router with=
in the ERD can specify an explicit path between itself and any other router=
 in the ERD. It can then send any packet that passes through it through any=
 path that it has specified. Downstream routers within the ERD forward the =
packet as specified by the router at the head-end of the path.
>>>>>>>>>=20
>>>>>>>>> The STER working group is chartered for the following ordered lis=
t of work items:
>>>>>>>>>=20
>>>>>>>>> - The first goal of the STER WG is to identify use-cases for ERDs=
.
>>>>>>>>> - Having identified use-cases, the WG will identify gaps between =
currently available technologies and use-case requirements.
>>>>>>>>> - The WG will then define requirements for extensions to existing=
 protocols or new protocols that address gaps that are identified.
>>>>>>>>>=20
>>>>>>>>> Protocol work may be carried out in this working group or in othe=
r working groups responsible for the protocols, in coordination with this W=
G, and in agreement with the WG chairs and responsible ADs. However, no pro=
tocol work will be adopted by a working group to address the ERD use-cases =
until the requirements document motivating the protocol work has been sent =
to the IESG for publication as an RFC.
>>>>>>>>>=20
>>>>>>>>> ---
>>>>>>>>>=20
>>>>>>>>> <flame suit on>
>>>>>>>>>=20
>>>>>>>>> /hannes
>>>>>>>>>=20
>>>>>>>>>=20
>>>>>>>>> On Sep 3, 2013, at 5:31 PM, Loa Andersson wrote:
>>>>>>>>>=20
>>>>>>>>>> Folks,
>>>>>>>>>>=20
>>>>>>>>>> Excuse me if I'm slightly out of the loop, but so far I have
>>>>>>>>>> not seen a charter proposal, if there is one please point me to =
it.
>>>>>>>>>>=20
>>>>>>>>>> It seems a bit odd to put the cart (what the wg should do)
>>>>>>>>>> before the horse (wg name). If we drill down the the charter
>>>>>>>>>> first the wg name might be easier to figure out.
>>>>>>>>>>=20
>>>>>>>>>> /Loa
>>>>>>>>>>=20
>>>>>>>>>> PS
>>>>>>>>>> OK I understand that the horse and cart analogy limps a  bit :).
>>>>>>>>>>=20
>>>>>>>>>>=20
>>>>>>>>>>=20
>>>>>>>>>> On 2013-09-03 17:22, AshwoodsmithPeter wrote:
>>>>>>>>>>> " If the WG charter is limited to source routing, how will we h=
andle the "non source routing" use cases of segment routing ? In another wo=
rking group ? So we will go back to the WG synchronization issue that has b=
een raised for this technology ..."
>>>>>>>>>>>=20
>>>>>>>>>>> That's why I suggested SRV2. We are revisiting source routing w=
ith new concepts. More generic number/action behavior.
>>>>>>>>>>>=20
>>>>>>>>>>> Peter
>>>>>>>>>>>=20
>>>>>>>>>>> -----Original Message-----
>>>>>>>>>>> From: [email-masked] [mailto:[email-masked]]
>>>>>>>>>>> On Behalf Of [email-masked]
>>>>>>>>>>> Sent: Tuesday, September 03, 2013 10:43 AM
>>>>>>>>>>> To: AshwoodsmithPeter
>>>>>>>>>>> Cc: [email-masked]
>>>>>>>>>>> Subject: Re: [Status] Summary of STATUS BOF and the next steps
>>>>>>>>>>>=20
>>>>>>>>>>>=20
>>>>>>>>>>> There was a misunderstanding in my small comment :) so I will e=
xplain more :
>>>>>>>>>>>=20
>>>>>>>>>>> In segment routing, you have more than basic source routing : s=
egment routing is just associate a segment number to an action and then com=
bine segment as you want, yes you can do source routing, but you also can d=
o more.
>>>>>>>>>>>=20
>>>>>>>>>>> In the other hand, I completely agree with your statement that
>>>>>>>>>>> source routing is generic and dataplane agnostic, as segment ro=
uting is ...
>>>>>>>>>>> (segment routing is not a new dataplane ...)
>>>>>>>>>>>=20
>>>>>>>>>>> Now the definition of the WG naming must be inline with the
>>>>>>>>>>> charter that will be defined ... (draft today)
>>>>>>>>>>>=20
>>>>>>>>>>> Based on the already existing consensus (at least for MPLS data=
plane) brought up during Berlin STATUS BOF meeting, segment routing sounds =
to be a good target candidate.
>>>>>>>>>>>=20
>>>>>>>>>>> So now, do we want to do more in the WG charter than just make =
progressing segment routing architecture and uses cases document and ensure=
 coordination for the standardization of this technology ?
>>>>>>>>>>>=20
>>>>>>>>>>> Do we want to standardize other technologies in this WG ? I don=
't think so, based on Stewart's conclusion email from the BOF :"A new WG fo=
cused solely on SR therefore needs to be create"
>>>>>>>>>>>=20
>>>>>>>>>>> If the WG charter is limited to source routing, how will we han=
dle the "non source routing" use cases of segment routing ? In another work=
ing group ? So we will go back to the WG synchronization issue that has bee=
n raised for this technology ...
>>>>>>>>>>>=20
>>>>>>>>>>> If the WG is focused on SR, let's use a name in relation with S=
R.
>>>>>>>>>>>=20
>>>>>>>>>>> Feedback ?
>>>>>>>>>>>=20
>>>>>>>>>>>=20
>>>>>>>>>>> Stephane
>>>>>>>>>>>=20
>>>>>>>>>>>=20
>>>>>>>>>>> -----Message d'origine-----
>>>>>>>>>>> De : AshwoodsmithPeter [mailto:[email-masked]]
>>>>>>>>>>> Envoy=E9 : mardi 3 septembre 2013 15:27 =C0 : LITKOWSKI Stephan=
e
>>>>>>>>>>> DTF/DERX Cc : John E Drake; Mark Townsley; Victor Kuarsingh;
>>>>>>>>>>> Roberta Maglione (robmgl); John G. Scudder; Adrian Farrel;
>>>>>>>>>>> Alvaro Retana (aretana); [email-masked]; Stewart Bryant (stbry=
ant) Objet : Re:
>>>>>>>>>>> [Status] Summary of STATUS BOF and the next steps
>>>>>>>>>>>=20
>>>>>>>>>>> The term "source routing" has been around for a very long time =
and is data path agnostic. Its also the term used in the literature etc so =
my preference is to stick with this existing well known and data path agnos=
tic term.
>>>>>>>>>>>=20
>>>>>>>>>>> Peter
>>>>>>>>>>>=20
>>>>>>>>>>> On Sep 3, 2013, at 9:07 AM, "[email-masked]" <st=
[email-masked]> wrote:
>>>>>>>>>>>=20
>>>>>>>>>>>> Hi,
>>>>>>>>>>>>=20
>>>>>>>>>>>> "Source routing" is just a subcase of segment routing ... as i=
t is for IP routing ...
>>>>>>>>>>>>=20
>>>>>>>>>>>> Stephane
>>>>>>>>>>>>=20
>>>>>>>>>>>>=20
>>>>>>>>>>>> -----Message d'origine-----
>>>>>>>>>>>> De : [email-masked] [mailto:[email-masked]]
>>>>>>>>>>>> De la part de John E Drake Envoy=E9 : mardi 3 septembre 2013 1=
5:02 =C0 :
>>>>>>>>>>>> Mark Townsley; Victor Kuarsingh Cc : Roberta Maglione (robmgl)=
; John G.
>>>>>>>>>>>> Scudder; Alvaro Retana (aretana); Adrian Farrel;
>>>>>>>>>>>> [email-masked]; Stewart Bryant (stbryant) Objet : Re:
>>>>>>>>>>>> [Status] Summary of STATUS BOF and the next steps
>>>>>>>>>>>>=20
>>>>>>>>>>>> Hi,
>>>>>>>>>>>>=20
>>>>>>>>>>>> What is this 'segment routing' silliness?  The correct term is=
 'source routing'.
>>>>>>>>>>>>=20
>>>>>>>>>>>> Yours Irrespectively,
>>>>>>>>>>>>=20
>>>>>>>>>>>> John
>>>>>>>>>>>>=20
>>>>>>>>>>>>> -----Original Message-----
>>>>>>>>>>>>> From: [email-masked]
>>>>>>>>>>>>> [mailto:[email-masked]] On Behalf Of Mark Townsley
>>>>>>>>>>>>> Sent: Sunday, September 01, 2013 10:08 AM
>>>>>>>>>>>>> To: Victor Kuarsingh
>>>>>>>>>>>>> Cc: Roberta Maglione (robmgl); John G. Scudder; Adrian
>>>>>>>>>>>>> Farrel; Alvaro Retana (aretana); [email-masked]; Stewart
>>>>>>>>>>>>> Bryant
>>>>>>>>>>>>> (stbryant)
>>>>>>>>>>>>> Subject: Re: [Status] Summary of STATUS BOF and the next
>>>>>>>>>>>>> steps
>>>>>>>>>>>>>=20
>>>>>>>>>>>>>=20
>>>>>>>>>>>>> On Sep 1, 2013, at 5:38 PM, Victor Kuarsingh wrote:
>>>>>>>>>>>>>=20
>>>>>>>>>>>>>> All,
>>>>>>>>>>>>>>=20
>>>>>>>>>>>>>> I would also favour "Segment Routing WG" as well.
>>>>>>>>>>>>>>=20
>>>>>>>>>>>>>> I note this since attempting to come up with an all
>>>>>>>>>>>>>> encompassing acronym will be difficult and Segment Routing
>>>>>>>>>>>>>> is generic enough to associate to multiple functions.
>>>>>>>>>>>>>=20
>>>>>>>>>>>>> Then we can just use "segroute" for the short name. WGs do
>>>>>>>>>>>>> not have to have acronyms, but they do need to have an
>>>>>>>>>>>>> 8-char limited short name for the various automated tools not=
 to break.
>>>>>>>>>>>>>=20
>>>>>>>>>>>>> - Mark
>>>>>>>>>>>>>=20
>>>>>>>>>>>>>>=20
>>>>>>>>>>>>>> Regards,
>>>>>>>>>>>>>>=20
>>>>>>>>>>>>>> Victor K
>>>>>>>>>>>>>>=20
>>>>>>>>>>>>>>=20
>>>>>>>>>>>>>>=20
>>>>>>>>>>>>>> On 2013-08-31 6:51 PM, "Roberta Maglione (robmgl)"
>>>>>>>>>>>>>> <[email-masked]>
>>>>>>>>>>>>>> wrote:
>>>>>>>>>>>>>>=20
>>>>>>>>>>>>>>> +1 for Segment Routing WG
>>>>>>>>>>>>>>>=20
>>>>>>>>>>>>>>> Roberta
>>>>>>>>>>>>>>>=20
>>>>>>>>>>>>>>> Sent from my iPad
>>>>>>>>>>>>>>>=20
>>>>>>>>>>>>>>> On 2013-08-30, at 2:55 PM, "Alvaro Retana (aretana)"
>>>>>>>>>>>>>>> <[email-masked]>
>>>>>>>>>>>>>>> wrote:
>>>>>>>>>>>>>>>=20
>>>>>>>>>>>>>>>> Segment Routing WG
>>>>>>>>>>>>>>>>=20
>>>>>>>>>>>>>>>> Sent from my iPhone
>>>>>>>>>>>>>>>>=20
>>>>>>>>>>>>>>>> On Aug 30, 2013, at 1:39 PM, "Stewart Bryant (stbryant)"
>>>>>>>>>>>>>>>> <[email-masked]> wrote:
>>>>>>>>>>>>>>>>=20
>>>>>>>>>>>>>>>>> The second task, which hopefully should be relatively
>>>>>>>>>>>>>>>>> easy, is to find a better working name for the WG, since
>>>>>>>>>>>>>>>>> it has been put to me a number of times that STATUS is
>>>>>>>>>>>>>>>>> going to be confusing in text and a difficult search term=
.
>>>>>>>>>>>>>>>> _______________________________________________
>>>>>>>>>>>>>>>> status mailing list
>>>>>>>>>>>>>>>> [email-masked]
>>>>>>>>>>>>>>>> https://www.ietf.org/mailman/listinfo/status
>>>>>>>>>>>>>>> _______________________________________________
>>>>>>>>>>>>>>> status mailing list
>>>>>>>>>>>>>>> [email-masked]
>>>>>>>>>>>>>>> https://www.ietf.org/mailman/listinfo/status
>>>>>>>>>>>>>>=20
>>>>>>>>>>>>>>=20
>>>>>>>>>>>>>> _______________________________________________
>>>>>>>>>>>>>> status mailing list
>>>>>>>>>>>>>> [email-masked]
>>>>>>>>>>>>>> https://www.ietf.org/mailman/listinfo/status
>>>>>>>>>>>>>=20
>>>>>>>>>>>>> _______________________________________________
>>>>>>>>>>>>> status mailing list
>>>>>>>>>>>>> [email-masked]
>>>>>>>>>>>>> https://www.ietf.org/mailman/listinfo/status
>>>>>>>>>>>>=20
>>>>>>>>>>>>=20
>>>>>>>>>>>> _______________________________________________
>>>>>>>>>>>> status mailing list
>>>>>>>>>>>> [email-masked]
>>>>>>>>>>>> https://www.ietf.org/mailman/listinfo/status
>>>>>>>>>>>>=20
>>>>>>>>>>>> _____________________________________________________________
>>>>>>>>>>>> ____ _ _ _ __
>>>>>>>>>>>> ___________________________________________________
>>>>>>>>>>>>=20
>>>>>>>>>>>> Ce message et ses pieces jointes peuvent contenir des
>>>>>>>>>>>> informations confidentielles ou privilegiees et ne doivent
>>>>>>>>>>>> donc pas etre diffuses, exploites ou copies sans
>>>>>>>>>>>> autorisation. Si vous avez recu ce message par erreur, veuille=
z le signaler a l'expediteur et le detruire ainsi que les pieces jointes. L=
es messages electroniques etant susceptibles d'alteration, Orange decline t=
oute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.
>>>>>>>>>>>>=20
>>>>>>>>>>>> This message and its attachments may contain confidential or
>>>>>>>>>>>> privileged information that may be protected by law; they shou=
ld not be distributed, used or copied without authorisation.
>>>>>>>>>>>> If you have received this email in error, please notify the se=
nder and delete this message and its attachments.
>>>>>>>>>>>> As emails may be altered, Orange is not liable for messages th=
at have been modified, changed or falsified.
>>>>>>>>>>>> Thank you.
>>>>>>>>>>>>=20
>>>>>>>>>>>> _______________________________________________
>>>>>>>>>>>> status mailing list
>>>>>>>>>>>> [email-masked]
>>>>>>>>>>>> https://www.ietf.org/mailman/listinfo/status
>>>>>>>>>>>=20
>>>>>>>>>>> ______________________________________________________________
>>>>>>>>>>> ____ _ _ _
>>>>>>>>>>> ____________________________________________________
>>>>>>>>>>>=20
>>>>>>>>>>> Ce message et ses pieces jointes peuvent contenir des
>>>>>>>>>>> informations confidentielles ou privilegiees et ne doivent
>>>>>>>>>>> donc pas etre diffuses, exploites ou copies sans autorisation.
>>>>>>>>>>> Si vous avez recu ce message par erreur, veuillez le signaler a=
 l'expediteur et le detruire ainsi que les pieces jointes. Les messages ele=
ctroniques etant susceptibles d'alteration, Orange decline toute responsabi=
lite si ce message a ete altere, deforme ou falsifie. Merci.
>>>>>>>>>>>=20
>>>>>>>>>>> This message and its attachments may contain confidential or
>>>>>>>>>>> privileged information that may be protected by law; they shoul=
d not be distributed, used or copied without authorisation.
>>>>>>>>>>> If you have received this email in error, please notify the sen=
der and delete this message and its attachments.
>>>>>>>>>>> As emails may be altered, Orange is not liable for messages tha=
t have been modified, changed or falsified.
>>>>>>>>>>> Thank you.
>>>>>>>>>>>=20
>>>>>>>>>>> _______________________________________________
>>>>>>>>>>> status mailing list
>>>>>>>>>>> [email-masked]
>>>>>>>>>>> https://www.ietf.org/mailman/listinfo/status
>>>>>>>>>>> _______________________________________________
>>>>>>>>>>> status mailing list
>>>>>>>>>>> [email-masked]
>>>>>>>>>>> https://www.ietf.org/mailman/listinfo/status
>>>>>>>>>>>=20
>>>>>>>>>>=20
>>>>>>>>>> --
>>>>>>>>>>=20
>>>>>>>>>>=20
>>>>>>>>>> Loa Andersson                        email: [email-masked]=
m
>>>>>>>>>> Senior MPLS Expert                          [email-masked]
>>>>>>>>>> Huawei Technologies (consultant)     phone: +46 739 81 21 64
>>>>>>>>>> _______________________________________________
>>>>>>>>>> status mailing list
>>>>>>>>>> [email-masked]
>>>>>>>>>> https://www.ietf.org/mailman/listinfo/status
>>>>>>>>>>=20
>>>>>>>>>>=20
>>>>>>>>>=20
>>>>>>>>>=20
>>>>>>>>> _______________________________________________
>>>>>>>>> status mailing list
>>>>>>>>> [email-masked]
>>>>>>>>> https://www.ietf.org/mailman/listinfo/status
>>>>>>>>>=20
>>>>>>>>> ________________________________________________________________
>>>>>>>>> ____ _ _ ___________________________________________________
>>>>>>>>>=20
>>>>>>>>> Ce message et ses pieces jointes peuvent contenir des
>>>>>>>>> informations confidentielles ou privilegiees et ne doivent donc
>>>>>>>>> pas etre diffuses, exploites ou copies sans autorisation. Si
>>>>>>>>> vous avez recu ce message par erreur, veuillez le signaler a l'ex=
pediteur et le detruire ainsi que les pieces jointes. Les messages electron=
iques etant susceptibles d'alteration, Orange decline toute responsabilite =
si ce message a ete altere, deforme ou falsifie. Merci.
>>>>>>>>>=20
>>>>>>>>> This message and its attachments may contain confidential or
>>>>>>>>> privileged information that may be protected by law; they should =
not be distributed, used or copied without authorisation.
>>>>>>>>> If you have received this email in error, please notify the sende=
r and delete this message and its attachments.
>>>>>>>>> As emails may be altered, Orange is not liable for messages that =
have been modified, changed or falsified.
>>>>>>>>> Thank you.
>>>>>>>>>=20
>>>>>>>>>=20
>>>>>>>>>=20
>>>>>>>>=20
>>>>>>>>=20
>>>>>>>>=20
>>>>>>>> _________________________________________________________________
>>>>>>>> ____ _ ___________________________________________________
>>>>>>>>=20
>>>>>>>> Ce message et ses pieces jointes peuvent contenir des
>>>>>>>> informations confidentielles ou privilegiees et ne doivent donc
>>>>>>>> pas etre diffuses, exploites ou copies sans autorisation. Si vous
>>>>>>>> avez recu ce message par erreur, veuillez le signaler a l'expedite=
ur et le detruire ainsi que les pieces jointes. Les messages electroniques =
etant susceptibles d'alteration, Orange decline toute responsabilite si ce =
message a ete altere, deforme ou falsifie. Merci.
>>>>>>>>=20
>>>>>>>> This message and its attachments may contain confidential or
>>>>>>>> privileged information that may be protected by law; they should n=
ot be distributed, used or copied without authorisation.
>>>>>>>> If you have received this email in error, please notify the sender=
 and delete this message and its attachments.
>>>>>>>> As emails may be altered, Orange is not liable for messages that h=
ave been modified, changed or falsified.
>>>>>>>> Thank you.
>>>>>>>>=20
>>>>>>>> _______________________________________________
>>>>>>>> status mailing list
>>>>>>>> [email-masked]
>>>>>>>> https://www.ietf.org/mailman/listinfo/status
>>>>>>>=20
>>>>>>>=20
>>>>>>> __________________________________________________________________
>>>>>>> ____ ___________________________________________________
>>>>>>>=20
>>>>>>> Ce message et ses pieces jointes peuvent contenir des informations
>>>>>>> confidentielles ou privilegiees et ne doivent donc pas etre
>>>>>>> diffuses, exploites ou copies sans autorisation. Si vous avez recu
>>>>>>> ce message par erreur, veuillez le signaler a l'expediteur et le de=
truire ainsi que les pieces jointes. Les messages electroniques etant susce=
ptibles d'alteration, Orange decline toute responsabilite si ce message a e=
te altere, deforme ou falsifie. Merci.
>>>>>>>=20
>>>>>>> This message and its attachments may contain confidential or
>>>>>>> privileged information that may be protected by law; they should no=
t be distributed, used or copied without authorisation.
>>>>>>> If you have received this email in error, please notify the sender =
and delete this message and its attachments.
>>>>>>> As emails may be altered, Orange is not liable for messages that ha=
ve been modified, changed or falsified.
>>>>>>> Thank you.
>>>>>>>=20
>>>>>>=20
>>>>>>=20
>>>>>> ___________________________________________________________________
>>>>>> ______________________________________________________
>>>>>>=20
>>>>>> Ce message et ses pieces jointes peuvent contenir des informations
>>>>>> confidentielles ou privilegiees et ne doivent donc pas etre
>>>>>> diffuses, exploites ou copies sans autorisation. Si vous avez recu
>>>>>> ce message par erreur, veuillez le signaler a l'expediteur et le det=
ruire ainsi que les pieces jointes. Les messages electroniques etant suscep=
tibles d'alteration, Orange decline toute responsabilite si ce message a et=
e altere, deforme ou falsifie. Merci.
>>>>>>=20
>>>>>> This message and its attachments may contain confidential or
>>>>>> privileged information that may be protected by law; they should not=
 be distributed, used or copied without authorisation.
>>>>>> If you have received this email in error, please notify the sender a=
nd delete this message and its attachments.
>>>>>> As emails may be altered, Orange is not liable for messages that hav=
e been modified, changed or falsified.
>>>>>> Thank you.
>>>>>>=20
>>>>>=20
>>>>>=20
>>>>>=20
>>>>=20
>>>>=20
>>>=20
>>>=20
>>>=20
>>=20
>>=20
>>=20
>> ________________________________________________________________________=
_________________________________________________
>>=20
>> Ce message et ses pieces jointes peuvent contenir des informations confi=
dentielles ou privilegiees et ne doivent donc
>> pas etre diffuses, exploites ou copies sans autorisation. Si vous avez r=
ecu ce message par erreur, veuillez le signaler
>> a l'expediteur et le detruire ainsi que les pieces jointes. Les messages=
 electroniques etant susceptibles d'alteration,
>> Orange decline toute responsabilite si ce message a ete altere, deforme =
ou falsifie. Merci.
>>=20
>> This message and its attachments may contain confidential or privileged =
information that may be protected by law;
>> they should not be distributed, used or copied without authorisation.
>> If you have received this email in error, please notify the sender and d=
elete this message and its attachments.
>> As emails may be altered, Orange is not liable for messages that have be=
en modified, changed or falsified.
>> Thank you.
>>=20
>> _______________________________________________
>> status mailing list
>> [email-masked]
>> https://www.ietf.org/mailman/listinfo/status
>>=20
>>=20
>=20
>=20
> _______________________________________________
> status mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/status

From: "Stefano Previdi (sprevidi)" <[email-masked]>
To: Xuxiaohu <[email-masked]>
Date: Thu, 12 Sep 2013 12:43:45 +0000
Accept-Language: en-US
Cc: Stephane Litkowski <[email-masked]>, Rob Shakir <[email-masked]>, "[email-masked]" <[email-masked]>, Hannes Gredler <[email-masked]>
Subject: Re: [Status] Good charter proposals from Hannes and Stefano : try to merge ...

From: Xuxiaohu <[email-masked]>
To: "Stefano Previdi (sprevidi)" <[email-masked]>
Date: Thu, 12 Sep 2013 01:27:58 +0000
Accept-Language: zh-CN, en-US
Cc: Stephane Litkowski <[email-masked]>, Rob Shakir <[email-masked]>, "[email-masked]" <[email-masked]>, Hannes Gredler <[email-masked]>
Subject: Re: [Status] Good charter proposals from Hannes and Stefano : try to merge ...

From: "John G. Scudder" <[email-masked]>
Date: Wed, 11 Sep 2013 14:32:08 -0400
To: <[email-masked]>
Cc: Hannes Gredler <[email-masked]>, Rob Shakir <[email-masked]>, "[email-masked]" <[email-masked]>, Stefano Previdi <[email-masked]>
Subject: Re: [Status] Good charter proposals from Hannes and Stefano : try to merge ...

Stephane,

This seems like a very reasonable way forward to me and I think the last =
draft charter you posted is "about right". In particular I want to =
support the idea that "the use case analysis ... will give us what we =
need to address exactly".=20

--John

On Sep 11, 2013, at 5:53 AM, [email-masked] wrote:

> Hannes,
>=20
> Regarding "Service chaining", I would agree to not mention it directly =
in the charter (it's not mentionned explictly in my last proposal) BUT I =
don't want to close the door to other "action types" than forwarding. =
That's why using the wording "node" , "steering packets" seems to be =
good because it's large enough to address use cases that are not =
detailled today (for example service chaining).
>=20
> So my approach would be , keep it large in definition using the =
proposed wording and then the use case analysis (in the work items) will =
give us what we need to address exactly.
>=20
> Does it make sense for you to use this way ?
>=20
>=20
> Thanks,
>=20
> Stephane
>=20
>=20
>=20
> -----Message d'origine-----
> De : Hannes Gredler [mailto:[email-masked]]
> Envoy=E9 : mercredi 11 septembre 2013 08:15
> =C0 : Stefano Previdi
> Cc : LITKOWSKI Stephane DTF/DERX; Rob Shakir; [email-masked]
> Objet : Re: [Status] Good charter proposals from Hannes and Stefano : =
try to merge ...
>=20
> stefano,
>=20
> On Sep 10, 2013, at 7:34 PM, Stefano Previdi (sprevidi) wrote:
>=20
>> Hannes,
>>=20
>> On Sep 10, 2013, at 7:27 PM, Hannes Gredler wrote:
>>> stefano,
>>>=20
>>> On Sep 10, 2013, at 6:58 PM, Stefano Previdi (sprevidi) wrote:
>>>=20
>>>>=20
>>>> On Sep 10, 2013, at 1:25 PM, <[email-masked]> wrote:
>>>>=20
>>>>> Agree on all proposal except :
>>>>>=20
>>>>> "[SP] The architecture will support tunnel and non-tunnel =
paradigms
>>>>> The architecture will support multiple dataplanes: MPLS and V6"
>>>>>=20
>>>>> I don't see the reason for this ... IMHO, the gap analysis and
>>>>> requirements inventory will result on saying or not
>>>>=20
>>>>=20
>>>> [SP] While I understand what brought the following statements
>>>>  in the proposed charter:
>>>>    "Having identified use-cases, architecture and security,
>>>>     the WG will identify gaps between currently available
>>>>     technologies and use-case requirements.
>>>>     The WG will then define requirements for extensions to
>>>>     existing protocols or new protocols that address gaps
>>>>     that are identified."
>>>>=20
>>>>  I'd like to point out with better precision what are the
>>>>  directions we are ALREADY engaged into: dataplanes and
>>>>  paradigms. As I mentioned in my charter proposal, we do have
>>>>  implementations and multi-vendor interoperability tests will
>>>>  happen soon. So, I just want to be sure we don't ignore this
>>>>  reality.
>>>=20
>>> HG> just because you have an implementation for <foo> does not
>>> HG> constitute
>>>  community interest. we are trying to build here a charter that
>>>  matches what a broader community wants. if the use-case that you're =
concerned
>>>  about (service-chaining and a new internet data plane #4) are =
compelling
>>>  enough the group will work on it, but mandating that into the =
charter,
>>>  without asking the though questions first seems a wrong start to =
me.
>>=20
>>=20
>> [SP] Sorry to contradict but it's the exact opposite. If a group
>>    of vendors decide to invest in implementations is because
>>    they received, analyzed, processed a set of requirements
>>    coming for operators who know pretty well what they do, what
>>    they want to deploy and the technology they want the vendors
>>    to deliver. This fits the definition of "community interest".
>=20
> HG> interestingly enough i haven't encountered a network operator so
>    far who says 'i need SR for service chaining' nor
>    we had somebody asking for this in the 'operator use case' slots
>    in Berlin. - So who are they ? - can you manage such that
>    they speak up and make their case ?
>=20
>>    My point is that I strongly _suggest_ IETF WG (any) not to
>>    neglect these facts and not write a down a charter ...
> [ ... ]
>=20
> HG> i'd like to have some proof point for your 'facts' prior
>    to making 'service chaining' a charter item.
>=20
>>    Having said that, whoever does NOT believe in the benefit of
>>    a newly proposed technology, is always free to not implement
>>    it and to not deploy it.
>=20
> HG> that is fine and well understood, but since you have a desire to
>    standardize your 'newly proposed technology' you also need to play
>    a bit by the rules.
>=20
>>>>> : we must use tunnels and/or non tunnels, and the following =
dataplanes ... But I don't see the reason to put solutions directly in =
the charter ...
>>>>=20
>>>>=20
>>>> these are not solutions these are way to avoid boundaries in the
>>>> framework.
>>>>=20
>>>> Thanks.
>>>> s.
>>>>=20
>>>>=20
>>>>> Could you explain your point ?
>>>>>=20
>>>>>=20
>>>>> updated with the other comments :
>>>>>=20
>>>>> =
-------------------------------------------------------------------
>>>>> Name: <TBD>
>>>>> Charter:
>>>>>=20
>>>>>=20
>>>>> Introduction
>>>>> ------------
>>>>> The following use cases:
>>>>> . Path computation based on awareness of utilization or =
performance
>>>>> data, within both centralized and distributed environments, . =
Multi-topology (dual planes, disjoint trees), . Simplification and =
reduction of signaling components (scaling), . Combined application and =
network layer path specification, . Full coverage LFA-FRR, . Topology =
Aware OAM, . etc.
>>>>>=20
>>>>> have triggered work on the definition of new architecture and =
protocol extensions allowing to combine well known shortest path based =
routing paradigms with source/explicit routing methods. Some of these =
extensions have been implemented already.
>>>>>=20
>>>>>=20
>>>>> Objective
>>>>> ---------
>>>>>=20
>>>>> Define an architecture where a node can steer a packet through a =
network or set of networks (interdomain) on any path without requiring =
to maintain state along the path, other than in the ingress node.
>>>>>=20
>>>>> A node may be any type of device including routers or appliances.
>>>>>=20
>>>>> In this architecture, nodes sharing a common trust model form a =
<Name-TBD> domain. The architecture defined by this working group will =
allow a node to steer a packet between any source and destination node =
within the <Name-TBD> domain (formed of one or more networks), on any =
path (shortest, non-shortest, explicit or based on other characteristics =
specified by segment identifiers).
>>>>>=20
>>>>> It may then send any packet that passes through it through any =
path
>>>>> that it has specified and that is conform to the security rules.
>>>>> Downstream nodes along the path within the <Name-TBD> domain
>>>>> forward the packet by using the informations inserted by the node
>>>>> at the head-end
>>>>>=20
>>>>> The architecture should support centralized and distributed path =
computation.
>>>>>=20
>>>>> The architecture should support OAM functions.
>>>>>=20
>>>>> The architecture should allow different mechanisms through which  =
a
>>>>> path is constructed. SR allows a variety of mechanisms, not
>>>>> confined IGP/BGP path computation.
>>>>>=20
>>>>> As MPLS dataplane is largely deployed, the <Name-TBD> WG should =
avoid any modification in the MPLS dataplane when defining the =
architecture.
>>>>>=20
>>>>>=20
>>>>> Work items :
>>>>> ------------------
>>>>>=20
>>>>> The <Name-TBD> working group is chartered for the following =
ordered list of work items:
>>>>>=20
>>>>> - The first goal of the WG is to identify use-cases.
>>>>> - The WG will then define the architecture framework associated
>>>>> with the security considerations. The architecture framework and
>>>>> security considerations must address the relations between =
networks forming the <Name-TBD> domain (interAS).
>>>>> - Having identified use-cases, architecture and security, the WG
>>>>> will identify gaps between currently available technologies and
>>>>> use-case requirements.
>>>>> - The WG will then define requirements for extensions to existing
>>>>> protocols or new protocols that address gaps that are identified.
>>>>> - The WG will first focus on the intra-domain forwarding =
definition.
>>>>>=20
>>>>>=20
>>>>> Documents :
>>>>> ------------------
>>>>> . Use Cases
>>>>> . Architecture including security considerations
>>>>> - Protocol extension requirements
>>>>> . Interoperability Report
>>>>>=20
>>>>>=20
>>>>> Required protocol extensions are carried out in working groups =
responsible (ISIS,OSPF,BGP,PCEP ...). Work on new protocols may be =
carried out by the <Name-TBD> WG.
>>>>>=20
>>>>> -----Message d'origine-----
>>>>> De : Stefano Previdi (sprevidi) [mailto:[email-masked]] Envoy=E9=

>>>>> : mardi 10 septembre 2013 12:30 =C0 : LITKOWSKI Stephane DTF/DERX;
>>>>> Rob Shakir Cc : Hannes Gredler; [email-masked] Objet : Re:
>>>>> [Status] Good charter proposals from Hannes and Stefano : try to =
merge ...
>>>>>=20
>>>>> Hi Stephane, Rob,
>>>>>=20
>>>>> one preliminary remark: I prefer to use he therm "node" rather =
than "router". Use cases, such as Service Chaining requires that =
terminology.
>>>>>=20
>>>>> some other comments below...
>>>>>=20
>>>>>=20
>>>>> On Sep 10, 2013, at 11:19 AM, <[email-masked]> =
wrote:
>>>>>> Souns good to me, (adding OAM also)
>>>>>>=20
>>>>>> New recap :
>>>>>>=20
>>>>>> =
------------------------------------------------------------------
>>>>>> -
>>>>>> Name: <TBD>
>>>>>> Charter:
>>>>>>=20
>>>>>>=20
>>>>>> Introduction
>>>>>> ------------
>>>>>> The following use cases:
>>>>>> . Path computation based on awareness of utilization or
>>>>>> performance data, within both centralized and distributed =
environments, . Multi-topology (dual planes, disjoint trees), . =
Simplification and reduction of signaling components (scaling), . =
Combined application and network layer path specification, . Full =
coverage LFA-FRR, . Topology Aware OAM, . etc.
>>>>>>=20
>>>>>> have triggered work on the definition of new architecture and =
protocol extensions allowing to combine well known shortest path based =
routing paradigms with source/explicit routing methods. Some of these =
extensions have been implemented already.
>>>>>>=20
>>>>>>=20
>>>>>> Objective
>>>>>> ---------
>>>>>>=20
>>>>>> Define an architecture where a node can steer a packet through a =
network or set of networks (interdomain) on any path.
>>>>>=20
>>>>>=20
>>>>> [SP] As stated above, I'm fine with the above definition but I
>>>>> assume this includes service chaining and that by "network  or set
>>>>> of networks" you intend "nodes" which may include  others things
>>>>> than just routers.
>>>>>=20
>>>>> [SLI] Agree
>>>>>=20
>>>>>=20
>>>>>> In this architecture, routers sharing a common trust model form a =
<Name-TBD> domain. The architecture defined by this working group will =
allow a node to steer a packet between any source and destination node =
within the <Name-TBD> domain (formed of one or more networks), on any =
path (shortest, non-shortest, explicit or based on other characteristics =
specified by segment identifiers).
>>>>>=20
>>>>>=20
>>>>> [SP] without requiring to maintain state along the path, other
>>>>> than in the ingress node.
>>>>>=20
>>>>> [SLI] Agree
>>>>>=20
>>>>>=20
>>>>>> It may then send any packet that passes through it through any =
path that it has specified and that is conform to the security rules. =
Downstream routers along the path within the <Name-TBD> domain forward =
the packet as specified by the router at the head-end of the path.
>>>>>=20
>>>>>>=20
>>>>>> The architecture should support centralized and distributed path =
computation.
>>>>>>=20
>>>>>> The architecture should support OAM functions.
>>>>>=20
>>>>>=20
>>>>> [SP] The architecture should allow different mechanisms through
>>>>> which  a path is constructed. SR allows a variety of mechanisms,
>>>>> not  confined IGP/BGP path computation.
>>>>>=20
>>>>> [SLI] Agree
>>>>>=20
>>>>>> Work items :
>>>>>> ------------------
>>>>>>=20
>>>>>> The <Name-TBD> working group is chartered for the following =
ordered list of work items:
>>>>>>=20
>>>>>> - The first goal of the WG is to identify use-cases.
>>>>>> - The WG will then define the architecture framework associated
>>>>>> with the security considerations. The architecture framework and
>>>>>> security considerations must address the relations between =
networks forming the <Name-TBD> domain (interAS).
>>>>>> - Having identified use-cases, architecture and security, the WG
>>>>>> will identify gaps between currently available technologies and
>>>>>> use-case requirements.
>>>>>> - The WG will then define requirements for extensions to existing
>>>>>> protocols or new protocols that address gaps that are identified.
>>>>>> - The WG will first focus on the intra-domain forwarding =
definition.
>>>>>=20
>>>>>=20
>>>>> [SP] The architecture will support tunnel and non-tunnel paradigms
>>>>> The architecture will support multiple dataplanes: MPLS and V6
>>>>>=20
>>>>>=20
>>>>> Thanks.
>>>>> s.
>>>>>=20
>>>>>=20
>>>>>> Documents :
>>>>>> ------------------
>>>>>> . Use Cases
>>>>>> . Architecture including security considerations
>>>>>> - Protocol extension requirements
>>>>>> . Interoperability Report
>>>>>>=20
>>>>>>=20
>>>>>> Protocol work may be carried out in this working group or in =
other working groups responsible for the protocols (ISIS,OSPF,BGP,PCEP =
...), in coordination with this WG, and in agreement with the WG chairs =
and responsible ADs.
>>>>>>=20
>>>>>> -----Message d'origine-----
>>>>>> De : Rob Shakir [mailto:[email-masked]] Envoy=E9 : mardi 10 septembre
>>>>>> 2013 11:05 =C0 : LITKOWSKI Stephane DTF/DERX Cc : Hannes Gredler;
>>>>>> Stefano Previdi (sprevidi); [email-masked] Objet
>>>>>> : Re: [Status] Good charter proposals from Hannes and Stefano : =
try to merge ...
>>>>>>=20
>>>>>> Hi Stephane,
>>>>>>=20
>>>>>> Thanks for this, looks good! Comments in-line marked rjs>.
>>>>>>=20
>>>>>> On 10 Sep 2013, at 08:50, <[email-masked]> wrote:
>>>>>>=20
>>>>>>> Hi all,
>>>>>>>=20
>>>>>>> I'm creating a new mail topic because the "Summary of STATUS BOF =
..."
>>>>>>> starts to be unreadable :)
>>>>>>>=20
>>>>>>> Hannes and Stefano send to us two charter proposals that sounds =
good to me.
>>>>>>>=20
>>>>>>> The main difference between the two proposals is that Stefano =
propose a segment bound to any type of instruction (forwarding, =
application or service based) while Hannes is focusing on forwarding =
actions (which is the first priority, and I think everybody agree on =
this).
>>>>>>=20
>>>>>> rjs> Agreed -- I think it would be useful to allow definitions of =
segments to identify different types of "service", since there appear to =
be some use cases (e.g., the explicit exit selection case) which require =
a segment type describing something that is not explicitly IGP-based.
>>>>>>=20
>>>>>>>=20
>>>>>>> It would be interresting to have a feedback from the mailinglist =
on this specific point.
>>>>>>>=20
>>>>>>> IMHO, there is a strong interrest to explore the service actions =
bound to segment in a second step keeping forwarding as a priority.
>>>>>>>=20
>>>>>>> Apart of this problem, here is a merge try of the two good =
proposals (I'm putting '<>' on hot topics :) ) :
>>>>>>>=20
>>>>>>>=20
>>>>>>> =
-----------------------------------------------------------------
>>>>>>> --
>>>>>>> Name: <TBD>
>>>>>>> Charter:
>>>>>>>=20
>>>>>>>=20
>>>>>>> Introduction
>>>>>>> ------------
>>>>>>> The following use cases:
>>>>>>> . Path computation based on awareness of utilization or
>>>>>>> performance data, within both centralized and distributed =
environments, . Multi-topology (dual planes, disjoint trees), . =
Simplification and reduction of signaling components (scaling), . =
Combined application and network layer path specification, . Full =
coverage LFA-FRR, . Topology Aware OAM, . etc.
>>>>>>>=20
>>>>>>> have triggered work on the definition of new architecture and =
protocol extensions allowing to combine well known shortest path based =
routing paradigms with source/explicit routing methods. Some of these =
extensions have been implemented already.
>>>>>>>=20
>>>>>>>=20
>>>>>>> Objective
>>>>>>> ---------
>>>>>>>=20
>>>>>>> Define an architecture where a node can steer a packet through a =
network or set of networks (interdomain) on any path (shortest, non =
shortest, explicit, <service or application>).
>>>>>>>=20
>>>>>>> In this architecture, routers are sharing a common trust model =
and are forming a <Name-TBD> domain.
>>>>>>> Within this domain, a node can specify a path between itself and =
any destination in the domain. <The path may be a forwarding path, a =
service chaining path or a combination of both>.
>>>>>>=20
>>>>>> rjs> To clarify here, we define that our domain is under a common =
trust model (essentially, under common administrative control?), but =
then go on to talk about inter-domain elsewhere. Can we perhaps clarify =
(by defining a specific "<Name-TBD> domain" nomenclature) and say =
something like:
>>>>>>=20
>>>>>> "In this architecture, routers sharing a common trust model form =
a <Name-TBD> domain. The architecture defined by this working group will =
allow a node to steer a packet between any source and destination node =
within the <Name-TBD> domain (formed of one or more networks), on any =
path (shortest, non-shortest, explicit or based on other characteristics =
specified by segment identifiers)."
>>>>>>=20
>>>>>>> It may then send any packet that passes through it through any =
path that it has specified and that is conform to the security rules. =
Downstream routers along the path within the <Name-TBD> domain forward =
the packet as specified by the router at the head-end of the path.
>>>>>>>=20
>>>>>>> The architecture should support centralized and distributed path =
computation.
>>>>>>>=20
>>>>>>>=20
>>>>>>> Work items :
>>>>>>> ------------------
>>>>>>>=20
>>>>>>> The <Name-TBD> working group is chartered for the following =
ordered list of work items:
>>>>>>>=20
>>>>>>> - The first goal of the WG is to identify use-cases.
>>>>>>> - The WG will then define the architecture framework associated
>>>>>>> with the security considerations. The architecture framework and
>>>>>>> security considerations must address the relations between =
domains (inter domain).
>>>>>>=20
>>>>>> rjs> And then here "networks forming the <Name-TBD> domain"?
>>>>>>=20
>>>>>> Thanks for the efforts,
>>>>>> r.
>>>>>>=20
>>>>>>> - Having identified use-cases, architecture and security, the WG
>>>>>>> will identify gaps between currently available technologies and
>>>>>>> use-case requirements.
>>>>>>> - The WG will then define requirements for extensions to =
existing
>>>>>>> protocols or new protocols that address gaps that are =
identified.
>>>>>>> - The WG will first focus on the intra-domain forwarding =
definition.
>>>>>>>=20
>>>>>>>=20
>>>>>>> Documents :
>>>>>>> ------------------
>>>>>>> . Use Cases
>>>>>>> . Architecture including security considerations
>>>>>>> - Protocol extension requirements . Interoperability Report
>>>>>>>=20
>>>>>>>=20
>>>>>>> Protocol work may be carried out in this working group or in =
other working groups responsible for the protocols (ISIS,OSPF,BGP,PCEP =
...), in coordination with this WG, and in agreement with the WG chairs =
and responsible ADs.
>>>>>>>=20
>>>>>>>=20
>>>>>>>=20
>>>>>>> Hope it helps to progress on the definition.
>>>>>>>=20
>>>>>>>=20
>>>>>>> Stephane
>>>>>>>=20
>>>>>>>=20
>>>>>>> -----Message d'origine-----
>>>>>>> De : Hannes Gredler [mailto:[email-masked]] Envoy=E9 : =
vendredi
>>>>>>> 6 septembre 2013 18:27 =C0 : LITKOWSKI Stephane DTF/DERX Cc :
>>>>>>> [email-masked] Objet : Re: [Status] Summary of STATUS BOF and
>>>>>>> the next steps
>>>>>>>=20
>>>>>>> hi stephane,
>>>>>>>=20
>>>>>>> here is a revised draft charter as per your comments.
>>>>>>>=20
>>>>>>> ---
>>>>>>>=20
>>>>>>> <Name-TBD> domain contains a set of routers with the following
>>>>>>> characteristics:
>>>>>>>=20
>>>>>>> - They form a connected network
>>>>>>> - They can forward traffic through any path within the network
>>>>>>> using shortest path, or any other (e.g., an explicit) path
>>>>>>> - They share a common trust model. In this model, any router
>>>>>>> within the domain can specify a path between itself and any =
other
>>>>>>> router  in the domain. It may then send any packet that passes
>>>>>>> through it through any path that it has specified and that is
>>>>>>> conform to the security rules. Downstream routers along the path
>>>>>>> within the <Name-TBD>  domain forward the packet as specified by
>>>>>>> the router at the head-end  of the path.
>>>>>>>=20
>>>>>>> The <Name-TBD> working group is chartered for the following =
ordered list of work items:
>>>>>>>=20
>>>>>>> - The first goal of the WG is to identify use-cases.
>>>>>>> - The WG will then define the architecture framework associated
>>>>>>> with the security considerations. The architecture framework and
>>>>>>> security considerations must address the relations between =
domains (interdomain).
>>>>>>> - Having identified use-cases, architecture and security, the WG
>>>>>>> will identify gaps between currently available technologies and
>>>>>>> use-case requirements.
>>>>>>> - The WG will then define requirements for extensions to =
existing
>>>>>>> protocols or new protocols that address gaps that are =
identified.
>>>>>>> - The WG will first focus on the intra-domain forwarding =
definition.
>>>>>>>=20
>>>>>>> Protocol work may be carried out in this working group or in =
other working groups responsible for the protocols, in coordination with =
this WG, and in agreement with the WG chairs and responsible ADs.
>>>>>>> However, no protocol work will be adopted by a working group to =
address the identified use-cases until the requirements document =
motivating the protocol work has been sent to the IESG for publication =
as an RFC.
>>>>>>>=20
>>>>>>> ---
>>>>>>>=20
>>>>>>> /hannes
>>>>>>>=20
>>>>>>> On Sep 4, 2013, at 10:02 AM, <[email-masked]> =
<[email-masked]> wrote:
>>>>>>>=20
>>>>>>>> Hannes,
>>>>>>>>=20
>>>>>>>> In case, we are using only directed forwarding (adjacency
>>>>>>>> segment), could we still talk about tunneling ? (it's a very =
very small tunnel) Moreover talking about "stacking" is really dataplane =
agnostic (MPLS) ...
>>>>>>>>=20
>>>>>>>> In the proposed segment routing architectural concepts, =
segments are at the same "level" and pointer moves on the segment list, =
then the MPLS instantiation is performing this using stacking ...
>>>>>>>>=20
>>>>>>>> IMHO, if we use "Stacked Tunnels", we already talk about a =
chosen solution and it's closing the door to something else  ...
>>>>>>>>=20
>>>>>>>> Finally, about the "routing" word, routing is essentially a =
"forward" action which may limit the scope of what we can do by using a =
segment list. Actions associated with a segment could be something else =
than forwarding.
>>>>>>>>=20
>>>>>>>> Do we want in the charter to limit the scope to routing actions =
?
>>>>>>>>=20
>>>>>>>> I have no solution today to propose for the naming, but I =
completely agree with Loa, to first focus on working on the charter, and =
define a clear scope of the work and then the name will be easier to =
find.
>>>>>>>>=20
>>>>>>>> Regarding your charter proposal :
>>>>>>>>=20
>>>>>>>> --------
>>>>>>>>=20
>>>>>>>> - They form a connected network
>>>>>>>> [SLI] InterAS case must be included, but the WG can go step by =
step and first release intraAS, and then doing interAS (in relation with =
IDR ??).
>>>>>>>>=20
>>>>>>>> - They can forward traffic through the shortest paths or paths
>>>>>>>> other than the shortest (the latter called explicitly routed =
paths, or explicit paths)  [SLI] There is something else between SPT and =
Explicit path, you can define other algorithms than SPT to define a =
path, and it's not explicit path. Moreover I come back to my comment, on =
do we want to limit the scope to routing ? I would say no.
>>>>>>>>=20
>>>>>>>> - They share a common trust model. In this model, any router =
within the ERD can specify an explicit path between itself and any other =
router in the ERD. It can then send any packet that passes through it =
through any path that it has specified.
>>>>>>>> [SLI] Security considerations may have to be addressed in the
>>>>>>>> charter , especially for the interAS case (trust yes, but not
>>>>>>>> sure access to everything may not be good)
>>>>>>>>=20
>>>>>>>> Downstream routers within the ERD forward the packet as =
specified by the router at the head-end of the path.
>>>>>>>> [SLI] Yes, but any router in the middle may be able to change =
the end to end explicit path.
>>>>>>>>=20
>>>>>>>>=20
>>>>>>>>=20
>>>>>>>> - The first goal of the STER WG is to identify use-cases for =
ERDs.
>>>>>>>> - Having identified use-cases, the WG will identify gaps =
between currently available technologies and use-case requirements.
>>>>>>>> - The WG will then define requirements for extensions to =
existing protocols or new protocols that address gaps that are =
identified.
>>>>>>>>=20
>>>>>>>> [SLI] Agree, I would add :
>>>>>>>> - defining the architecture framework
>>>>>>>> - analysing the security considerisations
>>>>>>>>=20
>>>>>>>>=20
>>>>>>>> ---------
>>>>>>>>=20
>>>>>>>>=20
>>>>>>>> Here would be my proposal to extend yours :
>>>>>>>>=20
>>>>>>>> A <named to be defined> domain contains a set of routers with =
the following characteristics:
>>>>>>>>=20
>>>>>>>> - They form a connected network
>>>>>>>> - They can forward traffic through any path within the network
>>>>>>>> using shortest path, non shortest path or explicit path
>>>>>>>> - They may provide other types of services than forwarding and =
they can enforce service actions in the path.
>>>>>>>> - They share a common trust model. In this model, any router =
within the domain can specify a path between itself and any other router =
in the domain. It may then send any packet that passes through it =
through any path that it has specified and that is conform to the =
security rules. Downstream routers within the ERD forward the packet as =
specified by the router at the head-end of the path.
>>>>>>>>=20
>>>>>>>> The <name> working group is chartered for the following ordered =
list of work items:
>>>>>>>>=20
>>>>>>>> - The first goal of the WG is to identify use-cases.
>>>>>>>> - The WG will then define the architecture framework associated =
with the security considerations. The architecture framework and =
security considerations must address the relations between domains =
(interdomain).
>>>>>>>> - Having identified use-cases, architecture and security, the =
WG will identify gaps between currently available technologies and =
use-case requirements.
>>>>>>>> - The WG will then define requirements for extensions to =
existing protocols or new protocols that address gaps that are =
identified.
>>>>>>>> - The WG will first focus on the intra-domain forwarding =
definition.
>>>>>>>>=20
>>>>>>>> Protocol work may be carried out in this working group or in =
other working groups responsible for the protocols, in coordination with =
this WG, and in agreement with the WG chairs and responsible ADs. =
However, no protocol work will be adopted by a working group to address =
the ERD use-cases until the requirements document motivating the =
protocol work has been sent to the IESG for publication as an RFC.
>>>>>>>>=20
>>>>>>>> -----Message d'origine-----
>>>>>>>> De : [email-masked] [mailto:[email-masked]] =
De
>>>>>>>> la part de Hannes Gredler Envoy=E9 : mardi 3 septembre 2013 =
18:31
>>>>>>>> =C0 : Loa Andersson Cc : [email-masked] Objet : Re: [Status]
>>>>>>>> Summary of STATUS BOF and the next steps
>>>>>>>>=20
>>>>>>>> good point - what about this charter proposal ?
>>>>>>>>=20
>>>>>>>> ---
>>>>>>>>=20
>>>>>>>> Stacked Tunnels for Explicit Routing (STER)
>>>>>>>> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
>>>>>>>>=20
>>>>>>>> A explicit routing domain (ERD) contains a set of routers with =
the following characteristics:
>>>>>>>>=20
>>>>>>>> - They form a connected network
>>>>>>>> - They can forward traffic through the shortest paths or paths
>>>>>>>> other than the shortest (the latter called explicitly routed
>>>>>>>> paths, or explicit paths)
>>>>>>>> - They share a common trust model. In this model, any router =
within the ERD can specify an explicit path between itself and any other =
router in the ERD. It can then send any packet that passes through it =
through any path that it has specified. Downstream routers within the =
ERD forward the packet as specified by the router at the head-end of the =
path.
>>>>>>>>=20
>>>>>>>> The STER working group is chartered for the following ordered =
list of work items:
>>>>>>>>=20
>>>>>>>> - The first goal of the STER WG is to identify use-cases for =
ERDs.
>>>>>>>> - Having identified use-cases, the WG will identify gaps =
between currently available technologies and use-case requirements.
>>>>>>>> - The WG will then define requirements for extensions to =
existing protocols or new protocols that address gaps that are =
identified.
>>>>>>>>=20
>>>>>>>> Protocol work may be carried out in this working group or in =
other working groups responsible for the protocols, in coordination with =
this WG, and in agreement with the WG chairs and responsible ADs. =
However, no protocol work will be adopted by a working group to address =
the ERD use-cases until the requirements document motivating the =
protocol work has been sent to the IESG for publication as an RFC.
>>>>>>>>=20
>>>>>>>> ---
>>>>>>>>=20
>>>>>>>> <flame suit on>
>>>>>>>>=20
>>>>>>>> /hannes
>>>>>>>>=20
>>>>>>>>=20
>>>>>>>> On Sep 3, 2013, at 5:31 PM, Loa Andersson wrote:
>>>>>>>>=20
>>>>>>>>> Folks,
>>>>>>>>>=20
>>>>>>>>> Excuse me if I'm slightly out of the loop, but so far I have
>>>>>>>>> not seen a charter proposal, if there is one please point me =
to it.
>>>>>>>>>=20
>>>>>>>>> It seems a bit odd to put the cart (what the wg should do)
>>>>>>>>> before the horse (wg name). If we drill down the the charter
>>>>>>>>> first the wg name might be easier to figure out.
>>>>>>>>>=20
>>>>>>>>> /Loa
>>>>>>>>>=20
>>>>>>>>> PS
>>>>>>>>> OK I understand that the horse and cart analogy limps a  bit =
:).
>>>>>>>>>=20
>>>>>>>>>=20
>>>>>>>>>=20
>>>>>>>>> On 2013-09-03 17:22, AshwoodsmithPeter wrote:
>>>>>>>>>> " If the WG charter is limited to source routing, how will we =
handle the "non source routing" use cases of segment routing ? In =
another working group ? So we will go back to the WG synchronization =
issue that has been raised for this technology ..."
>>>>>>>>>>=20
>>>>>>>>>> That's why I suggested SRV2. We are revisiting source routing =
with new concepts. More generic number/action behavior.
>>>>>>>>>>=20
>>>>>>>>>> Peter
>>>>>>>>>>=20
>>>>>>>>>> -----Original Message-----
>>>>>>>>>> From: [email-masked] =
[mailto:[email-masked]]
>>>>>>>>>> On Behalf Of [email-masked]
>>>>>>>>>> Sent: Tuesday, September 03, 2013 10:43 AM
>>>>>>>>>> To: AshwoodsmithPeter
>>>>>>>>>> Cc: [email-masked]
>>>>>>>>>> Subject: Re: [Status] Summary of STATUS BOF and the next =
steps
>>>>>>>>>>=20
>>>>>>>>>>=20
>>>>>>>>>> There was a misunderstanding in my small comment :) so I will =
explain more :
>>>>>>>>>>=20
>>>>>>>>>> In segment routing, you have more than basic source routing : =
segment routing is just associate a segment number to an action and then =
combine segment as you want, yes you can do source routing, but you also =
can do more.
>>>>>>>>>>=20
>>>>>>>>>> In the other hand, I completely agree with your statement =
that
>>>>>>>>>> source routing is generic and dataplane agnostic, as segment =
routing is ...
>>>>>>>>>> (segment routing is not a new dataplane ...)
>>>>>>>>>>=20
>>>>>>>>>> Now the definition of the WG naming must be inline with the
>>>>>>>>>> charter that will be defined ... (draft today)
>>>>>>>>>>=20
>>>>>>>>>> Based on the already existing consensus (at least for MPLS =
dataplane) brought up during Berlin STATUS BOF meeting, segment routing =
sounds to be a good target candidate.
>>>>>>>>>>=20
>>>>>>>>>> So now, do we want to do more in the WG charter than just =
make progressing segment routing architecture and uses cases document =
and ensure coordination for the standardization of this technology ?
>>>>>>>>>>=20
>>>>>>>>>> Do we want to standardize other technologies in this WG ? I =
don't think so, based on Stewart's conclusion email from the BOF :"A new =
WG focused solely on SR therefore needs to be create"
>>>>>>>>>>=20
>>>>>>>>>> If the WG charter is limited to source routing, how will we =
handle the "non source routing" use cases of segment routing ? In =
another working group ? So we will go back to the WG synchronization =
issue that has been raised for this technology ...
>>>>>>>>>>=20
>>>>>>>>>> If the WG is focused on SR, let's use a name in relation with =
SR.
>>>>>>>>>>=20
>>>>>>>>>> Feedback ?
>>>>>>>>>>=20
>>>>>>>>>>=20
>>>>>>>>>> Stephane
>>>>>>>>>>=20
>>>>>>>>>>=20
>>>>>>>>>> -----Message d'origine-----
>>>>>>>>>> De : AshwoodsmithPeter [mailto:[email-masked]]
>>>>>>>>>> Envoy=E9 : mardi 3 septembre 2013 15:27 =C0 : LITKOWSKI =
Stephane
>>>>>>>>>> DTF/DERX Cc : John E Drake; Mark Townsley; Victor Kuarsingh;
>>>>>>>>>> Roberta Maglione (robmgl); John G. Scudder; Adrian Farrel;
>>>>>>>>>> Alvaro Retana (aretana); [email-masked]; Stewart Bryant =
(stbryant) Objet : Re:
>>>>>>>>>> [Status] Summary of STATUS BOF and the next steps
>>>>>>>>>>=20
>>>>>>>>>> The term "source routing" has been around for a very long =
time and is data path agnostic. Its also the term used in the literature =
etc so my preference is to stick with this existing well known and data =
path agnostic term.
>>>>>>>>>>=20
>>>>>>>>>> Peter
>>>>>>>>>>=20
>>>>>>>>>> On Sep 3, 2013, at 9:07 AM, "[email-masked]" =
<[email-masked]> wrote:
>>>>>>>>>>=20
>>>>>>>>>>> Hi,
>>>>>>>>>>>=20
>>>>>>>>>>> "Source routing" is just a subcase of segment routing ... as =
it is for IP routing ...
>>>>>>>>>>>=20
>>>>>>>>>>> Stephane
>>>>>>>>>>>=20
>>>>>>>>>>>=20
>>>>>>>>>>> -----Message d'origine-----
>>>>>>>>>>> De : [email-masked] =
[mailto:[email-masked]]
>>>>>>>>>>> De la part de John E Drake Envoy=E9 : mardi 3 septembre 2013 =
15:02 =C0 :
>>>>>>>>>>> Mark Townsley; Victor Kuarsingh Cc : Roberta Maglione =
(robmgl); John G.
>>>>>>>>>>> Scudder; Alvaro Retana (aretana); Adrian Farrel;
>>>>>>>>>>> [email-masked]; Stewart Bryant (stbryant) Objet : Re:
>>>>>>>>>>> [Status] Summary of STATUS BOF and the next steps
>>>>>>>>>>>=20
>>>>>>>>>>> Hi,
>>>>>>>>>>>=20
>>>>>>>>>>> What is this 'segment routing' silliness?  The correct term =
is 'source routing'.
>>>>>>>>>>>=20
>>>>>>>>>>> Yours Irrespectively,
>>>>>>>>>>>=20
>>>>>>>>>>> John
>>>>>>>>>>>=20
>>>>>>>>>>>> -----Original Message-----
>>>>>>>>>>>> From: [email-masked]
>>>>>>>>>>>> [mailto:[email-masked]] On Behalf Of Mark Townsley
>>>>>>>>>>>> Sent: Sunday, September 01, 2013 10:08 AM
>>>>>>>>>>>> To: Victor Kuarsingh
>>>>>>>>>>>> Cc: Roberta Maglione (robmgl); John G. Scudder; Adrian
>>>>>>>>>>>> Farrel; Alvaro Retana (aretana); [email-masked]; Stewart
>>>>>>>>>>>> Bryant
>>>>>>>>>>>> (stbryant)
>>>>>>>>>>>> Subject: Re: [Status] Summary of STATUS BOF and the next
>>>>>>>>>>>> steps
>>>>>>>>>>>>=20
>>>>>>>>>>>>=20
>>>>>>>>>>>> On Sep 1, 2013, at 5:38 PM, Victor Kuarsingh wrote:
>>>>>>>>>>>>=20
>>>>>>>>>>>>> All,
>>>>>>>>>>>>>=20
>>>>>>>>>>>>> I would also favour "Segment Routing WG" as well.
>>>>>>>>>>>>>=20
>>>>>>>>>>>>> I note this since attempting to come up with an all
>>>>>>>>>>>>> encompassing acronym will be difficult and Segment Routing
>>>>>>>>>>>>> is generic enough to associate to multiple functions.
>>>>>>>>>>>>=20
>>>>>>>>>>>> Then we can just use "segroute" for the short name. WGs do
>>>>>>>>>>>> not have to have acronyms, but they do need to have an
>>>>>>>>>>>> 8-char limited short name for the various automated tools =
not to break.
>>>>>>>>>>>>=20
>>>>>>>>>>>> - Mark
>>>>>>>>>>>>=20
>>>>>>>>>>>>>=20
>>>>>>>>>>>>> Regards,
>>>>>>>>>>>>>=20
>>>>>>>>>>>>> Victor K
>>>>>>>>>>>>>=20
>>>>>>>>>>>>>=20
>>>>>>>>>>>>>=20
>>>>>>>>>>>>> On 2013-08-31 6:51 PM, "Roberta Maglione (robmgl)"
>>>>>>>>>>>>> <[email-masked]>
>>>>>>>>>>>>> wrote:
>>>>>>>>>>>>>=20
>>>>>>>>>>>>>> +1 for Segment Routing WG
>>>>>>>>>>>>>>=20
>>>>>>>>>>>>>> Roberta
>>>>>>>>>>>>>>=20
>>>>>>>>>>>>>> Sent from my iPad
>>>>>>>>>>>>>>=20
>>>>>>>>>>>>>> On 2013-08-30, at 2:55 PM, "Alvaro Retana (aretana)"
>>>>>>>>>>>>>> <[email-masked]>
>>>>>>>>>>>>>> wrote:
>>>>>>>>>>>>>>=20
>>>>>>>>>>>>>>> Segment Routing WG
>>>>>>>>>>>>>>>=20
>>>>>>>>>>>>>>> Sent from my iPhone
>>>>>>>>>>>>>>>=20
>>>>>>>>>>>>>>> On Aug 30, 2013, at 1:39 PM, "Stewart Bryant (stbryant)"
>>>>>>>>>>>>>>> <[email-masked]> wrote:
>>>>>>>>>>>>>>>=20
>>>>>>>>>>>>>>>> The second task, which hopefully should be relatively
>>>>>>>>>>>>>>>> easy, is to find a better working name for the WG, =
since
>>>>>>>>>>>>>>>> it has been put to me a number of times that STATUS is
>>>>>>>>>>>>>>>> going to be confusing in text and a difficult search =
term.
>>>>>>>>>>>>>>> _______________________________________________
>>>>>>>>>>>>>>> status mailing list
>>>>>>>>>>>>>>> [email-masked]
>>>>>>>>>>>>>>> https://www.ietf.org/mailman/listinfo/status
>>>>>>>>>>>>>> _______________________________________________
>>>>>>>>>>>>>> status mailing list
>>>>>>>>>>>>>> [email-masked]
>>>>>>>>>>>>>> https://www.ietf.org/mailman/listinfo/status
>>>>>>>>>>>>>=20
>>>>>>>>>>>>>=20
>>>>>>>>>>>>> _______________________________________________
>>>>>>>>>>>>> status mailing list
>>>>>>>>>>>>> [email-masked]
>>>>>>>>>>>>> https://www.ietf.org/mailman/listinfo/status
>>>>>>>>>>>>=20
>>>>>>>>>>>> _______________________________________________
>>>>>>>>>>>> status mailing list
>>>>>>>>>>>> [email-masked]
>>>>>>>>>>>> https://www.ietf.org/mailman/listinfo/status
>>>>>>>>>>>=20
>>>>>>>>>>>=20
>>>>>>>>>>> _______________________________________________
>>>>>>>>>>> status mailing list
>>>>>>>>>>> [email-masked]
>>>>>>>>>>> https://www.ietf.org/mailman/listinfo/status
>>>>>>>>>>>=20
>>>>>>>>>>> =
_____________________________________________________________
>>>>>>>>>>> ____ _ _ _ __
>>>>>>>>>>> ___________________________________________________
>>>>>>>>>>>=20
>>>>>>>>>>> Ce message et ses pieces jointes peuvent contenir des
>>>>>>>>>>> informations confidentielles ou privilegiees et ne doivent
>>>>>>>>>>> donc pas etre diffuses, exploites ou copies sans
>>>>>>>>>>> autorisation. Si vous avez recu ce message par erreur, =
veuillez le signaler a l'expediteur et le detruire ainsi que les pieces =
jointes. Les messages electroniques etant susceptibles d'alteration, =
Orange decline toute responsabilite si ce message a ete altere, deforme =
ou falsifie. Merci.
>>>>>>>>>>>=20
>>>>>>>>>>> This message and its attachments may contain confidential or
>>>>>>>>>>> privileged information that may be protected by law; they =
should not be distributed, used or copied without authorisation.
>>>>>>>>>>> If you have received this email in error, please notify the =
sender and delete this message and its attachments.
>>>>>>>>>>> As emails may be altered, Orange is not liable for messages =
that have been modified, changed or falsified.
>>>>>>>>>>> Thank you.
>>>>>>>>>>>=20
>>>>>>>>>>> _______________________________________________
>>>>>>>>>>> status mailing list
>>>>>>>>>>> [email-masked]
>>>>>>>>>>> https://www.ietf.org/mailman/listinfo/status
>>>>>>>>>>=20
>>>>>>>>>> =
______________________________________________________________
>>>>>>>>>> ____ _ _ _
>>>>>>>>>> ____________________________________________________
>>>>>>>>>>=20
>>>>>>>>>> Ce message et ses pieces jointes peuvent contenir des
>>>>>>>>>> informations confidentielles ou privilegiees et ne doivent
>>>>>>>>>> donc pas etre diffuses, exploites ou copies sans =
autorisation.
>>>>>>>>>> Si vous avez recu ce message par erreur, veuillez le signaler =
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages =
electroniques etant susceptibles d'alteration, Orange decline toute =
responsabilite si ce message a ete altere, deforme ou falsifie. Merci.
>>>>>>>>>>=20
>>>>>>>>>> This message and its attachments may contain confidential or
>>>>>>>>>> privileged information that may be protected by law; they =
should not be distributed, used or copied without authorisation.
>>>>>>>>>> If you have received this email in error, please notify the =
sender and delete this message and its attachments.
>>>>>>>>>> As emails may be altered, Orange is not liable for messages =
that have been modified, changed or falsified.
>>>>>>>>>> Thank you.
>>>>>>>>>>=20
>>>>>>>>>> _______________________________________________
>>>>>>>>>> status mailing list
>>>>>>>>>> [email-masked]
>>>>>>>>>> https://www.ietf.org/mailman/listinfo/status
>>>>>>>>>> _______________________________________________
>>>>>>>>>> status mailing list
>>>>>>>>>> [email-masked]
>>>>>>>>>> https://www.ietf.org/mailman/listinfo/status
>>>>>>>>>>=20
>>>>>>>>>=20
>>>>>>>>> --
>>>>>>>>>=20
>>>>>>>>>=20
>>>>>>>>> Loa Andersson                        email: =
[email-masked]
>>>>>>>>> Senior MPLS Expert                          [email-masked]
>>>>>>>>> Huawei Technologies (consultant)     phone: +46 739 81 21 64
>>>>>>>>> _______________________________________________
>>>>>>>>> status mailing list
>>>>>>>>> [email-masked]
>>>>>>>>> https://www.ietf.org/mailman/listinfo/status
>>>>>>>>>=20
>>>>>>>>>=20
>>>>>>>>=20
>>>>>>>>=20
>>>>>>>> _______________________________________________
>>>>>>>> status mailing list
>>>>>>>> [email-masked]
>>>>>>>> https://www.ietf.org/mailman/listinfo/status
>>>>>>>>=20
>>>>>>>> =
________________________________________________________________
>>>>>>>> ____ _ _ ___________________________________________________
>>>>>>>>=20
>>>>>>>> Ce message et ses pieces jointes peuvent contenir des
>>>>>>>> informations confidentielles ou privilegiees et ne doivent donc
>>>>>>>> pas etre diffuses, exploites ou copies sans autorisation. Si
>>>>>>>> vous avez recu ce message par erreur, veuillez le signaler a =
l'expediteur et le detruire ainsi que les pieces jointes. Les messages =
electroniques etant susceptibles d'alteration, Orange decline toute =
responsabilite si ce message a ete altere, deforme ou falsifie. Merci.
>>>>>>>>=20
>>>>>>>> This message and its attachments may contain confidential or
>>>>>>>> privileged information that may be protected by law; they =
should not be distributed, used or copied without authorisation.
>>>>>>>> If you have received this email in error, please notify the =
sender and delete this message and its attachments.
>>>>>>>> As emails may be altered, Orange is not liable for messages =
that have been modified, changed or falsified.
>>>>>>>> Thank you.
>>>>>>>>=20
>>>>>>>>=20
>>>>>>>>=20
>>>>>>>=20
>>>>>>>=20
>>>>>>>=20
>>>>>>> =
_________________________________________________________________
>>>>>>> ____ _ ___________________________________________________
>>>>>>>=20
>>>>>>> Ce message et ses pieces jointes peuvent contenir des
>>>>>>> informations confidentielles ou privilegiees et ne doivent donc
>>>>>>> pas etre diffuses, exploites ou copies sans autorisation. Si =
vous
>>>>>>> avez recu ce message par erreur, veuillez le signaler a =
l'expediteur et le detruire ainsi que les pieces jointes. Les messages =
electroniques etant susceptibles d'alteration, Orange decline toute =
responsabilite si ce message a ete altere, deforme ou falsifie. Merci.
>>>>>>>=20
>>>>>>> This message and its attachments may contain confidential or
>>>>>>> privileged information that may be protected by law; they should =
not be distributed, used or copied without authorisation.
>>>>>>> If you have received this email in error, please notify the =
sender and delete this message and its attachments.
>>>>>>> As emails may be altered, Orange is not liable for messages that =
have been modified, changed or falsified.
>>>>>>> Thank you.
>>>>>>>=20
>>>>>>> _______________________________________________
>>>>>>> status mailing list
>>>>>>> [email-masked]
>>>>>>> https://www.ietf.org/mailman/listinfo/status
>>>>>>=20
>>>>>>=20
>>>>>> =
__________________________________________________________________
>>>>>> ____ ___________________________________________________
>>>>>>=20
>>>>>> Ce message et ses pieces jointes peuvent contenir des =
informations
>>>>>> confidentielles ou privilegiees et ne doivent donc pas etre
>>>>>> diffuses, exploites ou copies sans autorisation. Si vous avez =
recu
>>>>>> ce message par erreur, veuillez le signaler a l'expediteur et le =
detruire ainsi que les pieces jointes. Les messages electroniques etant =
susceptibles d'alteration, Orange decline toute responsabilite si ce =
message a ete altere, deforme ou falsifie. Merci.
>>>>>>=20
>>>>>> This message and its attachments may contain confidential or
>>>>>> privileged information that may be protected by law; they should =
not be distributed, used or copied without authorisation.
>>>>>> If you have received this email in error, please notify the =
sender and delete this message and its attachments.
>>>>>> As emails may be altered, Orange is not liable for messages that =
have been modified, changed or falsified.
>>>>>> Thank you.
>>>>>>=20
>>>>>=20
>>>>>=20
>>>>> =
___________________________________________________________________
>>>>> ______________________________________________________
>>>>>=20
>>>>> Ce message et ses pieces jointes peuvent contenir des informations
>>>>> confidentielles ou privilegiees et ne doivent donc pas etre
>>>>> diffuses, exploites ou copies sans autorisation. Si vous avez recu
>>>>> ce message par erreur, veuillez le signaler a l'expediteur et le =
detruire ainsi que les pieces jointes. Les messages electroniques etant =
susceptibles d'alteration, Orange decline toute responsabilite si ce =
message a ete altere, deforme ou falsifie. Merci.
>>>>>=20
>>>>> This message and its attachments may contain confidential or
>>>>> privileged information that may be protected by law; they should =
not be distributed, used or copied without authorisation.
>>>>> If you have received this email in error, please notify the sender =
and delete this message and its attachments.
>>>>> As emails may be altered, Orange is not liable for messages that =
have been modified, changed or falsified.
>>>>> Thank you.
>>>>>=20
>>>>=20
>>>>=20
>>>>=20
>>>=20
>>>=20
>>=20
>>=20
>>=20
>=20
>=20
>=20
> =
__________________________________________________________________________=
_______________________________________________
>=20
> Ce message et ses pieces jointes peuvent contenir des informations =
confidentielles ou privilegiees et ne doivent donc
> pas etre diffuses, exploites ou copies sans autorisation. Si vous avez =
recu ce message par erreur, veuillez le signaler
> a l'expediteur et le detruire ainsi que les pieces jointes. Les =
messages electroniques etant susceptibles d'alteration,
> Orange decline toute responsabilite si ce message a ete altere, =
deforme ou falsifie. Merci.
>=20
> This message and its attachments may contain confidential or =
privileged information that may be protected by law;
> they should not be distributed, used or copied without authorisation.
> If you have received this email in error, please notify the sender and =
delete this message and its attachments.
> As emails may be altered, Orange is not liable for messages that have =
been modified, changed or falsified.
> Thank you.
>=20
> _______________________________________________
> status mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/status
>=20
>=20

From: "Stefano Previdi (sprevidi)" <[email-masked]>
To: Xuxiaohu <[email-masked]>
Date: Wed, 11 Sep 2013 10:37:45 +0000
Accept-Language: en-US
Cc: Stephane Litkowski <[email-masked]>, Rob Shakir <[email-masked]>, "[email-masked]" <[email-masked]>, Hannes Gredler <[email-masked]>
Subject: Re: [Status] Good charter proposals from Hannes and Stefano : try to merge ...

From: <[email-masked]>
To: Hannes Gredler <[email-masked]>, Stefano Previdi <[email-masked]>
Date: Wed, 11 Sep 2013 11:53:32 +0200
Accept-Language: fr-FR
acceptlanguage: fr-FR
Cc: Rob Shakir <[email-masked]>, "[email-masked]" <[email-masked]>
Subject: Re: [Status] Good charter proposals from Hannes and Stefano : try to merge ...

Hannes,

Regarding "Service chaining", I would agree to not mention it directly in t=
he charter (it's not mentionned explictly in my last proposal) BUT I don't =
want to close the door to other "action types" than forwarding. That's why =
using the wording "node" , "steering packets" seems to be good because it's=
 large enough to address use cases that are not detailled today (for exampl=
e service chaining).

So my approach would be , keep it large in definition using the proposed wo=
rding and then the use case analysis (in the work items) will give us what =
we need to address exactly.

Does it make sense for you to use this way ?

Thanks,

Stephane

-----Message d'origine-----
De : Hannes Gredler [mailto:[email-masked]]
Envoy=E9 : mercredi 11 septembre 2013 08:15
=C0 : Stefano Previdi
Cc : LITKOWSKI Stephane DTF/DERX; Rob Shakir; [email-masked]
Objet : Re: [Status] Good charter proposals from Hannes and Stefano : try t=
o merge ...

stefano,

On Sep 10, 2013, at 7:34 PM, Stefano Previdi (sprevidi) wrote:

> Hannes,
>
> On Sep 10, 2013, at 7:27 PM, Hannes Gredler wrote:
>> stefano,
>>
>> On Sep 10, 2013, at 6:58 PM, Stefano Previdi (sprevidi) wrote:
>>
>>>
>>> On Sep 10, 2013, at 1:25 PM, <[email-masked]> wrote:
>>>
>>>> Agree on all proposal except :
>>>>
>>>> "[SP] The architecture will support tunnel and non-tunnel paradigms
>>>> The architecture will support multiple dataplanes: MPLS and V6"
>>>>
>>>> I don't see the reason for this ... IMHO, the gap analysis and
>>>> requirements inventory will result on saying or not
>>>
>>>
>>> [SP] While I understand what brought the following statements
>>>   in the proposed charter:
>>>     "Having identified use-cases, architecture and security,
>>>      the WG will identify gaps between currently available
>>>      technologies and use-case requirements.
>>>      The WG will then define requirements for extensions to
>>>      existing protocols or new protocols that address gaps
>>>      that are identified."
>>>
>>>   I'd like to point out with better precision what are the
>>>   directions we are ALREADY engaged into: dataplanes and
>>>   paradigms. As I mentioned in my charter proposal, we do have
>>>   implementations and multi-vendor interoperability tests will
>>>   happen soon. So, I just want to be sure we don't ignore this
>>>   reality.
>>
>> HG> just because you have an implementation for <foo> does not
>> HG> constitute
>>   community interest. we are trying to build here a charter that
>>   matches what a broader community wants. if the use-case that you're co=
ncerned
>>   about (service-chaining and a new internet data plane #4) are compelli=
ng
>>   enough the group will work on it, but mandating that into the charter,
>>   without asking the though questions first seems a wrong start to me.
>
>
> [SP] Sorry to contradict but it's the exact opposite. If a group
>     of vendors decide to invest in implementations is because
>     they received, analyzed, processed a set of requirements
>     coming for operators who know pretty well what they do, what
>     they want to deploy and the technology they want the vendors
>     to deliver. This fits the definition of "community interest".

HG> interestingly enough i haven't encountered a network operator so
    far who says 'i need SR for service chaining' nor
    we had somebody asking for this in the 'operator use case' slots
    in Berlin. - So who are they ? - can you manage such that
    they speak up and make their case ?

>     My point is that I strongly _suggest_ IETF WG (any) not to
>     neglect these facts and not write a down a charter ...
 [ ... ]

HG> i'd like to have some proof point for your 'facts' prior
    to making 'service chaining' a charter item.

>     Having said that, whoever does NOT believe in the benefit of
>     a newly proposed technology, is always free to not implement
>     it and to not deploy it.

HG> that is fine and well understood, but since you have a desire to
    standardize your 'newly proposed technology' you also need to play
    a bit by the rules.

>>>> : we must use tunnels and/or non tunnels, and the following dataplanes=
 ... But I don't see the reason to put solutions directly in the charter ...
>>>
>>>
>>> these are not solutions these are way to avoid boundaries in the
>>> framework.
>>>
>>> Thanks.
>>> s.
>>>
>>>
>>>> Could you explain your point ?
>>>>
>>>>
>>>> updated with the other comments :
>>>>
>>>> -------------------------------------------------------------------
>>>> Name: <TBD>
>>>> Charter:
>>>>
>>>>
>>>> Introduction
>>>> ------------
>>>> The following use cases:
>>>> . Path computation based on awareness of utilization or performance
>>>> data, within both centralized and distributed environments, . Multi-to=
pology (dual planes, disjoint trees), . Simplification and reduction of sig=
naling components (scaling), . Combined application and network layer path =
specification, . Full coverage LFA-FRR, . Topology Aware OAM, . etc.
>>>>
>>>> have triggered work on the definition of new architecture and protocol=
 extensions allowing to combine well known shortest path based routing para=
digms with source/explicit routing methods. Some of these extensions have b=
een implemented already.
>>>>
>>>>
>>>> Objective
>>>> ---------
>>>>
>>>> Define an architecture where a node can steer a packet through a netwo=
rk or set of networks (interdomain) on any path without requiring to mainta=
in state along the path, other than in the ingress node.
>>>>
>>>> A node may be any type of device including routers or appliances.
>>>>
>>>> In this architecture, nodes sharing a common trust model form a <Name-=
TBD> domain. The architecture defined by this working group will allow a no=
de to steer a packet between any source and destination node within the <Na=
me-TBD> domain (formed of one or more networks), on any path (shortest, non=
-shortest, explicit or based on other characteristics specified by segment =
identifiers).
>>>>
>>>> It may then send any packet that passes through it through any path
>>>> that it has specified and that is conform to the security rules.
>>>> Downstream nodes along the path within the <Name-TBD> domain
>>>> forward the packet by using the informations inserted by the node
>>>> at the head-end
>>>>
>>>> The architecture should support centralized and distributed path compu=
tation.
>>>>
>>>> The architecture should support OAM functions.
>>>>
>>>> The architecture should allow different mechanisms through which  a
>>>> path is constructed. SR allows a variety of mechanisms, not
>>>> confined IGP/BGP path computation.
>>>>
>>>> As MPLS dataplane is largely deployed, the <Name-TBD> WG should avoid =
any modification in the MPLS dataplane when defining the architecture.
>>>>
>>>>
>>>> Work items :
>>>> ------------------
>>>>
>>>> The <Name-TBD> working group is chartered for the following ordered li=
st of work items:
>>>>
>>>> - The first goal of the WG is to identify use-cases.
>>>> - The WG will then define the architecture framework associated
>>>> with the security considerations. The architecture framework and
>>>> security considerations must address the relations between networks fo=
rming the <Name-TBD> domain (interAS).
>>>> - Having identified use-cases, architecture and security, the WG
>>>> will identify gaps between currently available technologies and
>>>> use-case requirements.
>>>> - The WG will then define requirements for extensions to existing
>>>> protocols or new protocols that address gaps that are identified.
>>>> - The WG will first focus on the intra-domain forwarding definition.
>>>>
>>>>
>>>> Documents :
>>>> ------------------
>>>> . Use Cases
>>>> . Architecture including security considerations
>>>> - Protocol extension requirements
>>>> . Interoperability Report
>>>>
>>>>
>>>> Required protocol extensions are carried out in working groups respons=
ible (ISIS,OSPF,BGP,PCEP ...). Work on new protocols may be carried out by =
the <Name-TBD> WG.
>>>>
>>>> -----Message d'origine-----
>>>> De : Stefano Previdi (sprevidi) [mailto:[email-masked]] Envoy=E9
>>>> : mardi 10 septembre 2013 12:30 =C0 : LITKOWSKI Stephane DTF/DERX;
>>>> Rob Shakir Cc : Hannes Gredler; [email-masked] Objet : Re:
>>>> [Status] Good charter proposals from Hannes and Stefano : try to merge=
 ...
>>>>
>>>> Hi Stephane, Rob,
>>>>
>>>> one preliminary remark: I prefer to use he therm "node" rather than "r=
outer". Use cases, such as Service Chaining requires that terminology.
>>>>
>>>> some other comments below...
>>>>
>>>>
>>>> On Sep 10, 2013, at 11:19 AM, <[email-masked]> wrote:
>>>>> Souns good to me, (adding OAM also)
>>>>>
>>>>> New recap :
>>>>>
>>>>> ------------------------------------------------------------------
>>>>> -
>>>>> Name: <TBD>
>>>>> Charter:
>>>>>
>>>>>
>>>>> Introduction
>>>>> ------------
>>>>> The following use cases:
>>>>> . Path computation based on awareness of utilization or
>>>>> performance data, within both centralized and distributed environment=
s, . Multi-topology (dual planes, disjoint trees), . Simplification and red=
uction of signaling components (scaling), . Combined application and networ=
k layer path specification, . Full coverage LFA-FRR, . Topology Aware OAM, =
. etc.
>>>>>
>>>>> have triggered work on the definition of new architecture and protoco=
l extensions allowing to combine well known shortest path based routing par=
adigms with source/explicit routing methods. Some of these extensions have =
been implemented already.
>>>>>
>>>>>
>>>>> Objective
>>>>> ---------
>>>>>
>>>>> Define an architecture where a node can steer a packet through a netw=
ork or set of networks (interdomain) on any path.
>>>>
>>>>
>>>> [SP] As stated above, I'm fine with the above definition but I
>>>> assume this includes service chaining and that by "network  or set
>>>> of networks" you intend "nodes" which may include  others things
>>>> than just routers.
>>>>
>>>> [SLI] Agree
>>>>
>>>>
>>>>> In this architecture, routers sharing a common trust model form a <Na=
me-TBD> domain. The architecture defined by this working group will allow a=
 node to steer a packet between any source and destination node within the =
<Name-TBD> domain (formed of one or more networks), on any path (shortest, =
non-shortest, explicit or based on other characteristics specified by segme=
nt identifiers).
>>>>
>>>>
>>>> [SP] without requiring to maintain state along the path, other
>>>> than in the ingress node.
>>>>
>>>> [SLI] Agree
>>>>
>>>>
>>>>> It may then send any packet that passes through it through any path t=
hat it has specified and that is conform to the security rules. Downstream =
routers along the path within the <Name-TBD> domain forward the packet as s=
pecified by the router at the head-end of the path.
>>>>
>>>>>
>>>>> The architecture should support centralized and distributed path comp=
utation.
>>>>>
>>>>> The architecture should support OAM functions.
>>>>
>>>>
>>>> [SP] The architecture should allow different mechanisms through
>>>> which  a path is constructed. SR allows a variety of mechanisms,
>>>> not  confined IGP/BGP path computation.
>>>>
>>>> [SLI] Agree
>>>>
>>>>> Work items :
>>>>> ------------------
>>>>>
>>>>> The <Name-TBD> working group is chartered for the following ordered l=
ist of work items:
>>>>>
>>>>> - The first goal of the WG is to identify use-cases.
>>>>> - The WG will then define the architecture framework associated
>>>>> with the security considerations. The architecture framework and
>>>>> security considerations must address the relations between networks f=
orming the <Name-TBD> domain (interAS).
>>>>> - Having identified use-cases, architecture and security, the WG
>>>>> will identify gaps between currently available technologies and
>>>>> use-case requirements.
>>>>> - The WG will then define requirements for extensions to existing
>>>>> protocols or new protocols that address gaps that are identified.
>>>>> - The WG will first focus on the intra-domain forwarding definition.
>>>>
>>>>
>>>> [SP] The architecture will support tunnel and non-tunnel paradigms
>>>> The architecture will support multiple dataplanes: MPLS and V6
>>>>
>>>>
>>>> Thanks.
>>>> s.
>>>>
>>>>
>>>>> Documents :
>>>>> ------------------
>>>>> . Use Cases
>>>>> . Architecture including security considerations
>>>>> - Protocol extension requirements
>>>>> . Interoperability Report
>>>>>
>>>>>
>>>>> Protocol work may be carried out in this working group or in other wo=
rking groups responsible for the protocols (ISIS,OSPF,BGP,PCEP ...), in coo=
rdination with this WG, and in agreement with the WG chairs and responsible=
 ADs.
>>>>>
>>>>> -----Message d'origine-----
>>>>> De : Rob Shakir [mailto:[email-masked]] Envoy=E9 : mardi 10 septembre
>>>>> 2013 11:05 =C0 : LITKOWSKI Stephane DTF/DERX Cc : Hannes Gredler;
>>>>> Stefano Previdi (sprevidi); [email-masked] Objet
>>>>> : Re: [Status] Good charter proposals from Hannes and Stefano : try t=
o merge ...
>>>>>
>>>>> Hi Stephane,
>>>>>
>>>>> Thanks for this, looks good! Comments in-line marked rjs>.
>>>>>
>>>>> On 10 Sep 2013, at 08:50, <[email-masked]> wrote:
>>>>>
>>>>>> Hi all,
>>>>>>
>>>>>> I'm creating a new mail topic because the "Summary of STATUS BOF ..."
>>>>>> starts to be unreadable :)
>>>>>>
>>>>>> Hannes and Stefano send to us two charter proposals that sounds good=
 to me.
>>>>>>
>>>>>> The main difference between the two proposals is that Stefano propos=
e a segment bound to any type of instruction (forwarding, application or se=
rvice based) while Hannes is focusing on forwarding actions (which is the f=
irst priority, and I think everybody agree on this).
>>>>>
>>>>> rjs> Agreed -- I think it would be useful to allow definitions of seg=
ments to identify different types of "service", since there appear to be so=
me use cases (e.g., the explicit exit selection case) which require a segme=
nt type describing something that is not explicitly IGP-based.
>>>>>
>>>>>>
>>>>>> It would be interresting to have a feedback from the mailinglist on =
this specific point.
>>>>>>
>>>>>> IMHO, there is a strong interrest to explore the service actions bou=
nd to segment in a second step keeping forwarding as a priority.
>>>>>>
>>>>>> Apart of this problem, here is a merge try of the two good proposals=
 (I'm putting '<>' on hot topics :) ) :
>>>>>>
>>>>>>
>>>>>> -----------------------------------------------------------------
>>>>>> --
>>>>>> Name: <TBD>
>>>>>> Charter:
>>>>>>
>>>>>>
>>>>>> Introduction
>>>>>> ------------
>>>>>> The following use cases:
>>>>>> . Path computation based on awareness of utilization or
>>>>>> performance data, within both centralized and distributed environmen=
ts, . Multi-topology (dual planes, disjoint trees), . Simplification and re=
duction of signaling components (scaling), . Combined application and netwo=
rk layer path specification, . Full coverage LFA-FRR, . Topology Aware OAM,=
 . etc.
>>>>>>
>>>>>> have triggered work on the definition of new architecture and protoc=
ol extensions allowing to combine well known shortest path based routing pa=
radigms with source/explicit routing methods. Some of these extensions have=
 been implemented already.
>>>>>>
>>>>>>
>>>>>> Objective
>>>>>> ---------
>>>>>>
>>>>>> Define an architecture where a node can steer a packet through a net=
work or set of networks (interdomain) on any path (shortest, non shortest, =
explicit, <service or application>).
>>>>>>
>>>>>> In this architecture, routers are sharing a common trust model and a=
re forming a <Name-TBD> domain.
>>>>>> Within this domain, a node can specify a path between itself and any=
 destination in the domain. <The path may be a forwarding path, a service c=
haining path or a combination of both>.
>>>>>
>>>>> rjs> To clarify here, we define that our domain is under a common tru=
st model (essentially, under common administrative control?), but then go o=
n to talk about inter-domain elsewhere. Can we perhaps clarify (by defining=
 a specific "<Name-TBD> domain" nomenclature) and say something like:
>>>>>
>>>>> "In this architecture, routers sharing a common trust model form a <N=
ame-TBD> domain. The architecture defined by this working group will allow =
a node to steer a packet between any source and destination node within the=
 <Name-TBD> domain (formed of one or more networks), on any path (shortest,=
 non-shortest, explicit or based on other characteristics specified by segm=
ent identifiers)."
>>>>>
>>>>>> It may then send any packet that passes through it through any path =
that it has specified and that is conform to the security rules. Downstream=
 routers along the path within the <Name-TBD> domain forward the packet as =
specified by the router at the head-end of the path.
>>>>>>
>>>>>> The architecture should support centralized and distributed path com=
putation.
>>>>>>
>>>>>>
>>>>>> Work items :
>>>>>> ------------------
>>>>>>
>>>>>> The <Name-TBD> working group is chartered for the following ordered =
list of work items:
>>>>>>
>>>>>> - The first goal of the WG is to identify use-cases.
>>>>>> - The WG will then define the architecture framework associated
>>>>>> with the security considerations. The architecture framework and
>>>>>> security considerations must address the relations between domains (=
inter domain).
>>>>>
>>>>> rjs> And then here "networks forming the <Name-TBD> domain"?
>>>>>
>>>>> Thanks for the efforts,
>>>>> r.
>>>>>
>>>>>> - Having identified use-cases, architecture and security, the WG
>>>>>> will identify gaps between currently available technologies and
>>>>>> use-case requirements.
>>>>>> - The WG will then define requirements for extensions to existing
>>>>>> protocols or new protocols that address gaps that are identified.
>>>>>> - The WG will first focus on the intra-domain forwarding definition.
>>>>>>
>>>>>>
>>>>>> Documents :
>>>>>> ------------------
>>>>>> . Use Cases
>>>>>> . Architecture including security considerations
>>>>>> - Protocol extension requirements . Interoperability Report
>>>>>>
>>>>>>
>>>>>> Protocol work may be carried out in this working group or in other w=
orking groups responsible for the protocols (ISIS,OSPF,BGP,PCEP ...), in co=
ordination with this WG, and in agreement with the WG chairs and responsibl=
e ADs.
>>>>>>
>>>>>>
>>>>>>
>>>>>> Hope it helps to progress on the definition.
>>>>>>
>>>>>>
>>>>>> Stephane
>>>>>>
>>>>>>
>>>>>> -----Message d'origine-----
>>>>>> De : Hannes Gredler [mailto:[email-masked]] Envoy=E9 : vendredi
>>>>>> 6 septembre 2013 18:27 =C0 : LITKOWSKI Stephane DTF/DERX Cc :
>>>>>> [email-masked] Objet : Re: [Status] Summary of STATUS BOF and
>>>>>> the next steps
>>>>>>
>>>>>> hi stephane,
>>>>>>
>>>>>> here is a revised draft charter as per your comments.
>>>>>>
>>>>>> ---
>>>>>>
>>>>>> <Name-TBD> domain contains a set of routers with the following
>>>>>> characteristics:
>>>>>>
>>>>>> - They form a connected network
>>>>>> - They can forward traffic through any path within the network
>>>>>> using shortest path, or any other (e.g., an explicit) path
>>>>>> - They share a common trust model. In this model, any router
>>>>>> within the domain can specify a path between itself and any other
>>>>>> router  in the domain. It may then send any packet that passes
>>>>>> through it through any path that it has specified and that is
>>>>>> conform to the security rules. Downstream routers along the path
>>>>>> within the <Name-TBD>  domain forward the packet as specified by
>>>>>> the router at the head-end  of the path.
>>>>>>
>>>>>> The <Name-TBD> working group is chartered for the following ordered =
list of work items:
>>>>>>
>>>>>> - The first goal of the WG is to identify use-cases.
>>>>>> - The WG will then define the architecture framework associated
>>>>>> with the security considerations. The architecture framework and
>>>>>> security considerations must address the relations between domains (=
interdomain).
>>>>>> - Having identified use-cases, architecture and security, the WG
>>>>>> will identify gaps between currently available technologies and
>>>>>> use-case requirements.
>>>>>> - The WG will then define requirements for extensions to existing
>>>>>> protocols or new protocols that address gaps that are identified.
>>>>>> - The WG will first focus on the intra-domain forwarding definition.
>>>>>>
>>>>>> Protocol work may be carried out in this working group or in other w=
orking groups responsible for the protocols, in coordination with this WG, =
and in agreement with the WG chairs and responsible ADs.
>>>>>> However, no protocol work will be adopted by a working group to addr=
ess the identified use-cases until the requirements document motivating the=
 protocol work has been sent to the IESG for publication as an RFC.
>>>>>>
>>>>>> ---
>>>>>>
>>>>>> /hannes
>>>>>>
>>>>>> On Sep 4, 2013, at 10:02 AM, <[email-masked]> <stepha=
[email-masked]> wrote:
>>>>>>
>>>>>>> Hannes,
>>>>>>>
>>>>>>> In case, we are using only directed forwarding (adjacency
>>>>>>> segment), could we still talk about tunneling ? (it's a very very s=
mall tunnel) Moreover talking about "stacking" is really dataplane agnostic=
 (MPLS) ...
>>>>>>>
>>>>>>> In the proposed segment routing architectural concepts, segments ar=
e at the same "level" and pointer moves on the segment list, then the MPLS =
instantiation is performing this using stacking ...
>>>>>>>
>>>>>>> IMHO, if we use "Stacked Tunnels", we already talk about a chosen s=
olution and it's closing the door to something else  ...
>>>>>>>
>>>>>>> Finally, about the "routing" word, routing is essentially a "forwar=
d" action which may limit the scope of what we can do by using a segment li=
st. Actions associated with a segment could be something else than forwardi=
ng.
>>>>>>>
>>>>>>> Do we want in the charter to limit the scope to routing actions ?
>>>>>>>
>>>>>>> I have no solution today to propose for the naming, but I completel=
y agree with Loa, to first focus on working on the charter, and define a cl=
ear scope of the work and then the name will be easier to find.
>>>>>>>
>>>>>>> Regarding your charter proposal :
>>>>>>>
>>>>>>> --------
>>>>>>>
>>>>>>> - They form a connected network
>>>>>>>  [SLI] InterAS case must be included, but the WG can go step by ste=
p and first release intraAS, and then doing interAS (in relation with IDR ?=
?).
>>>>>>>
>>>>>>> - They can forward traffic through the shortest paths or paths
>>>>>>> other than the shortest (the latter called explicitly routed paths,=
 or explicit paths)  [SLI] There is something else between SPT and Explicit=
 path, you can define other algorithms than SPT to define a path, and it's =
not explicit path. Moreover I come back to my comment, on do we want to lim=
it the scope to routing ? I would say no.
>>>>>>>
>>>>>>> - They share a common trust model. In this model, any router within=
 the ERD can specify an explicit path between itself and any other router i=
n the ERD. It can then send any packet that passes through it through any p=
ath that it has specified.
>>>>>>>  [SLI] Security considerations may have to be addressed in the
>>>>>>> charter , especially for the interAS case (trust yes, but not
>>>>>>> sure access to everything may not be good)
>>>>>>>
>>>>>>> Downstream routers within the ERD forward the packet as specified b=
y the router at the head-end of the path.
>>>>>>> [SLI] Yes, but any router in the middle may be able to change the e=
nd to end explicit path.
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> - The first goal of the STER WG is to identify use-cases for ERDs.
>>>>>>> - Having identified use-cases, the WG will identify gaps between cu=
rrently available technologies and use-case requirements.
>>>>>>> - The WG will then define requirements for extensions to existing p=
rotocols or new protocols that address gaps that are identified.
>>>>>>>
>>>>>>> [SLI] Agree, I would add :
>>>>>>> - defining the architecture framework
>>>>>>> - analysing the security considerisations
>>>>>>>
>>>>>>>
>>>>>>> ---------
>>>>>>>
>>>>>>>
>>>>>>> Here would be my proposal to extend yours :
>>>>>>>
>>>>>>> A <named to be defined> domain contains a set of routers with the f=
ollowing characteristics:
>>>>>>>
>>>>>>> - They form a connected network
>>>>>>> - They can forward traffic through any path within the network
>>>>>>> using shortest path, non shortest path or explicit path
>>>>>>> - They may provide other types of services than forwarding and they=
 can enforce service actions in the path.
>>>>>>> - They share a common trust model. In this model, any router within=
 the domain can specify a path between itself and any other router in the d=
omain. It may then send any packet that passes through it through any path =
that it has specified and that is conform to the security rules. Downstream=
 routers within the ERD forward the packet as specified by the router at th=
e head-end of the path.
>>>>>>>
>>>>>>> The <name> working group is chartered for the following ordered lis=
t of work items:
>>>>>>>
>>>>>>> - The first goal of the WG is to identify use-cases.
>>>>>>> - The WG will then define the architecture framework associated wit=
h the security considerations. The architecture framework and security cons=
iderations must address the relations between domains (interdomain).
>>>>>>> - Having identified use-cases, architecture and security, the WG wi=
ll identify gaps between currently available technologies and use-case requ=
irements.
>>>>>>> - The WG will then define requirements for extensions to existing p=
rotocols or new protocols that address gaps that are identified.
>>>>>>> - The WG will first focus on the intra-domain forwarding definition.
>>>>>>>
>>>>>>> Protocol work may be carried out in this working group or in other =
working groups responsible for the protocols, in coordination with this WG,=
 and in agreement with the WG chairs and responsible ADs. However, no proto=
col work will be adopted by a working group to address the ERD use-cases un=
til the requirements document motivating the protocol work has been sent to=
 the IESG for publication as an RFC.
>>>>>>>
>>>>>>> -----Message d'origine-----
>>>>>>> De : [email-masked] [mailto:[email-masked]] De
>>>>>>> la part de Hannes Gredler Envoy=E9 : mardi 3 septembre 2013 18:31
>>>>>>> =C0 : Loa Andersson Cc : [email-masked] Objet : Re: [Status]
>>>>>>> Summary of STATUS BOF and the next steps
>>>>>>>
>>>>>>> good point - what about this charter proposal ?
>>>>>>>
>>>>>>> ---
>>>>>>>
>>>>>>> Stacked Tunnels for Explicit Routing (STER)
>>>>>>> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
>>>>>>>
>>>>>>> A explicit routing domain (ERD) contains a set of routers with the =
following characteristics:
>>>>>>>
>>>>>>> - They form a connected network
>>>>>>> - They can forward traffic through the shortest paths or paths
>>>>>>> other than the shortest (the latter called explicitly routed
>>>>>>> paths, or explicit paths)
>>>>>>> - They share a common trust model. In this model, any router within=
 the ERD can specify an explicit path between itself and any other router i=
n the ERD. It can then send any packet that passes through it through any p=
ath that it has specified. Downstream routers within the ERD forward the pa=
cket as specified by the router at the head-end of the path.
>>>>>>>
>>>>>>> The STER working group is chartered for the following ordered list =
of work items:
>>>>>>>
>>>>>>> - The first goal of the STER WG is to identify use-cases for ERDs.
>>>>>>> - Having identified use-cases, the WG will identify gaps between cu=
rrently available technologies and use-case requirements.
>>>>>>> - The WG will then define requirements for extensions to existing p=
rotocols or new protocols that address gaps that are identified.
>>>>>>>
>>>>>>> Protocol work may be carried out in this working group or in other =
working groups responsible for the protocols, in coordination with this WG,=
 and in agreement with the WG chairs and responsible ADs. However, no proto=
col work will be adopted by a working group to address the ERD use-cases un=
til the requirements document motivating the protocol work has been sent to=
 the IESG for publication as an RFC.
>>>>>>>
>>>>>>> ---
>>>>>>>
>>>>>>> <flame suit on>
>>>>>>>
>>>>>>> /hannes
>>>>>>>
>>>>>>>
>>>>>>> On Sep 3, 2013, at 5:31 PM, Loa Andersson wrote:
>>>>>>>
>>>>>>>> Folks,
>>>>>>>>
>>>>>>>> Excuse me if I'm slightly out of the loop, but so far I have
>>>>>>>> not seen a charter proposal, if there is one please point me to it.
>>>>>>>>
>>>>>>>> It seems a bit odd to put the cart (what the wg should do)
>>>>>>>> before the horse (wg name). If we drill down the the charter
>>>>>>>> first the wg name might be easier to figure out.
>>>>>>>>
>>>>>>>> /Loa
>>>>>>>>
>>>>>>>> PS
>>>>>>>> OK I understand that the horse and cart analogy limps a  bit :).
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> On 2013-09-03 17:22, AshwoodsmithPeter wrote:
>>>>>>>>> " If the WG charter is limited to source routing, how will we han=
dle the "non source routing" use cases of segment routing ? In another work=
ing group ? So we will go back to the WG synchronization issue that has bee=
n raised for this technology ..."
>>>>>>>>>
>>>>>>>>> That's why I suggested SRV2. We are revisiting source routing wit=
h new concepts. More generic number/action behavior.
>>>>>>>>>
>>>>>>>>> Peter
>>>>>>>>>
>>>>>>>>> -----Original Message-----
>>>>>>>>> From: [email-masked] [mailto:[email-masked]]
>>>>>>>>> On Behalf Of [email-masked]
>>>>>>>>> Sent: Tuesday, September 03, 2013 10:43 AM
>>>>>>>>> To: AshwoodsmithPeter
>>>>>>>>> Cc: [email-masked]
>>>>>>>>> Subject: Re: [Status] Summary of STATUS BOF and the next steps
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> There was a misunderstanding in my small comment :) so I will exp=
lain more :
>>>>>>>>>
>>>>>>>>> In segment routing, you have more than basic source routing : seg=
ment routing is just associate a segment number to an action and then combi=
ne segment as you want, yes you can do source routing, but you also can do =
more.
>>>>>>>>>
>>>>>>>>> In the other hand, I completely agree with your statement that
>>>>>>>>> source routing is generic and dataplane agnostic, as segment rout=
ing is ...
>>>>>>>>> (segment routing is not a new dataplane ...)
>>>>>>>>>
>>>>>>>>> Now the definition of the WG naming must be inline with the
>>>>>>>>> charter that will be defined ... (draft today)
>>>>>>>>>
>>>>>>>>> Based on the already existing consensus (at least for MPLS datapl=
ane) brought up during Berlin STATUS BOF meeting, segment routing sounds to=
 be a good target candidate.
>>>>>>>>>
>>>>>>>>> So now, do we want to do more in the WG charter than just make pr=
ogressing segment routing architecture and uses cases document and ensure c=
oordination for the standardization of this technology ?
>>>>>>>>>
>>>>>>>>> Do we want to standardize other technologies in this WG ? I don't=
 think so, based on Stewart's conclusion email from the BOF :"A new WG focu=
sed solely on SR therefore needs to be create"
>>>>>>>>>
>>>>>>>>> If the WG charter is limited to source routing, how will we handl=
e the "non source routing" use cases of segment routing ? In another workin=
g group ? So we will go back to the WG synchronization issue that has been =
raised for this technology ...
>>>>>>>>>
>>>>>>>>> If the WG is focused on SR, let's use a name in relation with SR.
>>>>>>>>>
>>>>>>>>> Feedback ?
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> Stephane
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> -----Message d'origine-----
>>>>>>>>> De : AshwoodsmithPeter [mailto:[email-masked]]
>>>>>>>>> Envoy=E9 : mardi 3 septembre 2013 15:27 =C0 : LITKOWSKI Stephane
>>>>>>>>> DTF/DERX Cc : John E Drake; Mark Townsley; Victor Kuarsingh;
>>>>>>>>> Roberta Maglione (robmgl); John G. Scudder; Adrian Farrel;
>>>>>>>>> Alvaro Retana (aretana); [email-masked]; Stewart Bryant (stbryan=
t) Objet : Re:
>>>>>>>>> [Status] Summary of STATUS BOF and the next steps
>>>>>>>>>
>>>>>>>>> The term "source routing" has been around for a very long time an=
d is data path agnostic. Its also the term used in the literature etc so my=
 preference is to stick with this existing well known and data path agnosti=
c term.
>>>>>>>>>
>>>>>>>>> Peter
>>>>>>>>>
>>>>>>>>> On Sep 3, 2013, at 9:07 AM, "[email-masked]" <step=
[email-masked]> wrote:
>>>>>>>>>
>>>>>>>>>> Hi,
>>>>>>>>>>
>>>>>>>>>> "Source routing" is just a subcase of segment routing ... as it =
is for IP routing ...
>>>>>>>>>>
>>>>>>>>>> Stephane
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> -----Message d'origine-----
>>>>>>>>>> De : [email-masked] [mailto:[email-masked]]
>>>>>>>>>> De la part de John E Drake Envoy=E9 : mardi 3 septembre 2013 15:=
02 =C0 :
>>>>>>>>>> Mark Townsley; Victor Kuarsingh Cc : Roberta Maglione (robmgl); =
John G.
>>>>>>>>>> Scudder; Alvaro Retana (aretana); Adrian Farrel;
>>>>>>>>>> [email-masked]; Stewart Bryant (stbryant) Objet : Re:
>>>>>>>>>> [Status] Summary of STATUS BOF and the next steps
>>>>>>>>>>
>>>>>>>>>> Hi,
>>>>>>>>>>
>>>>>>>>>> What is this 'segment routing' silliness?  The correct term is '=
source routing'.
>>>>>>>>>>
>>>>>>>>>> Yours Irrespectively,
>>>>>>>>>>
>>>>>>>>>> John
>>>>>>>>>>
>>>>>>>>>>> -----Original Message-----
>>>>>>>>>>> From: [email-masked]
>>>>>>>>>>> [mailto:[email-masked]] On Behalf Of Mark Townsley
>>>>>>>>>>> Sent: Sunday, September 01, 2013 10:08 AM
>>>>>>>>>>> To: Victor Kuarsingh
>>>>>>>>>>> Cc: Roberta Maglione (robmgl); John G. Scudder; Adrian
>>>>>>>>>>> Farrel; Alvaro Retana (aretana); [email-masked]; Stewart
>>>>>>>>>>> Bryant
>>>>>>>>>>> (stbryant)
>>>>>>>>>>> Subject: Re: [Status] Summary of STATUS BOF and the next
>>>>>>>>>>> steps
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> On Sep 1, 2013, at 5:38 PM, Victor Kuarsingh wrote:
>>>>>>>>>>>
>>>>>>>>>>>> All,
>>>>>>>>>>>>
>>>>>>>>>>>> I would also favour "Segment Routing WG" as well.
>>>>>>>>>>>>
>>>>>>>>>>>> I note this since attempting to come up with an all
>>>>>>>>>>>> encompassing acronym will be difficult and Segment Routing
>>>>>>>>>>>> is generic enough to associate to multiple functions.
>>>>>>>>>>>
>>>>>>>>>>> Then we can just use "segroute" for the short name. WGs do
>>>>>>>>>>> not have to have acronyms, but they do need to have an
>>>>>>>>>>> 8-char limited short name for the various automated tools not t=
o break.
>>>>>>>>>>>
>>>>>>>>>>> - Mark
>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> Regards,
>>>>>>>>>>>>
>>>>>>>>>>>> Victor K
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> On 2013-08-31 6:51 PM, "Roberta Maglione (robmgl)"
>>>>>>>>>>>> <[email-masked]>
>>>>>>>>>>>> wrote:
>>>>>>>>>>>>
>>>>>>>>>>>>> +1 for Segment Routing WG
>>>>>>>>>>>>>
>>>>>>>>>>>>> Roberta
>>>>>>>>>>>>>
>>>>>>>>>>>>> Sent from my iPad
>>>>>>>>>>>>>
>>>>>>>>>>>>> On 2013-08-30, at 2:55 PM, "Alvaro Retana (aretana)"
>>>>>>>>>>>>> <[email-masked]>
>>>>>>>>>>>>> wrote:
>>>>>>>>>>>>>
>>>>>>>>>>>>>> Segment Routing WG
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Sent from my iPhone
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> On Aug 30, 2013, at 1:39 PM, "Stewart Bryant (stbryant)"
>>>>>>>>>>>>>> <[email-masked]> wrote:
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> The second task, which hopefully should be relatively
>>>>>>>>>>>>>>> easy, is to find a better working name for the WG, since
>>>>>>>>>>>>>>> it has been put to me a number of times that STATUS is
>>>>>>>>>>>>>>> going to be confusing in text and a difficult search term.
>>>>>>>>>>>>>> _______________________________________________
>>>>>>>>>>>>>> status mailing list
>>>>>>>>>>>>>> [email-masked]
>>>>>>>>>>>>>> https://www.ietf.org/mailman/listinfo/status
>>>>>>>>>>>>> _______________________________________________
>>>>>>>>>>>>> status mailing list
>>>>>>>>>>>>> [email-masked]
>>>>>>>>>>>>> https://www.ietf.org/mailman/listinfo/status
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> _______________________________________________
>>>>>>>>>>>> status mailing list
>>>>>>>>>>>> [email-masked]
>>>>>>>>>>>> https://www.ietf.org/mailman/listinfo/status
>>>>>>>>>>>
>>>>>>>>>>> _______________________________________________
>>>>>>>>>>> status mailing list
>>>>>>>>>>> [email-masked]
>>>>>>>>>>> https://www.ietf.org/mailman/listinfo/status
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> _______________________________________________
>>>>>>>>>> status mailing list
>>>>>>>>>> [email-masked]
>>>>>>>>>> https://www.ietf.org/mailman/listinfo/status
>>>>>>>>>>
>>>>>>>>>> _____________________________________________________________
>>>>>>>>>> ____ _ _ _ __
>>>>>>>>>> ___________________________________________________
>>>>>>>>>>
>>>>>>>>>> Ce message et ses pieces jointes peuvent contenir des
>>>>>>>>>> informations confidentielles ou privilegiees et ne doivent
>>>>>>>>>> donc pas etre diffuses, exploites ou copies sans
>>>>>>>>>> autorisation. Si vous avez recu ce message par erreur, veuillez =
le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les=
 messages electroniques etant susceptibles d'alteration, Orange decline tou=
te responsabilite si ce message a ete altere, deforme ou falsifie. Merci.
>>>>>>>>>>
>>>>>>>>>> This message and its attachments may contain confidential or
>>>>>>>>>> privileged information that may be protected by law; they should=
 not be distributed, used or copied without authorisation.
>>>>>>>>>> If you have received this email in error, please notify the send=
er and delete this message and its attachments.
>>>>>>>>>> As emails may be altered, Orange is not liable for messages that=
 have been modified, changed or falsified.
>>>>>>>>>> Thank you.
>>>>>>>>>>
>>>>>>>>>> _______________________________________________
>>>>>>>>>> status mailing list
>>>>>>>>>> [email-masked]
>>>>>>>>>> https://www.ietf.org/mailman/listinfo/status
>>>>>>>>>
>>>>>>>>> ______________________________________________________________
>>>>>>>>> ____ _ _ _
>>>>>>>>> ____________________________________________________
>>>>>>>>>
>>>>>>>>> Ce message et ses pieces jointes peuvent contenir des
>>>>>>>>> informations confidentielles ou privilegiees et ne doivent
>>>>>>>>> donc pas etre diffuses, exploites ou copies sans autorisation.
>>>>>>>>> Si vous avez recu ce message par erreur, veuillez le signaler a l=
'expediteur et le detruire ainsi que les pieces jointes. Les messages elect=
roniques etant susceptibles d'alteration, Orange decline toute responsabili=
te si ce message a ete altere, deforme ou falsifie. Merci.
>>>>>>>>>
>>>>>>>>> This message and its attachments may contain confidential or
>>>>>>>>> privileged information that may be protected by law; they should =
not be distributed, used or copied without authorisation.
>>>>>>>>> If you have received this email in error, please notify the sende=
r and delete this message and its attachments.
>>>>>>>>> As emails may be altered, Orange is not liable for messages that =
have been modified, changed or falsified.
>>>>>>>>> Thank you.
>>>>>>>>>
>>>>>>>>> _______________________________________________
>>>>>>>>> status mailing list
>>>>>>>>> [email-masked]
>>>>>>>>> https://www.ietf.org/mailman/listinfo/status
>>>>>>>>> _______________________________________________
>>>>>>>>> status mailing list
>>>>>>>>> [email-masked]
>>>>>>>>> https://www.ietf.org/mailman/listinfo/status
>>>>>>>>>
>>>>>>>>
>>>>>>>> --
>>>>>>>>
>>>>>>>>
>>>>>>>> Loa Andersson                        email: [email-masked]
>>>>>>>> Senior MPLS Expert                          [email-masked]
>>>>>>>> Huawei Technologies (consultant)     phone: +46 739 81 21 64
>>>>>>>> _______________________________________________
>>>>>>>> status mailing list
>>>>>>>> [email-masked]
>>>>>>>> https://www.ietf.org/mailman/listinfo/status
>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> _______________________________________________
>>>>>>> status mailing list
>>>>>>> [email-masked]
>>>>>>> https://www.ietf.org/mailman/listinfo/status
>>>>>>>
>>>>>>> ________________________________________________________________
>>>>>>> ____ _ _ ___________________________________________________
>>>>>>>
>>>>>>> Ce message et ses pieces jointes peuvent contenir des
>>>>>>> informations confidentielles ou privilegiees et ne doivent donc
>>>>>>> pas etre diffuses, exploites ou copies sans autorisation. Si
>>>>>>> vous avez recu ce message par erreur, veuillez le signaler a l'expe=
diteur et le detruire ainsi que les pieces jointes. Les messages electroniq=
ues etant susceptibles d'alteration, Orange decline toute responsabilite si=
 ce message a ete altere, deforme ou falsifie. Merci.
>>>>>>>
>>>>>>> This message and its attachments may contain confidential or
>>>>>>> privileged information that may be protected by law; they should no=
t be distributed, used or copied without authorisation.
>>>>>>> If you have received this email in error, please notify the sender =
and delete this message and its attachments.
>>>>>>> As emails may be altered, Orange is not liable for messages that ha=
ve been modified, changed or falsified.
>>>>>>> Thank you.
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> _________________________________________________________________
>>>>>> ____ _ ___________________________________________________
>>>>>>
>>>>>> Ce message et ses pieces jointes peuvent contenir des
>>>>>> informations confidentielles ou privilegiees et ne doivent donc
>>>>>> pas etre diffuses, exploites ou copies sans autorisation. Si vous
>>>>>> avez recu ce message par erreur, veuillez le signaler a l'expediteur=
 et le detruire ainsi que les pieces jointes. Les messages electroniques et=
ant susceptibles d'alteration, Orange decline toute responsabilite si ce me=
ssage a ete altere, deforme ou falsifie. Merci.
>>>>>>
>>>>>> This message and its attachments may contain confidential or
>>>>>> privileged information that may be protected by law; they should not=
 be distributed, used or copied without authorisation.
>>>>>> If you have received this email in error, please notify the sender a=
nd delete this message and its attachments.
>>>>>> As emails may be altered, Orange is not liable for messages that hav=
e been modified, changed or falsified.
>>>>>> Thank you.
>>>>>>
>>>>>> _______________________________________________
>>>>>> status mailing list
>>>>>> [email-masked]
>>>>>> https://www.ietf.org/mailman/listinfo/status
>>>>>
>>>>>
>>>>> __________________________________________________________________
>>>>> ____ ___________________________________________________
>>>>>
>>>>> Ce message et ses pieces jointes peuvent contenir des informations
>>>>> confidentielles ou privilegiees et ne doivent donc pas etre
>>>>> diffuses, exploites ou copies sans autorisation. Si vous avez recu
>>>>> ce message par erreur, veuillez le signaler a l'expediteur et le detr=
uire ainsi que les pieces jointes. Les messages electroniques etant suscept=
ibles d'alteration, Orange decline toute responsabilite si ce message a ete=
 altere, deforme ou falsifie. Merci.
>>>>>
>>>>> This message and its attachments may contain confidential or
>>>>> privileged information that may be protected by law; they should not =
be distributed, used or copied without authorisation.
>>>>> If you have received this email in error, please notify the sender an=
d delete this message and its attachments.
>>>>> As emails may be altered, Orange is not liable for messages that have=
 been modified, changed or falsified.
>>>>> Thank you.
>>>>>
>>>>
>>>>
>>>> ___________________________________________________________________
>>>> ______________________________________________________
>>>>
>>>> Ce message et ses pieces jointes peuvent contenir des informations
>>>> confidentielles ou privilegiees et ne doivent donc pas etre
>>>> diffuses, exploites ou copies sans autorisation. Si vous avez recu
>>>> ce message par erreur, veuillez le signaler a l'expediteur et le detru=
ire ainsi que les pieces jointes. Les messages electroniques etant suscepti=
bles d'alteration, Orange decline toute responsabilite si ce message a ete =
altere, deforme ou falsifie. Merci.
>>>>
>>>> This message and its attachments may contain confidential or
>>>> privileged information that may be protected by law; they should not b=
e distributed, used or copied without authorisation.
>>>> If you have received this email in error, please notify the sender and=
 delete this message and its attachments.
>>>> As emails may be altered, Orange is not liable for messages that have =
been modified, changed or falsified.
>>>> Thank you.
>>>>
>>>
>>>
>>>
>>
>>
>
>
>

___________________________________________________________________________=
______________________________________________

Ce message et ses pieces jointes peuvent contenir des informations confiden=
tielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu=
 ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages el=
ectroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou =
falsifie. Merci.

This message and its attachments may contain confidential or privileged inf=
ormation that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and dele=
te this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been =
modified, changed or falsified.
Thank you.

From: Hannes Gredler <[email-masked]>
Date: Wed, 11 Sep 2013 08:14:35 +0200
To: Stefano Previdi <[email-masked]>
Cc: Stephane Litkowski <[email-masked]>, Rob Shakir <[email-masked]>, "[email-masked]" <[email-masked]>
Subject: Re: [Status] Good charter proposals from Hannes and Stefano : try to merge ...

stefano,

On Sep 10, 2013, at 7:34 PM, Stefano Previdi (sprevidi) wrote:

> Hannes,
>=20
> On Sep 10, 2013, at 7:27 PM, Hannes Gredler wrote:
>> stefano,
>>=20
>> On Sep 10, 2013, at 6:58 PM, Stefano Previdi (sprevidi) wrote:
>>=20
>>>=20
>>> On Sep 10, 2013, at 1:25 PM, <[email-masked]> wrote:
>>>=20
>>>> Agree on all proposal except :
>>>>=20
>>>> "[SP] The architecture will support tunnel and non-tunnel paradigms
>>>>  The architecture will support multiple dataplanes: MPLS and V6"
>>>>=20
>>>> I don't see the reason for this ... IMHO, the gap analysis and =
requirements inventory will result on saying or not
>>>=20
>>>=20
>>> [SP] While I understand what brought the following statements
>>>   in the proposed charter:
>>> 	"Having identified use-cases, architecture and security,=20
>>> 	 the WG will identify gaps between currently available=20
>>> 	 technologies and use-case requirements.
>>> 	 The WG will then define requirements for extensions to=20
>>> 	 existing protocols or new protocols that address gaps=20
>>> 	 that are identified."
>>>=20
>>>   I'd like to point out with better precision what are the=20
>>>   directions we are ALREADY engaged into: dataplanes and=20
>>>   paradigms. As I mentioned in my charter proposal, we do have=20
>>>   implementations and multi-vendor interoperability tests will
>>>   happen soon. So, I just want to be sure we don't ignore this=20
>>>   reality.
>>=20
>> HG> just because you have an implementation for <foo> does not =
constitute
>>   community interest. we are trying to build here a charter that
>>   matches what a broader community wants. if the use-case that you're =
concerned
>>   about (service-chaining and a new internet data plane #4) are =
compelling
>>   enough the group will work on it, but mandating that into the =
charter,
>>   without asking the though questions first seems a wrong start to =
me.
>=20
>=20
> [SP] Sorry to contradict but it's the exact opposite. If a group=20
>     of vendors decide to invest in implementations is because=20
>     they received, analyzed, processed a set of requirements=20
>     coming for operators who know pretty well what they do, what=20
>     they want to deploy and the technology they want the vendors=20
>     to deliver. This fits the definition of "community interest".

HG> interestingly enough i haven't encountered a network operator so
    far who says 'i need SR for service chaining' nor=20
    we had somebody asking for this in the 'operator use case' slots
    in Berlin. - So who are they ? - can you manage such that
    they speak up and make their case ?

>     My point is that I strongly _suggest_ IETF WG (any) not to=20
>     neglect these facts and not write a down a charter ...
 [ =85 ]

HG> i'd like to have some proof point for your 'facts' prior
    to making 'service chaining' a charter item.

>     Having said that, whoever does NOT believe in the benefit of=20
>     a newly proposed technology, is always free to not implement=20
>     it and to not deploy it.

HG> that is fine and well understood, but since you have a desire to
    standardize your 'newly proposed technology' you also need to play
    a bit by the rules.

>>>> : we must use tunnels and/or non tunnels, and the following =
dataplanes ... But I don't see the reason to put solutions directly in =
the charter ...
>>>=20
>>>=20
>>> these are not solutions these are way to avoid boundaries in the
>>> framework.
>>>=20
>>> Thanks.
>>> s.
>>>=20
>>>=20
>>>> Could you explain your point ?
>>>>=20
>>>>=20
>>>> updated with the other comments :
>>>>=20
>>>> -------------------------------------------------------------------
>>>> Name: <TBD>
>>>> Charter:
>>>>=20
>>>>=20
>>>> Introduction
>>>> ------------
>>>> The following use cases:
>>>> . Path computation based on awareness of utilization or performance
>>>> data, within both centralized and distributed environments, . =
Multi-topology (dual planes, disjoint trees), . Simplification and =
reduction of signaling components (scaling), . Combined application and =
network layer path specification, . Full coverage LFA-FRR, . Topology =
Aware OAM, . etc.
>>>>=20
>>>> have triggered work on the definition of new architecture and =
protocol extensions allowing to combine well known shortest path based =
routing paradigms with source/explicit routing methods. Some of these =
extensions have been implemented already.
>>>>=20
>>>>=20
>>>> Objective
>>>> ---------
>>>>=20
>>>> Define an architecture where a node can steer a packet through a =
network or set of networks (interdomain) on any path without requiring =
to maintain state along the path, other than in the ingress node.
>>>>=20
>>>> A node may be any type of device including routers or appliances.
>>>>=20
>>>> In this architecture, nodes sharing a common trust model form a =
<Name-TBD> domain. The architecture defined by this working group will =
allow a node to steer a packet between any source and destination node =
within the <Name-TBD> domain (formed of one or more networks), on any =
path (shortest, non-shortest, explicit or based on other characteristics =
specified by segment identifiers).
>>>>=20
>>>> It may then send any packet that passes through it through any path =
that it has specified and that is conform to the security rules. =
Downstream nodes along the path within the <Name-TBD> domain forward the =
packet by using the informations inserted by the node at the head-end
>>>>=20
>>>> The architecture should support centralized and distributed path =
computation.
>>>>=20
>>>> The architecture should support OAM functions.
>>>>=20
>>>> The architecture should allow different mechanisms through which
>>>>  a path is constructed. SR allows a variety of mechanisms, not
>>>>  confined IGP/BGP path computation.
>>>>=20
>>>> As MPLS dataplane is largely deployed, the <Name-TBD> WG should =
avoid any modification in the MPLS dataplane when defining the =
architecture.
>>>>=20
>>>>=20
>>>> Work items :
>>>> ------------------
>>>>=20
>>>> The <Name-TBD> working group is chartered for the following ordered =
list of work items:
>>>>=20
>>>> - The first goal of the WG is to identify use-cases.
>>>> - The WG will then define the architecture framework associated =
with
>>>> the security considerations. The architecture framework and =
security
>>>> considerations must address the relations between networks forming =
the <Name-TBD> domain (interAS).
>>>> - Having identified use-cases, architecture and security, the WG =
will
>>>> identify gaps between currently available technologies and use-case
>>>> requirements.
>>>> - The WG will then define requirements for extensions to existing
>>>> protocols or new protocols that address gaps that are identified.
>>>> - The WG will first focus on the intra-domain forwarding =
definition.
>>>>=20
>>>>=20
>>>> Documents :
>>>> ------------------
>>>> . Use Cases
>>>> . Architecture including security considerations
>>>> - Protocol extension requirements
>>>> . Interoperability Report
>>>>=20
>>>>=20
>>>> Required protocol extensions are carried out in working groups =
responsible (ISIS,OSPF,BGP,PCEP ...). Work on new protocols may be =
carried out by the <Name-TBD> WG.
>>>>=20
>>>> -----Message d'origine-----
>>>> De : Stefano Previdi (sprevidi) [mailto:[email-masked]]
>>>> Envoy=E9 : mardi 10 septembre 2013 12:30
>>>> =C0 : LITKOWSKI Stephane DTF/DERX; Rob Shakir
>>>> Cc : Hannes Gredler; [email-masked]
>>>> Objet : Re: [Status] Good charter proposals from Hannes and Stefano =
: try to merge ...
>>>>=20
>>>> Hi Stephane, Rob,
>>>>=20
>>>> one preliminary remark: I prefer to use he therm "node" rather than =
"router". Use cases, such as Service Chaining requires that terminology.
>>>>=20
>>>> some other comments below...
>>>>=20
>>>>=20
>>>> On Sep 10, 2013, at 11:19 AM, <[email-masked]> =
wrote:
>>>>> Souns good to me, (adding OAM also)
>>>>>=20
>>>>> New recap :
>>>>>=20
>>>>> =
-------------------------------------------------------------------
>>>>> Name: <TBD>
>>>>> Charter:
>>>>>=20
>>>>>=20
>>>>> Introduction
>>>>> ------------
>>>>> The following use cases:
>>>>> . Path computation based on awareness of utilization or =
performance
>>>>> data, within both centralized and distributed environments, . =
Multi-topology (dual planes, disjoint trees), . Simplification and =
reduction of signaling components (scaling), . Combined application and =
network layer path specification, . Full coverage LFA-FRR, . Topology =
Aware OAM, . etc.
>>>>>=20
>>>>> have triggered work on the definition of new architecture and =
protocol extensions allowing to combine well known shortest path based =
routing paradigms with source/explicit routing methods. Some of these =
extensions have been implemented already.
>>>>>=20
>>>>>=20
>>>>> Objective
>>>>> ---------
>>>>>=20
>>>>> Define an architecture where a node can steer a packet through a =
network or set of networks (interdomain) on any path.
>>>>=20
>>>>=20
>>>> [SP] As stated above, I'm fine with the above definition but I
>>>>  assume this includes service chaining and that by "network
>>>>  or set of networks" you intend "nodes" which may include
>>>>  others things than just routers.
>>>>=20
>>>> [SLI] Agree
>>>>=20
>>>>=20
>>>>> In this architecture, routers sharing a common trust model form a =
<Name-TBD> domain. The architecture defined by this working group will =
allow a node to steer a packet between any source and destination node =
within the <Name-TBD> domain (formed of one or more networks), on any =
path (shortest, non-shortest, explicit or based on other characteristics =
specified by segment identifiers).
>>>>=20
>>>>=20
>>>> [SP] without requiring to maintain state along the path, other
>>>>  than in the ingress node.
>>>>=20
>>>> [SLI] Agree
>>>>=20
>>>>=20
>>>>> It may then send any packet that passes through it through any =
path that it has specified and that is conform to the security rules. =
Downstream routers along the path within the <Name-TBD> domain forward =
the packet as specified by the router at the head-end of the path.
>>>>=20
>>>>>=20
>>>>> The architecture should support centralized and distributed path =
computation.
>>>>>=20
>>>>> The architecture should support OAM functions.
>>>>=20
>>>>=20
>>>> [SP] The architecture should allow different mechanisms through =
which
>>>>  a path is constructed. SR allows a variety of mechanisms, not
>>>>  confined IGP/BGP path computation.
>>>>=20
>>>> [SLI] Agree
>>>>=20
>>>>> Work items :
>>>>> ------------------
>>>>>=20
>>>>> The <Name-TBD> working group is chartered for the following =
ordered list of work items:
>>>>>=20
>>>>> - The first goal of the WG is to identify use-cases.
>>>>> - The WG will then define the architecture framework associated =
with
>>>>> the security considerations. The architecture framework and =
security
>>>>> considerations must address the relations between networks forming =
the <Name-TBD> domain (interAS).
>>>>> - Having identified use-cases, architecture and security, the WG =
will
>>>>> identify gaps between currently available technologies and =
use-case
>>>>> requirements.
>>>>> - The WG will then define requirements for extensions to existing
>>>>> protocols or new protocols that address gaps that are identified.
>>>>> - The WG will first focus on the intra-domain forwarding =
definition.
>>>>=20
>>>>=20
>>>> [SP] The architecture will support tunnel and non-tunnel paradigms
>>>>  The architecture will support multiple dataplanes: MPLS and V6
>>>>=20
>>>>=20
>>>> Thanks.
>>>> s.
>>>>=20
>>>>=20
>>>>> Documents :
>>>>> ------------------
>>>>> . Use Cases
>>>>> . Architecture including security considerations
>>>>> - Protocol extension requirements
>>>>> . Interoperability Report
>>>>>=20
>>>>>=20
>>>>> Protocol work may be carried out in this working group or in other =
working groups responsible for the protocols (ISIS,OSPF,BGP,PCEP ...), =
in coordination with this WG, and in agreement with the WG chairs and =
responsible ADs.
>>>>>=20
>>>>> -----Message d'origine-----
>>>>> De : Rob Shakir [mailto:[email-masked]]
>>>>> Envoy=E9 : mardi 10 septembre 2013 11:05 =C0 : LITKOWSKI Stephane =
DTF/DERX
>>>>> Cc : Hannes Gredler; Stefano Previdi (sprevidi); [email-masked] =
Objet
>>>>> : Re: [Status] Good charter proposals from Hannes and Stefano : =
try to merge ...
>>>>>=20
>>>>> Hi Stephane,
>>>>>=20
>>>>> Thanks for this, looks good! Comments in-line marked rjs>.
>>>>>=20
>>>>> On 10 Sep 2013, at 08:50, <[email-masked]> wrote:
>>>>>=20
>>>>>> Hi all,
>>>>>>=20
>>>>>> I'm creating a new mail topic because the "Summary of STATUS BOF =
..."
>>>>>> starts to be unreadable :)
>>>>>>=20
>>>>>> Hannes and Stefano send to us two charter proposals that sounds =
good to me.
>>>>>>=20
>>>>>> The main difference between the two proposals is that Stefano =
propose a segment bound to any type of instruction (forwarding, =
application or service based) while Hannes is focusing on forwarding =
actions (which is the first priority, and I think everybody agree on =
this).
>>>>>=20
>>>>> rjs> Agreed -- I think it would be useful to allow definitions of =
segments to identify different types of "service", since there appear to =
be some use cases (e.g., the explicit exit selection case) which require =
a segment type describing something that is not explicitly IGP-based.
>>>>>=20
>>>>>>=20
>>>>>> It would be interresting to have a feedback from the mailinglist =
on this specific point.
>>>>>>=20
>>>>>> IMHO, there is a strong interrest to explore the service actions =
bound to segment in a second step keeping forwarding as a priority.
>>>>>>=20
>>>>>> Apart of this problem, here is a merge try of the two good =
proposals (I'm putting '<>' on hot topics :) ) :
>>>>>>=20
>>>>>>=20
>>>>>> =
-------------------------------------------------------------------
>>>>>> Name: <TBD>
>>>>>> Charter:
>>>>>>=20
>>>>>>=20
>>>>>> Introduction
>>>>>> ------------
>>>>>> The following use cases:
>>>>>> . Path computation based on awareness of utilization or =
performance
>>>>>> data, within both centralized and distributed environments, . =
Multi-topology (dual planes, disjoint trees), . Simplification and =
reduction of signaling components (scaling), . Combined application and =
network layer path specification, . Full coverage LFA-FRR, . Topology =
Aware OAM, . etc.
>>>>>>=20
>>>>>> have triggered work on the definition of new architecture and =
protocol extensions allowing to combine well known shortest path based =
routing paradigms with source/explicit routing methods. Some of these =
extensions have been implemented already.
>>>>>>=20
>>>>>>=20
>>>>>> Objective
>>>>>> ---------
>>>>>>=20
>>>>>> Define an architecture where a node can steer a packet through a =
network or set of networks (interdomain) on any path (shortest, non =
shortest, explicit, <service or application>).
>>>>>>=20
>>>>>> In this architecture, routers are sharing a common trust model =
and are forming a <Name-TBD> domain.
>>>>>> Within this domain, a node can specify a path between itself and =
any destination in the domain. <The path may be a forwarding path, a =
service chaining path or a combination of both>.
>>>>>=20
>>>>> rjs> To clarify here, we define that our domain is under a common =
trust model (essentially, under common administrative control?), but =
then go on to talk about inter-domain elsewhere. Can we perhaps clarify =
(by defining a specific "<Name-TBD> domain" nomenclature) and say =
something like:
>>>>>=20
>>>>> "In this architecture, routers sharing a common trust model form a =
<Name-TBD> domain. The architecture defined by this working group will =
allow a node to steer a packet between any source and destination node =
within the <Name-TBD> domain (formed of one or more networks), on any =
path (shortest, non-shortest, explicit or based on other characteristics =
specified by segment identifiers)."
>>>>>=20
>>>>>> It may then send any packet that passes through it through any =
path that it has specified and that is conform to the security rules. =
Downstream routers along the path within the <Name-TBD> domain forward =
the packet as specified by the router at the head-end of the path.
>>>>>>=20
>>>>>> The architecture should support centralized and distributed path =
computation.
>>>>>>=20
>>>>>>=20
>>>>>> Work items :
>>>>>> ------------------
>>>>>>=20
>>>>>> The <Name-TBD> working group is chartered for the following =
ordered list of work items:
>>>>>>=20
>>>>>> - The first goal of the WG is to identify use-cases.
>>>>>> - The WG will then define the architecture framework associated =
with
>>>>>> the security considerations. The architecture framework and =
security
>>>>>> considerations must address the relations between domains (inter =
domain).
>>>>>=20
>>>>> rjs> And then here "networks forming the <Name-TBD> domain"?
>>>>>=20
>>>>> Thanks for the efforts,
>>>>> r.
>>>>>=20
>>>>>> - Having identified use-cases, architecture and security, the WG =
will
>>>>>> identify gaps between currently available technologies and =
use-case
>>>>>> requirements.
>>>>>> - The WG will then define requirements for extensions to existing
>>>>>> protocols or new protocols that address gaps that are identified.
>>>>>> - The WG will first focus on the intra-domain forwarding =
definition.
>>>>>>=20
>>>>>>=20
>>>>>> Documents :
>>>>>> ------------------
>>>>>> . Use Cases
>>>>>> . Architecture including security considerations
>>>>>> - Protocol extension requirements
>>>>>> . Interoperability Report
>>>>>>=20
>>>>>>=20
>>>>>> Protocol work may be carried out in this working group or in =
other working groups responsible for the protocols (ISIS,OSPF,BGP,PCEP =
...), in coordination with this WG, and in agreement with the WG chairs =
and responsible ADs.
>>>>>>=20
>>>>>>=20
>>>>>>=20
>>>>>> Hope it helps to progress on the definition.
>>>>>>=20
>>>>>>=20
>>>>>> Stephane
>>>>>>=20
>>>>>>=20
>>>>>> -----Message d'origine-----
>>>>>> De : Hannes Gredler [mailto:[email-masked]] Envoy=E9 : =
vendredi 6
>>>>>> septembre 2013 18:27 =C0 : LITKOWSKI Stephane DTF/DERX Cc :
>>>>>> [email-masked] Objet : Re: [Status] Summary of STATUS BOF and =
the
>>>>>> next steps
>>>>>>=20
>>>>>> hi stephane,
>>>>>>=20
>>>>>> here is a revised draft charter as per your comments.
>>>>>>=20
>>>>>> ---
>>>>>>=20
>>>>>> <Name-TBD> domain contains a set of routers with the following
>>>>>> characteristics:
>>>>>>=20
>>>>>> - They form a connected network
>>>>>> - They can forward traffic through any path within the network =
using
>>>>>> shortest path, or any other (e.g., an explicit) path
>>>>>> - They share a common trust model. In this model, any router =
within
>>>>>> the domain can specify a path between itself and any other router =
 in
>>>>>> the domain. It may then send any packet that passes through it
>>>>>> through any path that it has specified and that is conform to the
>>>>>> security rules. Downstream routers along the path within the
>>>>>> <Name-TBD>  domain forward the packet as specified by the router =
at
>>>>>> the head-end  of the path.
>>>>>>=20
>>>>>> The <Name-TBD> working group is chartered for the following =
ordered list of work items:
>>>>>>=20
>>>>>> - The first goal of the WG is to identify use-cases.
>>>>>> - The WG will then define the architecture framework associated =
with
>>>>>> the security considerations. The architecture framework and =
security
>>>>>> considerations must address the relations between domains =
(interdomain).
>>>>>> - Having identified use-cases, architecture and security, the WG =
will
>>>>>> identify gaps between currently available technologies and =
use-case
>>>>>> requirements.
>>>>>> - The WG will then define requirements for extensions to existing
>>>>>> protocols or new protocols that address gaps that are identified.
>>>>>> - The WG will first focus on the intra-domain forwarding =
definition.
>>>>>>=20
>>>>>> Protocol work may be carried out in this working group or in =
other working groups responsible for the protocols, in coordination with =
this WG, and in agreement with the WG chairs and responsible ADs.
>>>>>> However, no protocol work will be adopted by a working group to =
address the identified use-cases until the requirements document =
motivating the protocol work has been sent to the IESG for publication =
as an RFC.
>>>>>>=20
>>>>>> ---
>>>>>>=20
>>>>>> /hannes
>>>>>>=20
>>>>>> On Sep 4, 2013, at 10:02 AM, <[email-masked]> =
<[email-masked]> wrote:
>>>>>>=20
>>>>>>> Hannes,
>>>>>>>=20
>>>>>>> In case, we are using only directed forwarding (adjacency =
segment),
>>>>>>> could we still talk about tunneling ? (it's a very very small =
tunnel) Moreover talking about "stacking" is really dataplane agnostic =
(MPLS) ...
>>>>>>>=20
>>>>>>> In the proposed segment routing architectural concepts, segments =
are at the same "level" and pointer moves on the segment list, then the =
MPLS instantiation is performing this using stacking ...
>>>>>>>=20
>>>>>>> IMHO, if we use "Stacked Tunnels", we already talk about a =
chosen solution and it's closing the door to something else  ...
>>>>>>>=20
>>>>>>> Finally, about the "routing" word, routing is essentially a =
"forward" action which may limit the scope of what we can do by using a =
segment list. Actions associated with a segment could be something else =
than forwarding.
>>>>>>>=20
>>>>>>> Do we want in the charter to limit the scope to routing actions =
?
>>>>>>>=20
>>>>>>> I have no solution today to propose for the naming, but I =
completely agree with Loa, to first focus on working on the charter, and =
define a clear scope of the work and then the name will be easier to =
find.
>>>>>>>=20
>>>>>>> Regarding your charter proposal :
>>>>>>>=20
>>>>>>> --------
>>>>>>>=20
>>>>>>> - They form a connected network
>>>>>>>  [SLI] InterAS case must be included, but the WG can go step by =
step and first release intraAS, and then doing interAS (in relation with =
IDR ??).
>>>>>>>=20
>>>>>>> - They can forward traffic through the shortest paths or paths =
other than the shortest (the latter called explicitly routed paths, or =
explicit paths)
>>>>>>>  [SLI] There is something else between SPT and Explicit path, =
you can define other algorithms than SPT to define a path, and it's not =
explicit path. Moreover I come back to my comment, on do we want to =
limit the scope to routing ? I would say no.
>>>>>>>=20
>>>>>>> - They share a common trust model. In this model, any router =
within the ERD can specify an explicit path between itself and any other =
router in the ERD. It can then send any packet that passes through it =
through any path that it has specified.
>>>>>>>  [SLI] Security considerations may have to be addressed in the
>>>>>>> charter , especially for the interAS case (trust yes, but not =
sure
>>>>>>> access to everything may not be good)
>>>>>>>=20
>>>>>>> Downstream routers within the ERD forward the packet as =
specified by the router at the head-end of the path.
>>>>>>> [SLI] Yes, but any router in the middle may be able to change =
the end to end explicit path.
>>>>>>>=20
>>>>>>>=20
>>>>>>>=20
>>>>>>> - The first goal of the STER WG is to identify use-cases for =
ERDs.
>>>>>>> - Having identified use-cases, the WG will identify gaps between =
currently available technologies and use-case requirements.
>>>>>>> - The WG will then define requirements for extensions to =
existing protocols or new protocols that address gaps that are =
identified.
>>>>>>>=20
>>>>>>> [SLI] Agree, I would add :
>>>>>>> - defining the architecture framework
>>>>>>> - analysing the security considerisations
>>>>>>>=20
>>>>>>>=20
>>>>>>> ---------
>>>>>>>=20
>>>>>>>=20
>>>>>>> Here would be my proposal to extend yours :
>>>>>>>=20
>>>>>>> A <named to be defined> domain contains a set of routers with =
the following characteristics:
>>>>>>>=20
>>>>>>> - They form a connected network
>>>>>>> - They can forward traffic through any path within the network =
using
>>>>>>> shortest path, non shortest path or explicit path
>>>>>>> - They may provide other types of services than forwarding and =
they can enforce service actions in the path.
>>>>>>> - They share a common trust model. In this model, any router =
within the domain can specify a path between itself and any other router =
in the domain. It may then send any packet that passes through it =
through any path that it has specified and that is conform to the =
security rules. Downstream routers within the ERD forward the packet as =
specified by the router at the head-end of the path.
>>>>>>>=20
>>>>>>> The <name> working group is chartered for the following ordered =
list of work items:
>>>>>>>=20
>>>>>>> - The first goal of the WG is to identify use-cases.
>>>>>>> - The WG will then define the architecture framework associated =
with the security considerations. The architecture framework and =
security considerations must address the relations between domains =
(interdomain).
>>>>>>> - Having identified use-cases, architecture and security, the WG =
will identify gaps between currently available technologies and use-case =
requirements.
>>>>>>> - The WG will then define requirements for extensions to =
existing protocols or new protocols that address gaps that are =
identified.
>>>>>>> - The WG will first focus on the intra-domain forwarding =
definition.
>>>>>>>=20
>>>>>>> Protocol work may be carried out in this working group or in =
other working groups responsible for the protocols, in coordination with =
this WG, and in agreement with the WG chairs and responsible ADs. =
However, no protocol work will be adopted by a working group to address =
the ERD use-cases until the requirements document motivating the =
protocol work has been sent to the IESG for publication as an RFC.
>>>>>>>=20
>>>>>>> -----Message d'origine-----
>>>>>>> De : [email-masked] [mailto:[email-masked]] De =
la
>>>>>>> part de Hannes Gredler Envoy=E9 : mardi 3 septembre 2013 18:31 =C0=
 : Loa
>>>>>>> Andersson Cc : [email-masked] Objet : Re: [Status] Summary of
>>>>>>> STATUS BOF and the next steps
>>>>>>>=20
>>>>>>> good point - what about this charter proposal ?
>>>>>>>=20
>>>>>>> ---
>>>>>>>=20
>>>>>>> Stacked Tunnels for Explicit Routing (STER)
>>>>>>> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
>>>>>>>=20
>>>>>>> A explicit routing domain (ERD) contains a set of routers with =
the following characteristics:
>>>>>>>=20
>>>>>>> - They form a connected network
>>>>>>> - They can forward traffic through the shortest paths or paths =
other
>>>>>>> than the shortest (the latter called explicitly routed paths, or
>>>>>>> explicit paths)
>>>>>>> - They share a common trust model. In this model, any router =
within the ERD can specify an explicit path between itself and any other =
router in the ERD. It can then send any packet that passes through it =
through any path that it has specified. Downstream routers within the =
ERD forward the packet as specified by the router at the head-end of the =
path.
>>>>>>>=20
>>>>>>> The STER working group is chartered for the following ordered =
list of work items:
>>>>>>>=20
>>>>>>> - The first goal of the STER WG is to identify use-cases for =
ERDs.
>>>>>>> - Having identified use-cases, the WG will identify gaps between =
currently available technologies and use-case requirements.
>>>>>>> - The WG will then define requirements for extensions to =
existing protocols or new protocols that address gaps that are =
identified.
>>>>>>>=20
>>>>>>> Protocol work may be carried out in this working group or in =
other working groups responsible for the protocols, in coordination with =
this WG, and in agreement with the WG chairs and responsible ADs. =
However, no protocol work will be adopted by a working group to address =
the ERD use-cases until the requirements document motivating the =
protocol work has been sent to the IESG for publication as an RFC.
>>>>>>>=20
>>>>>>> ---
>>>>>>>=20
>>>>>>> <flame suit on>
>>>>>>>=20
>>>>>>> /hannes
>>>>>>>=20
>>>>>>>=20
>>>>>>> On Sep 3, 2013, at 5:31 PM, Loa Andersson wrote:
>>>>>>>=20
>>>>>>>> Folks,
>>>>>>>>=20
>>>>>>>> Excuse me if I'm slightly out of the loop, but so far I have =
not
>>>>>>>> seen a charter proposal, if there is one please point me to it.
>>>>>>>>=20
>>>>>>>> It seems a bit odd to put the cart (what the wg should do) =
before
>>>>>>>> the horse (wg name). If we drill down the the charter first the =
wg
>>>>>>>> name might be easier to figure out.
>>>>>>>>=20
>>>>>>>> /Loa
>>>>>>>>=20
>>>>>>>> PS
>>>>>>>> OK I understand that the horse and cart analogy limps a  bit =
:).
>>>>>>>>=20
>>>>>>>>=20
>>>>>>>>=20
>>>>>>>> On 2013-09-03 17:22, AshwoodsmithPeter wrote:
>>>>>>>>> " If the WG charter is limited to source routing, how will we =
handle the "non source routing" use cases of segment routing ? In =
another working group ? So we will go back to the WG synchronization =
issue that has been raised for this technology ..."
>>>>>>>>>=20
>>>>>>>>> That's why I suggested SRV2. We are revisiting source routing =
with new concepts. More generic number/action behavior.
>>>>>>>>>=20
>>>>>>>>> Peter
>>>>>>>>>=20
>>>>>>>>> -----Original Message-----
>>>>>>>>> From: [email-masked] [mailto:[email-masked]] =
On
>>>>>>>>> Behalf Of [email-masked]
>>>>>>>>> Sent: Tuesday, September 03, 2013 10:43 AM
>>>>>>>>> To: AshwoodsmithPeter
>>>>>>>>> Cc: [email-masked]
>>>>>>>>> Subject: Re: [Status] Summary of STATUS BOF and the next steps
>>>>>>>>>=20
>>>>>>>>>=20
>>>>>>>>> There was a misunderstanding in my small comment :) so I will =
explain more :
>>>>>>>>>=20
>>>>>>>>> In segment routing, you have more than basic source routing : =
segment routing is just associate a segment number to an action and then =
combine segment as you want, yes you can do source routing, but you also =
can do more.
>>>>>>>>>=20
>>>>>>>>> In the other hand, I completely agree with your statement that
>>>>>>>>> source routing is generic and dataplane agnostic, as segment =
routing is ...
>>>>>>>>> (segment routing is not a new dataplane ...)
>>>>>>>>>=20
>>>>>>>>> Now the definition of the WG naming must be inline with the
>>>>>>>>> charter that will be defined ... (draft today)
>>>>>>>>>=20
>>>>>>>>> Based on the already existing consensus (at least for MPLS =
dataplane) brought up during Berlin STATUS BOF meeting, segment routing =
sounds to be a good target candidate.
>>>>>>>>>=20
>>>>>>>>> So now, do we want to do more in the WG charter than just make =
progressing segment routing architecture and uses cases document and =
ensure coordination for the standardization of this technology ?
>>>>>>>>>=20
>>>>>>>>> Do we want to standardize other technologies in this WG ? I =
don't think so, based on Stewart's conclusion email from the BOF :"A new =
WG focused solely on SR therefore needs to be create"
>>>>>>>>>=20
>>>>>>>>> If the WG charter is limited to source routing, how will we =
handle the "non source routing" use cases of segment routing ? In =
another working group ? So we will go back to the WG synchronization =
issue that has been raised for this technology ...
>>>>>>>>>=20
>>>>>>>>> If the WG is focused on SR, let's use a name in relation with =
SR.
>>>>>>>>>=20
>>>>>>>>> Feedback ?
>>>>>>>>>=20
>>>>>>>>>=20
>>>>>>>>> Stephane
>>>>>>>>>=20
>>>>>>>>>=20
>>>>>>>>> -----Message d'origine-----
>>>>>>>>> De : AshwoodsmithPeter [mailto:[email-masked]]
>>>>>>>>> Envoy=E9 : mardi 3 septembre 2013 15:27 =C0 : LITKOWSKI =
Stephane
>>>>>>>>> DTF/DERX Cc : John E Drake; Mark Townsley; Victor Kuarsingh;
>>>>>>>>> Roberta Maglione (robmgl); John G. Scudder; Adrian Farrel; =
Alvaro
>>>>>>>>> Retana (aretana); [email-masked]; Stewart Bryant (stbryant) =
Objet : Re:
>>>>>>>>> [Status] Summary of STATUS BOF and the next steps
>>>>>>>>>=20
>>>>>>>>> The term "source routing" has been around for a very long time =
and is data path agnostic. Its also the term used in the literature etc =
so my preference is to stick with this existing well known and data path =
agnostic term.
>>>>>>>>>=20
>>>>>>>>> Peter
>>>>>>>>>=20
>>>>>>>>> On Sep 3, 2013, at 9:07 AM, "[email-masked]" =
<[email-masked]> wrote:
>>>>>>>>>=20
>>>>>>>>>> Hi,
>>>>>>>>>>=20
>>>>>>>>>> "Source routing" is just a subcase of segment routing ... as =
it is for IP routing ...
>>>>>>>>>>=20
>>>>>>>>>> Stephane
>>>>>>>>>>=20
>>>>>>>>>>=20
>>>>>>>>>> -----Message d'origine-----
>>>>>>>>>> De : [email-masked] [mailto:[email-masked]] =
De
>>>>>>>>>> la part de John E Drake Envoy=E9 : mardi 3 septembre 2013 =
15:02 =C0 :
>>>>>>>>>> Mark Townsley; Victor Kuarsingh Cc : Roberta Maglione =
(robmgl); John G.
>>>>>>>>>> Scudder; Alvaro Retana (aretana); Adrian Farrel; =
[email-masked];
>>>>>>>>>> Stewart Bryant (stbryant) Objet : Re: [Status] Summary of =
STATUS
>>>>>>>>>> BOF and the next steps
>>>>>>>>>>=20
>>>>>>>>>> Hi,
>>>>>>>>>>=20
>>>>>>>>>> What is this 'segment routing' silliness?  The correct term =
is 'source routing'.
>>>>>>>>>>=20
>>>>>>>>>> Yours Irrespectively,
>>>>>>>>>>=20
>>>>>>>>>> John
>>>>>>>>>>=20
>>>>>>>>>>> -----Original Message-----
>>>>>>>>>>> From: [email-masked] =
[mailto:[email-masked]]
>>>>>>>>>>> On Behalf Of Mark Townsley
>>>>>>>>>>> Sent: Sunday, September 01, 2013 10:08 AM
>>>>>>>>>>> To: Victor Kuarsingh
>>>>>>>>>>> Cc: Roberta Maglione (robmgl); John G. Scudder; Adrian =
Farrel;
>>>>>>>>>>> Alvaro Retana (aretana); [email-masked]; Stewart Bryant
>>>>>>>>>>> (stbryant)
>>>>>>>>>>> Subject: Re: [Status] Summary of STATUS BOF and the next =
steps
>>>>>>>>>>>=20
>>>>>>>>>>>=20
>>>>>>>>>>> On Sep 1, 2013, at 5:38 PM, Victor Kuarsingh wrote:
>>>>>>>>>>>=20
>>>>>>>>>>>> All,
>>>>>>>>>>>>=20
>>>>>>>>>>>> I would also favour "Segment Routing WG" as well.
>>>>>>>>>>>>=20
>>>>>>>>>>>> I note this since attempting to come up with an all
>>>>>>>>>>>> encompassing acronym will be difficult and Segment Routing =
is
>>>>>>>>>>>> generic enough to associate to multiple functions.
>>>>>>>>>>>=20
>>>>>>>>>>> Then we can just use "segroute" for the short name. WGs do =
not
>>>>>>>>>>> have to have acronyms, but they do need to have an 8-char
>>>>>>>>>>> limited short name for the various automated tools not to =
break.
>>>>>>>>>>>=20
>>>>>>>>>>> - Mark
>>>>>>>>>>>=20
>>>>>>>>>>>>=20
>>>>>>>>>>>> Regards,
>>>>>>>>>>>>=20
>>>>>>>>>>>> Victor K
>>>>>>>>>>>>=20
>>>>>>>>>>>>=20
>>>>>>>>>>>>=20
>>>>>>>>>>>> On 2013-08-31 6:51 PM, "Roberta Maglione (robmgl)"
>>>>>>>>>>>> <[email-masked]>
>>>>>>>>>>>> wrote:
>>>>>>>>>>>>=20
>>>>>>>>>>>>> +1 for Segment Routing WG
>>>>>>>>>>>>>=20
>>>>>>>>>>>>> Roberta
>>>>>>>>>>>>>=20
>>>>>>>>>>>>> Sent from my iPad
>>>>>>>>>>>>>=20
>>>>>>>>>>>>> On 2013-08-30, at 2:55 PM, "Alvaro Retana (aretana)"
>>>>>>>>>>>>> <[email-masked]>
>>>>>>>>>>>>> wrote:
>>>>>>>>>>>>>=20
>>>>>>>>>>>>>> Segment Routing WG
>>>>>>>>>>>>>>=20
>>>>>>>>>>>>>> Sent from my iPhone
>>>>>>>>>>>>>>=20
>>>>>>>>>>>>>> On Aug 30, 2013, at 1:39 PM, "Stewart Bryant (stbryant)"
>>>>>>>>>>>>>> <[email-masked]> wrote:
>>>>>>>>>>>>>>=20
>>>>>>>>>>>>>>> The second task, which hopefully should be relatively =
easy,
>>>>>>>>>>>>>>> is to find a better working name for the WG, since it =
has
>>>>>>>>>>>>>>> been put to me a number of times that STATUS is going to =
be
>>>>>>>>>>>>>>> confusing in text and a difficult search term.
>>>>>>>>>>>>>> _______________________________________________
>>>>>>>>>>>>>> status mailing list
>>>>>>>>>>>>>> [email-masked]
>>>>>>>>>>>>>> https://www.ietf.org/mailman/listinfo/status
>>>>>>>>>>>>> _______________________________________________
>>>>>>>>>>>>> status mailing list
>>>>>>>>>>>>> [email-masked]
>>>>>>>>>>>>> https://www.ietf.org/mailman/listinfo/status
>>>>>>>>>>>>=20
>>>>>>>>>>>>=20
>>>>>>>>>>>> _______________________________________________
>>>>>>>>>>>> status mailing list
>>>>>>>>>>>> [email-masked]
>>>>>>>>>>>> https://www.ietf.org/mailman/listinfo/status
>>>>>>>>>>>=20
>>>>>>>>>>> _______________________________________________
>>>>>>>>>>> status mailing list
>>>>>>>>>>> [email-masked]
>>>>>>>>>>> https://www.ietf.org/mailman/listinfo/status
>>>>>>>>>>=20
>>>>>>>>>>=20
>>>>>>>>>> _______________________________________________
>>>>>>>>>> status mailing list
>>>>>>>>>> [email-masked]
>>>>>>>>>> https://www.ietf.org/mailman/listinfo/status
>>>>>>>>>>=20
>>>>>>>>>> =
_________________________________________________________________
>>>>>>>>>> _ _ _ __ ___________________________________________________
>>>>>>>>>>=20
>>>>>>>>>> Ce message et ses pieces jointes peuvent contenir des
>>>>>>>>>> informations confidentielles ou privilegiees et ne doivent =
donc
>>>>>>>>>> pas etre diffuses, exploites ou copies sans autorisation. Si =
vous
>>>>>>>>>> avez recu ce message par erreur, veuillez le signaler a =
l'expediteur et le detruire ainsi que les pieces jointes. Les messages =
electroniques etant susceptibles d'alteration, Orange decline toute =
responsabilite si ce message a ete altere, deforme ou falsifie. Merci.
>>>>>>>>>>=20
>>>>>>>>>> This message and its attachments may contain confidential or
>>>>>>>>>> privileged information that may be protected by law; they =
should not be distributed, used or copied without authorisation.
>>>>>>>>>> If you have received this email in error, please notify the =
sender and delete this message and its attachments.
>>>>>>>>>> As emails may be altered, Orange is not liable for messages =
that have been modified, changed or falsified.
>>>>>>>>>> Thank you.
>>>>>>>>>>=20
>>>>>>>>>> _______________________________________________
>>>>>>>>>> status mailing list
>>>>>>>>>> [email-masked]
>>>>>>>>>> https://www.ietf.org/mailman/listinfo/status
>>>>>>>>>=20
>>>>>>>>> =
__________________________________________________________________
>>>>>>>>> _ _ _ ____________________________________________________
>>>>>>>>>=20
>>>>>>>>> Ce message et ses pieces jointes peuvent contenir des =
informations
>>>>>>>>> confidentielles ou privilegiees et ne doivent donc pas etre
>>>>>>>>> diffuses, exploites ou copies sans autorisation. Si vous avez =
recu
>>>>>>>>> ce message par erreur, veuillez le signaler a l'expediteur et =
le detruire ainsi que les pieces jointes. Les messages electroniques =
etant susceptibles d'alteration, Orange decline toute responsabilite si =
ce message a ete altere, deforme ou falsifie. Merci.
>>>>>>>>>=20
>>>>>>>>> This message and its attachments may contain confidential or
>>>>>>>>> privileged information that may be protected by law; they =
should not be distributed, used or copied without authorisation.
>>>>>>>>> If you have received this email in error, please notify the =
sender and delete this message and its attachments.
>>>>>>>>> As emails may be altered, Orange is not liable for messages =
that have been modified, changed or falsified.
>>>>>>>>> Thank you.
>>>>>>>>>=20
>>>>>>>>> _______________________________________________
>>>>>>>>> status mailing list
>>>>>>>>> [email-masked]
>>>>>>>>> https://www.ietf.org/mailman/listinfo/status
>>>>>>>>> _______________________________________________
>>>>>>>>> status mailing list
>>>>>>>>> [email-masked]
>>>>>>>>> https://www.ietf.org/mailman/listinfo/status
>>>>>>>>>=20
>>>>>>>>=20
>>>>>>>> --
>>>>>>>>=20
>>>>>>>>=20
>>>>>>>> Loa Andersson                        email: =
[email-masked]
>>>>>>>> Senior MPLS Expert                          [email-masked]
>>>>>>>> Huawei Technologies (consultant)     phone: +46 739 81 21 64
>>>>>>>> _______________________________________________
>>>>>>>> status mailing list
>>>>>>>> [email-masked]
>>>>>>>> https://www.ietf.org/mailman/listinfo/status
>>>>>>>>=20
>>>>>>>>=20
>>>>>>>=20
>>>>>>>=20
>>>>>>> _______________________________________________
>>>>>>> status mailing list
>>>>>>> [email-masked]
>>>>>>> https://www.ietf.org/mailman/listinfo/status
>>>>>>>=20
>>>>>>> =
____________________________________________________________________
>>>>>>> _ _ ___________________________________________________
>>>>>>>=20
>>>>>>> Ce message et ses pieces jointes peuvent contenir des =
informations
>>>>>>> confidentielles ou privilegiees et ne doivent donc pas etre
>>>>>>> diffuses, exploites ou copies sans autorisation. Si vous avez =
recu
>>>>>>> ce message par erreur, veuillez le signaler a l'expediteur et le =
detruire ainsi que les pieces jointes. Les messages electroniques etant =
susceptibles d'alteration, Orange decline toute responsabilite si ce =
message a ete altere, deforme ou falsifie. Merci.
>>>>>>>=20
>>>>>>> This message and its attachments may contain confidential or
>>>>>>> privileged information that may be protected by law; they should =
not be distributed, used or copied without authorisation.
>>>>>>> If you have received this email in error, please notify the =
sender and delete this message and its attachments.
>>>>>>> As emails may be altered, Orange is not liable for messages that =
have been modified, changed or falsified.
>>>>>>> Thank you.
>>>>>>>=20
>>>>>>>=20
>>>>>>>=20
>>>>>>=20
>>>>>>=20
>>>>>>=20
>>>>>> =
_____________________________________________________________________
>>>>>> _ ___________________________________________________
>>>>>>=20
>>>>>> Ce message et ses pieces jointes peuvent contenir des =
informations
>>>>>> confidentielles ou privilegiees et ne doivent donc pas etre =
diffuses,
>>>>>> exploites ou copies sans autorisation. Si vous avez recu ce =
message
>>>>>> par erreur, veuillez le signaler a l'expediteur et le detruire =
ainsi que les pieces jointes. Les messages electroniques etant =
susceptibles d'alteration, Orange decline toute responsabilite si ce =
message a ete altere, deforme ou falsifie. Merci.
>>>>>>=20
>>>>>> This message and its attachments may contain confidential or
>>>>>> privileged information that may be protected by law; they should =
not be distributed, used or copied without authorisation.
>>>>>> If you have received this email in error, please notify the =
sender and delete this message and its attachments.
>>>>>> As emails may be altered, Orange is not liable for messages that =
have been modified, changed or falsified.
>>>>>> Thank you.
>>>>>>=20
>>>>>> _______________________________________________
>>>>>> status mailing list
>>>>>> [email-masked]
>>>>>> https://www.ietf.org/mailman/listinfo/status
>>>>>=20
>>>>>=20
>>>>> =
______________________________________________________________________
>>>>> ___________________________________________________
>>>>>=20
>>>>> Ce message et ses pieces jointes peuvent contenir des informations
>>>>> confidentielles ou privilegiees et ne doivent donc pas etre =
diffuses,
>>>>> exploites ou copies sans autorisation. Si vous avez recu ce =
message
>>>>> par erreur, veuillez le signaler a l'expediteur et le detruire =
ainsi que les pieces jointes. Les messages electroniques etant =
susceptibles d'alteration, Orange decline toute responsabilite si ce =
message a ete altere, deforme ou falsifie. Merci.
>>>>>=20
>>>>> This message and its attachments may contain confidential or
>>>>> privileged information that may be protected by law; they should =
not be distributed, used or copied without authorisation.
>>>>> If you have received this email in error, please notify the sender =
and delete this message and its attachments.
>>>>> As emails may be altered, Orange is not liable for messages that =
have been modified, changed or falsified.
>>>>> Thank you.
>>>>>=20
>>>>=20
>>>>=20
>>>> =
__________________________________________________________________________=
_______________________________________________
>>>>=20
>>>> Ce message et ses pieces jointes peuvent contenir des informations =
confidentielles ou privilegiees et ne doivent donc
>>>> pas etre diffuses, exploites ou copies sans autorisation. Si vous =
avez recu ce message par erreur, veuillez le signaler
>>>> a l'expediteur et le detruire ainsi que les pieces jointes. Les =
messages electroniques etant susceptibles d'alteration,
>>>> Orange decline toute responsabilite si ce message a ete altere, =
deforme ou falsifie. Merci.
>>>>=20
>>>> This message and its attachments may contain confidential or =
privileged information that may be protected by law;
>>>> they should not be distributed, used or copied without =
authorisation.
>>>> If you have received this email in error, please notify the sender =
and delete this message and its attachments.
>>>> As emails may be altered, Orange is not liable for messages that =
have been modified, changed or falsified.
>>>> Thank you.
>>>>=20
>>>=20
>>>=20
>>>=20
>>=20
>>=20
>=20
>=20
>=20

From: Xuxiaohu <[email-masked]>
To: "Stefano Previdi (sprevidi)" <[email-masked]>, Stephane Litkowski <[email-masked]>
Date: Wed, 11 Sep 2013 02:14:42 +0000
Accept-Language: zh-CN, en-US
Cc: Hannes Gredler <[email-masked]>, Rob Shakir <[email-masked]>, "[email-masked]" <[email-masked]>
Subject: [Status] =?utf-8?b?562U5aSNOiAgR29vZCBjaGFydGVyIHByb3Bvc2FscyBm?= =?utf-8?q?rom_Hannes_and_Stefano_=3A_try_to_merge_=2E=2E=2E?=

From: "Stefano Previdi (sprevidi)" <[email-masked]>
To: Hannes Gredler <[email-masked]>
Date: Tue, 10 Sep 2013 17:34:58 +0000
Accept-Language: en-US
Cc: Stephane Litkowski <[email-masked]>, Rob Shakir <[email-masked]>, "[email-masked]" <[email-masked]>
Subject: Re: [Status] Good charter proposals from Hannes and Stefano : try to merge ...

Hannes,

On Sep 10, 2013, at 7:27 PM, Hannes Gredler wrote:
> stefano,
>=20
> On Sep 10, 2013, at 6:58 PM, Stefano Previdi (sprevidi) wrote:
>=20
>>=20
>> On Sep 10, 2013, at 1:25 PM, <[email-masked]> wrote:
>>=20
>>> Agree on all proposal except :
>>>=20
>>> "[SP] The architecture will support tunnel and non-tunnel paradigms
>>>   The architecture will support multiple dataplanes: MPLS and V6"
>>>=20
>>> I don't see the reason for this ... IMHO, the gap analysis and requirem=
ents inventory will result on saying or not
>>=20
>>=20
>> [SP] While I understand what brought the following statements
>>    in the proposed charter:
>> 	"Having identified use-cases, architecture and security,=20
>> 	 the WG will identify gaps between currently available=20
>> 	 technologies and use-case requirements.
>> 	 The WG will then define requirements for extensions to=20
>> 	 existing protocols or new protocols that address gaps=20
>> 	 that are identified."
>>=20
>>    I'd like to point out with better precision what are the=20
>>    directions we are ALREADY engaged into: dataplanes and=20
>>    paradigms. As I mentioned in my charter proposal, we do have=20
>>    implementations and multi-vendor interoperability tests will
>>    happen soon. So, I just want to be sure we don't ignore this=20
>>    reality.
>=20
> HG> just because you have an implementation for <foo> does not constitute
>    community interest. we are trying to build here a charter that
>    matches what a broader community wants. if the use-case that you're co=
ncerned
>    about (service-chaining and a new internet data plane #4) are compelli=
ng
>    enough the group will work on it, but mandating that into the charter,
>    without asking the though questions first seems a wrong start to me.

[SP] Sorry to contradict but it's the exact opposite. If a group=20
     of vendors decide to invest in implementations is because=20
     they received, analyzed, processed a set of requirements=20
     coming for operators who know pretty well what they do, what=20
     they want to deploy and the technology they want the vendors=20
     to deliver. This fits the definition of "community interest".

     My point is that I strongly _suggest_ IETF WG (any) not to=20
     neglect these facts and not write a down a charter that will=20
     take the "community" to argue whether "RSVP can do the job"=20
     for the next 3 years.

     Having said that, whoever does NOT believe in the benefit of=20
     a newly proposed technology, is always free to not implement=20
     it and to not deploy it.

s.

>=20
> /hannes
>=20
>>> : we must use tunnels and/or non tunnels, and the following dataplanes =
... But I don't see the reason to put solutions directly in the charter ...
>>=20
>>=20
>> these are not solutions these are way to avoid boundaries in the
>> framework.
>>=20
>> Thanks.
>> s.
>>=20
>>=20
>>> Could you explain your point ?
>>>=20
>>>=20
>>> updated with the other comments :
>>>=20
>>> -------------------------------------------------------------------
>>> Name: <TBD>
>>> Charter:
>>>=20
>>>=20
>>> Introduction
>>> ------------
>>> The following use cases:
>>> . Path computation based on awareness of utilization or performance
>>> data, within both centralized and distributed environments, . Multi-top=
ology (dual planes, disjoint trees), . Simplification and reduction of sign=
aling components (scaling), . Combined application and network layer path s=
pecification, . Full coverage LFA-FRR, . Topology Aware OAM, . etc.
>>>=20
>>> have triggered work on the definition of new architecture and protocol =
extensions allowing to combine well known shortest path based routing parad=
igms with source/explicit routing methods. Some of these extensions have be=
en implemented already.
>>>=20
>>>=20
>>> Objective
>>> ---------
>>>=20
>>> Define an architecture where a node can steer a packet through a networ=
k or set of networks (interdomain) on any path without requiring to maintai=
n state along the path, other than in the ingress node.
>>>=20
>>> A node may be any type of device including routers or appliances.
>>>=20
>>> In this architecture, nodes sharing a common trust model form a <Name-T=
BD> domain. The architecture defined by this working group will allow a nod=
e to steer a packet between any source and destination node within the <Nam=
e-TBD> domain (formed of one or more networks), on any path (shortest, non-=
shortest, explicit or based on other characteristics specified by segment i=
dentifiers).
>>>=20
>>> It may then send any packet that passes through it through any path tha=
t it has specified and that is conform to the security rules. Downstream no=
des along the path within the <Name-TBD> domain forward the packet by using=
 the informations inserted by the node at the head-end
>>>=20
>>> The architecture should support centralized and distributed path comput=
ation.
>>>=20
>>> The architecture should support OAM functions.
>>>=20
>>> The architecture should allow different mechanisms through which
>>>   a path is constructed. SR allows a variety of mechanisms, not
>>>   confined IGP/BGP path computation.
>>>=20
>>> As MPLS dataplane is largely deployed, the <Name-TBD> WG should avoid a=
ny modification in the MPLS dataplane when defining the architecture.
>>>=20
>>>=20
>>> Work items :
>>> ------------------
>>>=20
>>> The <Name-TBD> working group is chartered for the following ordered lis=
t of work items:
>>>=20
>>> - The first goal of the WG is to identify use-cases.
>>> - The WG will then define the architecture framework associated with
>>> the security considerations. The architecture framework and security
>>> considerations must address the relations between networks forming the =
<Name-TBD> domain (interAS).
>>> - Having identified use-cases, architecture and security, the WG will
>>> identify gaps between currently available technologies and use-case
>>> requirements.
>>> - The WG will then define requirements for extensions to existing
>>> protocols or new protocols that address gaps that are identified.
>>> - The WG will first focus on the intra-domain forwarding definition.
>>>=20
>>>=20
>>> Documents :
>>> ------------------
>>> . Use Cases
>>> . Architecture including security considerations
>>> - Protocol extension requirements
>>> . Interoperability Report
>>>=20
>>>=20
>>> Required protocol extensions are carried out in working groups responsi=
ble (ISIS,OSPF,BGP,PCEP ...). Work on new protocols may be carried out by t=
he <Name-TBD> WG.
>>>=20
>>> -----Message d'origine-----
>>> De : Stefano Previdi (sprevidi) [mailto:[email-masked]]
>>> Envoy=E9 : mardi 10 septembre 2013 12:30
>>> =C0 : LITKOWSKI Stephane DTF/DERX; Rob Shakir
>>> Cc : Hannes Gredler; [email-masked]
>>> Objet : Re: [Status] Good charter proposals from Hannes and Stefano : t=
ry to merge ...
>>>=20
>>> Hi Stephane, Rob,
>>>=20
>>> one preliminary remark: I prefer to use he therm "node" rather than "ro=
uter". Use cases, such as Service Chaining requires that terminology.
>>>=20
>>> some other comments below...
>>>=20
>>>=20
>>> On Sep 10, 2013, at 11:19 AM, <[email-masked]> wrote:
>>>> Souns good to me, (adding OAM also)
>>>>=20
>>>> New recap :
>>>>=20
>>>> -------------------------------------------------------------------
>>>> Name: <TBD>
>>>> Charter:
>>>>=20
>>>>=20
>>>> Introduction
>>>> ------------
>>>> The following use cases:
>>>> . Path computation based on awareness of utilization or performance
>>>> data, within both centralized and distributed environments, . Multi-to=
pology (dual planes, disjoint trees), . Simplification and reduction of sig=
naling components (scaling), . Combined application and network layer path =
specification, . Full coverage LFA-FRR, . Topology Aware OAM, . etc.
>>>>=20
>>>> have triggered work on the definition of new architecture and protocol=
 extensions allowing to combine well known shortest path based routing para=
digms with source/explicit routing methods. Some of these extensions have b=
een implemented already.
>>>>=20
>>>>=20
>>>> Objective
>>>> ---------
>>>>=20
>>>> Define an architecture where a node can steer a packet through a netwo=
rk or set of networks (interdomain) on any path.
>>>=20
>>>=20
>>> [SP] As stated above, I'm fine with the above definition but I
>>>   assume this includes service chaining and that by "network
>>>   or set of networks" you intend "nodes" which may include
>>>   others things than just routers.
>>>=20
>>> [SLI] Agree
>>>=20
>>>=20
>>>> In this architecture, routers sharing a common trust model form a <Nam=
e-TBD> domain. The architecture defined by this working group will allow a =
node to steer a packet between any source and destination node within the <=
Name-TBD> domain (formed of one or more networks), on any path (shortest, n=
on-shortest, explicit or based on other characteristics specified by segmen=
t identifiers).
>>>=20
>>>=20
>>> [SP] without requiring to maintain state along the path, other
>>>   than in the ingress node.
>>>=20
>>> [SLI] Agree
>>>=20
>>>=20
>>>> It may then send any packet that passes through it through any path th=
at it has specified and that is conform to the security rules. Downstream r=
outers along the path within the <Name-TBD> domain forward the packet as sp=
ecified by the router at the head-end of the path.
>>>=20
>>>>=20
>>>> The architecture should support centralized and distributed path compu=
tation.
>>>>=20
>>>> The architecture should support OAM functions.
>>>=20
>>>=20
>>> [SP] The architecture should allow different mechanisms through which
>>>   a path is constructed. SR allows a variety of mechanisms, not
>>>   confined IGP/BGP path computation.
>>>=20
>>> [SLI] Agree
>>>=20
>>>> Work items :
>>>> ------------------
>>>>=20
>>>> The <Name-TBD> working group is chartered for the following ordered li=
st of work items:
>>>>=20
>>>> - The first goal of the WG is to identify use-cases.
>>>> - The WG will then define the architecture framework associated with
>>>> the security considerations. The architecture framework and security
>>>> considerations must address the relations between networks forming the=
 <Name-TBD> domain (interAS).
>>>> - Having identified use-cases, architecture and security, the WG will
>>>> identify gaps between currently available technologies and use-case
>>>> requirements.
>>>> - The WG will then define requirements for extensions to existing
>>>> protocols or new protocols that address gaps that are identified.
>>>> - The WG will first focus on the intra-domain forwarding definition.
>>>=20
>>>=20
>>> [SP] The architecture will support tunnel and non-tunnel paradigms
>>>   The architecture will support multiple dataplanes: MPLS and V6
>>>=20
>>>=20
>>> Thanks.
>>> s.
>>>=20
>>>=20
>>>> Documents :
>>>> ------------------
>>>> . Use Cases
>>>> . Architecture including security considerations
>>>> - Protocol extension requirements
>>>> . Interoperability Report
>>>>=20
>>>>=20
>>>> Protocol work may be carried out in this working group or in other wor=
king groups responsible for the protocols (ISIS,OSPF,BGP,PCEP ...), in coor=
dination with this WG, and in agreement with the WG chairs and responsible =
ADs.
>>>>=20
>>>> -----Message d'origine-----
>>>> De : Rob Shakir [mailto:[email-masked]]
>>>> Envoy=E9 : mardi 10 septembre 2013 11:05 =C0 : LITKOWSKI Stephane DTF/=
DERX
>>>> Cc : Hannes Gredler; Stefano Previdi (sprevidi); [email-masked] Objet
>>>> : Re: [Status] Good charter proposals from Hannes and Stefano : try to=
 merge ...
>>>>=20
>>>> Hi Stephane,
>>>>=20
>>>> Thanks for this, looks good! Comments in-line marked rjs>.
>>>>=20
>>>> On 10 Sep 2013, at 08:50, <[email-masked]> wrote:
>>>>=20
>>>>> Hi all,
>>>>>=20
>>>>> I'm creating a new mail topic because the "Summary of STATUS BOF ..."
>>>>> starts to be unreadable :)
>>>>>=20
>>>>> Hannes and Stefano send to us two charter proposals that sounds good =
to me.
>>>>>=20
>>>>> The main difference between the two proposals is that Stefano propose=
 a segment bound to any type of instruction (forwarding, application or ser=
vice based) while Hannes is focusing on forwarding actions (which is the fi=
rst priority, and I think everybody agree on this).
>>>>=20
>>>> rjs> Agreed -- I think it would be useful to allow definitions of segm=
ents to identify different types of "service", since there appear to be som=
e use cases (e.g., the explicit exit selection case) which require a segmen=
t type describing something that is not explicitly IGP-based.
>>>>=20
>>>>>=20
>>>>> It would be interresting to have a feedback from the mailinglist on t=
his specific point.
>>>>>=20
>>>>> IMHO, there is a strong interrest to explore the service actions boun=
d to segment in a second step keeping forwarding as a priority.
>>>>>=20
>>>>> Apart of this problem, here is a merge try of the two good proposals =
(I'm putting '<>' on hot topics :) ) :
>>>>>=20
>>>>>=20
>>>>> -------------------------------------------------------------------
>>>>> Name: <TBD>
>>>>> Charter:
>>>>>=20
>>>>>=20
>>>>> Introduction
>>>>> ------------
>>>>> The following use cases:
>>>>> . Path computation based on awareness of utilization or performance
>>>>> data, within both centralized and distributed environments, . Multi-t=
opology (dual planes, disjoint trees), . Simplification and reduction of si=
gnaling components (scaling), . Combined application and network layer path=
 specification, . Full coverage LFA-FRR, . Topology Aware OAM, . etc.
>>>>>=20
>>>>> have triggered work on the definition of new architecture and protoco=
l extensions allowing to combine well known shortest path based routing par=
adigms with source/explicit routing methods. Some of these extensions have =
been implemented already.
>>>>>=20
>>>>>=20
>>>>> Objective
>>>>> ---------
>>>>>=20
>>>>> Define an architecture where a node can steer a packet through a netw=
ork or set of networks (interdomain) on any path (shortest, non shortest, e=
xplicit, <service or application>).
>>>>>=20
>>>>> In this architecture, routers are sharing a common trust model and ar=
e forming a <Name-TBD> domain.
>>>>> Within this domain, a node can specify a path between itself and any =
destination in the domain. <The path may be a forwarding path, a service ch=
aining path or a combination of both>.
>>>>=20
>>>> rjs> To clarify here, we define that our domain is under a common trus=
t model (essentially, under common administrative control?), but then go on=
 to talk about inter-domain elsewhere. Can we perhaps clarify (by defining =
a specific "<Name-TBD> domain" nomenclature) and say something like:
>>>>=20
>>>> "In this architecture, routers sharing a common trust model form a <Na=
me-TBD> domain. The architecture defined by this working group will allow a=
 node to steer a packet between any source and destination node within the =
<Name-TBD> domain (formed of one or more networks), on any path (shortest, =
non-shortest, explicit or based on other characteristics specified by segme=
nt identifiers)."
>>>>=20
>>>>> It may then send any packet that passes through it through any path t=
hat it has specified and that is conform to the security rules. Downstream =
routers along the path within the <Name-TBD> domain forward the packet as s=
pecified by the router at the head-end of the path.
>>>>>=20
>>>>> The architecture should support centralized and distributed path comp=
utation.
>>>>>=20
>>>>>=20
>>>>> Work items :
>>>>> ------------------
>>>>>=20
>>>>> The <Name-TBD> working group is chartered for the following ordered l=
ist of work items:
>>>>>=20
>>>>> - The first goal of the WG is to identify use-cases.
>>>>> - The WG will then define the architecture framework associated with
>>>>> the security considerations. The architecture framework and security
>>>>> considerations must address the relations between domains (inter doma=
in).
>>>>=20
>>>> rjs> And then here "networks forming the <Name-TBD> domain"?
>>>>=20
>>>> Thanks for the efforts,
>>>> r.
>>>>=20
>>>>> - Having identified use-cases, architecture and security, the WG will
>>>>> identify gaps between currently available technologies and use-case
>>>>> requirements.
>>>>> - The WG will then define requirements for extensions to existing
>>>>> protocols or new protocols that address gaps that are identified.
>>>>> - The WG will first focus on the intra-domain forwarding definition.
>>>>>=20
>>>>>=20
>>>>> Documents :
>>>>> ------------------
>>>>> . Use Cases
>>>>> . Architecture including security considerations
>>>>> - Protocol extension requirements
>>>>> . Interoperability Report
>>>>>=20
>>>>>=20
>>>>> Protocol work may be carried out in this working group or in other wo=
rking groups responsible for the protocols (ISIS,OSPF,BGP,PCEP ...), in coo=
rdination with this WG, and in agreement with the WG chairs and responsible=
 ADs.
>>>>>=20
>>>>>=20
>>>>>=20
>>>>> Hope it helps to progress on the definition.
>>>>>=20
>>>>>=20
>>>>> Stephane
>>>>>=20
>>>>>=20
>>>>> -----Message d'origine-----
>>>>> De : Hannes Gredler [mailto:[email-masked]] Envoy=E9 : vendredi 6
>>>>> septembre 2013 18:27 =C0 : LITKOWSKI Stephane DTF/DERX Cc :
>>>>> [email-masked] Objet : Re: [Status] Summary of STATUS BOF and the
>>>>> next steps
>>>>>=20
>>>>> hi stephane,
>>>>>=20
>>>>> here is a revised draft charter as per your comments.
>>>>>=20
>>>>> ---
>>>>>=20
>>>>> <Name-TBD> domain contains a set of routers with the following
>>>>> characteristics:
>>>>>=20
>>>>> - They form a connected network
>>>>> - They can forward traffic through any path within the network using
>>>>> shortest path, or any other (e.g., an explicit) path
>>>>> - They share a common trust model. In this model, any router within
>>>>> the domain can specify a path between itself and any other router  in
>>>>> the domain. It may then send any packet that passes through it
>>>>> through any path that it has specified and that is conform to the
>>>>> security rules. Downstream routers along the path within the
>>>>> <Name-TBD>  domain forward the packet as specified by the router at
>>>>> the head-end  of the path.
>>>>>=20
>>>>> The <Name-TBD> working group is chartered for the following ordered l=
ist of work items:
>>>>>=20
>>>>> - The first goal of the WG is to identify use-cases.
>>>>> - The WG will then define the architecture framework associated with
>>>>> the security considerations. The architecture framework and security
>>>>> considerations must address the relations between domains (interdomai=
n).
>>>>> - Having identified use-cases, architecture and security, the WG will
>>>>> identify gaps between currently available technologies and use-case
>>>>> requirements.
>>>>> - The WG will then define requirements for extensions to existing
>>>>> protocols or new protocols that address gaps that are identified.
>>>>> - The WG will first focus on the intra-domain forwarding definition.
>>>>>=20
>>>>> Protocol work may be carried out in this working group or in other wo=
rking groups responsible for the protocols, in coordination with this WG, a=
nd in agreement with the WG chairs and responsible ADs.
>>>>> However, no protocol work will be adopted by a working group to addre=
ss the identified use-cases until the requirements document motivating the =
protocol work has been sent to the IESG for publication as an RFC.
>>>>>=20
>>>>> ---
>>>>>=20
>>>>> /hannes
>>>>>=20
>>>>> On Sep 4, 2013, at 10:02 AM, <[email-masked]> <stephan=
[email-masked]> wrote:
>>>>>=20
>>>>>> Hannes,
>>>>>>=20
>>>>>> In case, we are using only directed forwarding (adjacency segment),
>>>>>> could we still talk about tunneling ? (it's a very very small tunnel=
) Moreover talking about "stacking" is really dataplane agnostic (MPLS) ...
>>>>>>=20
>>>>>> In the proposed segment routing architectural concepts, segments are=
 at the same "level" and pointer moves on the segment list, then the MPLS i=
nstantiation is performing this using stacking ...
>>>>>>=20
>>>>>> IMHO, if we use "Stacked Tunnels", we already talk about a chosen so=
lution and it's closing the door to something else  ...
>>>>>>=20
>>>>>> Finally, about the "routing" word, routing is essentially a "forward=
" action which may limit the scope of what we can do by using a segment lis=
t. Actions associated with a segment could be something else than forwardin=
g.
>>>>>>=20
>>>>>> Do we want in the charter to limit the scope to routing actions ?
>>>>>>=20
>>>>>> I have no solution today to propose for the naming, but I completely=
 agree with Loa, to first focus on working on the charter, and define a cle=
ar scope of the work and then the name will be easier to find.
>>>>>>=20
>>>>>> Regarding your charter proposal :
>>>>>>=20
>>>>>> --------
>>>>>>=20
>>>>>> - They form a connected network
>>>>>>   [SLI] InterAS case must be included, but the WG can go step by ste=
p and first release intraAS, and then doing interAS (in relation with IDR ?=
?).
>>>>>>=20
>>>>>> - They can forward traffic through the shortest paths or paths other=
 than the shortest (the latter called explicitly routed paths, or explicit =
paths)
>>>>>>   [SLI] There is something else between SPT and Explicit path, you c=
an define other algorithms than SPT to define a path, and it's not explicit=
 path. Moreover I come back to my comment, on do we want to limit the scope=
 to routing ? I would say no.
>>>>>>=20
>>>>>> - They share a common trust model. In this model, any router within =
the ERD can specify an explicit path between itself and any other router in=
 the ERD. It can then send any packet that passes through it through any pa=
th that it has specified.
>>>>>>   [SLI] Security considerations may have to be addressed in the
>>>>>> charter , especially for the interAS case (trust yes, but not sure
>>>>>> access to everything may not be good)
>>>>>>=20
>>>>>> Downstream routers within the ERD forward the packet as specified by=
 the router at the head-end of the path.
>>>>>> [SLI] Yes, but any router in the middle may be able to change the en=
d to end explicit path.
>>>>>>=20
>>>>>>=20
>>>>>>=20
>>>>>> - The first goal of the STER WG is to identify use-cases for ERDs.
>>>>>> - Having identified use-cases, the WG will identify gaps between cur=
rently available technologies and use-case requirements.
>>>>>> - The WG will then define requirements for extensions to existing pr=
otocols or new protocols that address gaps that are identified.
>>>>>>=20
>>>>>> [SLI] Agree, I would add :
>>>>>> - defining the architecture framework
>>>>>> - analysing the security considerisations
>>>>>>=20
>>>>>>=20
>>>>>> ---------
>>>>>>=20
>>>>>>=20
>>>>>> Here would be my proposal to extend yours :
>>>>>>=20
>>>>>> A <named to be defined> domain contains a set of routers with the fo=
llowing characteristics:
>>>>>>=20
>>>>>> - They form a connected network
>>>>>> - They can forward traffic through any path within the network using
>>>>>> shortest path, non shortest path or explicit path
>>>>>> - They may provide other types of services than forwarding and they =
can enforce service actions in the path.
>>>>>> - They share a common trust model. In this model, any router within =
the domain can specify a path between itself and any other router in the do=
main. It may then send any packet that passes through it through any path t=
hat it has specified and that is conform to the security rules. Downstream =
routers within the ERD forward the packet as specified by the router at the=
 head-end of the path.
>>>>>>=20
>>>>>> The <name> working group is chartered for the following ordered list=
 of work items:
>>>>>>=20
>>>>>> - The first goal of the WG is to identify use-cases.
>>>>>> - The WG will then define the architecture framework associated with=
 the security considerations. The architecture framework and security consi=
derations must address the relations between domains (interdomain).
>>>>>> - Having identified use-cases, architecture and security, the WG wil=
l identify gaps between currently available technologies and use-case requi=
rements.
>>>>>> - The WG will then define requirements for extensions to existing pr=
otocols or new protocols that address gaps that are identified.
>>>>>> - The WG will first focus on the intra-domain forwarding definition.
>>>>>>=20
>>>>>> Protocol work may be carried out in this working group or in other w=
orking groups responsible for the protocols, in coordination with this WG, =
and in agreement with the WG chairs and responsible ADs. However, no protoc=
ol work will be adopted by a working group to address the ERD use-cases unt=
il the requirements document motivating the protocol work has been sent to =
the IESG for publication as an RFC.
>>>>>>=20
>>>>>> -----Message d'origine-----
>>>>>> De : [email-masked] [mailto:[email-masked]] De la
>>>>>> part de Hannes Gredler Envoy=E9 : mardi 3 septembre 2013 18:31 =C0 :=
 Loa
>>>>>> Andersson Cc : [email-masked] Objet : Re: [Status] Summary of
>>>>>> STATUS BOF and the next steps
>>>>>>=20
>>>>>> good point - what about this charter proposal ?
>>>>>>=20
>>>>>> ---
>>>>>>=20
>>>>>> Stacked Tunnels for Explicit Routing (STER)
>>>>>> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
>>>>>>=20
>>>>>> A explicit routing domain (ERD) contains a set of routers with the f=
ollowing characteristics:
>>>>>>=20
>>>>>> - They form a connected network
>>>>>> - They can forward traffic through the shortest paths or paths other
>>>>>> than the shortest (the latter called explicitly routed paths, or
>>>>>> explicit paths)
>>>>>> - They share a common trust model. In this model, any router within =
the ERD can specify an explicit path between itself and any other router in=
 the ERD. It can then send any packet that passes through it through any pa=
th that it has specified. Downstream routers within the ERD forward the pac=
ket as specified by the router at the head-end of the path.
>>>>>>=20
>>>>>> The STER working group is chartered for the following ordered list o=
f work items:
>>>>>>=20
>>>>>> - The first goal of the STER WG is to identify use-cases for ERDs.
>>>>>> - Having identified use-cases, the WG will identify gaps between cur=
rently available technologies and use-case requirements.
>>>>>> - The WG will then define requirements for extensions to existing pr=
otocols or new protocols that address gaps that are identified.
>>>>>>=20
>>>>>> Protocol work may be carried out in this working group or in other w=
orking groups responsible for the protocols, in coordination with this WG, =
and in agreement with the WG chairs and responsible ADs. However, no protoc=
ol work will be adopted by a working group to address the ERD use-cases unt=
il the requirements document motivating the protocol work has been sent to =
the IESG for publication as an RFC.
>>>>>>=20
>>>>>> ---
>>>>>>=20
>>>>>> <flame suit on>
>>>>>>=20
>>>>>> /hannes
>>>>>>=20
>>>>>>=20
>>>>>> On Sep 3, 2013, at 5:31 PM, Loa Andersson wrote:
>>>>>>=20
>>>>>>> Folks,
>>>>>>>=20
>>>>>>> Excuse me if I'm slightly out of the loop, but so far I have not
>>>>>>> seen a charter proposal, if there is one please point me to it.
>>>>>>>=20
>>>>>>> It seems a bit odd to put the cart (what the wg should do) before
>>>>>>> the horse (wg name). If we drill down the the charter first the wg
>>>>>>> name might be easier to figure out.
>>>>>>>=20
>>>>>>> /Loa
>>>>>>>=20
>>>>>>> PS
>>>>>>> OK I understand that the horse and cart analogy limps a  bit :).
>>>>>>>=20
>>>>>>>=20
>>>>>>>=20
>>>>>>> On 2013-09-03 17:22, AshwoodsmithPeter wrote:
>>>>>>>> " If the WG charter is limited to source routing, how will we hand=
le the "non source routing" use cases of segment routing ? In another worki=
ng group ? So we will go back to the WG synchronization issue that has been=
 raised for this technology ..."
>>>>>>>>=20
>>>>>>>> That's why I suggested SRV2. We are revisiting source routing with=
 new concepts. More generic number/action behavior.
>>>>>>>>=20
>>>>>>>> Peter
>>>>>>>>=20
>>>>>>>> -----Original Message-----
>>>>>>>> From: [email-masked] [mailto:[email-masked]] On
>>>>>>>> Behalf Of [email-masked]
>>>>>>>> Sent: Tuesday, September 03, 2013 10:43 AM
>>>>>>>> To: AshwoodsmithPeter
>>>>>>>> Cc: [email-masked]
>>>>>>>> Subject: Re: [Status] Summary of STATUS BOF and the next steps
>>>>>>>>=20
>>>>>>>>=20
>>>>>>>> There was a misunderstanding in my small comment :) so I will expl=
ain more :
>>>>>>>>=20
>>>>>>>> In segment routing, you have more than basic source routing : segm=
ent routing is just associate a segment number to an action and then combin=
e segment as you want, yes you can do source routing, but you also can do m=
ore.
>>>>>>>>=20
>>>>>>>> In the other hand, I completely agree with your statement that
>>>>>>>> source routing is generic and dataplane agnostic, as segment routi=
ng is ...
>>>>>>>> (segment routing is not a new dataplane ...)
>>>>>>>>=20
>>>>>>>> Now the definition of the WG naming must be inline with the
>>>>>>>> charter that will be defined ... (draft today)
>>>>>>>>=20
>>>>>>>> Based on the already existing consensus (at least for MPLS datapla=
ne) brought up during Berlin STATUS BOF meeting, segment routing sounds to =
be a good target candidate.
>>>>>>>>=20
>>>>>>>> So now, do we want to do more in the WG charter than just make pro=
gressing segment routing architecture and uses cases document and ensure co=
ordination for the standardization of this technology ?
>>>>>>>>=20
>>>>>>>> Do we want to standardize other technologies in this WG ? I don't =
think so, based on Stewart's conclusion email from the BOF :"A new WG focus=
ed solely on SR therefore needs to be create"
>>>>>>>>=20
>>>>>>>> If the WG charter is limited to source routing, how will we handle=
 the "non source routing" use cases of segment routing ? In another working=
 group ? So we will go back to the WG synchronization issue that has been r=
aised for this technology ...
>>>>>>>>=20
>>>>>>>> If the WG is focused on SR, let's use a name in relation with SR.
>>>>>>>>=20
>>>>>>>> Feedback ?
>>>>>>>>=20
>>>>>>>>=20
>>>>>>>> Stephane
>>>>>>>>=20
>>>>>>>>=20
>>>>>>>> -----Message d'origine-----
>>>>>>>> De : AshwoodsmithPeter [mailto:[email-masked]]
>>>>>>>> Envoy=E9 : mardi 3 septembre 2013 15:27 =C0 : LITKOWSKI Stephane
>>>>>>>> DTF/DERX Cc : John E Drake; Mark Townsley; Victor Kuarsingh;
>>>>>>>> Roberta Maglione (robmgl); John G. Scudder; Adrian Farrel; Alvaro
>>>>>>>> Retana (aretana); [email-masked]; Stewart Bryant (stbryant) Objet=
 : Re:
>>>>>>>> [Status] Summary of STATUS BOF and the next steps
>>>>>>>>=20
>>>>>>>> The term "source routing" has been around for a very long time and=
 is data path agnostic. Its also the term used in the literature etc so my =
preference is to stick with this existing well known and data path agnostic=
 term.
>>>>>>>>=20
>>>>>>>> Peter
>>>>>>>>=20
>>>>>>>> On Sep 3, 2013, at 9:07 AM, "[email-masked]" <steph=
[email-masked]> wrote:
>>>>>>>>=20
>>>>>>>>> Hi,
>>>>>>>>>=20
>>>>>>>>> "Source routing" is just a subcase of segment routing ... as it i=
s for IP routing ...
>>>>>>>>>=20
>>>>>>>>> Stephane
>>>>>>>>>=20
>>>>>>>>>=20
>>>>>>>>> -----Message d'origine-----
>>>>>>>>> De : [email-masked] [mailto:[email-masked]] De
>>>>>>>>> la part de John E Drake Envoy=E9 : mardi 3 septembre 2013 15:02 =
=C0 :
>>>>>>>>> Mark Townsley; Victor Kuarsingh Cc : Roberta Maglione (robmgl); J=
ohn G.
>>>>>>>>> Scudder; Alvaro Retana (aretana); Adrian Farrel; [email-masked];
>>>>>>>>> Stewart Bryant (stbryant) Objet : Re: [Status] Summary of STATUS
>>>>>>>>> BOF and the next steps
>>>>>>>>>=20
>>>>>>>>> Hi,
>>>>>>>>>=20
>>>>>>>>> What is this 'segment routing' silliness?  The correct term is 's=
ource routing'.
>>>>>>>>>=20
>>>>>>>>> Yours Irrespectively,
>>>>>>>>>=20
>>>>>>>>> John
>>>>>>>>>=20
>>>>>>>>>> -----Original Message-----
>>>>>>>>>> From: [email-masked] [mailto:[email-masked]]
>>>>>>>>>> On Behalf Of Mark Townsley
>>>>>>>>>> Sent: Sunday, September 01, 2013 10:08 AM
>>>>>>>>>> To: Victor Kuarsingh
>>>>>>>>>> Cc: Roberta Maglione (robmgl); John G. Scudder; Adrian Farrel;
>>>>>>>>>> Alvaro Retana (aretana); [email-masked]; Stewart Bryant
>>>>>>>>>> (stbryant)
>>>>>>>>>> Subject: Re: [Status] Summary of STATUS BOF and the next steps
>>>>>>>>>>=20
>>>>>>>>>>=20
>>>>>>>>>> On Sep 1, 2013, at 5:38 PM, Victor Kuarsingh wrote:
>>>>>>>>>>=20
>>>>>>>>>>> All,
>>>>>>>>>>>=20
>>>>>>>>>>> I would also favour "Segment Routing WG" as well.
>>>>>>>>>>>=20
>>>>>>>>>>> I note this since attempting to come up with an all
>>>>>>>>>>> encompassing acronym will be difficult and Segment Routing is
>>>>>>>>>>> generic enough to associate to multiple functions.
>>>>>>>>>>=20
>>>>>>>>>> Then we can just use "segroute" for the short name. WGs do not
>>>>>>>>>> have to have acronyms, but they do need to have an 8-char
>>>>>>>>>> limited short name for the various automated tools not to break.
>>>>>>>>>>=20
>>>>>>>>>> - Mark
>>>>>>>>>>=20
>>>>>>>>>>>=20
>>>>>>>>>>> Regards,
>>>>>>>>>>>=20
>>>>>>>>>>> Victor K
>>>>>>>>>>>=20
>>>>>>>>>>>=20
>>>>>>>>>>>=20
>>>>>>>>>>> On 2013-08-31 6:51 PM, "Roberta Maglione (robmgl)"
>>>>>>>>>>> <[email-masked]>
>>>>>>>>>>> wrote:
>>>>>>>>>>>=20
>>>>>>>>>>>> +1 for Segment Routing WG
>>>>>>>>>>>>=20
>>>>>>>>>>>> Roberta
>>>>>>>>>>>>=20
>>>>>>>>>>>> Sent from my iPad
>>>>>>>>>>>>=20
>>>>>>>>>>>> On 2013-08-30, at 2:55 PM, "Alvaro Retana (aretana)"
>>>>>>>>>>>> <[email-masked]>
>>>>>>>>>>>> wrote:
>>>>>>>>>>>>=20
>>>>>>>>>>>>> Segment Routing WG
>>>>>>>>>>>>>=20
>>>>>>>>>>>>> Sent from my iPhone
>>>>>>>>>>>>>=20
>>>>>>>>>>>>> On Aug 30, 2013, at 1:39 PM, "Stewart Bryant (stbryant)"
>>>>>>>>>>>>> <[email-masked]> wrote:
>>>>>>>>>>>>>=20
>>>>>>>>>>>>>> The second task, which hopefully should be relatively easy,
>>>>>>>>>>>>>> is to find a better working name for the WG, since it has
>>>>>>>>>>>>>> been put to me a number of times that STATUS is going to be
>>>>>>>>>>>>>> confusing in text and a difficult search term.
>>>>>>>>>>>>> _______________________________________________
>>>>>>>>>>>>> status mailing list
>>>>>>>>>>>>> [email-masked]
>>>>>>>>>>>>> https://www.ietf.org/mailman/listinfo/status
>>>>>>>>>>>> _______________________________________________
>>>>>>>>>>>> status mailing list
>>>>>>>>>>>> [email-masked]
>>>>>>>>>>>> https://www.ietf.org/mailman/listinfo/status
>>>>>>>>>>>=20
>>>>>>>>>>>=20
>>>>>>>>>>> _______________________________________________
>>>>>>>>>>> status mailing list
>>>>>>>>>>> [email-masked]
>>>>>>>>>>> https://www.ietf.org/mailman/listinfo/status
>>>>>>>>>>=20
>>>>>>>>>> _______________________________________________
>>>>>>>>>> status mailing list
>>>>>>>>>> [email-masked]
>>>>>>>>>> https://www.ietf.org/mailman/listinfo/status
>>>>>>>>>=20
>>>>>>>>>=20
>>>>>>>>> _______________________________________________
>>>>>>>>> status mailing list
>>>>>>>>> [email-masked]
>>>>>>>>> https://www.ietf.org/mailman/listinfo/status
>>>>>>>>>=20
>>>>>>>>> _________________________________________________________________
>>>>>>>>> _ _ _ __ ___________________________________________________
>>>>>>>>>=20
>>>>>>>>> Ce message et ses pieces jointes peuvent contenir des
>>>>>>>>> informations confidentielles ou privilegiees et ne doivent donc
>>>>>>>>> pas etre diffuses, exploites ou copies sans autorisation. Si vous
>>>>>>>>> avez recu ce message par erreur, veuillez le signaler a l'expedit=
eur et le detruire ainsi que les pieces jointes. Les messages electroniques=
 etant susceptibles d'alteration, Orange decline toute responsabilite si ce=
 message a ete altere, deforme ou falsifie. Merci.
>>>>>>>>>=20
>>>>>>>>> This message and its attachments may contain confidential or
>>>>>>>>> privileged information that may be protected by law; they should =
not be distributed, used or copied without authorisation.
>>>>>>>>> If you have received this email in error, please notify the sende=
r and delete this message and its attachments.
>>>>>>>>> As emails may be altered, Orange is not liable for messages that =
have been modified, changed or falsified.
>>>>>>>>> Thank you.
>>>>>>>>>=20
>>>>>>>>> _______________________________________________
>>>>>>>>> status mailing list
>>>>>>>>> [email-masked]
>>>>>>>>> https://www.ietf.org/mailman/listinfo/status
>>>>>>>>=20
>>>>>>>> __________________________________________________________________
>>>>>>>> _ _ _ ____________________________________________________
>>>>>>>>=20
>>>>>>>> Ce message et ses pieces jointes peuvent contenir des informations
>>>>>>>> confidentielles ou privilegiees et ne doivent donc pas etre
>>>>>>>> diffuses, exploites ou copies sans autorisation. Si vous avez recu
>>>>>>>> ce message par erreur, veuillez le signaler a l'expediteur et le d=
etruire ainsi que les pieces jointes. Les messages electroniques etant susc=
eptibles d'alteration, Orange decline toute responsabilite si ce message a =
ete altere, deforme ou falsifie. Merci.
>>>>>>>>=20
>>>>>>>> This message and its attachments may contain confidential or
>>>>>>>> privileged information that may be protected by law; they should n=
ot be distributed, used or copied without authorisation.
>>>>>>>> If you have received this email in error, please notify the sender=
 and delete this message and its attachments.
>>>>>>>> As emails may be altered, Orange is not liable for messages that h=
ave been modified, changed or falsified.
>>>>>>>> Thank you.
>>>>>>>>=20
>>>>>>>> _______________________________________________
>>>>>>>> status mailing list
>>>>>>>> [email-masked]
>>>>>>>> https://www.ietf.org/mailman/listinfo/status
>>>>>>>> _______________________________________________
>>>>>>>> status mailing list
>>>>>>>> [email-masked]
>>>>>>>> https://www.ietf.org/mailman/listinfo/status
>>>>>>>>=20
>>>>>>>=20
>>>>>>> --
>>>>>>>=20
>>>>>>>=20
>>>>>>> Loa Andersson                        email: [email-masked]
>>>>>>> Senior MPLS Expert                          [email-masked]
>>>>>>> Huawei Technologies (consultant)     phone: +46 739 81 21 64
>>>>>>> _______________________________________________
>>>>>>> status mailing list
>>>>>>> [email-masked]
>>>>>>> https://www.ietf.org/mailman/listinfo/status
>>>>>>>=20
>>>>>>>=20
>>>>>>=20
>>>>>>=20
>>>>>> _______________________________________________
>>>>>> status mailing list
>>>>>> [email-masked]
>>>>>> https://www.ietf.org/mailman/listinfo/status
>>>>>>=20
>>>>>> ____________________________________________________________________
>>>>>> _ _ ___________________________________________________
>>>>>>=20
>>>>>> Ce message et ses pieces jointes peuvent contenir des informations
>>>>>> confidentielles ou privilegiees et ne doivent donc pas etre
>>>>>> diffuses, exploites ou copies sans autorisation. Si vous avez recu
>>>>>> ce message par erreur, veuillez le signaler a l'expediteur et le det=
ruire ainsi que les pieces jointes. Les messages electroniques etant suscep=
tibles d'alteration, Orange decline toute responsabilite si ce message a et=
e altere, deforme ou falsifie. Merci.
>>>>>>=20
>>>>>> This message and its attachments may contain confidential or
>>>>>> privileged information that may be protected by law; they should not=
 be distributed, used or copied without authorisation.
>>>>>> If you have received this email in error, please notify the sender a=
nd delete this message and its attachments.
>>>>>> As emails may be altered, Orange is not liable for messages that hav=
e been modified, changed or falsified.
>>>>>> Thank you.
>>>>>>=20
>>>>>>=20
>>>>>>=20
>>>>>=20
>>>>>=20
>>>>>=20
>>>>> _____________________________________________________________________
>>>>> _ ___________________________________________________
>>>>>=20
>>>>> Ce message et ses pieces jointes peuvent contenir des informations
>>>>> confidentielles ou privilegiees et ne doivent donc pas etre diffuses,
>>>>> exploites ou copies sans autorisation. Si vous avez recu ce message
>>>>> par erreur, veuillez le signaler a l'expediteur et le detruire ainsi =
que les pieces jointes. Les messages electroniques etant susceptibles d'alt=
eration, Orange decline toute responsabilite si ce message a ete altere, de=
forme ou falsifie. Merci.
>>>>>=20
>>>>> This message and its attachments may contain confidential or
>>>>> privileged information that may be protected by law; they should not =
be distributed, used or copied without authorisation.
>>>>> If you have received this email in error, please notify the sender an=
d delete this message and its attachments.
>>>>> As emails may be altered, Orange is not liable for messages that have=
 been modified, changed or falsified.
>>>>> Thank you.
>>>>>=20
>>>>> _______________________________________________
>>>>> status mailing list
>>>>> [email-masked]
>>>>> https://www.ietf.org/mailman/listinfo/status
>>>>=20
>>>>=20
>>>> ______________________________________________________________________
>>>> ___________________________________________________
>>>>=20
>>>> Ce message et ses pieces jointes peuvent contenir des informations
>>>> confidentielles ou privilegiees et ne doivent donc pas etre diffuses,
>>>> exploites ou copies sans autorisation. Si vous avez recu ce message
>>>> par erreur, veuillez le signaler a l'expediteur et le detruire ainsi q=
ue les pieces jointes. Les messages electroniques etant susceptibles d'alte=
ration, Orange decline toute responsabilite si ce message a ete altere, def=
orme ou falsifie. Merci.
>>>>=20
>>>> This message and its attachments may contain confidential or
>>>> privileged information that may be protected by law; they should not b=
e distributed, used or copied without authorisation.
>>>> If you have received this email in error, please notify the sender and=
 delete this message and its attachments.
>>>> As emails may be altered, Orange is not liable for messages that have =
been modified, changed or falsified.
>>>> Thank you.
>>>>=20
>>>=20
>>>=20
>>> _______________________________________________________________________=
__________________________________________________
>>>=20
>>> Ce message et ses pieces jointes peuvent contenir des informations conf=
identielles ou privilegiees et ne doivent donc
>>> pas etre diffuses, exploites ou copies sans autorisation. Si vous avez =
recu ce message par erreur, veuillez le signaler
>>> a l'expediteur et le detruire ainsi que les pieces jointes. Les message=
s electroniques etant susceptibles d'alteration,
>>> Orange decline toute responsabilite si ce message a ete altere, deforme=
 ou falsifie. Merci.
>>>=20
>>> This message and its attachments may contain confidential or privileged=
 information that may be protected by law;
>>> they should not be distributed, used or copied without authorisation.
>>> If you have received this email in error, please notify the sender and =
delete this message and its attachments.
>>> As emails may be altered, Orange is not liable for messages that have b=
een modified, changed or falsified.
>>> Thank you.
>>>=20
>>=20
>>=20
>>=20
>=20
>=20

From: Hannes Gredler <[email-masked]>
Date: Tue, 10 Sep 2013 19:27:03 +0200
To: "Stefano Previdi (sprevidi)" <[email-masked]>
Cc: Stephane Litkowski <[email-masked]>, Rob Shakir <[email-masked]>, "[email-masked]" <[email-masked]>
Subject: Re: [Status] Good charter proposals from Hannes and Stefano : try to merge ...

stefano,

On Sep 10, 2013, at 6:58 PM, Stefano Previdi (sprevidi) wrote:

>=20
> On Sep 10, 2013, at 1:25 PM, <[email-masked]> wrote:
>=20
>> Agree on all proposal except :
>>=20
>> "[SP] The architecture will support tunnel and non-tunnel paradigms
>>    The architecture will support multiple dataplanes: MPLS and V6"
>>=20
>> I don't see the reason for this ... IMHO, the gap analysis and =
requirements inventory will result on saying or not
>=20
>=20
> [SP] While I understand what brought the following statements
>     in the proposed charter:
> 	"Having identified use-cases, architecture and security,=20
> 	 the WG will identify gaps between currently available=20
> 	 technologies and use-case requirements.
> 	 The WG will then define requirements for extensions to=20
> 	 existing protocols or new protocols that address gaps=20
> 	 that are identified."
>=20
>     I'd like to point out with better precision what are the=20
>     directions we are ALREADY engaged into: dataplanes and=20
>     paradigms. As I mentioned in my charter proposal, we do have=20
>     implementations and multi-vendor interoperability tests will
>     happen soon. So, I just want to be sure we don't ignore this=20
>     reality.

HG> just because you have an implementation for <foo> does not =
constitute
    community interest. we are trying to build here a charter that
    matches what a broader community wants. if the use-case that you're =
concerned
    about (service-chaining and a new internet data plane #4) are =
compelling
    enough the group will work on it, but mandating that into the =
charter,
    without asking the though questions first seems a wrong start to me.

/hannes

>> : we must use tunnels and/or non tunnels, and the following =
dataplanes ... But I don't see the reason to put solutions directly in =
the charter ...
>=20
>=20
> these are not solutions these are way to avoid boundaries in the
> framework.
>=20
> Thanks.
> s.
>=20
>=20
>> Could you explain your point ?
>>=20
>>=20
>> updated with the other comments :
>>=20
>> -------------------------------------------------------------------
>> Name: <TBD>
>> Charter:
>>=20
>>=20
>> Introduction
>> ------------
>> The following use cases:
>> . Path computation based on awareness of utilization or performance
>> data, within both centralized and distributed environments, . =
Multi-topology (dual planes, disjoint trees), . Simplification and =
reduction of signaling components (scaling), . Combined application and =
network layer path specification, . Full coverage LFA-FRR, . Topology =
Aware OAM, . etc.
>>=20
>> have triggered work on the definition of new architecture and =
protocol extensions allowing to combine well known shortest path based =
routing paradigms with source/explicit routing methods. Some of these =
extensions have been implemented already.
>>=20
>>=20
>> Objective
>> ---------
>>=20
>> Define an architecture where a node can steer a packet through a =
network or set of networks (interdomain) on any path without requiring =
to maintain state along the path, other than in the ingress node.
>>=20
>> A node may be any type of device including routers or appliances.
>>=20
>> In this architecture, nodes sharing a common trust model form a =
<Name-TBD> domain. The architecture defined by this working group will =
allow a node to steer a packet between any source and destination node =
within the <Name-TBD> domain (formed of one or more networks), on any =
path (shortest, non-shortest, explicit or based on other characteristics =
specified by segment identifiers).
>>=20
>> It may then send any packet that passes through it through any path =
that it has specified and that is conform to the security rules. =
Downstream nodes along the path within the <Name-TBD> domain forward the =
packet by using the informations inserted by the node at the head-end
>>=20
>> The architecture should support centralized and distributed path =
computation.
>>=20
>> The architecture should support OAM functions.
>>=20
>> The architecture should allow different mechanisms through which
>>    a path is constructed. SR allows a variety of mechanisms, not
>>    confined IGP/BGP path computation.
>>=20
>> As MPLS dataplane is largely deployed, the <Name-TBD> WG should avoid =
any modification in the MPLS dataplane when defining the architecture.
>>=20
>>=20
>> Work items :
>> ------------------
>>=20
>> The <Name-TBD> working group is chartered for the following ordered =
list of work items:
>>=20
>> - The first goal of the WG is to identify use-cases.
>> - The WG will then define the architecture framework associated with
>> the security considerations. The architecture framework and security
>> considerations must address the relations between networks forming =
the <Name-TBD> domain (interAS).
>> - Having identified use-cases, architecture and security, the WG will
>> identify gaps between currently available technologies and use-case
>> requirements.
>> - The WG will then define requirements for extensions to existing
>> protocols or new protocols that address gaps that are identified.
>> - The WG will first focus on the intra-domain forwarding definition.
>>=20
>>=20
>> Documents :
>> ------------------
>> . Use Cases
>> . Architecture including security considerations
>> - Protocol extension requirements
>> . Interoperability Report
>>=20
>>=20
>> Required protocol extensions are carried out in working groups =
responsible (ISIS,OSPF,BGP,PCEP ...). Work on new protocols may be =
carried out by the <Name-TBD> WG.
>>=20
>> -----Message d'origine-----
>> De : Stefano Previdi (sprevidi) [mailto:[email-masked]]
>> Envoy=E9 : mardi 10 septembre 2013 12:30
>> =C0 : LITKOWSKI Stephane DTF/DERX; Rob Shakir
>> Cc : Hannes Gredler; [email-masked]
>> Objet : Re: [Status] Good charter proposals from Hannes and Stefano : =
try to merge ...
>>=20
>> Hi Stephane, Rob,
>>=20
>> one preliminary remark: I prefer to use he therm "node" rather than =
"router". Use cases, such as Service Chaining requires that terminology.
>>=20
>> some other comments below...
>>=20
>>=20
>> On Sep 10, 2013, at 11:19 AM, <[email-masked]> wrote:
>>> Souns good to me, (adding OAM also)
>>>=20
>>> New recap :
>>>=20
>>> -------------------------------------------------------------------
>>> Name: <TBD>
>>> Charter:
>>>=20
>>>=20
>>> Introduction
>>> ------------
>>> The following use cases:
>>> . Path computation based on awareness of utilization or performance
>>> data, within both centralized and distributed environments, . =
Multi-topology (dual planes, disjoint trees), . Simplification and =
reduction of signaling components (scaling), . Combined application and =
network layer path specification, . Full coverage LFA-FRR, . Topology =
Aware OAM, . etc.
>>>=20
>>> have triggered work on the definition of new architecture and =
protocol extensions allowing to combine well known shortest path based =
routing paradigms with source/explicit routing methods. Some of these =
extensions have been implemented already.
>>>=20
>>>=20
>>> Objective
>>> ---------
>>>=20
>>> Define an architecture where a node can steer a packet through a =
network or set of networks (interdomain) on any path.
>>=20
>>=20
>> [SP] As stated above, I'm fine with the above definition but I
>>    assume this includes service chaining and that by "network
>>    or set of networks" you intend "nodes" which may include
>>    others things than just routers.
>>=20
>> [SLI] Agree
>>=20
>>=20
>>> In this architecture, routers sharing a common trust model form a =
<Name-TBD> domain. The architecture defined by this working group will =
allow a node to steer a packet between any source and destination node =
within the <Name-TBD> domain (formed of one or more networks), on any =
path (shortest, non-shortest, explicit or based on other characteristics =
specified by segment identifiers).
>>=20
>>=20
>> [SP] without requiring to maintain state along the path, other
>>    than in the ingress node.
>>=20
>> [SLI] Agree
>>=20
>>=20
>>> It may then send any packet that passes through it through any path =
that it has specified and that is conform to the security rules. =
Downstream routers along the path within the <Name-TBD> domain forward =
the packet as specified by the router at the head-end of the path.
>>=20
>>>=20
>>> The architecture should support centralized and distributed path =
computation.
>>>=20
>>> The architecture should support OAM functions.
>>=20
>>=20
>> [SP] The architecture should allow different mechanisms through which
>>    a path is constructed. SR allows a variety of mechanisms, not
>>    confined IGP/BGP path computation.
>>=20
>> [SLI] Agree
>>=20
>>> Work items :
>>> ------------------
>>>=20
>>> The <Name-TBD> working group is chartered for the following ordered =
list of work items:
>>>=20
>>> - The first goal of the WG is to identify use-cases.
>>> - The WG will then define the architecture framework associated with
>>> the security considerations. The architecture framework and security
>>> considerations must address the relations between networks forming =
the <Name-TBD> domain (interAS).
>>> - Having identified use-cases, architecture and security, the WG =
will
>>> identify gaps between currently available technologies and use-case
>>> requirements.
>>> - The WG will then define requirements for extensions to existing
>>> protocols or new protocols that address gaps that are identified.
>>> - The WG will first focus on the intra-domain forwarding definition.
>>=20
>>=20
>> [SP] The architecture will support tunnel and non-tunnel paradigms
>>    The architecture will support multiple dataplanes: MPLS and V6
>>=20
>>=20
>> Thanks.
>> s.
>>=20
>>=20
>>> Documents :
>>> ------------------
>>> . Use Cases
>>> . Architecture including security considerations
>>> - Protocol extension requirements
>>> . Interoperability Report
>>>=20
>>>=20
>>> Protocol work may be carried out in this working group or in other =
working groups responsible for the protocols (ISIS,OSPF,BGP,PCEP ...), =
in coordination with this WG, and in agreement with the WG chairs and =
responsible ADs.
>>>=20
>>> -----Message d'origine-----
>>> De : Rob Shakir [mailto:[email-masked]]
>>> Envoy=E9 : mardi 10 septembre 2013 11:05 =C0 : LITKOWSKI Stephane =
DTF/DERX
>>> Cc : Hannes Gredler; Stefano Previdi (sprevidi); [email-masked] =
Objet
>>> : Re: [Status] Good charter proposals from Hannes and Stefano : try =
to merge ...
>>>=20
>>> Hi Stephane,
>>>=20
>>> Thanks for this, looks good! Comments in-line marked rjs>.
>>>=20
>>> On 10 Sep 2013, at 08:50, <[email-masked]> wrote:
>>>=20
>>>> Hi all,
>>>>=20
>>>> I'm creating a new mail topic because the "Summary of STATUS BOF =
..."
>>>> starts to be unreadable :)
>>>>=20
>>>> Hannes and Stefano send to us two charter proposals that sounds =
good to me.
>>>>=20
>>>> The main difference between the two proposals is that Stefano =
propose a segment bound to any type of instruction (forwarding, =
application or service based) while Hannes is focusing on forwarding =
actions (which is the first priority, and I think everybody agree on =
this).
>>>=20
>>> rjs> Agreed -- I think it would be useful to allow definitions of =
segments to identify different types of "service", since there appear to =
be some use cases (e.g., the explicit exit selection case) which require =
a segment type describing something that is not explicitly IGP-based.
>>>=20
>>>>=20
>>>> It would be interresting to have a feedback from the mailinglist on =
this specific point.
>>>>=20
>>>> IMHO, there is a strong interrest to explore the service actions =
bound to segment in a second step keeping forwarding as a priority.
>>>>=20
>>>> Apart of this problem, here is a merge try of the two good =
proposals (I'm putting '<>' on hot topics :) ) :
>>>>=20
>>>>=20
>>>> -------------------------------------------------------------------
>>>> Name: <TBD>
>>>> Charter:
>>>>=20
>>>>=20
>>>> Introduction
>>>> ------------
>>>> The following use cases:
>>>> . Path computation based on awareness of utilization or performance
>>>> data, within both centralized and distributed environments, . =
Multi-topology (dual planes, disjoint trees), . Simplification and =
reduction of signaling components (scaling), . Combined application and =
network layer path specification, . Full coverage LFA-FRR, . Topology =
Aware OAM, . etc.
>>>>=20
>>>> have triggered work on the definition of new architecture and =
protocol extensions allowing to combine well known shortest path based =
routing paradigms with source/explicit routing methods. Some of these =
extensions have been implemented already.
>>>>=20
>>>>=20
>>>> Objective
>>>> ---------
>>>>=20
>>>> Define an architecture where a node can steer a packet through a =
network or set of networks (interdomain) on any path (shortest, non =
shortest, explicit, <service or application>).
>>>>=20
>>>> In this architecture, routers are sharing a common trust model and =
are forming a <Name-TBD> domain.
>>>> Within this domain, a node can specify a path between itself and =
any destination in the domain. <The path may be a forwarding path, a =
service chaining path or a combination of both>.
>>>=20
>>> rjs> To clarify here, we define that our domain is under a common =
trust model (essentially, under common administrative control?), but =
then go on to talk about inter-domain elsewhere. Can we perhaps clarify =
(by defining a specific "<Name-TBD> domain" nomenclature) and say =
something like:
>>>=20
>>> "In this architecture, routers sharing a common trust model form a =
<Name-TBD> domain. The architecture defined by this working group will =
allow a node to steer a packet between any source and destination node =
within the <Name-TBD> domain (formed of one or more networks), on any =
path (shortest, non-shortest, explicit or based on other characteristics =
specified by segment identifiers)."
>>>=20
>>>> It may then send any packet that passes through it through any path =
that it has specified and that is conform to the security rules. =
Downstream routers along the path within the <Name-TBD> domain forward =
the packet as specified by the router at the head-end of the path.
>>>>=20
>>>> The architecture should support centralized and distributed path =
computation.
>>>>=20
>>>>=20
>>>> Work items :
>>>> ------------------
>>>>=20
>>>> The <Name-TBD> working group is chartered for the following ordered =
list of work items:
>>>>=20
>>>> - The first goal of the WG is to identify use-cases.
>>>> - The WG will then define the architecture framework associated =
with
>>>> the security considerations. The architecture framework and =
security
>>>> considerations must address the relations between domains (inter =
domain).
>>>=20
>>> rjs> And then here "networks forming the <Name-TBD> domain"?
>>>=20
>>> Thanks for the efforts,
>>> r.
>>>=20
>>>> - Having identified use-cases, architecture and security, the WG =
will
>>>> identify gaps between currently available technologies and use-case
>>>> requirements.
>>>> - The WG will then define requirements for extensions to existing
>>>> protocols or new protocols that address gaps that are identified.
>>>> - The WG will first focus on the intra-domain forwarding =
definition.
>>>>=20
>>>>=20
>>>> Documents :
>>>> ------------------
>>>> . Use Cases
>>>> . Architecture including security considerations
>>>> - Protocol extension requirements
>>>> . Interoperability Report
>>>>=20
>>>>=20
>>>> Protocol work may be carried out in this working group or in other =
working groups responsible for the protocols (ISIS,OSPF,BGP,PCEP ...), =
in coordination with this WG, and in agreement with the WG chairs and =
responsible ADs.
>>>>=20
>>>>=20
>>>>=20
>>>> Hope it helps to progress on the definition.
>>>>=20
>>>>=20
>>>> Stephane
>>>>=20
>>>>=20
>>>> -----Message d'origine-----
>>>> De : Hannes Gredler [mailto:[email-masked]] Envoy=E9 : vendredi =
6
>>>> septembre 2013 18:27 =C0 : LITKOWSKI Stephane DTF/DERX Cc :
>>>> [email-masked] Objet : Re: [Status] Summary of STATUS BOF and the
>>>> next steps
>>>>=20
>>>> hi stephane,
>>>>=20
>>>> here is a revised draft charter as per your comments.
>>>>=20
>>>> ---
>>>>=20
>>>> <Name-TBD> domain contains a set of routers with the following
>>>> characteristics:
>>>>=20
>>>> - They form a connected network
>>>> - They can forward traffic through any path within the network =
using
>>>> shortest path, or any other (e.g., an explicit) path
>>>> - They share a common trust model. In this model, any router within
>>>> the domain can specify a path between itself and any other router  =
in
>>>> the domain. It may then send any packet that passes through it
>>>> through any path that it has specified and that is conform to the
>>>> security rules. Downstream routers along the path within the
>>>> <Name-TBD>  domain forward the packet as specified by the router at
>>>> the head-end  of the path.
>>>>=20
>>>> The <Name-TBD> working group is chartered for the following ordered =
list of work items:
>>>>=20
>>>> - The first goal of the WG is to identify use-cases.
>>>> - The WG will then define the architecture framework associated =
with
>>>> the security considerations. The architecture framework and =
security
>>>> considerations must address the relations between domains =
(interdomain).
>>>> - Having identified use-cases, architecture and security, the WG =
will
>>>> identify gaps between currently available technologies and use-case
>>>> requirements.
>>>> - The WG will then define requirements for extensions to existing
>>>> protocols or new protocols that address gaps that are identified.
>>>> - The WG will first focus on the intra-domain forwarding =
definition.
>>>>=20
>>>> Protocol work may be carried out in this working group or in other =
working groups responsible for the protocols, in coordination with this =
WG, and in agreement with the WG chairs and responsible ADs.
>>>> However, no protocol work will be adopted by a working group to =
address the identified use-cases until the requirements document =
motivating the protocol work has been sent to the IESG for publication =
as an RFC.
>>>>=20
>>>> ---
>>>>=20
>>>> /hannes
>>>>=20
>>>> On Sep 4, 2013, at 10:02 AM, <[email-masked]> =
<[email-masked]> wrote:
>>>>=20
>>>>> Hannes,
>>>>>=20
>>>>> In case, we are using only directed forwarding (adjacency =
segment),
>>>>> could we still talk about tunneling ? (it's a very very small =
tunnel) Moreover talking about "stacking" is really dataplane agnostic =
(MPLS) ...
>>>>>=20
>>>>> In the proposed segment routing architectural concepts, segments =
are at the same "level" and pointer moves on the segment list, then the =
MPLS instantiation is performing this using stacking ...
>>>>>=20
>>>>> IMHO, if we use "Stacked Tunnels", we already talk about a chosen =
solution and it's closing the door to something else  ...
>>>>>=20
>>>>> Finally, about the "routing" word, routing is essentially a =
"forward" action which may limit the scope of what we can do by using a =
segment list. Actions associated with a segment could be something else =
than forwarding.
>>>>>=20
>>>>> Do we want in the charter to limit the scope to routing actions ?
>>>>>=20
>>>>> I have no solution today to propose for the naming, but I =
completely agree with Loa, to first focus on working on the charter, and =
define a clear scope of the work and then the name will be easier to =
find.
>>>>>=20
>>>>> Regarding your charter proposal :
>>>>>=20
>>>>> --------
>>>>>=20
>>>>> - They form a connected network
>>>>>    [SLI] InterAS case must be included, but the WG can go step by =
step and first release intraAS, and then doing interAS (in relation with =
IDR ??).
>>>>>=20
>>>>> - They can forward traffic through the shortest paths or paths =
other than the shortest (the latter called explicitly routed paths, or =
explicit paths)
>>>>>    [SLI] There is something else between SPT and Explicit path, =
you can define other algorithms than SPT to define a path, and it's not =
explicit path. Moreover I come back to my comment, on do we want to =
limit the scope to routing ? I would say no.
>>>>>=20
>>>>> - They share a common trust model. In this model, any router =
within the ERD can specify an explicit path between itself and any other =
router in the ERD. It can then send any packet that passes through it =
through any path that it has specified.
>>>>>    [SLI] Security considerations may have to be addressed in the
>>>>> charter , especially for the interAS case (trust yes, but not sure
>>>>> access to everything may not be good)
>>>>>=20
>>>>> Downstream routers within the ERD forward the packet as specified =
by the router at the head-end of the path.
>>>>> [SLI] Yes, but any router in the middle may be able to change the =
end to end explicit path.
>>>>>=20
>>>>>=20
>>>>>=20
>>>>> - The first goal of the STER WG is to identify use-cases for ERDs.
>>>>> - Having identified use-cases, the WG will identify gaps between =
currently available technologies and use-case requirements.
>>>>> - The WG will then define requirements for extensions to existing =
protocols or new protocols that address gaps that are identified.
>>>>>=20
>>>>> [SLI] Agree, I would add :
>>>>> - defining the architecture framework
>>>>> - analysing the security considerisations
>>>>>=20
>>>>>=20
>>>>> ---------
>>>>>=20
>>>>>=20
>>>>> Here would be my proposal to extend yours :
>>>>>=20
>>>>> A <named to be defined> domain contains a set of routers with the =
following characteristics:
>>>>>=20
>>>>> - They form a connected network
>>>>> - They can forward traffic through any path within the network =
using
>>>>> shortest path, non shortest path or explicit path
>>>>> - They may provide other types of services than forwarding and =
they can enforce service actions in the path.
>>>>> - They share a common trust model. In this model, any router =
within the domain can specify a path between itself and any other router =
in the domain. It may then send any packet that passes through it =
through any path that it has specified and that is conform to the =
security rules. Downstream routers within the ERD forward the packet as =
specified by the router at the head-end of the path.
>>>>>=20
>>>>> The <name> working group is chartered for the following ordered =
list of work items:
>>>>>=20
>>>>> - The first goal of the WG is to identify use-cases.
>>>>> - The WG will then define the architecture framework associated =
with the security considerations. The architecture framework and =
security considerations must address the relations between domains =
(interdomain).
>>>>> - Having identified use-cases, architecture and security, the WG =
will identify gaps between currently available technologies and use-case =
requirements.
>>>>> - The WG will then define requirements for extensions to existing =
protocols or new protocols that address gaps that are identified.
>>>>> - The WG will first focus on the intra-domain forwarding =
definition.
>>>>>=20
>>>>> Protocol work may be carried out in this working group or in other =
working groups responsible for the protocols, in coordination with this =
WG, and in agreement with the WG chairs and responsible ADs. However, no =
protocol work will be adopted by a working group to address the ERD =
use-cases until the requirements document motivating the protocol work =
has been sent to the IESG for publication as an RFC.
>>>>>=20
>>>>> -----Message d'origine-----
>>>>> De : [email-masked] [mailto:[email-masked]] De =
la
>>>>> part de Hannes Gredler Envoy=E9 : mardi 3 septembre 2013 18:31 =C0 =
: Loa
>>>>> Andersson Cc : [email-masked] Objet : Re: [Status] Summary of
>>>>> STATUS BOF and the next steps
>>>>>=20
>>>>> good point - what about this charter proposal ?
>>>>>=20
>>>>> ---
>>>>>=20
>>>>> Stacked Tunnels for Explicit Routing (STER)
>>>>> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
>>>>>=20
>>>>> A explicit routing domain (ERD) contains a set of routers with the =
following characteristics:
>>>>>=20
>>>>> - They form a connected network
>>>>> - They can forward traffic through the shortest paths or paths =
other
>>>>> than the shortest (the latter called explicitly routed paths, or
>>>>> explicit paths)
>>>>> - They share a common trust model. In this model, any router =
within the ERD can specify an explicit path between itself and any other =
router in the ERD. It can then send any packet that passes through it =
through any path that it has specified. Downstream routers within the =
ERD forward the packet as specified by the router at the head-end of the =
path.
>>>>>=20
>>>>> The STER working group is chartered for the following ordered list =
of work items:
>>>>>=20
>>>>> - The first goal of the STER WG is to identify use-cases for ERDs.
>>>>> - Having identified use-cases, the WG will identify gaps between =
currently available technologies and use-case requirements.
>>>>> - The WG will then define requirements for extensions to existing =
protocols or new protocols that address gaps that are identified.
>>>>>=20
>>>>> Protocol work may be carried out in this working group or in other =
working groups responsible for the protocols, in coordination with this =
WG, and in agreement with the WG chairs and responsible ADs. However, no =
protocol work will be adopted by a working group to address the ERD =
use-cases until the requirements document motivating the protocol work =
has been sent to the IESG for publication as an RFC.
>>>>>=20
>>>>> ---
>>>>>=20
>>>>> <flame suit on>
>>>>>=20
>>>>> /hannes
>>>>>=20
>>>>>=20
>>>>> On Sep 3, 2013, at 5:31 PM, Loa Andersson wrote:
>>>>>=20
>>>>>> Folks,
>>>>>>=20
>>>>>> Excuse me if I'm slightly out of the loop, but so far I have not
>>>>>> seen a charter proposal, if there is one please point me to it.
>>>>>>=20
>>>>>> It seems a bit odd to put the cart (what the wg should do) before
>>>>>> the horse (wg name). If we drill down the the charter first the =
wg
>>>>>> name might be easier to figure out.
>>>>>>=20
>>>>>> /Loa
>>>>>>=20
>>>>>> PS
>>>>>> OK I understand that the horse and cart analogy limps a  bit :).
>>>>>>=20
>>>>>>=20
>>>>>>=20
>>>>>> On 2013-09-03 17:22, AshwoodsmithPeter wrote:
>>>>>>> " If the WG charter is limited to source routing, how will we =
handle the "non source routing" use cases of segment routing ? In =
another working group ? So we will go back to the WG synchronization =
issue that has been raised for this technology ..."
>>>>>>>=20
>>>>>>> That's why I suggested SRV2. We are revisiting source routing =
with new concepts. More generic number/action behavior.
>>>>>>>=20
>>>>>>> Peter
>>>>>>>=20
>>>>>>> -----Original Message-----
>>>>>>> From: [email-masked] [mailto:[email-masked]] =
On
>>>>>>> Behalf Of [email-masked]
>>>>>>> Sent: Tuesday, September 03, 2013 10:43 AM
>>>>>>> To: AshwoodsmithPeter
>>>>>>> Cc: [email-masked]
>>>>>>> Subject: Re: [Status] Summary of STATUS BOF and the next steps
>>>>>>>=20
>>>>>>>=20
>>>>>>> There was a misunderstanding in my small comment :) so I will =
explain more :
>>>>>>>=20
>>>>>>> In segment routing, you have more than basic source routing : =
segment routing is just associate a segment number to an action and then =
combine segment as you want, yes you can do source routing, but you also =
can do more.
>>>>>>>=20
>>>>>>> In the other hand, I completely agree with your statement that
>>>>>>> source routing is generic and dataplane agnostic, as segment =
routing is ...
>>>>>>> (segment routing is not a new dataplane ...)
>>>>>>>=20
>>>>>>> Now the definition of the WG naming must be inline with the
>>>>>>> charter that will be defined ... (draft today)
>>>>>>>=20
>>>>>>> Based on the already existing consensus (at least for MPLS =
dataplane) brought up during Berlin STATUS BOF meeting, segment routing =
sounds to be a good target candidate.
>>>>>>>=20
>>>>>>> So now, do we want to do more in the WG charter than just make =
progressing segment routing architecture and uses cases document and =
ensure coordination for the standardization of this technology ?
>>>>>>>=20
>>>>>>> Do we want to standardize other technologies in this WG ? I =
don't think so, based on Stewart's conclusion email from the BOF :"A new =
WG focused solely on SR therefore needs to be create"
>>>>>>>=20
>>>>>>> If the WG charter is limited to source routing, how will we =
handle the "non source routing" use cases of segment routing ? In =
another working group ? So we will go back to the WG synchronization =
issue that has been raised for this technology ...
>>>>>>>=20
>>>>>>> If the WG is focused on SR, let's use a name in relation with =
SR.
>>>>>>>=20
>>>>>>> Feedback ?
>>>>>>>=20
>>>>>>>=20
>>>>>>> Stephane
>>>>>>>=20
>>>>>>>=20
>>>>>>> -----Message d'origine-----
>>>>>>> De : AshwoodsmithPeter [mailto:[email-masked]]
>>>>>>> Envoy=E9 : mardi 3 septembre 2013 15:27 =C0 : LITKOWSKI Stephane
>>>>>>> DTF/DERX Cc : John E Drake; Mark Townsley; Victor Kuarsingh;
>>>>>>> Roberta Maglione (robmgl); John G. Scudder; Adrian Farrel; =
Alvaro
>>>>>>> Retana (aretana); [email-masked]; Stewart Bryant (stbryant) =
Objet : Re:
>>>>>>> [Status] Summary of STATUS BOF and the next steps
>>>>>>>=20
>>>>>>> The term "source routing" has been around for a very long time =
and is data path agnostic. Its also the term used in the literature etc =
so my preference is to stick with this existing well known and data path =
agnostic term.
>>>>>>>=20
>>>>>>> Peter
>>>>>>>=20
>>>>>>> On Sep 3, 2013, at 9:07 AM, "[email-masked]" =
<[email-masked]> wrote:
>>>>>>>=20
>>>>>>>> Hi,
>>>>>>>>=20
>>>>>>>> "Source routing" is just a subcase of segment routing ... as it =
is for IP routing ...
>>>>>>>>=20
>>>>>>>> Stephane
>>>>>>>>=20
>>>>>>>>=20
>>>>>>>> -----Message d'origine-----
>>>>>>>> De : [email-masked] [mailto:[email-masked]] =
De
>>>>>>>> la part de John E Drake Envoy=E9 : mardi 3 septembre 2013 15:02 =
=C0 :
>>>>>>>> Mark Townsley; Victor Kuarsingh Cc : Roberta Maglione (robmgl); =
John G.
>>>>>>>> Scudder; Alvaro Retana (aretana); Adrian Farrel; =
[email-masked];
>>>>>>>> Stewart Bryant (stbryant) Objet : Re: [Status] Summary of =
STATUS
>>>>>>>> BOF and the next steps
>>>>>>>>=20
>>>>>>>> Hi,
>>>>>>>>=20
>>>>>>>> What is this 'segment routing' silliness?  The correct term is =
'source routing'.
>>>>>>>>=20
>>>>>>>> Yours Irrespectively,
>>>>>>>>=20
>>>>>>>> John
>>>>>>>>=20
>>>>>>>>> -----Original Message-----
>>>>>>>>> From: [email-masked] [mailto:[email-masked]]
>>>>>>>>> On Behalf Of Mark Townsley
>>>>>>>>> Sent: Sunday, September 01, 2013 10:08 AM
>>>>>>>>> To: Victor Kuarsingh
>>>>>>>>> Cc: Roberta Maglione (robmgl); John G. Scudder; Adrian Farrel;
>>>>>>>>> Alvaro Retana (aretana); [email-masked]; Stewart Bryant
>>>>>>>>> (stbryant)
>>>>>>>>> Subject: Re: [Status] Summary of STATUS BOF and the next steps
>>>>>>>>>=20
>>>>>>>>>=20
>>>>>>>>> On Sep 1, 2013, at 5:38 PM, Victor Kuarsingh wrote:
>>>>>>>>>=20
>>>>>>>>>> All,
>>>>>>>>>>=20
>>>>>>>>>> I would also favour "Segment Routing WG" as well.
>>>>>>>>>>=20
>>>>>>>>>> I note this since attempting to come up with an all
>>>>>>>>>> encompassing acronym will be difficult and Segment Routing is
>>>>>>>>>> generic enough to associate to multiple functions.
>>>>>>>>>=20
>>>>>>>>> Then we can just use "segroute" for the short name. WGs do not
>>>>>>>>> have to have acronyms, but they do need to have an 8-char
>>>>>>>>> limited short name for the various automated tools not to =
break.
>>>>>>>>>=20
>>>>>>>>> - Mark
>>>>>>>>>=20
>>>>>>>>>>=20
>>>>>>>>>> Regards,
>>>>>>>>>>=20
>>>>>>>>>> Victor K
>>>>>>>>>>=20
>>>>>>>>>>=20
>>>>>>>>>>=20
>>>>>>>>>> On 2013-08-31 6:51 PM, "Roberta Maglione (robmgl)"
>>>>>>>>>> <[email-masked]>
>>>>>>>>>> wrote:
>>>>>>>>>>=20
>>>>>>>>>>> +1 for Segment Routing WG
>>>>>>>>>>>=20
>>>>>>>>>>> Roberta
>>>>>>>>>>>=20
>>>>>>>>>>> Sent from my iPad
>>>>>>>>>>>=20
>>>>>>>>>>> On 2013-08-30, at 2:55 PM, "Alvaro Retana (aretana)"
>>>>>>>>>>> <[email-masked]>
>>>>>>>>>>> wrote:
>>>>>>>>>>>=20
>>>>>>>>>>>> Segment Routing WG
>>>>>>>>>>>>=20
>>>>>>>>>>>> Sent from my iPhone
>>>>>>>>>>>>=20
>>>>>>>>>>>> On Aug 30, 2013, at 1:39 PM, "Stewart Bryant (stbryant)"
>>>>>>>>>>>> <[email-masked]> wrote:
>>>>>>>>>>>>=20
>>>>>>>>>>>>> The second task, which hopefully should be relatively =
easy,
>>>>>>>>>>>>> is to find a better working name for the WG, since it has
>>>>>>>>>>>>> been put to me a number of times that STATUS is going to =
be
>>>>>>>>>>>>> confusing in text and a difficult search term.
>>>>>>>>>>>> _______________________________________________
>>>>>>>>>>>> status mailing list
>>>>>>>>>>>> [email-masked]
>>>>>>>>>>>> https://www.ietf.org/mailman/listinfo/status
>>>>>>>>>>> _______________________________________________
>>>>>>>>>>> status mailing list
>>>>>>>>>>> [email-masked]
>>>>>>>>>>> https://www.ietf.org/mailman/listinfo/status
>>>>>>>>>>=20
>>>>>>>>>>=20
>>>>>>>>>> _______________________________________________
>>>>>>>>>> status mailing list
>>>>>>>>>> [email-masked]
>>>>>>>>>> https://www.ietf.org/mailman/listinfo/status
>>>>>>>>>=20
>>>>>>>>> _______________________________________________
>>>>>>>>> status mailing list
>>>>>>>>> [email-masked]
>>>>>>>>> https://www.ietf.org/mailman/listinfo/status
>>>>>>>>=20
>>>>>>>>=20
>>>>>>>> _______________________________________________
>>>>>>>> status mailing list
>>>>>>>> [email-masked]
>>>>>>>> https://www.ietf.org/mailman/listinfo/status
>>>>>>>>=20
>>>>>>>> =
_________________________________________________________________
>>>>>>>> _ _ _ __ ___________________________________________________
>>>>>>>>=20
>>>>>>>> Ce message et ses pieces jointes peuvent contenir des
>>>>>>>> informations confidentielles ou privilegiees et ne doivent donc
>>>>>>>> pas etre diffuses, exploites ou copies sans autorisation. Si =
vous
>>>>>>>> avez recu ce message par erreur, veuillez le signaler a =
l'expediteur et le detruire ainsi que les pieces jointes. Les messages =
electroniques etant susceptibles d'alteration, Orange decline toute =
responsabilite si ce message a ete altere, deforme ou falsifie. Merci.
>>>>>>>>=20
>>>>>>>> This message and its attachments may contain confidential or
>>>>>>>> privileged information that may be protected by law; they =
should not be distributed, used or copied without authorisation.
>>>>>>>> If you have received this email in error, please notify the =
sender and delete this message and its attachments.
>>>>>>>> As emails may be altered, Orange is not liable for messages =
that have been modified, changed or falsified.
>>>>>>>> Thank you.
>>>>>>>>=20
>>>>>>>> _______________________________________________
>>>>>>>> status mailing list
>>>>>>>> [email-masked]
>>>>>>>> https://www.ietf.org/mailman/listinfo/status
>>>>>>>=20
>>>>>>> =
__________________________________________________________________
>>>>>>> _ _ _ ____________________________________________________
>>>>>>>=20
>>>>>>> Ce message et ses pieces jointes peuvent contenir des =
informations
>>>>>>> confidentielles ou privilegiees et ne doivent donc pas etre
>>>>>>> diffuses, exploites ou copies sans autorisation. Si vous avez =
recu
>>>>>>> ce message par erreur, veuillez le signaler a l'expediteur et le =
detruire ainsi que les pieces jointes. Les messages electroniques etant =
susceptibles d'alteration, Orange decline toute responsabilite si ce =
message a ete altere, deforme ou falsifie. Merci.
>>>>>>>=20
>>>>>>> This message and its attachments may contain confidential or
>>>>>>> privileged information that may be protected by law; they should =
not be distributed, used or copied without authorisation.
>>>>>>> If you have received this email in error, please notify the =
sender and delete this message and its attachments.
>>>>>>> As emails may be altered, Orange is not liable for messages that =
have been modified, changed or falsified.
>>>>>>> Thank you.
>>>>>>>=20
>>>>>>> _______________________________________________
>>>>>>> status mailing list
>>>>>>> [email-masked]
>>>>>>> https://www.ietf.org/mailman/listinfo/status
>>>>>>> _______________________________________________
>>>>>>> status mailing list
>>>>>>> [email-masked]
>>>>>>> https://www.ietf.org/mailman/listinfo/status
>>>>>>>=20
>>>>>>=20
>>>>>> --
>>>>>>=20
>>>>>>=20
>>>>>> Loa Andersson                        email: [email-masked]
>>>>>> Senior MPLS Expert                          [email-masked]
>>>>>> Huawei Technologies (consultant)     phone: +46 739 81 21 64
>>>>>> _______________________________________________
>>>>>> status mailing list
>>>>>> [email-masked]
>>>>>> https://www.ietf.org/mailman/listinfo/status
>>>>>>=20
>>>>>>=20
>>>>>=20
>>>>>=20
>>>>> _______________________________________________
>>>>> status mailing list
>>>>> [email-masked]
>>>>> https://www.ietf.org/mailman/listinfo/status
>>>>>=20
>>>>> =
____________________________________________________________________
>>>>> _ _ ___________________________________________________
>>>>>=20
>>>>> Ce message et ses pieces jointes peuvent contenir des informations
>>>>> confidentielles ou privilegiees et ne doivent donc pas etre
>>>>> diffuses, exploites ou copies sans autorisation. Si vous avez recu
>>>>> ce message par erreur, veuillez le signaler a l'expediteur et le =
detruire ainsi que les pieces jointes. Les messages electroniques etant =
susceptibles d'alteration, Orange decline toute responsabilite si ce =
message a ete altere, deforme ou falsifie. Merci.
>>>>>=20
>>>>> This message and its attachments may contain confidential or
>>>>> privileged information that may be protected by law; they should =
not be distributed, used or copied without authorisation.
>>>>> If you have received this email in error, please notify the sender =
and delete this message and its attachments.
>>>>> As emails may be altered, Orange is not liable for messages that =
have been modified, changed or falsified.
>>>>> Thank you.
>>>>>=20
>>>>>=20
>>>>>=20
>>>>=20
>>>>=20
>>>>=20
>>>> =
_____________________________________________________________________
>>>> _ ___________________________________________________
>>>>=20
>>>> Ce message et ses pieces jointes peuvent contenir des informations
>>>> confidentielles ou privilegiees et ne doivent donc pas etre =
diffuses,
>>>> exploites ou copies sans autorisation. Si vous avez recu ce message
>>>> par erreur, veuillez le signaler a l'expediteur et le detruire =
ainsi que les pieces jointes. Les messages electroniques etant =
susceptibles d'alteration, Orange decline toute responsabilite si ce =
message a ete altere, deforme ou falsifie. Merci.
>>>>=20
>>>> This message and its attachments may contain confidential or
>>>> privileged information that may be protected by law; they should =
not be distributed, used or copied without authorisation.
>>>> If you have received this email in error, please notify the sender =
and delete this message and its attachments.
>>>> As emails may be altered, Orange is not liable for messages that =
have been modified, changed or falsified.
>>>> Thank you.
>>>>=20
>>>> _______________________________________________
>>>> status mailing list
>>>> [email-masked]
>>>> https://www.ietf.org/mailman/listinfo/status
>>>=20
>>>=20
>>> =
______________________________________________________________________
>>> ___________________________________________________
>>>=20
>>> Ce message et ses pieces jointes peuvent contenir des informations
>>> confidentielles ou privilegiees et ne doivent donc pas etre =
diffuses,
>>> exploites ou copies sans autorisation. Si vous avez recu ce message
>>> par erreur, veuillez le signaler a l'expediteur et le detruire ainsi =
que les pieces jointes. Les messages electroniques etant susceptibles =
d'alteration, Orange decline toute responsabilite si ce message a ete =
altere, deforme ou falsifie. Merci.
>>>=20
>>> This message and its attachments may contain confidential or
>>> privileged information that may be protected by law; they should not =
be distributed, used or copied without authorisation.
>>> If you have received this email in error, please notify the sender =
and delete this message and its attachments.
>>> As emails may be altered, Orange is not liable for messages that =
have been modified, changed or falsified.
>>> Thank you.
>>>=20
>>=20
>>=20
>> =
__________________________________________________________________________=
_______________________________________________
>>=20
>> Ce message et ses pieces jointes peuvent contenir des informations =
confidentielles ou privilegiees et ne doivent donc
>> pas etre diffuses, exploites ou copies sans autorisation. Si vous =
avez recu ce message par erreur, veuillez le signaler
>> a l'expediteur et le detruire ainsi que les pieces jointes. Les =
messages electroniques etant susceptibles d'alteration,
>> Orange decline toute responsabilite si ce message a ete altere, =
deforme ou falsifie. Merci.
>>=20
>> This message and its attachments may contain confidential or =
privileged information that may be protected by law;
>> they should not be distributed, used or copied without authorisation.
>> If you have received this email in error, please notify the sender =
and delete this message and its attachments.
>> As emails may be altered, Orange is not liable for messages that have =
been modified, changed or falsified.
>> Thank you.
>>=20
>=20
>=20
>=20

From: "Stefano Previdi (sprevidi)" <[email-masked]>
To: Stephane Litkowski <[email-masked]>
Date: Tue, 10 Sep 2013 16:58:28 +0000
Accept-Language: en-US
Cc: Hannes Gredler <[email-masked]>, Rob Shakir <[email-masked]>, "[email-masked]" <[email-masked]>
Subject: Re: [Status] Good charter proposals from Hannes and Stefano : try to merge ...

On Sep 10, 2013, at 1:25 PM, <[email-masked]> wrote:

> Agree on all proposal except :
>=20
> "[SP] The architecture will support tunnel and non-tunnel paradigms
>     The architecture will support multiple dataplanes: MPLS and V6"
>=20
> I don't see the reason for this ... IMHO, the gap analysis and requiremen=
ts inventory will result on saying or not

[SP] While I understand what brought the following statements
     in the proposed charter:
	"Having identified use-cases, architecture and security,=20
	 the WG will identify gaps between currently available=20
	 technologies and use-case requirements.
	 The WG will then define requirements for extensions to=20
	 existing protocols or new protocols that address gaps=20
	 that are identified."

     I'd like to point out with better precision what are the=20
     directions we are ALREADY engaged into: dataplanes and=20
     paradigms. As I mentioned in my charter proposal, we do have=20
     implementations and multi-vendor interoperability tests will
     happen soon. So, I just want to be sure we don't ignore this=20
     reality.

     MPLS and v6 data-plane are part of this reality, as well as=20
     tunnel-based and non-tunnel based approaches.

> : we must use tunnels and/or non tunnels, and the following dataplanes ..=
. But I don't see the reason to put solutions directly in the charter ...

these are not solutions these are way to avoid boundaries in the
framework.

Thanks.
s.

> Could you explain your point ?
>=20
>=20
> updated with the other comments :
>=20
> -------------------------------------------------------------------
> Name: <TBD>
> Charter:
>=20
>=20
> Introduction
> ------------
> The following use cases:
> . Path computation based on awareness of utilization or performance
>  data, within both centralized and distributed environments, . Multi-topo=
logy (dual planes, disjoint trees), . Simplification and reduction of signa=
ling components (scaling), . Combined application and network layer path sp=
ecification, . Full coverage LFA-FRR, . Topology Aware OAM, . etc.
>=20
> have triggered work on the definition of new architecture and protocol ex=
tensions allowing to combine well known shortest path based routing paradig=
ms with source/explicit routing methods. Some of these extensions have been=
 implemented already.
>=20
>=20
> Objective
> ---------
>=20
> Define an architecture where a node can steer a packet through a network =
or set of networks (interdomain) on any path without requiring to maintain =
state along the path, other than in the ingress node.
>=20
> A node may be any type of device including routers or appliances.
>=20
> In this architecture, nodes sharing a common trust model form a <Name-TBD=
> domain. The architecture defined by this working group will allow a node =
to steer a packet between any source and destination node within the <Name-=
TBD> domain (formed of one or more networks), on any path (shortest, non-sh=
ortest, explicit or based on other characteristics specified by segment ide=
ntifiers).
>=20
> It may then send any packet that passes through it through any path that =
it has specified and that is conform to the security rules. Downstream node=
s along the path within the <Name-TBD> domain forward the packet by using t=
he informations inserted by the node at the head-end
>=20
> The architecture should support centralized and distributed path computat=
ion.
>=20
> The architecture should support OAM functions.
>=20
> The architecture should allow different mechanisms through which
>     a path is constructed. SR allows a variety of mechanisms, not
>     confined IGP/BGP path computation.
>=20
> As MPLS dataplane is largely deployed, the <Name-TBD> WG should avoid any=
 modification in the MPLS dataplane when defining the architecture.
>=20
>=20
> Work items :
> ------------------
>=20
> The <Name-TBD> working group is chartered for the following ordered list =
of work items:
>=20
> - The first goal of the WG is to identify use-cases.
> - The WG will then define the architecture framework associated with
>  the security considerations. The architecture framework and security
>  considerations must address the relations between networks forming the <=
Name-TBD> domain (interAS).
> - Having identified use-cases, architecture and security, the WG will
>  identify gaps between currently available technologies and use-case
>  requirements.
> - The WG will then define requirements for extensions to existing
>  protocols or new protocols that address gaps that are identified.
> - The WG will first focus on the intra-domain forwarding definition.
>=20
>=20
> Documents :
> ------------------
> . Use Cases
> . Architecture including security considerations
> - Protocol extension requirements
> . Interoperability Report
>=20
>=20
> Required protocol extensions are carried out in working groups responsibl=
e (ISIS,OSPF,BGP,PCEP ...). Work on new protocols may be carried out by the=
 <Name-TBD> WG.
>=20
> -----Message d'origine-----
> De : Stefano Previdi (sprevidi) [mailto:[email-masked]]
> Envoy=E9 : mardi 10 septembre 2013 12:30
> =C0 : LITKOWSKI Stephane DTF/DERX; Rob Shakir
> Cc : Hannes Gredler; [email-masked]
> Objet : Re: [Status] Good charter proposals from Hannes and Stefano : try=
 to merge ...
>=20
> Hi Stephane, Rob,
>=20
> one preliminary remark: I prefer to use he therm "node" rather than "rout=
er". Use cases, such as Service Chaining requires that terminology.
>=20
> some other comments below...
>=20
>=20
> On Sep 10, 2013, at 11:19 AM, <[email-masked]> wrote:
>> Souns good to me, (adding OAM also)
>>=20
>> New recap :
>>=20
>> -------------------------------------------------------------------
>> Name: <TBD>
>> Charter:
>>=20
>>=20
>> Introduction
>> ------------
>> The following use cases:
>> . Path computation based on awareness of utilization or performance
>> data, within both centralized and distributed environments, . Multi-topo=
logy (dual planes, disjoint trees), . Simplification and reduction of signa=
ling components (scaling), . Combined application and network layer path sp=
ecification, . Full coverage LFA-FRR, . Topology Aware OAM, . etc.
>>=20
>> have triggered work on the definition of new architecture and protocol e=
xtensions allowing to combine well known shortest path based routing paradi=
gms with source/explicit routing methods. Some of these extensions have bee=
n implemented already.
>>=20
>>=20
>> Objective
>> ---------
>>=20
>> Define an architecture where a node can steer a packet through a network=
 or set of networks (interdomain) on any path.
>=20
>=20
> [SP] As stated above, I'm fine with the above definition but I
>     assume this includes service chaining and that by "network
>     or set of networks" you intend "nodes" which may include
>     others things than just routers.
>=20
> [SLI] Agree
>=20
>=20
>> In this architecture, routers sharing a common trust model form a <Name-=
TBD> domain. The architecture defined by this working group will allow a no=
de to steer a packet between any source and destination node within the <Na=
me-TBD> domain (formed of one or more networks), on any path (shortest, non=
-shortest, explicit or based on other characteristics specified by segment =
identifiers).
>=20
>=20
> [SP] without requiring to maintain state along the path, other
>     than in the ingress node.
>=20
> [SLI] Agree
>=20
>=20
>> It may then send any packet that passes through it through any path that=
 it has specified and that is conform to the security rules. Downstream rou=
ters along the path within the <Name-TBD> domain forward the packet as spec=
ified by the router at the head-end of the path.
>=20
>>=20
>> The architecture should support centralized and distributed path computa=
tion.
>>=20
>> The architecture should support OAM functions.
>=20
>=20
> [SP] The architecture should allow different mechanisms through which
>     a path is constructed. SR allows a variety of mechanisms, not
>     confined IGP/BGP path computation.
>=20
> [SLI] Agree
>=20
>> Work items :
>> ------------------
>>=20
>> The <Name-TBD> working group is chartered for the following ordered list=
 of work items:
>>=20
>> - The first goal of the WG is to identify use-cases.
>> - The WG will then define the architecture framework associated with
>> the security considerations. The architecture framework and security
>> considerations must address the relations between networks forming the <=
Name-TBD> domain (interAS).
>> - Having identified use-cases, architecture and security, the WG will
>> identify gaps between currently available technologies and use-case
>> requirements.
>> - The WG will then define requirements for extensions to existing
>> protocols or new protocols that address gaps that are identified.
>> - The WG will first focus on the intra-domain forwarding definition.
>=20
>=20
> [SP] The architecture will support tunnel and non-tunnel paradigms
>     The architecture will support multiple dataplanes: MPLS and V6
>=20
>=20
> Thanks.
> s.
>=20
>=20
>> Documents :
>> ------------------
>> . Use Cases
>> . Architecture including security considerations
>> - Protocol extension requirements
>> . Interoperability Report
>>=20
>>=20
>> Protocol work may be carried out in this working group or in other worki=
ng groups responsible for the protocols (ISIS,OSPF,BGP,PCEP ...), in coordi=
nation with this WG, and in agreement with the WG chairs and responsible AD=
s.
>>=20
>> -----Message d'origine-----
>> De : Rob Shakir [mailto:[email-masked]]
>> Envoy=E9 : mardi 10 septembre 2013 11:05 =C0 : LITKOWSKI Stephane DTF/DE=
RX
>> Cc : Hannes Gredler; Stefano Previdi (sprevidi); [email-masked] Objet
>> : Re: [Status] Good charter proposals from Hannes and Stefano : try to m=
erge ...
>>=20
>> Hi Stephane,
>>=20
>> Thanks for this, looks good! Comments in-line marked rjs>.
>>=20
>> On 10 Sep 2013, at 08:50, <[email-masked]> wrote:
>>=20
>>> Hi all,
>>>=20
>>> I'm creating a new mail topic because the "Summary of STATUS BOF ..."
>>> starts to be unreadable :)
>>>=20
>>> Hannes and Stefano send to us two charter proposals that sounds good to=
 me.
>>>=20
>>> The main difference between the two proposals is that Stefano propose a=
 segment bound to any type of instruction (forwarding, application or servi=
ce based) while Hannes is focusing on forwarding actions (which is the firs=
t priority, and I think everybody agree on this).
>>=20
>> rjs> Agreed -- I think it would be useful to allow definitions of segmen=
ts to identify different types of "service", since there appear to be some =
use cases (e.g., the explicit exit selection case) which require a segment =
type describing something that is not explicitly IGP-based.
>>=20
>>>=20
>>> It would be interresting to have a feedback from the mailinglist on thi=
s specific point.
>>>=20
>>> IMHO, there is a strong interrest to explore the service actions bound =
to segment in a second step keeping forwarding as a priority.
>>>=20
>>> Apart of this problem, here is a merge try of the two good proposals (I=
'm putting '<>' on hot topics :) ) :
>>>=20
>>>=20
>>> -------------------------------------------------------------------
>>> Name: <TBD>
>>> Charter:
>>>=20
>>>=20
>>> Introduction
>>> ------------
>>> The following use cases:
>>> . Path computation based on awareness of utilization or performance
>>> data, within both centralized and distributed environments, . Multi-top=
ology (dual planes, disjoint trees), . Simplification and reduction of sign=
aling components (scaling), . Combined application and network layer path s=
pecification, . Full coverage LFA-FRR, . Topology Aware OAM, . etc.
>>>=20
>>> have triggered work on the definition of new architecture and protocol =
extensions allowing to combine well known shortest path based routing parad=
igms with source/explicit routing methods. Some of these extensions have be=
en implemented already.
>>>=20
>>>=20
>>> Objective
>>> ---------
>>>=20
>>> Define an architecture where a node can steer a packet through a networ=
k or set of networks (interdomain) on any path (shortest, non shortest, exp=
licit, <service or application>).
>>>=20
>>> In this architecture, routers are sharing a common trust model and are =
forming a <Name-TBD> domain.
>>> Within this domain, a node can specify a path between itself and any de=
stination in the domain. <The path may be a forwarding path, a service chai=
ning path or a combination of both>.
>>=20
>> rjs> To clarify here, we define that our domain is under a common trust =
model (essentially, under common administrative control?), but then go on t=
o talk about inter-domain elsewhere. Can we perhaps clarify (by defining a =
specific "<Name-TBD> domain" nomenclature) and say something like:
>>=20
>> "In this architecture, routers sharing a common trust model form a <Name=
-TBD> domain. The architecture defined by this working group will allow a n=
ode to steer a packet between any source and destination node within the <N=
ame-TBD> domain (formed of one or more networks), on any path (shortest, no=
n-shortest, explicit or based on other characteristics specified by segment=
 identifiers)."
>>=20
>>> It may then send any packet that passes through it through any path tha=
t it has specified and that is conform to the security rules. Downstream ro=
uters along the path within the <Name-TBD> domain forward the packet as spe=
cified by the router at the head-end of the path.
>>>=20
>>> The architecture should support centralized and distributed path comput=
ation.
>>>=20
>>>=20
>>> Work items :
>>> ------------------
>>>=20
>>> The <Name-TBD> working group is chartered for the following ordered lis=
t of work items:
>>>=20
>>> - The first goal of the WG is to identify use-cases.
>>> - The WG will then define the architecture framework associated with
>>> the security considerations. The architecture framework and security
>>> considerations must address the relations between domains (inter domain=
).
>>=20
>> rjs> And then here "networks forming the <Name-TBD> domain"?
>>=20
>> Thanks for the efforts,
>> r.
>>=20
>>> - Having identified use-cases, architecture and security, the WG will
>>> identify gaps between currently available technologies and use-case
>>> requirements.
>>> - The WG will then define requirements for extensions to existing
>>> protocols or new protocols that address gaps that are identified.
>>> - The WG will first focus on the intra-domain forwarding definition.
>>>=20
>>>=20
>>> Documents :
>>> ------------------
>>> . Use Cases
>>> . Architecture including security considerations
>>> - Protocol extension requirements
>>> . Interoperability Report
>>>=20
>>>=20
>>> Protocol work may be carried out in this working group or in other work=
ing groups responsible for the protocols (ISIS,OSPF,BGP,PCEP ...), in coord=
ination with this WG, and in agreement with the WG chairs and responsible A=
Ds.
>>>=20
>>>=20
>>>=20
>>> Hope it helps to progress on the definition.
>>>=20
>>>=20
>>> Stephane
>>>=20
>>>=20
>>> -----Message d'origine-----
>>> De : Hannes Gredler [mailto:[email-masked]] Envoy=E9 : vendredi 6
>>> septembre 2013 18:27 =C0 : LITKOWSKI Stephane DTF/DERX Cc :
>>> [email-masked] Objet : Re: [Status] Summary of STATUS BOF and the
>>> next steps
>>>=20
>>> hi stephane,
>>>=20
>>> here is a revised draft charter as per your comments.
>>>=20
>>> ---
>>>=20
>>> <Name-TBD> domain contains a set of routers with the following
>>> characteristics:
>>>=20
>>> - They form a connected network
>>> - They can forward traffic through any path within the network using
>>> shortest path, or any other (e.g., an explicit) path
>>> - They share a common trust model. In this model, any router within
>>> the domain can specify a path between itself and any other router  in
>>> the domain. It may then send any packet that passes through it
>>> through any path that it has specified and that is conform to the
>>> security rules. Downstream routers along the path within the
>>> <Name-TBD>  domain forward the packet as specified by the router at
>>> the head-end  of the path.
>>>=20
>>> The <Name-TBD> working group is chartered for the following ordered lis=
t of work items:
>>>=20
>>> - The first goal of the WG is to identify use-cases.
>>> - The WG will then define the architecture framework associated with
>>> the security considerations. The architecture framework and security
>>> considerations must address the relations between domains (interdomain)=
.
>>> - Having identified use-cases, architecture and security, the WG will
>>> identify gaps between currently available technologies and use-case
>>> requirements.
>>> - The WG will then define requirements for extensions to existing
>>> protocols or new protocols that address gaps that are identified.
>>> - The WG will first focus on the intra-domain forwarding definition.
>>>=20
>>> Protocol work may be carried out in this working group or in other work=
ing groups responsible for the protocols, in coordination with this WG, and=
 in agreement with the WG chairs and responsible ADs.
>>> However, no protocol work will be adopted by a working group to address=
 the identified use-cases until the requirements document motivating the pr=
otocol work has been sent to the IESG for publication as an RFC.
>>>=20
>>> ---
>>>=20
>>> /hannes
>>>=20
>>> On Sep 4, 2013, at 10:02 AM, <[email-masked]> <stephane.=
[email-masked]> wrote:
>>>=20
>>>> Hannes,
>>>>=20
>>>> In case, we are using only directed forwarding (adjacency segment),
>>>> could we still talk about tunneling ? (it's a very very small tunnel) =
Moreover talking about "stacking" is really dataplane agnostic (MPLS) ...
>>>>=20
>>>> In the proposed segment routing architectural concepts, segments are a=
t the same "level" and pointer moves on the segment list, then the MPLS ins=
tantiation is performing this using stacking ...
>>>>=20
>>>> IMHO, if we use "Stacked Tunnels", we already talk about a chosen solu=
tion and it's closing the door to something else  ...
>>>>=20
>>>> Finally, about the "routing" word, routing is essentially a "forward" =
action which may limit the scope of what we can do by using a segment list.=
 Actions associated with a segment could be something else than forwarding.
>>>>=20
>>>> Do we want in the charter to limit the scope to routing actions ?
>>>>=20
>>>> I have no solution today to propose for the naming, but I completely a=
gree with Loa, to first focus on working on the charter, and define a clear=
 scope of the work and then the name will be easier to find.
>>>>=20
>>>> Regarding your charter proposal :
>>>>=20
>>>> --------
>>>>=20
>>>> - They form a connected network
>>>>     [SLI] InterAS case must be included, but the WG can go step by ste=
p and first release intraAS, and then doing interAS (in relation with IDR ?=
?).
>>>>=20
>>>> - They can forward traffic through the shortest paths or paths other t=
han the shortest (the latter called explicitly routed paths, or explicit pa=
ths)
>>>>     [SLI] There is something else between SPT and Explicit path, you c=
an define other algorithms than SPT to define a path, and it's not explicit=
 path. Moreover I come back to my comment, on do we want to limit the scope=
 to routing ? I would say no.
>>>>=20
>>>> - They share a common trust model. In this model, any router within th=
e ERD can specify an explicit path between itself and any other router in t=
he ERD. It can then send any packet that passes through it through any path=
 that it has specified.
>>>>     [SLI] Security considerations may have to be addressed in the
>>>> charter , especially for the interAS case (trust yes, but not sure
>>>> access to everything may not be good)
>>>>=20
>>>> Downstream routers within the ERD forward the packet as specified by t=
he router at the head-end of the path.
>>>> [SLI] Yes, but any router in the middle may be able to change the end =
to end explicit path.
>>>>=20
>>>>=20
>>>>=20
>>>> - The first goal of the STER WG is to identify use-cases for ERDs.
>>>> - Having identified use-cases, the WG will identify gaps between curre=
ntly available technologies and use-case requirements.
>>>> - The WG will then define requirements for extensions to existing prot=
ocols or new protocols that address gaps that are identified.
>>>>=20
>>>> [SLI] Agree, I would add :
>>>> - defining the architecture framework
>>>> - analysing the security considerisations
>>>>=20
>>>>=20
>>>> ---------
>>>>=20
>>>>=20
>>>> Here would be my proposal to extend yours :
>>>>=20
>>>> A <named to be defined> domain contains a set of routers with the foll=
owing characteristics:
>>>>=20
>>>> - They form a connected network
>>>> - They can forward traffic through any path within the network using
>>>> shortest path, non shortest path or explicit path
>>>> - They may provide other types of services than forwarding and they ca=
n enforce service actions in the path.
>>>> - They share a common trust model. In this model, any router within th=
e domain can specify a path between itself and any other router in the doma=
in. It may then send any packet that passes through it through any path tha=
t it has specified and that is conform to the security rules. Downstream ro=
uters within the ERD forward the packet as specified by the router at the h=
ead-end of the path.
>>>>=20
>>>> The <name> working group is chartered for the following ordered list o=
f work items:
>>>>=20
>>>> - The first goal of the WG is to identify use-cases.
>>>> - The WG will then define the architecture framework associated with t=
he security considerations. The architecture framework and security conside=
rations must address the relations between domains (interdomain).
>>>> - Having identified use-cases, architecture and security, the WG will =
identify gaps between currently available technologies and use-case require=
ments.
>>>> - The WG will then define requirements for extensions to existing prot=
ocols or new protocols that address gaps that are identified.
>>>> - The WG will first focus on the intra-domain forwarding definition.
>>>>=20
>>>> Protocol work may be carried out in this working group or in other wor=
king groups responsible for the protocols, in coordination with this WG, an=
d in agreement with the WG chairs and responsible ADs. However, no protocol=
 work will be adopted by a working group to address the ERD use-cases until=
 the requirements document motivating the protocol work has been sent to th=
e IESG for publication as an RFC.
>>>>=20
>>>> -----Message d'origine-----
>>>> De : [email-masked] [mailto:[email-masked]] De la
>>>> part de Hannes Gredler Envoy=E9 : mardi 3 septembre 2013 18:31 =C0 : L=
oa
>>>> Andersson Cc : [email-masked] Objet : Re: [Status] Summary of
>>>> STATUS BOF and the next steps
>>>>=20
>>>> good point - what about this charter proposal ?
>>>>=20
>>>> ---
>>>>=20
>>>> Stacked Tunnels for Explicit Routing (STER)
>>>> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
>>>>=20
>>>> A explicit routing domain (ERD) contains a set of routers with the fol=
lowing characteristics:
>>>>=20
>>>> - They form a connected network
>>>> - They can forward traffic through the shortest paths or paths other
>>>> than the shortest (the latter called explicitly routed paths, or
>>>> explicit paths)
>>>> - They share a common trust model. In this model, any router within th=
e ERD can specify an explicit path between itself and any other router in t=
he ERD. It can then send any packet that passes through it through any path=
 that it has specified. Downstream routers within the ERD forward the packe=
t as specified by the router at the head-end of the path.
>>>>=20
>>>> The STER working group is chartered for the following ordered list of =
work items:
>>>>=20
>>>> - The first goal of the STER WG is to identify use-cases for ERDs.
>>>> - Having identified use-cases, the WG will identify gaps between curre=
ntly available technologies and use-case requirements.
>>>> - The WG will then define requirements for extensions to existing prot=
ocols or new protocols that address gaps that are identified.
>>>>=20
>>>> Protocol work may be carried out in this working group or in other wor=
king groups responsible for the protocols, in coordination with this WG, an=
d in agreement with the WG chairs and responsible ADs. However, no protocol=
 work will be adopted by a working group to address the ERD use-cases until=
 the requirements document motivating the protocol work has been sent to th=
e IESG for publication as an RFC.
>>>>=20
>>>> ---
>>>>=20
>>>> <flame suit on>
>>>>=20
>>>> /hannes
>>>>=20
>>>>=20
>>>> On Sep 3, 2013, at 5:31 PM, Loa Andersson wrote:
>>>>=20
>>>>> Folks,
>>>>>=20
>>>>> Excuse me if I'm slightly out of the loop, but so far I have not
>>>>> seen a charter proposal, if there is one please point me to it.
>>>>>=20
>>>>> It seems a bit odd to put the cart (what the wg should do) before
>>>>> the horse (wg name). If we drill down the the charter first the wg
>>>>> name might be easier to figure out.
>>>>>=20
>>>>> /Loa
>>>>>=20
>>>>> PS
>>>>> OK I understand that the horse and cart analogy limps a  bit :).
>>>>>=20
>>>>>=20
>>>>>=20
>>>>> On 2013-09-03 17:22, AshwoodsmithPeter wrote:
>>>>>> " If the WG charter is limited to source routing, how will we handle=
 the "non source routing" use cases of segment routing ? In another working=
 group ? So we will go back to the WG synchronization issue that has been r=
aised for this technology ..."
>>>>>>=20
>>>>>> That's why I suggested SRV2. We are revisiting source routing with n=
ew concepts. More generic number/action behavior.
>>>>>>=20
>>>>>> Peter
>>>>>>=20
>>>>>> -----Original Message-----
>>>>>> From: [email-masked] [mailto:[email-masked]] On
>>>>>> Behalf Of [email-masked]
>>>>>> Sent: Tuesday, September 03, 2013 10:43 AM
>>>>>> To: AshwoodsmithPeter
>>>>>> Cc: [email-masked]
>>>>>> Subject: Re: [Status] Summary of STATUS BOF and the next steps
>>>>>>=20
>>>>>>=20
>>>>>> There was a misunderstanding in my small comment :) so I will explai=
n more :
>>>>>>=20
>>>>>> In segment routing, you have more than basic source routing : segmen=
t routing is just associate a segment number to an action and then combine =
segment as you want, yes you can do source routing, but you also can do mor=
e.
>>>>>>=20
>>>>>> In the other hand, I completely agree with your statement that
>>>>>> source routing is generic and dataplane agnostic, as segment routing=
 is ...
>>>>>> (segment routing is not a new dataplane ...)
>>>>>>=20
>>>>>> Now the definition of the WG naming must be inline with the
>>>>>> charter that will be defined ... (draft today)
>>>>>>=20
>>>>>> Based on the already existing consensus (at least for MPLS dataplane=
) brought up during Berlin STATUS BOF meeting, segment routing sounds to be=
 a good target candidate.
>>>>>>=20
>>>>>> So now, do we want to do more in the WG charter than just make progr=
essing segment routing architecture and uses cases document and ensure coor=
dination for the standardization of this technology ?
>>>>>>=20
>>>>>> Do we want to standardize other technologies in this WG ? I don't th=
ink so, based on Stewart's conclusion email from the BOF :"A new WG focused=
 solely on SR therefore needs to be create"
>>>>>>=20
>>>>>> If the WG charter is limited to source routing, how will we handle t=
he "non source routing" use cases of segment routing ? In another working g=
roup ? So we will go back to the WG synchronization issue that has been rai=
sed for this technology ...
>>>>>>=20
>>>>>> If the WG is focused on SR, let's use a name in relation with SR.
>>>>>>=20
>>>>>> Feedback ?
>>>>>>=20
>>>>>>=20
>>>>>> Stephane
>>>>>>=20
>>>>>>=20
>>>>>> -----Message d'origine-----
>>>>>> De : AshwoodsmithPeter [mailto:[email-masked]]
>>>>>> Envoy=E9 : mardi 3 septembre 2013 15:27 =C0 : LITKOWSKI Stephane
>>>>>> DTF/DERX Cc : John E Drake; Mark Townsley; Victor Kuarsingh;
>>>>>> Roberta Maglione (robmgl); John G. Scudder; Adrian Farrel; Alvaro
>>>>>> Retana (aretana); [email-masked]; Stewart Bryant (stbryant) Objet :=
 Re:
>>>>>> [Status] Summary of STATUS BOF and the next steps
>>>>>>=20
>>>>>> The term "source routing" has been around for a very long time and i=
s data path agnostic. Its also the term used in the literature etc so my pr=
eference is to stick with this existing well known and data path agnostic t=
erm.
>>>>>>=20
>>>>>> Peter
>>>>>>=20
>>>>>> On Sep 3, 2013, at 9:07 AM, "[email-masked]" <stephan=
[email-masked]> wrote:
>>>>>>=20
>>>>>>> Hi,
>>>>>>>=20
>>>>>>> "Source routing" is just a subcase of segment routing ... as it is =
for IP routing ...
>>>>>>>=20
>>>>>>> Stephane
>>>>>>>=20
>>>>>>>=20
>>>>>>> -----Message d'origine-----
>>>>>>> De : [email-masked] [mailto:[email-masked]] De
>>>>>>> la part de John E Drake Envoy=E9 : mardi 3 septembre 2013 15:02 =C0=
 :
>>>>>>> Mark Townsley; Victor Kuarsingh Cc : Roberta Maglione (robmgl); Joh=
n G.
>>>>>>> Scudder; Alvaro Retana (aretana); Adrian Farrel; [email-masked];
>>>>>>> Stewart Bryant (stbryant) Objet : Re: [Status] Summary of STATUS
>>>>>>> BOF and the next steps
>>>>>>>=20
>>>>>>> Hi,
>>>>>>>=20
>>>>>>> What is this 'segment routing' silliness?  The correct term is 'sou=
rce routing'.
>>>>>>>=20
>>>>>>> Yours Irrespectively,
>>>>>>>=20
>>>>>>> John
>>>>>>>=20
>>>>>>>> -----Original Message-----
>>>>>>>> From: [email-masked] [mailto:[email-masked]]
>>>>>>>> On Behalf Of Mark Townsley
>>>>>>>> Sent: Sunday, September 01, 2013 10:08 AM
>>>>>>>> To: Victor Kuarsingh
>>>>>>>> Cc: Roberta Maglione (robmgl); John G. Scudder; Adrian Farrel;
>>>>>>>> Alvaro Retana (aretana); [email-masked]; Stewart Bryant
>>>>>>>> (stbryant)
>>>>>>>> Subject: Re: [Status] Summary of STATUS BOF and the next steps
>>>>>>>>=20
>>>>>>>>=20
>>>>>>>> On Sep 1, 2013, at 5:38 PM, Victor Kuarsingh wrote:
>>>>>>>>=20
>>>>>>>>> All,
>>>>>>>>>=20
>>>>>>>>> I would also favour "Segment Routing WG" as well.
>>>>>>>>>=20
>>>>>>>>> I note this since attempting to come up with an all
>>>>>>>>> encompassing acronym will be difficult and Segment Routing is
>>>>>>>>> generic enough to associate to multiple functions.
>>>>>>>>=20
>>>>>>>> Then we can just use "segroute" for the short name. WGs do not
>>>>>>>> have to have acronyms, but they do need to have an 8-char
>>>>>>>> limited short name for the various automated tools not to break.
>>>>>>>>=20
>>>>>>>> - Mark
>>>>>>>>=20
>>>>>>>>>=20
>>>>>>>>> Regards,
>>>>>>>>>=20
>>>>>>>>> Victor K
>>>>>>>>>=20
>>>>>>>>>=20
>>>>>>>>>=20
>>>>>>>>> On 2013-08-31 6:51 PM, "Roberta Maglione (robmgl)"
>>>>>>>>> <[email-masked]>
>>>>>>>>> wrote:
>>>>>>>>>=20
>>>>>>>>>> +1 for Segment Routing WG
>>>>>>>>>>=20
>>>>>>>>>> Roberta
>>>>>>>>>>=20
>>>>>>>>>> Sent from my iPad
>>>>>>>>>>=20
>>>>>>>>>> On 2013-08-30, at 2:55 PM, "Alvaro Retana (aretana)"
>>>>>>>>>> <[email-masked]>
>>>>>>>>>> wrote:
>>>>>>>>>>=20
>>>>>>>>>>> Segment Routing WG
>>>>>>>>>>>=20
>>>>>>>>>>> Sent from my iPhone
>>>>>>>>>>>=20
>>>>>>>>>>> On Aug 30, 2013, at 1:39 PM, "Stewart Bryant (stbryant)"
>>>>>>>>>>> <[email-masked]> wrote:
>>>>>>>>>>>=20
>>>>>>>>>>>> The second task, which hopefully should be relatively easy,
>>>>>>>>>>>> is to find a better working name for the WG, since it has
>>>>>>>>>>>> been put to me a number of times that STATUS is going to be
>>>>>>>>>>>> confusing in text and a difficult search term.
>>>>>>>>>>> _______________________________________________
>>>>>>>>>>> status mailing list
>>>>>>>>>>> [email-masked]
>>>>>>>>>>> https://www.ietf.org/mailman/listinfo/status
>>>>>>>>>> _______________________________________________
>>>>>>>>>> status mailing list
>>>>>>>>>> [email-masked]
>>>>>>>>>> https://www.ietf.org/mailman/listinfo/status
>>>>>>>>>=20
>>>>>>>>>=20
>>>>>>>>> _______________________________________________
>>>>>>>>> status mailing list
>>>>>>>>> [email-masked]
>>>>>>>>> https://www.ietf.org/mailman/listinfo/status
>>>>>>>>=20
>>>>>>>> _______________________________________________
>>>>>>>> status mailing list
>>>>>>>> [email-masked]
>>>>>>>> https://www.ietf.org/mailman/listinfo/status
>>>>>>>=20
>>>>>>>=20
>>>>>>> _______________________________________________
>>>>>>> status mailing list
>>>>>>> [email-masked]
>>>>>>> https://www.ietf.org/mailman/listinfo/status
>>>>>>>=20
>>>>>>> _________________________________________________________________
>>>>>>> _ _ _ __ ___________________________________________________
>>>>>>>=20
>>>>>>> Ce message et ses pieces jointes peuvent contenir des
>>>>>>> informations confidentielles ou privilegiees et ne doivent donc
>>>>>>> pas etre diffuses, exploites ou copies sans autorisation. Si vous
>>>>>>> avez recu ce message par erreur, veuillez le signaler a l'expediteu=
r et le detruire ainsi que les pieces jointes. Les messages electroniques e=
tant susceptibles d'alteration, Orange decline toute responsabilite si ce m=
essage a ete altere, deforme ou falsifie. Merci.
>>>>>>>=20
>>>>>>> This message and its attachments may contain confidential or
>>>>>>> privileged information that may be protected by law; they should no=
t be distributed, used or copied without authorisation.
>>>>>>> If you have received this email in error, please notify the sender =
and delete this message and its attachments.
>>>>>>> As emails may be altered, Orange is not liable for messages that ha=
ve been modified, changed or falsified.
>>>>>>> Thank you.
>>>>>>>=20
>>>>>>> _______________________________________________
>>>>>>> status mailing list
>>>>>>> [email-masked]
>>>>>>> https://www.ietf.org/mailman/listinfo/status
>>>>>>=20
>>>>>> __________________________________________________________________
>>>>>> _ _ _ ____________________________________________________
>>>>>>=20
>>>>>> Ce message et ses pieces jointes peuvent contenir des informations
>>>>>> confidentielles ou privilegiees et ne doivent donc pas etre
>>>>>> diffuses, exploites ou copies sans autorisation. Si vous avez recu
>>>>>> ce message par erreur, veuillez le signaler a l'expediteur et le det=
ruire ainsi que les pieces jointes. Les messages electroniques etant suscep=
tibles d'alteration, Orange decline toute responsabilite si ce message a et=
e altere, deforme ou falsifie. Merci.
>>>>>>=20
>>>>>> This message and its attachments may contain confidential or
>>>>>> privileged information that may be protected by law; they should not=
 be distributed, used or copied without authorisation.
>>>>>> If you have received this email in error, please notify the sender a=
nd delete this message and its attachments.
>>>>>> As emails may be altered, Orange is not liable for messages that hav=
e been modified, changed or falsified.
>>>>>> Thank you.
>>>>>>=20
>>>>>> _______________________________________________
>>>>>> status mailing list
>>>>>> [email-masked]
>>>>>> https://www.ietf.org/mailman/listinfo/status
>>>>>> _______________________________________________
>>>>>> status mailing list
>>>>>> [email-masked]
>>>>>> https://www.ietf.org/mailman/listinfo/status
>>>>>>=20
>>>>>=20
>>>>> --
>>>>>=20
>>>>>=20
>>>>> Loa Andersson                        email: [email-masked]
>>>>> Senior MPLS Expert                          [email-masked]
>>>>> Huawei Technologies (consultant)     phone: +46 739 81 21 64
>>>>> _______________________________________________
>>>>> status mailing list
>>>>> [email-masked]
>>>>> https://www.ietf.org/mailman/listinfo/status
>>>>>=20
>>>>>=20
>>>>=20
>>>>=20
>>>> _______________________________________________
>>>> status mailing list
>>>> [email-masked]
>>>> https://www.ietf.org/mailman/listinfo/status
>>>>=20
>>>> ____________________________________________________________________
>>>> _ _ ___________________________________________________
>>>>=20
>>>> Ce message et ses pieces jointes peuvent contenir des informations
>>>> confidentielles ou privilegiees et ne doivent donc pas etre
>>>> diffuses, exploites ou copies sans autorisation. Si vous avez recu
>>>> ce message par erreur, veuillez le signaler a l'expediteur et le detru=
ire ainsi que les pieces jointes. Les messages electroniques etant suscepti=
bles d'alteration, Orange decline toute responsabilite si ce message a ete =
altere, deforme ou falsifie. Merci.
>>>>=20
>>>> This message and its attachments may contain confidential or
>>>> privileged information that may be protected by law; they should not b=
e distributed, used or copied without authorisation.
>>>> If you have received this email in error, please notify the sender and=
 delete this message and its attachments.
>>>> As emails may be altered, Orange is not liable for messages that have =
been modified, changed or falsified.
>>>> Thank you.
>>>>=20
>>>>=20
>>>>=20
>>>=20
>>>=20
>>>=20
>>> _____________________________________________________________________
>>> _ ___________________________________________________
>>>=20
>>> Ce message et ses pieces jointes peuvent contenir des informations
>>> confidentielles ou privilegiees et ne doivent donc pas etre diffuses,
>>> exploites ou copies sans autorisation. Si vous avez recu ce message
>>> par erreur, veuillez le signaler a l'expediteur et le detruire ainsi qu=
e les pieces jointes. Les messages electroniques etant susceptibles d'alter=
ation, Orange decline toute responsabilite si ce message a ete altere, defo=
rme ou falsifie. Merci.
>>>=20
>>> This message and its attachments may contain confidential or
>>> privileged information that may be protected by law; they should not be=
 distributed, used or copied without authorisation.
>>> If you have received this email in error, please notify the sender and =
delete this message and its attachments.
>>> As emails may be altered, Orange is not liable for messages that have b=
een modified, changed or falsified.
>>> Thank you.
>>>=20
>>> _______________________________________________
>>> status mailing list
>>> [email-masked]
>>> https://www.ietf.org/mailman/listinfo/status
>>=20
>>=20
>> ______________________________________________________________________
>> ___________________________________________________
>>=20
>> Ce message et ses pieces jointes peuvent contenir des informations
>> confidentielles ou privilegiees et ne doivent donc pas etre diffuses,
>> exploites ou copies sans autorisation. Si vous avez recu ce message
>> par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que=
 les pieces jointes. Les messages electroniques etant susceptibles d'altera=
tion, Orange decline toute responsabilite si ce message a ete altere, defor=
me ou falsifie. Merci.
>>=20
>> This message and its attachments may contain confidential or
>> privileged information that may be protected by law; they should not be =
distributed, used or copied without authorisation.
>> If you have received this email in error, please notify the sender and d=
elete this message and its attachments.
>> As emails may be altered, Orange is not liable for messages that have be=
en modified, changed or falsified.
>> Thank you.
>>=20
>=20
>=20
> _________________________________________________________________________=
________________________________________________
>=20
> Ce message et ses pieces jointes peuvent contenir des informations confid=
entielles ou privilegiees et ne doivent donc
> pas etre diffuses, exploites ou copies sans autorisation. Si vous avez re=
cu ce message par erreur, veuillez le signaler
> a l'expediteur et le detruire ainsi que les pieces jointes. Les messages =
electroniques etant susceptibles d'alteration,
> Orange decline toute responsabilite si ce message a ete altere, deforme o=
u falsifie. Merci.
>=20
> This message and its attachments may contain confidential or privileged i=
nformation that may be protected by law;
> they should not be distributed, used or copied without authorisation.
> If you have received this email in error, please notify the sender and de=
lete this message and its attachments.
> As emails may be altered, Orange is not liable for messages that have bee=
n modified, changed or falsified.
> Thank you.
>=20

From: <[email-masked]>
To: "Stefano Previdi (sprevidi)" <[email-masked]>, Rob Shakir <[email-masked]>
Date: Tue, 10 Sep 2013 13:25:01 +0200
Accept-Language: fr-FR
acceptlanguage: fr-FR
Cc: Hannes Gredler <[email-masked]>, "[email-masked]" <[email-masked]>
Subject: Re: [Status] Good charter proposals from Hannes and Stefano : try to merge ...

Agree on all proposal except :

"[SP] The architecture will support tunnel and non-tunnel paradigms
     The architecture will support multiple dataplanes: MPLS and V6"

I don't see the reason for this ... IMHO, the gap analysis and requirements=
 inventory will result on saying or not : we must use tunnels and/or non tu=
nnels, and the following dataplanes ... But I don't see the reason to put s=
olutions directly in the charter ...
Could you explain your point ?

updated with the other comments :

 -------------------------------------------------------------------
Name: <TBD>
Charter:

Introduction
------------
The following use cases:
. Path computation based on awareness of utilization or performance
  data, within both centralized and distributed environments, . Multi-topol=
ogy (dual planes, disjoint trees), . Simplification and reduction of signal=
ing components (scaling), . Combined application and network layer path spe=
cification, . Full coverage LFA-FRR, . Topology Aware OAM, . etc.

have triggered work on the definition of new architecture and protocol exte=
nsions allowing to combine well known shortest path based routing paradigms=
 with source/explicit routing methods. Some of these extensions have been i=
mplemented already.

Objective
---------

Define an architecture where a node can steer a packet through a network or=
 set of networks (interdomain) on any path without requiring to maintain st=
ate along the path, other than in the ingress node.

A node may be any type of device including routers or appliances.

In this architecture, nodes sharing a common trust model form a <Name-TBD> =
domain. The architecture defined by this working group will allow a node to=
 steer a packet between any source and destination node within the <Name-TB=
D> domain (formed of one or more networks), on any path (shortest, non-shor=
test, explicit or based on other characteristics specified by segment ident=
ifiers).

It may then send any packet that passes through it through any path that it=
 has specified and that is conform to the security rules. Downstream nodes =
along the path within the <Name-TBD> domain forward the packet by using the=
 informations inserted by the node at the head-end

The architecture should support centralized and distributed path computatio=
n.

The architecture should support OAM functions.

The architecture should allow different mechanisms through which
     a path is constructed. SR allows a variety of mechanisms, not
     confined IGP/BGP path computation.

As MPLS dataplane is largely deployed, the <Name-TBD> WG should avoid any m=
odification in the MPLS dataplane when defining the architecture.

Work items :
------------------

The <Name-TBD> working group is chartered for the following ordered list of=
 work items:

- The first goal of the WG is to identify use-cases.
- The WG will then define the architecture framework associated with
  the security considerations. The architecture framework and security
  considerations must address the relations between networks forming the <N=
ame-TBD> domain (interAS).
- Having identified use-cases, architecture and security, the WG will
  identify gaps between currently available technologies and use-case
  requirements.
- The WG will then define requirements for extensions to existing
  protocols or new protocols that address gaps that are identified.
- The WG will first focus on the intra-domain forwarding definition.

Documents :
------------------
. Use Cases
. Architecture including security considerations
- Protocol extension requirements
. Interoperability Report

Required protocol extensions are carried out in working groups responsible =
(ISIS,OSPF,BGP,PCEP ...). Work on new protocols may be carried out by the <=
Name-TBD> WG.

-----Message d'origine-----
De : Stefano Previdi (sprevidi) [mailto:[email-masked]]
Envoy=E9 : mardi 10 septembre 2013 12:30
=C0 : LITKOWSKI Stephane DTF/DERX; Rob Shakir
Cc : Hannes Gredler; [email-masked]
Objet : Re: [Status] Good charter proposals from Hannes and Stefano : try t=
o merge ...

Hi Stephane, Rob,

one preliminary remark: I prefer to use he therm "node" rather than "router=
". Use cases, such as Service Chaining requires that terminology.

some other comments below...

On Sep 10, 2013, at 11:19 AM, <[email-masked]> wrote:
> Souns good to me, (adding OAM also)
>
> New recap :
>
> -------------------------------------------------------------------
> Name: <TBD>
> Charter:
>
>
> Introduction
> ------------
> The following use cases:
> . Path computation based on awareness of utilization or performance
> data, within both centralized and distributed environments, . Multi-topol=
ogy (dual planes, disjoint trees), . Simplification and reduction of signal=
ing components (scaling), . Combined application and network layer path spe=
cification, . Full coverage LFA-FRR, . Topology Aware OAM, . etc.
>
> have triggered work on the definition of new architecture and protocol ex=
tensions allowing to combine well known shortest path based routing paradig=
ms with source/explicit routing methods. Some of these extensions have been=
 implemented already.
>
>
> Objective
> ---------
>
> Define an architecture where a node can steer a packet through a network =
or set of networks (interdomain) on any path.

[SP] As stated above, I'm fine with the above definition but I
     assume this includes service chaining and that by "network
     or set of networks" you intend "nodes" which may include
     others things than just routers.

[SLI] Agree

> In this architecture, routers sharing a common trust model form a <Name-T=
BD> domain. The architecture defined by this working group will allow a nod=
e to steer a packet between any source and destination node within the <Nam=
e-TBD> domain (formed of one or more networks), on any path (shortest, non-=
shortest, explicit or based on other characteristics specified by segment i=
dentifiers).

[SP] without requiring to maintain state along the path, other
     than in the ingress node.

[SLI] Agree

> It may then send any packet that passes through it through any path that =
it has specified and that is conform to the security rules. Downstream rout=
ers along the path within the <Name-TBD> domain forward the packet as speci=
fied by the router at the head-end of the path.

>
> The architecture should support centralized and distributed path computat=
ion.
>
> The architecture should support OAM functions.

[SP] The architecture should allow different mechanisms through which
     a path is constructed. SR allows a variety of mechanisms, not
     confined IGP/BGP path computation.

[SLI] Agree

> Work items :
> ------------------
>
> The <Name-TBD> working group is chartered for the following ordered list =
of work items:
>
> - The first goal of the WG is to identify use-cases.
> - The WG will then define the architecture framework associated with
> the security considerations. The architecture framework and security
> considerations must address the relations between networks forming the <N=
ame-TBD> domain (interAS).
> - Having identified use-cases, architecture and security, the WG will
> identify gaps between currently available technologies and use-case
> requirements.
> - The WG will then define requirements for extensions to existing
> protocols or new protocols that address gaps that are identified.
> - The WG will first focus on the intra-domain forwarding definition.

[SP] The architecture will support tunnel and non-tunnel paradigms
     The architecture will support multiple dataplanes: MPLS and V6

Thanks.
s.

> Documents :
> ------------------
> . Use Cases
> . Architecture including security considerations
> - Protocol extension requirements
> . Interoperability Report
>
>
> Protocol work may be carried out in this working group or in other workin=
g groups responsible for the protocols (ISIS,OSPF,BGP,PCEP ...), in coordin=
ation with this WG, and in agreement with the WG chairs and responsible ADs.
>
> -----Message d'origine-----
> De : Rob Shakir [mailto:[email-masked]]
> Envoy=E9 : mardi 10 septembre 2013 11:05 =C0 : LITKOWSKI Stephane DTF/DERX
> Cc : Hannes Gredler; Stefano Previdi (sprevidi); [email-masked] Objet
> : Re: [Status] Good charter proposals from Hannes and Stefano : try to me=
rge ...
>
> Hi Stephane,
>
> Thanks for this, looks good! Comments in-line marked rjs>.
>
> On 10 Sep 2013, at 08:50, <[email-masked]> wrote:
>
>> Hi all,
>>
>> I'm creating a new mail topic because the "Summary of STATUS BOF ..."
>> starts to be unreadable :)
>>
>> Hannes and Stefano send to us two charter proposals that sounds good to =
me.
>>
>> The main difference between the two proposals is that Stefano propose a =
segment bound to any type of instruction (forwarding, application or servic=
e based) while Hannes is focusing on forwarding actions (which is the first=
 priority, and I think everybody agree on this).
>
> rjs> Agreed -- I think it would be useful to allow definitions of segment=
s to identify different types of "service", since there appear to be some u=
se cases (e.g., the explicit exit selection case) which require a segment t=
ype describing something that is not explicitly IGP-based.
>
>>
>> It would be interresting to have a feedback from the mailinglist on this=
 specific point.
>>
>> IMHO, there is a strong interrest to explore the service actions bound t=
o segment in a second step keeping forwarding as a priority.
>>
>> Apart of this problem, here is a merge try of the two good proposals (I'=
m putting '<>' on hot topics :) ) :
>>
>>
>> -------------------------------------------------------------------
>> Name: <TBD>
>> Charter:
>>
>>
>> Introduction
>> ------------
>> The following use cases:
>> . Path computation based on awareness of utilization or performance
>> data, within both centralized and distributed environments, . Multi-topo=
logy (dual planes, disjoint trees), . Simplification and reduction of signa=
ling components (scaling), . Combined application and network layer path sp=
ecification, . Full coverage LFA-FRR, . Topology Aware OAM, . etc.
>>
>> have triggered work on the definition of new architecture and protocol e=
xtensions allowing to combine well known shortest path based routing paradi=
gms with source/explicit routing methods. Some of these extensions have bee=
n implemented already.
>>
>>
>> Objective
>> ---------
>>
>> Define an architecture where a node can steer a packet through a network=
 or set of networks (interdomain) on any path (shortest, non shortest, expl=
icit, <service or application>).
>>
>> In this architecture, routers are sharing a common trust model and are f=
orming a <Name-TBD> domain.
>> Within this domain, a node can specify a path between itself and any des=
tination in the domain. <The path may be a forwarding path, a service chain=
ing path or a combination of both>.
>
> rjs> To clarify here, we define that our domain is under a common trust m=
odel (essentially, under common administrative control?), but then go on to=
 talk about inter-domain elsewhere. Can we perhaps clarify (by defining a s=
pecific "<Name-TBD> domain" nomenclature) and say something like:
>
> "In this architecture, routers sharing a common trust model form a <Name-=
TBD> domain. The architecture defined by this working group will allow a no=
de to steer a packet between any source and destination node within the <Na=
me-TBD> domain (formed of one or more networks), on any path (shortest, non=
-shortest, explicit or based on other characteristics specified by segment =
identifiers)."
>
>> It may then send any packet that passes through it through any path that=
 it has specified and that is conform to the security rules. Downstream rou=
ters along the path within the <Name-TBD> domain forward the packet as spec=
ified by the router at the head-end of the path.
>>
>> The architecture should support centralized and distributed path computa=
tion.
>>
>>
>> Work items :
>> ------------------
>>
>> The <Name-TBD> working group is chartered for the following ordered list=
 of work items:
>>
>> - The first goal of the WG is to identify use-cases.
>> - The WG will then define the architecture framework associated with
>> the security considerations. The architecture framework and security
>> considerations must address the relations between domains (inter domain).
>
> rjs> And then here "networks forming the <Name-TBD> domain"?
>
> Thanks for the efforts,
> r.
>
>> - Having identified use-cases, architecture and security, the WG will
>> identify gaps between currently available technologies and use-case
>> requirements.
>> - The WG will then define requirements for extensions to existing
>> protocols or new protocols that address gaps that are identified.
>> - The WG will first focus on the intra-domain forwarding definition.
>>
>>
>> Documents :
>> ------------------
>> . Use Cases
>> . Architecture including security considerations
>> - Protocol extension requirements
>> . Interoperability Report
>>
>>
>> Protocol work may be carried out in this working group or in other worki=
ng groups responsible for the protocols (ISIS,OSPF,BGP,PCEP ...), in coordi=
nation with this WG, and in agreement with the WG chairs and responsible AD=
s.
>>
>>
>>
>> Hope it helps to progress on the definition.
>>
>>
>> Stephane
>>
>>
>> -----Message d'origine-----
>> De : Hannes Gredler [mailto:[email-masked]] Envoy=E9 : vendredi 6
>> septembre 2013 18:27 =C0 : LITKOWSKI Stephane DTF/DERX Cc :
>> [email-masked] Objet : Re: [Status] Summary of STATUS BOF and the
>> next steps
>>
>> hi stephane,
>>
>> here is a revised draft charter as per your comments.
>>
>> ---
>>
>> <Name-TBD> domain contains a set of routers with the following
>> characteristics:
>>
>> - They form a connected network
>> - They can forward traffic through any path within the network using
>> shortest path, or any other (e.g., an explicit) path
>> - They share a common trust model. In this model, any router within
>> the domain can specify a path between itself and any other router  in
>> the domain. It may then send any packet that passes through it
>> through any path that it has specified and that is conform to the
>> security rules. Downstream routers along the path within the
>> <Name-TBD>  domain forward the packet as specified by the router at
>> the head-end  of the path.
>>
>> The <Name-TBD> working group is chartered for the following ordered list=
 of work items:
>>
>> - The first goal of the WG is to identify use-cases.
>> - The WG will then define the architecture framework associated with
>> the security considerations. The architecture framework and security
>> considerations must address the relations between domains (interdomain).
>> - Having identified use-cases, architecture and security, the WG will
>> identify gaps between currently available technologies and use-case
>> requirements.
>> - The WG will then define requirements for extensions to existing
>> protocols or new protocols that address gaps that are identified.
>> - The WG will first focus on the intra-domain forwarding definition.
>>
>> Protocol work may be carried out in this working group or in other worki=
ng groups responsible for the protocols, in coordination with this WG, and =
in agreement with the WG chairs and responsible ADs.
>> However, no protocol work will be adopted by a working group to address =
the identified use-cases until the requirements document motivating the pro=
tocol work has been sent to the IESG for publication as an RFC.
>>
>> ---
>>
>> /hannes
>>
>> On Sep 4, 2013, at 10:02 AM, <[email-masked]> <stephane.l=
[email-masked]> wrote:
>>
>>> Hannes,
>>>
>>> In case, we are using only directed forwarding (adjacency segment),
>>> could we still talk about tunneling ? (it's a very very small tunnel) M=
oreover talking about "stacking" is really dataplane agnostic (MPLS) ...
>>>
>>> In the proposed segment routing architectural concepts, segments are at=
 the same "level" and pointer moves on the segment list, then the MPLS inst=
antiation is performing this using stacking ...
>>>
>>> IMHO, if we use "Stacked Tunnels", we already talk about a chosen solut=
ion and it's closing the door to something else  ...
>>>
>>> Finally, about the "routing" word, routing is essentially a "forward" a=
ction which may limit the scope of what we can do by using a segment list. =
Actions associated with a segment could be something else than forwarding.
>>>
>>> Do we want in the charter to limit the scope to routing actions ?
>>>
>>> I have no solution today to propose for the naming, but I completely ag=
ree with Loa, to first focus on working on the charter, and define a clear =
scope of the work and then the name will be easier to find.
>>>
>>> Regarding your charter proposal :
>>>
>>> --------
>>>
>>> - They form a connected network
>>>      [SLI] InterAS case must be included, but the WG can go step by ste=
p and first release intraAS, and then doing interAS (in relation with IDR ?=
?).
>>>
>>> - They can forward traffic through the shortest paths or paths other th=
an the shortest (the latter called explicitly routed paths, or explicit pat=
hs)
>>>      [SLI] There is something else between SPT and Explicit path, you c=
an define other algorithms than SPT to define a path, and it's not explicit=
 path. Moreover I come back to my comment, on do we want to limit the scope=
 to routing ? I would say no.
>>>
>>> - They share a common trust model. In this model, any router within the=
 ERD can specify an explicit path between itself and any other router in th=
e ERD. It can then send any packet that passes through it through any path =
that it has specified.
>>>      [SLI] Security considerations may have to be addressed in the
>>> charter , especially for the interAS case (trust yes, but not sure
>>> access to everything may not be good)
>>>
>>> Downstream routers within the ERD forward the packet as specified by th=
e router at the head-end of the path.
>>> [SLI] Yes, but any router in the middle may be able to change the end t=
o end explicit path.
>>>
>>>
>>>
>>> - The first goal of the STER WG is to identify use-cases for ERDs.
>>> - Having identified use-cases, the WG will identify gaps between curren=
tly available technologies and use-case requirements.
>>> - The WG will then define requirements for extensions to existing proto=
cols or new protocols that address gaps that are identified.
>>>
>>> [SLI] Agree, I would add :
>>> - defining the architecture framework
>>> - analysing the security considerisations
>>>
>>>
>>> ---------
>>>
>>>
>>> Here would be my proposal to extend yours :
>>>
>>> A <named to be defined> domain contains a set of routers with the follo=
wing characteristics:
>>>
>>> - They form a connected network
>>> - They can forward traffic through any path within the network using
>>> shortest path, non shortest path or explicit path
>>> - They may provide other types of services than forwarding and they can=
 enforce service actions in the path.
>>> - They share a common trust model. In this model, any router within the=
 domain can specify a path between itself and any other router in the domai=
n. It may then send any packet that passes through it through any path that=
 it has specified and that is conform to the security rules. Downstream rou=
ters within the ERD forward the packet as specified by the router at the he=
ad-end of the path.
>>>
>>> The <name> working group is chartered for the following ordered list of=
 work items:
>>>
>>> - The first goal of the WG is to identify use-cases.
>>> - The WG will then define the architecture framework associated with th=
e security considerations. The architecture framework and security consider=
ations must address the relations between domains (interdomain).
>>> - Having identified use-cases, architecture and security, the WG will i=
dentify gaps between currently available technologies and use-case requirem=
ents.
>>> - The WG will then define requirements for extensions to existing proto=
cols or new protocols that address gaps that are identified.
>>> - The WG will first focus on the intra-domain forwarding definition.
>>>
>>> Protocol work may be carried out in this working group or in other work=
ing groups responsible for the protocols, in coordination with this WG, and=
 in agreement with the WG chairs and responsible ADs. However, no protocol =
work will be adopted by a working group to address the ERD use-cases until =
the requirements document motivating the protocol work has been sent to the=
 IESG for publication as an RFC.
>>>
>>> -----Message d'origine-----
>>> De : [email-masked] [mailto:[email-masked]] De la
>>> part de Hannes Gredler Envoy=E9 : mardi 3 septembre 2013 18:31 =C0 : Loa
>>> Andersson Cc : [email-masked] Objet : Re: [Status] Summary of
>>> STATUS BOF and the next steps
>>>
>>> good point - what about this charter proposal ?
>>>
>>> ---
>>>
>>> Stacked Tunnels for Explicit Routing (STER)
>>> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
>>>
>>> A explicit routing domain (ERD) contains a set of routers with the foll=
owing characteristics:
>>>
>>> - They form a connected network
>>> - They can forward traffic through the shortest paths or paths other
>>> than the shortest (the latter called explicitly routed paths, or
>>> explicit paths)
>>> - They share a common trust model. In this model, any router within the=
 ERD can specify an explicit path between itself and any other router in th=
e ERD. It can then send any packet that passes through it through any path =
that it has specified. Downstream routers within the ERD forward the packet=
 as specified by the router at the head-end of the path.
>>>
>>> The STER working group is chartered for the following ordered list of w=
ork items:
>>>
>>> - The first goal of the STER WG is to identify use-cases for ERDs.
>>> - Having identified use-cases, the WG will identify gaps between curren=
tly available technologies and use-case requirements.
>>> - The WG will then define requirements for extensions to existing proto=
cols or new protocols that address gaps that are identified.
>>>
>>> Protocol work may be carried out in this working group or in other work=
ing groups responsible for the protocols, in coordination with this WG, and=
 in agreement with the WG chairs and responsible ADs. However, no protocol =
work will be adopted by a working group to address the ERD use-cases until =
the requirements document motivating the protocol work has been sent to the=
 IESG for publication as an RFC.
>>>
>>> ---
>>>
>>> <flame suit on>
>>>
>>> /hannes
>>>
>>>
>>> On Sep 3, 2013, at 5:31 PM, Loa Andersson wrote:
>>>
>>>> Folks,
>>>>
>>>> Excuse me if I'm slightly out of the loop, but so far I have not
>>>> seen a charter proposal, if there is one please point me to it.
>>>>
>>>> It seems a bit odd to put the cart (what the wg should do) before
>>>> the horse (wg name). If we drill down the the charter first the wg
>>>> name might be easier to figure out.
>>>>
>>>> /Loa
>>>>
>>>> PS
>>>> OK I understand that the horse and cart analogy limps a  bit :).
>>>>
>>>>
>>>>
>>>> On 2013-09-03 17:22, AshwoodsmithPeter wrote:
>>>>> " If the WG charter is limited to source routing, how will we handle =
the "non source routing" use cases of segment routing ? In another working =
group ? So we will go back to the WG synchronization issue that has been ra=
ised for this technology ..."
>>>>>
>>>>> That's why I suggested SRV2. We are revisiting source routing with ne=
w concepts. More generic number/action behavior.
>>>>>
>>>>> Peter
>>>>>
>>>>> -----Original Message-----
>>>>> From: [email-masked] [mailto:[email-masked]] On
>>>>> Behalf Of [email-masked]
>>>>> Sent: Tuesday, September 03, 2013 10:43 AM
>>>>> To: AshwoodsmithPeter
>>>>> Cc: [email-masked]
>>>>> Subject: Re: [Status] Summary of STATUS BOF and the next steps
>>>>>
>>>>>
>>>>> There was a misunderstanding in my small comment :) so I will explain=
 more :
>>>>>
>>>>> In segment routing, you have more than basic source routing : segment=
 routing is just associate a segment number to an action and then combine s=
egment as you want, yes you can do source routing, but you also can do more.
>>>>>
>>>>> In the other hand, I completely agree with your statement that
>>>>> source routing is generic and dataplane agnostic, as segment routing =
is ...
>>>>> (segment routing is not a new dataplane ...)
>>>>>
>>>>> Now the definition of the WG naming must be inline with the
>>>>> charter that will be defined ... (draft today)
>>>>>
>>>>> Based on the already existing consensus (at least for MPLS dataplane)=
 brought up during Berlin STATUS BOF meeting, segment routing sounds to be =
a good target candidate.
>>>>>
>>>>> So now, do we want to do more in the WG charter than just make progre=
ssing segment routing architecture and uses cases document and ensure coord=
ination for the standardization of this technology ?
>>>>>
>>>>> Do we want to standardize other technologies in this WG ? I don't thi=
nk so, based on Stewart's conclusion email from the BOF :"A new WG focused =
solely on SR therefore needs to be create"
>>>>>
>>>>> If the WG charter is limited to source routing, how will we handle th=
e "non source routing" use cases of segment routing ? In another working gr=
oup ? So we will go back to the WG synchronization issue that has been rais=
ed for this technology ...
>>>>>
>>>>> If the WG is focused on SR, let's use a name in relation with SR.
>>>>>
>>>>> Feedback ?
>>>>>
>>>>>
>>>>> Stephane
>>>>>
>>>>>
>>>>> -----Message d'origine-----
>>>>> De : AshwoodsmithPeter [mailto:[email-masked]]
>>>>> Envoy=E9 : mardi 3 septembre 2013 15:27 =C0 : LITKOWSKI Stephane
>>>>> DTF/DERX Cc : John E Drake; Mark Townsley; Victor Kuarsingh;
>>>>> Roberta Maglione (robmgl); John G. Scudder; Adrian Farrel; Alvaro
>>>>> Retana (aretana); [email-masked]; Stewart Bryant (stbryant) Objet : =
Re:
>>>>> [Status] Summary of STATUS BOF and the next steps
>>>>>
>>>>> The term "source routing" has been around for a very long time and is=
 data path agnostic. Its also the term used in the literature etc so my pre=
ference is to stick with this existing well known and data path agnostic te=
rm.
>>>>>
>>>>> Peter
>>>>>
>>>>> On Sep 3, 2013, at 9:07 AM, "[email-masked]" <stephane=
[email-masked]> wrote:
>>>>>
>>>>>> Hi,
>>>>>>
>>>>>> "Source routing" is just a subcase of segment routing ... as it is f=
or IP routing ...
>>>>>>
>>>>>> Stephane
>>>>>>
>>>>>>
>>>>>> -----Message d'origine-----
>>>>>> De : [email-masked] [mailto:[email-masked]] De
>>>>>> la part de John E Drake Envoy=E9 : mardi 3 septembre 2013 15:02 =C0 :
>>>>>> Mark Townsley; Victor Kuarsingh Cc : Roberta Maglione (robmgl); John=
 G.
>>>>>> Scudder; Alvaro Retana (aretana); Adrian Farrel; [email-masked];
>>>>>> Stewart Bryant (stbryant) Objet : Re: [Status] Summary of STATUS
>>>>>> BOF and the next steps
>>>>>>
>>>>>> Hi,
>>>>>>
>>>>>> What is this 'segment routing' silliness?  The correct term is 'sour=
ce routing'.
>>>>>>
>>>>>> Yours Irrespectively,
>>>>>>
>>>>>> John
>>>>>>
>>>>>>> -----Original Message-----
>>>>>>> From: [email-masked] [mailto:[email-masked]]
>>>>>>> On Behalf Of Mark Townsley
>>>>>>> Sent: Sunday, September 01, 2013 10:08 AM
>>>>>>> To: Victor Kuarsingh
>>>>>>> Cc: Roberta Maglione (robmgl); John G. Scudder; Adrian Farrel;
>>>>>>> Alvaro Retana (aretana); [email-masked]; Stewart Bryant
>>>>>>> (stbryant)
>>>>>>> Subject: Re: [Status] Summary of STATUS BOF and the next steps
>>>>>>>
>>>>>>>
>>>>>>> On Sep 1, 2013, at 5:38 PM, Victor Kuarsingh wrote:
>>>>>>>
>>>>>>>> All,
>>>>>>>>
>>>>>>>> I would also favour "Segment Routing WG" as well.
>>>>>>>>
>>>>>>>> I note this since attempting to come up with an all
>>>>>>>> encompassing acronym will be difficult and Segment Routing is
>>>>>>>> generic enough to associate to multiple functions.
>>>>>>>
>>>>>>> Then we can just use "segroute" for the short name. WGs do not
>>>>>>> have to have acronyms, but they do need to have an 8-char
>>>>>>> limited short name for the various automated tools not to break.
>>>>>>>
>>>>>>> - Mark
>>>>>>>
>>>>>>>>
>>>>>>>> Regards,
>>>>>>>>
>>>>>>>> Victor K
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> On 2013-08-31 6:51 PM, "Roberta Maglione (robmgl)"
>>>>>>>> <[email-masked]>
>>>>>>>> wrote:
>>>>>>>>
>>>>>>>>> +1 for Segment Routing WG
>>>>>>>>>
>>>>>>>>> Roberta
>>>>>>>>>
>>>>>>>>> Sent from my iPad
>>>>>>>>>
>>>>>>>>> On 2013-08-30, at 2:55 PM, "Alvaro Retana (aretana)"
>>>>>>>>> <[email-masked]>
>>>>>>>>> wrote:
>>>>>>>>>
>>>>>>>>>> Segment Routing WG
>>>>>>>>>>
>>>>>>>>>> Sent from my iPhone
>>>>>>>>>>
>>>>>>>>>> On Aug 30, 2013, at 1:39 PM, "Stewart Bryant (stbryant)"
>>>>>>>>>> <[email-masked]> wrote:
>>>>>>>>>>
>>>>>>>>>>> The second task, which hopefully should be relatively easy,
>>>>>>>>>>> is to find a better working name for the WG, since it has
>>>>>>>>>>> been put to me a number of times that STATUS is going to be
>>>>>>>>>>> confusing in text and a difficult search term.
>>>>>>>>>> _______________________________________________
>>>>>>>>>> status mailing list
>>>>>>>>>> [email-masked]
>>>>>>>>>> https://www.ietf.org/mailman/listinfo/status
>>>>>>>>> _______________________________________________
>>>>>>>>> status mailing list
>>>>>>>>> [email-masked]
>>>>>>>>> https://www.ietf.org/mailman/listinfo/status
>>>>>>>>
>>>>>>>>
>>>>>>>> _______________________________________________
>>>>>>>> status mailing list
>>>>>>>> [email-masked]
>>>>>>>> https://www.ietf.org/mailman/listinfo/status
>>>>>>>
>>>>>>> _______________________________________________
>>>>>>> status mailing list
>>>>>>> [email-masked]
>>>>>>> https://www.ietf.org/mailman/listinfo/status
>>>>>>
>>>>>>
>>>>>> _______________________________________________
>>>>>> status mailing list
>>>>>> [email-masked]
>>>>>> https://www.ietf.org/mailman/listinfo/status
>>>>>>
>>>>>> _________________________________________________________________
>>>>>> _ _ _ __ ___________________________________________________
>>>>>>
>>>>>> Ce message et ses pieces jointes peuvent contenir des
>>>>>> informations confidentielles ou privilegiees et ne doivent donc
>>>>>> pas etre diffuses, exploites ou copies sans autorisation. Si vous
>>>>>> avez recu ce message par erreur, veuillez le signaler a l'expediteur=
 et le detruire ainsi que les pieces jointes. Les messages electroniques et=
ant susceptibles d'alteration, Orange decline toute responsabilite si ce me=
ssage a ete altere, deforme ou falsifie. Merci.
>>>>>>
>>>>>> This message and its attachments may contain confidential or
>>>>>> privileged information that may be protected by law; they should not=
 be distributed, used or copied without authorisation.
>>>>>> If you have received this email in error, please notify the sender a=
nd delete this message and its attachments.
>>>>>> As emails may be altered, Orange is not liable for messages that hav=
e been modified, changed or falsified.
>>>>>> Thank you.
>>>>>>
>>>>>> _______________________________________________
>>>>>> status mailing list
>>>>>> [email-masked]
>>>>>> https://www.ietf.org/mailman/listinfo/status
>>>>>
>>>>> __________________________________________________________________
>>>>> _ _ _ ____________________________________________________
>>>>>
>>>>> Ce message et ses pieces jointes peuvent contenir des informations
>>>>> confidentielles ou privilegiees et ne doivent donc pas etre
>>>>> diffuses, exploites ou copies sans autorisation. Si vous avez recu
>>>>> ce message par erreur, veuillez le signaler a l'expediteur et le detr=
uire ainsi que les pieces jointes. Les messages electroniques etant suscept=
ibles d'alteration, Orange decline toute responsabilite si ce message a ete=
 altere, deforme ou falsifie. Merci.
>>>>>
>>>>> This message and its attachments may contain confidential or
>>>>> privileged information that may be protected by law; they should not =
be distributed, used or copied without authorisation.
>>>>> If you have received this email in error, please notify the sender an=
d delete this message and its attachments.
>>>>> As emails may be altered, Orange is not liable for messages that have=
 been modified, changed or falsified.
>>>>> Thank you.
>>>>>
>>>>> _______________________________________________
>>>>> status mailing list
>>>>> [email-masked]
>>>>> https://www.ietf.org/mailman/listinfo/status
>>>>> _______________________________________________
>>>>> status mailing list
>>>>> [email-masked]
>>>>> https://www.ietf.org/mailman/listinfo/status
>>>>>
>>>>
>>>> --
>>>>
>>>>
>>>> Loa Andersson                        email: [email-masked]
>>>> Senior MPLS Expert                          [email-masked]
>>>> Huawei Technologies (consultant)     phone: +46 739 81 21 64
>>>> _______________________________________________
>>>> status mailing list
>>>> [email-masked]
>>>> https://www.ietf.org/mailman/listinfo/status
>>>>
>>>>
>>>
>>>
>>> _______________________________________________
>>> status mailing list
>>> [email-masked]
>>> https://www.ietf.org/mailman/listinfo/status
>>>
>>> ____________________________________________________________________
>>> _ _ ___________________________________________________
>>>
>>> Ce message et ses pieces jointes peuvent contenir des informations
>>> confidentielles ou privilegiees et ne doivent donc pas etre
>>> diffuses, exploites ou copies sans autorisation. Si vous avez recu
>>> ce message par erreur, veuillez le signaler a l'expediteur et le detrui=
re ainsi que les pieces jointes. Les messages electroniques etant susceptib=
les d'alteration, Orange decline toute responsabilite si ce message a ete a=
ltere, deforme ou falsifie. Merci.
>>>
>>> This message and its attachments may contain confidential or
>>> privileged information that may be protected by law; they should not be=
 distributed, used or copied without authorisation.
>>> If you have received this email in error, please notify the sender and =
delete this message and its attachments.
>>> As emails may be altered, Orange is not liable for messages that have b=
een modified, changed or falsified.
>>> Thank you.
>>>
>>>
>>>
>>
>>
>>
>> _____________________________________________________________________
>> _ ___________________________________________________
>>
>> Ce message et ses pieces jointes peuvent contenir des informations
>> confidentielles ou privilegiees et ne doivent donc pas etre diffuses,
>> exploites ou copies sans autorisation. Si vous avez recu ce message
>> par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que=
 les pieces jointes. Les messages electroniques etant susceptibles d'altera=
tion, Orange decline toute responsabilite si ce message a ete altere, defor=
me ou falsifie. Merci.
>>
>> This message and its attachments may contain confidential or
>> privileged information that may be protected by law; they should not be =
distributed, used or copied without authorisation.
>> If you have received this email in error, please notify the sender and d=
elete this message and its attachments.
>> As emails may be altered, Orange is not liable for messages that have be=
en modified, changed or falsified.
>> Thank you.
>>
>> _______________________________________________
>> status mailing list
>> [email-masked]
>> https://www.ietf.org/mailman/listinfo/status
>
>
> ______________________________________________________________________
> ___________________________________________________
>
> Ce message et ses pieces jointes peuvent contenir des informations
> confidentielles ou privilegiees et ne doivent donc pas etre diffuses,
> exploites ou copies sans autorisation. Si vous avez recu ce message
> par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que =
les pieces jointes. Les messages electroniques etant susceptibles d'alterat=
ion, Orange decline toute responsabilite si ce message a ete altere, deform=
e ou falsifie. Merci.
>
> This message and its attachments may contain confidential or
> privileged information that may be protected by law; they should not be d=
istributed, used or copied without authorisation.
> If you have received this email in error, please notify the sender and de=
lete this message and its attachments.
> As emails may be altered, Orange is not liable for messages that have bee=
n modified, changed or falsified.
> Thank you.
>

___________________________________________________________________________=
______________________________________________

Ce message et ses pieces jointes peuvent contenir des informations confiden=
tielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu=
 ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages el=
ectroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou =
falsifie. Merci.

This message and its attachments may contain confidential or privileged inf=
ormation that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and dele=
te this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been =
modified, changed or falsified.
Thank you.

From: "Stefano Previdi (sprevidi)" <[email-masked]>
To: Stephane Litkowski <[email-masked]>, Rob Shakir <[email-masked]>
Date: Tue, 10 Sep 2013 10:30:03 +0000
Accept-Language: en-US
Cc: Hannes Gredler <[email-masked]>, "[email-masked]" <[email-masked]>
Subject: Re: [Status] Good charter proposals from Hannes and Stefano : try to merge ...

Hi Stephane, Rob,

one preliminary remark: I prefer to use he therm "node" rather=20
than "router". Use cases, such as Service Chaining requires that=20
terminology.

some other comments below...

On Sep 10, 2013, at 11:19 AM, <[email-masked]> wrote:
> Souns good to me, (adding OAM also)
>=20
> New recap :
>=20
> -------------------------------------------------------------------
> Name: <TBD>
> Charter:
>=20
>=20
> Introduction
> ------------
> The following use cases:
> . Path computation based on awareness of utilization or performance
>  data, within both centralized and distributed environments, . Multi-topo=
logy (dual planes, disjoint trees), . Simplification and reduction of signa=
ling components (scaling), . Combined application and network layer path sp=
ecification, . Full coverage LFA-FRR, . Topology Aware OAM, . etc.
>=20
> have triggered work on the definition of new architecture and protocol ex=
tensions allowing to combine well known shortest path based routing paradig=
ms with source/explicit routing methods. Some of these extensions have been=
 implemented already.
>=20
>=20
> Objective
> ---------
>=20
> Define an architecture where a node can steer a packet through a network =
or set of networks (interdomain) on any path.

[SP] As stated above, I'm fine with the above definition but I=20
     assume this includes service chaining and that by "network=20
     or set of networks" you intend "nodes" which may include=20
     others things than just routers.

    =20
> In this architecture, routers sharing a common trust model form a <Name-T=
BD> domain. The architecture defined by this working group will allow a nod=
e to steer a packet between any source and destination node within the <Nam=
e-TBD> domain (formed of one or more networks), on any path (shortest, non-=
shortest, explicit or based on other characteristics specified by segment i=
dentifiers).

[SP] without requiring to maintain state along the path, other=20
     than in the ingress node.

> It may then send any packet that passes through it through any path that =
it has specified and that is conform to the security rules. Downstream rout=
ers along the path within the <Name-TBD> domain forward the packet as speci=
fied by the router at the head-end of the path.

>=20
> The architecture should support centralized and distributed path computat=
ion.
>=20
> The architecture should support OAM functions.

[SP] The architecture should allow different mechanisms through which=20
     a path is constructed. SR allows a variety of mechanisms, not=20
     confined IGP/BGP path computation.

> Work items :
> ------------------
>=20
> The <Name-TBD> working group is chartered for the following ordered list =
of work items:
>=20
> - The first goal of the WG is to identify use-cases.
> - The WG will then define the architecture framework associated with
>  the security considerations. The architecture framework and security
>  considerations must address the relations between networks forming the <=
Name-TBD> domain (interAS).
> - Having identified use-cases, architecture and security, the WG will
>  identify gaps between currently available technologies and use-case
>  requirements.
> - The WG will then define requirements for extensions to existing
>  protocols or new protocols that address gaps that are identified.
> - The WG will first focus on the intra-domain forwarding definition.

[SP] The architecture will support tunnel and non-tunnel paradigms
     The architecture will support multiple dataplanes: MPLS and V6=09
    =20

Thanks.
s.

> Documents :
> ------------------
> . Use Cases
> . Architecture including security considerations
> - Protocol extension requirements
> . Interoperability Report
>=20
>=20
> Protocol work may be carried out in this working group or in other workin=
g groups responsible for the protocols (ISIS,OSPF,BGP,PCEP ...), in coordin=
ation with this WG, and in agreement with the WG chairs and responsible ADs=
.
>=20
> -----Message d'origine-----
> De : Rob Shakir [mailto:[email-masked]]
> Envoy=E9 : mardi 10 septembre 2013 11:05
> =C0 : LITKOWSKI Stephane DTF/DERX
> Cc : Hannes Gredler; Stefano Previdi (sprevidi); [email-masked]
> Objet : Re: [Status] Good charter proposals from Hannes and Stefano : try=
 to merge ...
>=20
> Hi Stephane,
>=20
> Thanks for this, looks good! Comments in-line marked rjs>.
>=20
> On 10 Sep 2013, at 08:50, <[email-masked]> wrote:
>=20
>> Hi all,
>>=20
>> I'm creating a new mail topic because the "Summary of STATUS BOF ..."
>> starts to be unreadable :)
>>=20
>> Hannes and Stefano send to us two charter proposals that sounds good to =
me.
>>=20
>> The main difference between the two proposals is that Stefano propose a =
segment bound to any type of instruction (forwarding, application or servic=
e based) while Hannes is focusing on forwarding actions (which is the first=
 priority, and I think everybody agree on this).
>=20
> rjs> Agreed -- I think it would be useful to allow definitions of segment=
s to identify different types of "service", since there appear to be some u=
se cases (e.g., the explicit exit selection case) which require a segment t=
ype describing something that is not explicitly IGP-based.
>=20
>>=20
>> It would be interresting to have a feedback from the mailinglist on this=
 specific point.
>>=20
>> IMHO, there is a strong interrest to explore the service actions bound t=
o segment in a second step keeping forwarding as a priority.
>>=20
>> Apart of this problem, here is a merge try of the two good proposals (I'=
m putting '<>' on hot topics :) ) :
>>=20
>>=20
>> -------------------------------------------------------------------
>> Name: <TBD>
>> Charter:
>>=20
>>=20
>> Introduction
>> ------------
>> The following use cases:
>> . Path computation based on awareness of utilization or performance
>> data, within both centralized and distributed environments, . Multi-topo=
logy (dual planes, disjoint trees), . Simplification and reduction of signa=
ling components (scaling), . Combined application and network layer path sp=
ecification, . Full coverage LFA-FRR, . Topology Aware OAM, . etc.
>>=20
>> have triggered work on the definition of new architecture and protocol e=
xtensions allowing to combine well known shortest path based routing paradi=
gms with source/explicit routing methods. Some of these extensions have bee=
n implemented already.
>>=20
>>=20
>> Objective
>> ---------
>>=20
>> Define an architecture where a node can steer a packet through a network=
 or set of networks (interdomain) on any path (shortest, non shortest, expl=
icit, <service or application>).
>>=20
>> In this architecture, routers are sharing a common trust model and are f=
orming a <Name-TBD> domain.
>> Within this domain, a node can specify a path between itself and any des=
tination in the domain. <The path may be a forwarding path, a service chain=
ing path or a combination of both>.
>=20
> rjs> To clarify here, we define that our domain is under a common trust m=
odel (essentially, under common administrative control?), but then go on to=
 talk about inter-domain elsewhere. Can we perhaps clarify (by defining a s=
pecific "<Name-TBD> domain" nomenclature) and say something like:
>=20
> "In this architecture, routers sharing a common trust model form a <Name-=
TBD> domain. The architecture defined by this working group will allow a no=
de to steer a packet between any source and destination node within the <Na=
me-TBD> domain (formed of one or more networks), on any path (shortest, non=
-shortest, explicit or based on other characteristics specified by segment =
identifiers)."
>=20
>> It may then send any packet that passes through it through any path that=
 it has specified and that is conform to the security rules. Downstream rou=
ters along the path within the <Name-TBD> domain forward the packet as spec=
ified by the router at the head-end of the path.
>>=20
>> The architecture should support centralized and distributed path computa=
tion.
>>=20
>>=20
>> Work items :
>> ------------------
>>=20
>> The <Name-TBD> working group is chartered for the following ordered list=
 of work items:
>>=20
>> - The first goal of the WG is to identify use-cases.
>> - The WG will then define the architecture framework associated with
>> the security considerations. The architecture framework and security
>> considerations must address the relations between domains (inter domain)=
.
>=20
> rjs> And then here "networks forming the <Name-TBD> domain"?
>=20
> Thanks for the efforts,
> r.
>=20
>> - Having identified use-cases, architecture and security, the WG will
>> identify gaps between currently available technologies and use-case
>> requirements.
>> - The WG will then define requirements for extensions to existing
>> protocols or new protocols that address gaps that are identified.
>> - The WG will first focus on the intra-domain forwarding definition.
>>=20
>>=20
>> Documents :
>> ------------------
>> . Use Cases
>> . Architecture including security considerations
>> - Protocol extension requirements
>> . Interoperability Report
>>=20
>>=20
>> Protocol work may be carried out in this working group or in other worki=
ng groups responsible for the protocols (ISIS,OSPF,BGP,PCEP ...), in coordi=
nation with this WG, and in agreement with the WG chairs and responsible AD=
s.
>>=20
>>=20
>>=20
>> Hope it helps to progress on the definition.
>>=20
>>=20
>> Stephane
>>=20
>>=20
>> -----Message d'origine-----
>> De : Hannes Gredler [mailto:[email-masked]] Envoy=E9 : vendredi 6
>> septembre 2013 18:27 =C0 : LITKOWSKI Stephane DTF/DERX Cc :
>> [email-masked] Objet : Re: [Status] Summary of STATUS BOF and the
>> next steps
>>=20
>> hi stephane,
>>=20
>> here is a revised draft charter as per your comments.
>>=20
>> ---
>>=20
>> <Name-TBD> domain contains a set of routers with the following
>> characteristics:
>>=20
>> - They form a connected network
>> - They can forward traffic through any path within the network using
>> shortest path, or any other (e.g., an explicit) path
>> - They share a common trust model. In this model, any router within
>> the domain can specify a path between itself and any other router  in
>> the domain. It may then send any packet that passes through it
>> through any path that it has specified and that is conform to the
>> security rules. Downstream routers along the path within the
>> <Name-TBD>  domain forward the packet as specified by the router at
>> the head-end  of the path.
>>=20
>> The <Name-TBD> working group is chartered for the following ordered list=
 of work items:
>>=20
>> - The first goal of the WG is to identify use-cases.
>> - The WG will then define the architecture framework associated with
>> the security considerations. The architecture framework and security
>> considerations must address the relations between domains (interdomain).
>> - Having identified use-cases, architecture and security, the WG will
>> identify gaps between currently available technologies and use-case
>> requirements.
>> - The WG will then define requirements for extensions to existing
>> protocols or new protocols that address gaps that are identified.
>> - The WG will first focus on the intra-domain forwarding definition.
>>=20
>> Protocol work may be carried out in this working group or in other worki=
ng groups responsible for the protocols, in coordination with this WG, and =
in agreement with the WG chairs and responsible ADs.
>> However, no protocol work will be adopted by a working group to address =
the identified use-cases until the requirements document motivating the pro=
tocol work has been sent to the IESG for publication as an RFC.
>>=20
>> ---
>>=20
>> /hannes
>>=20
>> On Sep 4, 2013, at 10:02 AM, <[email-masked]> <stephane.l=
[email-masked]> wrote:
>>=20
>>> Hannes,
>>>=20
>>> In case, we are using only directed forwarding (adjacency segment),
>>> could we still talk about tunneling ? (it's a very very small tunnel) M=
oreover talking about "stacking" is really dataplane agnostic (MPLS) ...
>>>=20
>>> In the proposed segment routing architectural concepts, segments are at=
 the same "level" and pointer moves on the segment list, then the MPLS inst=
antiation is performing this using stacking ...
>>>=20
>>> IMHO, if we use "Stacked Tunnels", we already talk about a chosen solut=
ion and it's closing the door to something else  ...
>>>=20
>>> Finally, about the "routing" word, routing is essentially a "forward" a=
ction which may limit the scope of what we can do by using a segment list. =
Actions associated with a segment could be something else than forwarding.
>>>=20
>>> Do we want in the charter to limit the scope to routing actions ?
>>>=20
>>> I have no solution today to propose for the naming, but I completely ag=
ree with Loa, to first focus on working on the charter, and define a clear =
scope of the work and then the name will be easier to find.
>>>=20
>>> Regarding your charter proposal :
>>>=20
>>> --------
>>>=20
>>> - They form a connected network
>>>      [SLI] InterAS case must be included, but the WG can go step by ste=
p and first release intraAS, and then doing interAS (in relation with IDR ?=
?).
>>>=20
>>> - They can forward traffic through the shortest paths or paths other th=
an the shortest (the latter called explicitly routed paths, or explicit pat=
hs)
>>>      [SLI] There is something else between SPT and Explicit path, you c=
an define other algorithms than SPT to define a path, and it's not explicit=
 path. Moreover I come back to my comment, on do we want to limit the scope=
 to routing ? I would say no.
>>>=20
>>> - They share a common trust model. In this model, any router within the=
 ERD can specify an explicit path between itself and any other router in th=
e ERD. It can then send any packet that passes through it through any path =
that it has specified.
>>>      [SLI] Security considerations may have to be addressed in the
>>> charter , especially for the interAS case (trust yes, but not sure
>>> access to everything may not be good)
>>>=20
>>> Downstream routers within the ERD forward the packet as specified by th=
e router at the head-end of the path.
>>> [SLI] Yes, but any router in the middle may be able to change the end t=
o end explicit path.
>>>=20
>>>=20
>>>=20
>>> - The first goal of the STER WG is to identify use-cases for ERDs.
>>> - Having identified use-cases, the WG will identify gaps between curren=
tly available technologies and use-case requirements.
>>> - The WG will then define requirements for extensions to existing proto=
cols or new protocols that address gaps that are identified.
>>>=20
>>> [SLI] Agree, I would add :
>>> - defining the architecture framework
>>> - analysing the security considerisations
>>>=20
>>>=20
>>> ---------
>>>=20
>>>=20
>>> Here would be my proposal to extend yours :
>>>=20
>>> A <named to be defined> domain contains a set of routers with the follo=
wing characteristics:
>>>=20
>>> - They form a connected network
>>> - They can forward traffic through any path within the network using
>>> shortest path, non shortest path or explicit path
>>> - They may provide other types of services than forwarding and they can=
 enforce service actions in the path.
>>> - They share a common trust model. In this model, any router within the=
 domain can specify a path between itself and any other router in the domai=
n. It may then send any packet that passes through it through any path that=
 it has specified and that is conform to the security rules. Downstream rou=
ters within the ERD forward the packet as specified by the router at the he=
ad-end of the path.
>>>=20
>>> The <name> working group is chartered for the following ordered list of=
 work items:
>>>=20
>>> - The first goal of the WG is to identify use-cases.
>>> - The WG will then define the architecture framework associated with th=
e security considerations. The architecture framework and security consider=
ations must address the relations between domains (interdomain).
>>> - Having identified use-cases, architecture and security, the WG will i=
dentify gaps between currently available technologies and use-case requirem=
ents.
>>> - The WG will then define requirements for extensions to existing proto=
cols or new protocols that address gaps that are identified.
>>> - The WG will first focus on the intra-domain forwarding definition.
>>>=20
>>> Protocol work may be carried out in this working group or in other work=
ing groups responsible for the protocols, in coordination with this WG, and=
 in agreement with the WG chairs and responsible ADs. However, no protocol =
work will be adopted by a working group to address the ERD use-cases until =
the requirements document motivating the protocol work has been sent to the=
 IESG for publication as an RFC.
>>>=20
>>> -----Message d'origine-----
>>> De : [email-masked] [mailto:[email-masked]] De la
>>> part de Hannes Gredler Envoy=E9 : mardi 3 septembre 2013 18:31 =C0 : Lo=
a
>>> Andersson Cc : [email-masked] Objet : Re: [Status] Summary of STATUS
>>> BOF and the next steps
>>>=20
>>> good point - what about this charter proposal ?
>>>=20
>>> ---
>>>=20
>>> Stacked Tunnels for Explicit Routing (STER)
>>> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
>>>=20
>>> A explicit routing domain (ERD) contains a set of routers with the foll=
owing characteristics:
>>>=20
>>> - They form a connected network
>>> - They can forward traffic through the shortest paths or paths other
>>> than the shortest (the latter called explicitly routed paths, or
>>> explicit paths)
>>> - They share a common trust model. In this model, any router within the=
 ERD can specify an explicit path between itself and any other router in th=
e ERD. It can then send any packet that passes through it through any path =
that it has specified. Downstream routers within the ERD forward the packet=
 as specified by the router at the head-end of the path.
>>>=20
>>> The STER working group is chartered for the following ordered list of w=
ork items:
>>>=20
>>> - The first goal of the STER WG is to identify use-cases for ERDs.
>>> - Having identified use-cases, the WG will identify gaps between curren=
tly available technologies and use-case requirements.
>>> - The WG will then define requirements for extensions to existing proto=
cols or new protocols that address gaps that are identified.
>>>=20
>>> Protocol work may be carried out in this working group or in other work=
ing groups responsible for the protocols, in coordination with this WG, and=
 in agreement with the WG chairs and responsible ADs. However, no protocol =
work will be adopted by a working group to address the ERD use-cases until =
the requirements document motivating the protocol work has been sent to the=
 IESG for publication as an RFC.
>>>=20
>>> ---
>>>=20
>>> <flame suit on>
>>>=20
>>> /hannes
>>>=20
>>>=20
>>> On Sep 3, 2013, at 5:31 PM, Loa Andersson wrote:
>>>=20
>>>> Folks,
>>>>=20
>>>> Excuse me if I'm slightly out of the loop, but so far I have not
>>>> seen a charter proposal, if there is one please point me to it.
>>>>=20
>>>> It seems a bit odd to put the cart (what the wg should do) before
>>>> the horse (wg name). If we drill down the the charter first the wg
>>>> name might be easier to figure out.
>>>>=20
>>>> /Loa
>>>>=20
>>>> PS
>>>> OK I understand that the horse and cart analogy limps a  bit :).
>>>>=20
>>>>=20
>>>>=20
>>>> On 2013-09-03 17:22, AshwoodsmithPeter wrote:
>>>>> " If the WG charter is limited to source routing, how will we handle =
the "non source routing" use cases of segment routing ? In another working =
group ? So we will go back to the WG synchronization issue that has been ra=
ised for this technology ..."
>>>>>=20
>>>>> That's why I suggested SRV2. We are revisiting source routing with ne=
w concepts. More generic number/action behavior.
>>>>>=20
>>>>> Peter
>>>>>=20
>>>>> -----Original Message-----
>>>>> From: [email-masked] [mailto:[email-masked]] On
>>>>> Behalf Of [email-masked]
>>>>> Sent: Tuesday, September 03, 2013 10:43 AM
>>>>> To: AshwoodsmithPeter
>>>>> Cc: [email-masked]
>>>>> Subject: Re: [Status] Summary of STATUS BOF and the next steps
>>>>>=20
>>>>>=20
>>>>> There was a misunderstanding in my small comment :) so I will explain=
 more :
>>>>>=20
>>>>> In segment routing, you have more than basic source routing : segment=
 routing is just associate a segment number to an action and then combine s=
egment as you want, yes you can do source routing, but you also can do more=
.
>>>>>=20
>>>>> In the other hand, I completely agree with your statement that
>>>>> source routing is generic and dataplane agnostic, as segment routing =
is ...
>>>>> (segment routing is not a new dataplane ...)
>>>>>=20
>>>>> Now the definition of the WG naming must be inline with the charter
>>>>> that will be defined ... (draft today)
>>>>>=20
>>>>> Based on the already existing consensus (at least for MPLS dataplane)=
 brought up during Berlin STATUS BOF meeting, segment routing sounds to be =
a good target candidate.
>>>>>=20
>>>>> So now, do we want to do more in the WG charter than just make progre=
ssing segment routing architecture and uses cases document and ensure coord=
ination for the standardization of this technology ?
>>>>>=20
>>>>> Do we want to standardize other technologies in this WG ? I don't thi=
nk so, based on Stewart's conclusion email from the BOF :"A new WG focused =
solely on SR therefore needs to be create"
>>>>>=20
>>>>> If the WG charter is limited to source routing, how will we handle th=
e "non source routing" use cases of segment routing ? In another working gr=
oup ? So we will go back to the WG synchronization issue that has been rais=
ed for this technology ...
>>>>>=20
>>>>> If the WG is focused on SR, let's use a name in relation with SR.
>>>>>=20
>>>>> Feedback ?
>>>>>=20
>>>>>=20
>>>>> Stephane
>>>>>=20
>>>>>=20
>>>>> -----Message d'origine-----
>>>>> De : AshwoodsmithPeter [mailto:[email-masked]]
>>>>> Envoy=E9 : mardi 3 septembre 2013 15:27 =C0 : LITKOWSKI Stephane
>>>>> DTF/DERX Cc : John E Drake; Mark Townsley; Victor Kuarsingh;
>>>>> Roberta Maglione (robmgl); John G. Scudder; Adrian Farrel; Alvaro
>>>>> Retana (aretana); [email-masked]; Stewart Bryant (stbryant) Objet : =
Re:
>>>>> [Status] Summary of STATUS BOF and the next steps
>>>>>=20
>>>>> The term "source routing" has been around for a very long time and is=
 data path agnostic. Its also the term used in the literature etc so my pre=
ference is to stick with this existing well known and data path agnostic te=
rm.
>>>>>=20
>>>>> Peter
>>>>>=20
>>>>> On Sep 3, 2013, at 9:07 AM, "[email-masked]" <stephane=
[email-masked]> wrote:
>>>>>=20
>>>>>> Hi,
>>>>>>=20
>>>>>> "Source routing" is just a subcase of segment routing ... as it is f=
or IP routing ...
>>>>>>=20
>>>>>> Stephane
>>>>>>=20
>>>>>>=20
>>>>>> -----Message d'origine-----
>>>>>> De : [email-masked] [mailto:[email-masked]] De
>>>>>> la part de John E Drake Envoy=E9 : mardi 3 septembre 2013 15:02 =C0 =
:
>>>>>> Mark Townsley; Victor Kuarsingh Cc : Roberta Maglione (robmgl); John=
 G.
>>>>>> Scudder; Alvaro Retana (aretana); Adrian Farrel; [email-masked];
>>>>>> Stewart Bryant (stbryant) Objet : Re: [Status] Summary of STATUS
>>>>>> BOF and the next steps
>>>>>>=20
>>>>>> Hi,
>>>>>>=20
>>>>>> What is this 'segment routing' silliness?  The correct term is 'sour=
ce routing'.
>>>>>>=20
>>>>>> Yours Irrespectively,
>>>>>>=20
>>>>>> John
>>>>>>=20
>>>>>>> -----Original Message-----
>>>>>>> From: [email-masked] [mailto:[email-masked]] On
>>>>>>> Behalf Of Mark Townsley
>>>>>>> Sent: Sunday, September 01, 2013 10:08 AM
>>>>>>> To: Victor Kuarsingh
>>>>>>> Cc: Roberta Maglione (robmgl); John G. Scudder; Adrian Farrel;
>>>>>>> Alvaro Retana (aretana); [email-masked]; Stewart Bryant
>>>>>>> (stbryant)
>>>>>>> Subject: Re: [Status] Summary of STATUS BOF and the next steps
>>>>>>>=20
>>>>>>>=20
>>>>>>> On Sep 1, 2013, at 5:38 PM, Victor Kuarsingh wrote:
>>>>>>>=20
>>>>>>>> All,
>>>>>>>>=20
>>>>>>>> I would also favour "Segment Routing WG" as well.
>>>>>>>>=20
>>>>>>>> I note this since attempting to come up with an all encompassing
>>>>>>>> acronym will be difficult and Segment Routing is generic enough
>>>>>>>> to associate to multiple functions.
>>>>>>>=20
>>>>>>> Then we can just use "segroute" for the short name. WGs do not
>>>>>>> have to have acronyms, but they do need to have an 8-char limited
>>>>>>> short name for the various automated tools not to break.
>>>>>>>=20
>>>>>>> - Mark
>>>>>>>=20
>>>>>>>>=20
>>>>>>>> Regards,
>>>>>>>>=20
>>>>>>>> Victor K
>>>>>>>>=20
>>>>>>>>=20
>>>>>>>>=20
>>>>>>>> On 2013-08-31 6:51 PM, "Roberta Maglione (robmgl)"
>>>>>>>> <[email-masked]>
>>>>>>>> wrote:
>>>>>>>>=20
>>>>>>>>> +1 for Segment Routing WG
>>>>>>>>>=20
>>>>>>>>> Roberta
>>>>>>>>>=20
>>>>>>>>> Sent from my iPad
>>>>>>>>>=20
>>>>>>>>> On 2013-08-30, at 2:55 PM, "Alvaro Retana (aretana)"
>>>>>>>>> <[email-masked]>
>>>>>>>>> wrote:
>>>>>>>>>=20
>>>>>>>>>> Segment Routing WG
>>>>>>>>>>=20
>>>>>>>>>> Sent from my iPhone
>>>>>>>>>>=20
>>>>>>>>>> On Aug 30, 2013, at 1:39 PM, "Stewart Bryant (stbryant)"
>>>>>>>>>> <[email-masked]> wrote:
>>>>>>>>>>=20
>>>>>>>>>>> The second task, which hopefully should be relatively easy,
>>>>>>>>>>> is to find a better working name for the WG, since it has
>>>>>>>>>>> been put to me a number of times that STATUS is going to be
>>>>>>>>>>> confusing in text and a difficult search term.
>>>>>>>>>> _______________________________________________
>>>>>>>>>> status mailing list
>>>>>>>>>> [email-masked]
>>>>>>>>>> https://www.ietf.org/mailman/listinfo/status
>>>>>>>>> _______________________________________________
>>>>>>>>> status mailing list
>>>>>>>>> [email-masked]
>>>>>>>>> https://www.ietf.org/mailman/listinfo/status
>>>>>>>>=20
>>>>>>>>=20
>>>>>>>> _______________________________________________
>>>>>>>> status mailing list
>>>>>>>> [email-masked]
>>>>>>>> https://www.ietf.org/mailman/listinfo/status
>>>>>>>=20
>>>>>>> _______________________________________________
>>>>>>> status mailing list
>>>>>>> [email-masked]
>>>>>>> https://www.ietf.org/mailman/listinfo/status
>>>>>>=20
>>>>>>=20
>>>>>> _______________________________________________
>>>>>> status mailing list
>>>>>> [email-masked]
>>>>>> https://www.ietf.org/mailman/listinfo/status
>>>>>>=20
>>>>>> __________________________________________________________________
>>>>>> _ _ __ ___________________________________________________
>>>>>>=20
>>>>>> Ce message et ses pieces jointes peuvent contenir des informations
>>>>>> confidentielles ou privilegiees et ne doivent donc pas etre
>>>>>> diffuses, exploites ou copies sans autorisation. Si vous avez recu
>>>>>> ce message par erreur, veuillez le signaler a l'expediteur et le det=
ruire ainsi que les pieces jointes. Les messages electroniques etant suscep=
tibles d'alteration, Orange decline toute responsabilite si ce message a et=
e altere, deforme ou falsifie. Merci.
>>>>>>=20
>>>>>> This message and its attachments may contain confidential or
>>>>>> privileged information that may be protected by law; they should not=
 be distributed, used or copied without authorisation.
>>>>>> If you have received this email in error, please notify the sender a=
nd delete this message and its attachments.
>>>>>> As emails may be altered, Orange is not liable for messages that hav=
e been modified, changed or falsified.
>>>>>> Thank you.
>>>>>>=20
>>>>>> _______________________________________________
>>>>>> status mailing list
>>>>>> [email-masked]
>>>>>> https://www.ietf.org/mailman/listinfo/status
>>>>>=20
>>>>> ___________________________________________________________________
>>>>> _ _ ____________________________________________________
>>>>>=20
>>>>> Ce message et ses pieces jointes peuvent contenir des informations
>>>>> confidentielles ou privilegiees et ne doivent donc pas etre
>>>>> diffuses, exploites ou copies sans autorisation. Si vous avez recu
>>>>> ce message par erreur, veuillez le signaler a l'expediteur et le detr=
uire ainsi que les pieces jointes. Les messages electroniques etant suscept=
ibles d'alteration, Orange decline toute responsabilite si ce message a ete=
 altere, deforme ou falsifie. Merci.
>>>>>=20
>>>>> This message and its attachments may contain confidential or
>>>>> privileged information that may be protected by law; they should not =
be distributed, used or copied without authorisation.
>>>>> If you have received this email in error, please notify the sender an=
d delete this message and its attachments.
>>>>> As emails may be altered, Orange is not liable for messages that have=
 been modified, changed or falsified.
>>>>> Thank you.
>>>>>=20
>>>>> _______________________________________________
>>>>> status mailing list
>>>>> [email-masked]
>>>>> https://www.ietf.org/mailman/listinfo/status
>>>>> _______________________________________________
>>>>> status mailing list
>>>>> [email-masked]
>>>>> https://www.ietf.org/mailman/listinfo/status
>>>>>=20
>>>>=20
>>>> --
>>>>=20
>>>>=20
>>>> Loa Andersson                        email: [email-masked]
>>>> Senior MPLS Expert                          [email-masked]
>>>> Huawei Technologies (consultant)     phone: +46 739 81 21 64
>>>> _______________________________________________
>>>> status mailing list
>>>> [email-masked]
>>>> https://www.ietf.org/mailman/listinfo/status
>>>>=20
>>>>=20
>>>=20
>>>=20
>>> _______________________________________________
>>> status mailing list
>>> [email-masked]
>>> https://www.ietf.org/mailman/listinfo/status
>>>=20
>>> _____________________________________________________________________
>>> _ ___________________________________________________
>>>=20
>>> Ce message et ses pieces jointes peuvent contenir des informations
>>> confidentielles ou privilegiees et ne doivent donc pas etre diffuses,
>>> exploites ou copies sans autorisation. Si vous avez recu ce message
>>> par erreur, veuillez le signaler a l'expediteur et le detruire ainsi qu=
e les pieces jointes. Les messages electroniques etant susceptibles d'alter=
ation, Orange decline toute responsabilite si ce message a ete altere, defo=
rme ou falsifie. Merci.
>>>=20
>>> This message and its attachments may contain confidential or
>>> privileged information that may be protected by law; they should not be=
 distributed, used or copied without authorisation.
>>> If you have received this email in error, please notify the sender and =
delete this message and its attachments.
>>> As emails may be altered, Orange is not liable for messages that have b=
een modified, changed or falsified.
>>> Thank you.
>>>=20
>>>=20
>>>=20
>>=20
>>=20
>>=20
>> ______________________________________________________________________
>> ___________________________________________________
>>=20
>> Ce message et ses pieces jointes peuvent contenir des informations
>> confidentielles ou privilegiees et ne doivent donc pas etre diffuses,
>> exploites ou copies sans autorisation. Si vous avez recu ce message
>> par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que=
 les pieces jointes. Les messages electroniques etant susceptibles d'altera=
tion, Orange decline toute responsabilite si ce message a ete altere, defor=
me ou falsifie. Merci.
>>=20
>> This message and its attachments may contain confidential or
>> privileged information that may be protected by law; they should not be =
distributed, used or copied without authorisation.
>> If you have received this email in error, please notify the sender and d=
elete this message and its attachments.
>> As emails may be altered, Orange is not liable for messages that have be=
en modified, changed or falsified.
>> Thank you.
>>=20
>> _______________________________________________
>> status mailing list
>> [email-masked]
>> https://www.ietf.org/mailman/listinfo/status
>=20
>=20
> _________________________________________________________________________=
________________________________________________
>=20
> Ce message et ses pieces jointes peuvent contenir des informations confid=
entielles ou privilegiees et ne doivent donc
> pas etre diffuses, exploites ou copies sans autorisation. Si vous avez re=
cu ce message par erreur, veuillez le signaler
> a l'expediteur et le detruire ainsi que les pieces jointes. Les messages =
electroniques etant susceptibles d'alteration,
> Orange decline toute responsabilite si ce message a ete altere, deforme o=
u falsifie. Merci.
>=20
> This message and its attachments may contain confidential or privileged i=
nformation that may be protected by law;
> they should not be distributed, used or copied without authorisation.
> If you have received this email in error, please notify the sender and de=
lete this message and its attachments.
> As emails may be altered, Orange is not liable for messages that have bee=
n modified, changed or falsified.
> Thank you.
>=20

From: <[email-masked]>
To: <[email-masked]>
Date: Tue, 10 Sep 2013 12:12:36 +0200
Accept-Language: en-US, de-DE
acceptlanguage: en-US, de-DE
Cc: [email-masked]
Subject: Re: [Status] Good charter proposals from Hannes and Stefano : try to merge ...

Hi Stephane,

allright, thanks.

Regards, Ruediger

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
Sent: Tuesday, September 10, 2013 12:04 PM
To: Geib, R=FCdiger
Cc: [email-masked]
Subject: RE: [Status] Good charter proposals from Hannes and Stefano : try =
to merge ...

 [RG] I'd appreciate if we were able to agree to avoid changes in the MPLS =
forwarding plane, at least in the first phase. That should be part of the c=
harter. We could re-charter, should this result in a deadlock later.

[SLI] Agree also

[RG] may be nit picking: to avoid the interpretation, that downstream route=
rs have to contact the head-end router to get specific routing
instructions.:
..forward the packet by the address stack inserted by the router at the hea=
d-end...

[SLI] Changed by :
 "forward the packet by using the informations inserted by the router at th=
e head-end"

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

Here is updated proposal :

-------------------------------------------------------------------
Name: <TBD>
Charter:

Introduction
------------
The following use cases:
. Path computation based on awareness of utilization or performance
  data, within both centralized and distributed environments, . Multi-topol=
ogy (dual planes, disjoint trees), . Simplification and reduction of signal=
ing components (scaling), . Combined application and network layer path spe=
cification, . Full coverage LFA-FRR, . Topology Aware OAM, . etc.

have triggered work on the definition of new architecture and protocol exte=
nsions allowing to combine well known shortest path based routing paradigms=
 with source/explicit routing methods. Some of these extensions have been i=
mplemented already.

Objective
---------

Define an architecture where a node can steer a packet through a network or=
 set of networks (interdomain) on any path.

In this architecture, routers sharing a common trust model form a <Name-TBD=
> domain. The architecture defined by this working group will allow a node =
to steer a packet between any source and destination node within the <Name-=
TBD> domain (formed of one or more networks), on any path (shortest, non-sh=
ortest, explicit or based on other characteristics specified by segment ide=
ntifiers).

It may then send any packet that passes through it through any path that it=
 has specified and that is conform to the security rules. Downstream router=
s along the path within the <Name-TBD> domain forward the packet by using t=
he informations inserted by the router at the head-end

The architecture should support centralized and distributed path computatio=
n.

The architecture should support OAM functions.

As MPLS dataplane is largely deployed, the <Name-TBD> WG should avoid any m=
odification in the MPLS dataplane when defining the architecture.

Work items :
------------------

The <Name-TBD> working group is chartered for the following ordered list of=
 work items:

- The first goal of the WG is to identify use-cases.
- The WG will then define the architecture framework associated with
  the security considerations. The architecture framework and security
  considerations must address the relations between networks forming the <N=
ame-TBD> domain (interAS).
- Having identified use-cases, architecture and security, the WG will
  identify gaps between currently available technologies and use-case
  requirements.
- The WG will then define requirements for extensions to existing
  protocols or new protocols that address gaps that are identified.
- The WG will first focus on the intra-domain forwarding definition.

Documents :
------------------
. Use Cases
. Architecture including security considerations
- Protocol extension requirements
. Interoperability Report

Required protocol extensions are carried out in working groups responsible =
(ISIS,OSPF,BGP,PCEP ...). Work on new protocols may be carried out by the <=
Name-TBD> WG.

-----Message d'origine-----
De : [email-masked] [mailto:[email-masked]]
Envoy=E9 : mardi 10 septembre 2013 11:49
=C0 : LITKOWSKI Stephane DTF/DERX
Cc : [email-masked]
Objet : RE: [Status] Good charter proposals from Hannes and Stefano : try t=
o merge ...

Hi Stephane,

thanks for your proposal. Three remarks marked [RG] in line.

Regards,

Ruediger

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of=
 [email-masked]
Sent: Tuesday, September 10, 2013 11:19 AM
To: Rob Shakir
Cc: Hannes Gredler; [email-masked]; Stefano Previdi (sprevidi)
Subject: Re: [Status] Good charter proposals from Hannes and Stefano : try =
to merge ...

Souns good to me, (adding OAM also)

New recap :

-------------------------------------------------------------------
Name: <TBD>
Charter:

  Introduction
  ------------
  The following use cases:
  . Path computation based on awareness of utilization or performance
    data, within both centralized and distributed environments,
  . Multi-topology (dual planes, disjoint trees),
  . Simplification and reduction of signaling components (scaling),
  . Combined application and network layer path specification,
  . Full coverage LFA-FRR,
  . Topology Aware OAM,
  . etc.

  have triggered work on the definition of new architecture and
  protocol extensions allowing to combine well known shortest path
  based routing paradigms with source/explicit routing methods.
  Some of these extensions have been implemented already.

  Objective
  ---------

  Define an architecture where a node can steer a packet through a
  network or set of networks (interdomain) on any path.

  In this architecture, routers sharing a common trust model form
  a <Name-TBD> domain. The architecture defined by this working
  group will allow a node to steer a packet between any source and
  destination node within the <Name-TBD> domain (formed of one or
  more networks), on any path (shortest, non-shortest, explicit
  or based on other characteristics specified by segment identifiers).

  It may then send any packet that passes through it through any
  path that it has specified and that is conform to the security
  rules. Downstream routers along the path within the <Name-TBD>
  domain forward the packet as specified by the router at the
  head-end of the path.

[RG] may be nit picking: to avoid the interpretation, that downstream route=
rs have to contact the head-end router to get specific routing
instructions.:
..forward the packet by the address stack inserted by the router at the hea=
d-end...

  The architecture should support centralized and distributed
  path computation.

  The architecture should support OAM functions.

  Work items :
  ------------------

  The <Name-TBD> working group is chartered for the following ordered list =
of work items:

  - The first goal of the WG is to identify use-cases.
  - The WG will then define the architecture framework associated with
    the security considerations. The architecture framework and security
    considerations must address the relations between networks forming
    the <Name-TBD> domain (interAS).
  - Having identified use-cases, architecture and security, the WG will
    identify gaps between currently available technologies and use-case
    requirements.
  - The WG will then define requirements for extensions to existing
    protocols or new protocols that address gaps that are identified.
  - The WG will first focus on the intra-domain forwarding definition.

  Documents :
  ------------------
  . Use Cases
  . Architecture including security considerations
  . Protocol extension requirements
  . Interoperability Report

  Protocol work may be carried out in this working group or in other
  working groups responsible for the protocols (ISIS,OSPF,BGP,PCEP ...),
  in coordination with this WG, and in agreement with the WG chairs
  and responsible ADs.

[RG] Would the following be better:

Required protocol extensions are carried out in working groups responsible.=
..(). Work on new protocols may be carried out by the <Name-TBD> WG ...

[RG] I'd appreciate if we were able to agree to avoid changes in the MPLS f=
orwarding plane, at least in the first phase. That should be part of the ch=
arter. We could re-charter, should this result in a deadlock later.

___________________________________________________________________________=
______________________________________________

Ce message et ses pieces jointes peuvent contenir des informations confiden=
tielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu=
 ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages el=
ectroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou =
falsifie. Merci.

This message and its attachments may contain confidential or privileged inf=
ormation that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and dele=
te this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been =
modified, changed or falsified.
Thank you.

From: <[email-masked]>
To: "[email-masked]" <[email-masked]>
Date: Tue, 10 Sep 2013 12:03:46 +0200
Accept-Language: fr-FR
acceptlanguage: fr-FR
Cc: "[email-masked]" <[email-masked]>
Subject: Re: [Status] Good charter proposals from Hannes and Stefano : try to merge ...

 [RG] I'd appreciate if we were able to agree to avoid changes in the MPLS =
forwarding plane, at least in the first phase. That should be part of the c=
harter. We could re-charter, should this result in a deadlock later.

[SLI] Agree also

[RG] may be nit picking: to avoid the interpretation, that downstream route=
rs have to contact the head-end router to get specific routing
instructions.:
..forward the packet by the address stack inserted by the router at the hea=
d-end...

[SLI] Changed by :=20
 "forward the packet by using the informations inserted by the router at th=
e head-end"

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

Here is updated proposal :

-------------------------------------------------------------------
Name: <TBD>
Charter:

Introduction
------------
The following use cases:
. Path computation based on awareness of utilization or performance
  data, within both centralized and distributed environments, . Multi-topol=
ogy (dual planes, disjoint trees), . Simplification and reduction of signal=
ing components (scaling), . Combined application and network layer path spe=
cification, . Full coverage LFA-FRR, . Topology Aware OAM, . etc.

have triggered work on the definition of new architecture and protocol exte=
nsions allowing to combine well known shortest path based routing paradigms=
 with source/explicit routing methods. Some of these extensions have been i=
mplemented already.

Objective
---------

Define an architecture where a node can steer a packet through a network or=
 set of networks (interdomain) on any path.

In this architecture, routers sharing a common trust model form a <Name-TBD=
> domain. The architecture defined by this working group will allow a node =
to steer a packet between any source and destination node within the <Name-=
TBD> domain (formed of one or more networks), on any path (shortest, non-sh=
ortest, explicit or based on other characteristics specified by segment ide=
ntifiers).

It may then send any packet that passes through it through any path that it=
 has specified and that is conform to the security rules. Downstream router=
s along the path within the <Name-TBD> domain forward the packet by using t=
he informations inserted by the router at the head-end

The architecture should support centralized and distributed path computatio=
n.

The architecture should support OAM functions.

As MPLS dataplane is largely deployed, the <Name-TBD> WG should avoid any m=
odification in the MPLS dataplane when defining the architecture.

Work items :
------------------

The <Name-TBD> working group is chartered for the following ordered list of=
 work items:

- The first goal of the WG is to identify use-cases.
- The WG will then define the architecture framework associated with
  the security considerations. The architecture framework and security
  considerations must address the relations between networks forming the <N=
ame-TBD> domain (interAS).
- Having identified use-cases, architecture and security, the WG will
  identify gaps between currently available technologies and use-case
  requirements.
- The WG will then define requirements for extensions to existing
  protocols or new protocols that address gaps that are identified.
- The WG will first focus on the intra-domain forwarding definition.

Documents :
------------------
. Use Cases
. Architecture including security considerations
- Protocol extension requirements
. Interoperability Report

Required protocol extensions are carried out in working groups responsible =
(ISIS,OSPF,BGP,PCEP ...). Work on new protocols may be carried out by the <=
Name-TBD> WG.=20

-----Message d'origine-----
De : [email-masked] [mailto:[email-masked]]=20
Envoy=E9 : mardi 10 septembre 2013 11:49
=C0 : LITKOWSKI Stephane DTF/DERX
Cc : [email-masked]
Objet : RE: [Status] Good charter proposals from Hannes and Stefano : try t=
o merge ...

Hi Stephane,

thanks for your proposal. Three remarks marked [RG] in line.

Regards,

Ruediger

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of=
 [email-masked]
Sent: Tuesday, September 10, 2013 11:19 AM
To: Rob Shakir
Cc: Hannes Gredler; [email-masked]; Stefano Previdi (sprevidi)
Subject: Re: [Status] Good charter proposals from Hannes and Stefano : try =
to merge ...

Souns good to me, (adding OAM also)

New recap :

-------------------------------------------------------------------
Name: <TBD>
Charter:

  Introduction
  ------------
  The following use cases:
  . Path computation based on awareness of utilization or performance
    data, within both centralized and distributed environments,
  . Multi-topology (dual planes, disjoint trees),
  . Simplification and reduction of signaling components (scaling),
  . Combined application and network layer path specification,
  . Full coverage LFA-FRR,
  . Topology Aware OAM,
  . etc.

  have triggered work on the definition of new architecture and
  protocol extensions allowing to combine well known shortest path
  based routing paradigms with source/explicit routing methods.
  Some of these extensions have been implemented already.

  Objective
  ---------

  Define an architecture where a node can steer a packet through a
  network or set of networks (interdomain) on any path.

  In this architecture, routers sharing a common trust model form
  a <Name-TBD> domain. The architecture defined by this working
  group will allow a node to steer a packet between any source and
  destination node within the <Name-TBD> domain (formed of one or
  more networks), on any path (shortest, non-shortest, explicit
  or based on other characteristics specified by segment identifiers).

  It may then send any packet that passes through it through any
  path that it has specified and that is conform to the security
  rules. Downstream routers along the path within the <Name-TBD>
  domain forward the packet as specified by the router at the
  head-end of the path.

[RG] may be nit picking: to avoid the interpretation, that downstream route=
rs have to contact the head-end router to get specific routing
instructions.:
..forward the packet by the address stack inserted by the router at the hea=
d-end...

  The architecture should support centralized and distributed
  path computation.

  The architecture should support OAM functions.

  Work items :
  ------------------

  The <Name-TBD> working group is chartered for the following ordered list =
of work items:

  - The first goal of the WG is to identify use-cases.
  - The WG will then define the architecture framework associated with
    the security considerations. The architecture framework and security
    considerations must address the relations between networks forming
    the <Name-TBD> domain (interAS).
  - Having identified use-cases, architecture and security, the WG will
    identify gaps between currently available technologies and use-case
    requirements.
  - The WG will then define requirements for extensions to existing
    protocols or new protocols that address gaps that are identified.
  - The WG will first focus on the intra-domain forwarding definition.

  Documents :
  ------------------
  . Use Cases
  . Architecture including security considerations
  . Protocol extension requirements
  . Interoperability Report

  Protocol work may be carried out in this working group or in other
  working groups responsible for the protocols (ISIS,OSPF,BGP,PCEP ...),
  in coordination with this WG, and in agreement with the WG chairs
  and responsible ADs.

[RG] Would the following be better:

Required protocol extensions are carried out in working groups responsible.=
..(). Work on new protocols may be carried out by the <Name-TBD> WG ...

[RG] I'd appreciate if we were able to agree to avoid changes in the MPLS f=
orwarding plane, at least in the first phase. That should be part of the ch=
arter. We could re-charter, should this result in a deadlock later.

___________________________________________________________________________=
______________________________________________

Ce message et ses pieces jointes peuvent contenir des informations confiden=
tielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu=
 ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages el=
ectroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou =
falsifie. Merci.

This message and its attachments may contain confidential or privileged inf=
ormation that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and dele=
te this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been =
modified, changed or falsified.
Thank you.

From: <[email-masked]>
To: <[email-masked]>
Date: Tue, 10 Sep 2013 11:48:36 +0200
Accept-Language: en-US, de-DE
acceptlanguage: en-US, de-DE
Cc: [email-masked]
Subject: Re: [Status] Good charter proposals from Hannes and Stefano : try to merge ...

Hi Stephane,

thanks for your proposal. Three remarks marked [RG] in line.

Regards,

Ruediger

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of=
 [email-masked]
Sent: Tuesday, September 10, 2013 11:19 AM
To: Rob Shakir
Cc: Hannes Gredler; [email-masked]; Stefano Previdi (sprevidi)
Subject: Re: [Status] Good charter proposals from Hannes and Stefano : try =
to merge ...

Souns good to me, (adding OAM also)

New recap :

-------------------------------------------------------------------
Name: <TBD>
Charter:

  Introduction
  ------------
  The following use cases:
  . Path computation based on awareness of utilization or performance
    data, within both centralized and distributed environments,
  . Multi-topology (dual planes, disjoint trees),
  . Simplification and reduction of signaling components (scaling),
  . Combined application and network layer path specification,
  . Full coverage LFA-FRR,
  . Topology Aware OAM,
  . etc.

  have triggered work on the definition of new architecture and
  protocol extensions allowing to combine well known shortest path
  based routing paradigms with source/explicit routing methods.
  Some of these extensions have been implemented already.

  Objective
  ---------

  Define an architecture where a node can steer a packet through a
  network or set of networks (interdomain) on any path.

  In this architecture, routers sharing a common trust model form
  a <Name-TBD> domain. The architecture defined by this working
  group will allow a node to steer a packet between any source and
  destination node within the <Name-TBD> domain (formed of one or
  more networks), on any path (shortest, non-shortest, explicit
  or based on other characteristics specified by segment identifiers).

  It may then send any packet that passes through it through any
  path that it has specified and that is conform to the security
  rules. Downstream routers along the path within the <Name-TBD>
  domain forward the packet as specified by the router at the
  head-end of the path.

[RG] may be nit picking: to avoid the interpretation, that downstream
routers have to contact the head-end router to get specific routing
instructions.:
..forward the packet by the address stack inserted by the router
at the head-end...

  The architecture should support centralized and distributed
  path computation.

  The architecture should support OAM functions.

  Work items :
  ------------------

  The <Name-TBD> working group is chartered for the following ordered list =
of work items:

  - The first goal of the WG is to identify use-cases.
  - The WG will then define the architecture framework associated with
    the security considerations. The architecture framework and security
    considerations must address the relations between networks forming
    the <Name-TBD> domain (interAS).
  - Having identified use-cases, architecture and security, the WG will
    identify gaps between currently available technologies and use-case
    requirements.
  - The WG will then define requirements for extensions to existing
    protocols or new protocols that address gaps that are identified.
  - The WG will first focus on the intra-domain forwarding definition.

  Documents :
  ------------------
  . Use Cases
  . Architecture including security considerations
  . Protocol extension requirements
  . Interoperability Report

  Protocol work may be carried out in this working group or in other
  working groups responsible for the protocols (ISIS,OSPF,BGP,PCEP ...),
  in coordination with this WG, and in agreement with the WG chairs
  and responsible ADs.

[RG] Would the following be better:

Required protocol extensions are carried out in working groups
responsible...(). Work on new protocols may be carried out by
the <Name-TBD> WG ...

[RG] I'd appreciate if we were able to agree to avoid changes in
the MPLS forwarding plane, at least in the first phase. That should
be part of the charter. We could re-charter, should this result in a
deadlock later.

From: <[email-masked]>
To: Rob Shakir <[email-masked]>
Date: Tue, 10 Sep 2013 11:19:00 +0200
Accept-Language: fr-FR
acceptlanguage: fr-FR
Cc: Hannes Gredler <[email-masked]>, "[email-masked]" <[email-masked]>, "Stefano Previdi \(sprevidi\)" <[email-masked]>
Subject: Re: [Status] Good charter proposals from Hannes and Stefano : try to merge ...

Souns good to me, (adding OAM also)

New recap :

-------------------------------------------------------------------
Name: <TBD>
Charter:

Introduction
------------
The following use cases:
. Path computation based on awareness of utilization or performance
  data, within both centralized and distributed environments, . Multi-topol=
ogy (dual planes, disjoint trees), . Simplification and reduction of signal=
ing components (scaling), . Combined application and network layer path spe=
cification, . Full coverage LFA-FRR, . Topology Aware OAM, . etc.

have triggered work on the definition of new architecture and protocol exte=
nsions allowing to combine well known shortest path based routing paradigms=
 with source/explicit routing methods. Some of these extensions have been i=
mplemented already.

Objective
---------

Define an architecture where a node can steer a packet through a network or=
 set of networks (interdomain) on any path.

In this architecture, routers sharing a common trust model form a <Name-TBD=
> domain. The architecture defined by this working group will allow a node =
to steer a packet between any source and destination node within the <Name-=
TBD> domain (formed of one or more networks), on any path (shortest, non-sh=
ortest, explicit or based on other characteristics specified by segment ide=
ntifiers).

It may then send any packet that passes through it through any path that it=
 has specified and that is conform to the security rules. Downstream router=
s along the path within the <Name-TBD> domain forward the packet as specifi=
ed by the router at the head-end of the path.

The architecture should support centralized and distributed path computatio=
n.

The architecture should support OAM functions.

Work items :
------------------

The <Name-TBD> working group is chartered for the following ordered list of=
 work items:

- The first goal of the WG is to identify use-cases.
- The WG will then define the architecture framework associated with
  the security considerations. The architecture framework and security
  considerations must address the relations between networks forming the <N=
ame-TBD> domain (interAS).
- Having identified use-cases, architecture and security, the WG will
  identify gaps between currently available technologies and use-case
  requirements.
- The WG will then define requirements for extensions to existing
  protocols or new protocols that address gaps that are identified.
- The WG will first focus on the intra-domain forwarding definition.

Documents :
------------------
. Use Cases
. Architecture including security considerations
- Protocol extension requirements
. Interoperability Report

Protocol work may be carried out in this working group or in other working =
groups responsible for the protocols (ISIS,OSPF,BGP,PCEP ...), in coordinat=
ion with this WG, and in agreement with the WG chairs and responsible ADs.

-----Message d'origine-----
De : Rob Shakir [mailto:[email-masked]]
Envoy=E9 : mardi 10 septembre 2013 11:05
=C0 : LITKOWSKI Stephane DTF/DERX
Cc : Hannes Gredler; Stefano Previdi (sprevidi); [email-masked]
Objet : Re: [Status] Good charter proposals from Hannes and Stefano : try t=
o merge ...

Hi Stephane,

Thanks for this, looks good! Comments in-line marked rjs>.

On 10 Sep 2013, at 08:50, <[email-masked]> wrote:

> Hi all,
>
> I'm creating a new mail topic because the "Summary of STATUS BOF ..."
> starts to be unreadable :)
>
> Hannes and Stefano send to us two charter proposals that sounds good to m=
e.
>
> The main difference between the two proposals is that Stefano propose a s=
egment bound to any type of instruction (forwarding, application or service=
 based) while Hannes is focusing on forwarding actions (which is the first =
priority, and I think everybody agree on this).

rjs> Agreed -- I think it would be useful to allow definitions of segments =
to identify different types of "service", since there appear to be some use=
 cases (e.g., the explicit exit selection case) which require a segment typ=
e describing something that is not explicitly IGP-based.

>
> It would be interresting to have a feedback from the mailinglist on this =
specific point.
>
> IMHO, there is a strong interrest to explore the service actions bound to=
 segment in a second step keeping forwarding as a priority.
>
> Apart of this problem, here is a merge try of the two good proposals (I'm=
 putting '<>' on hot topics :) ) :
>
>
> -------------------------------------------------------------------
> Name: <TBD>
> Charter:
>
>
> Introduction
> ------------
> The following use cases:
> . Path computation based on awareness of utilization or performance
> data, within both centralized and distributed environments, . Multi-topol=
ogy (dual planes, disjoint trees), . Simplification and reduction of signal=
ing components (scaling), . Combined application and network layer path spe=
cification, . Full coverage LFA-FRR, . Topology Aware OAM, . etc.
>
> have triggered work on the definition of new architecture and protocol ex=
tensions allowing to combine well known shortest path based routing paradig=
ms with source/explicit routing methods. Some of these extensions have been=
 implemented already.
>
>
> Objective
> ---------
>
> Define an architecture where a node can steer a packet through a network =
or set of networks (interdomain) on any path (shortest, non shortest, expli=
cit, <service or application>).
>
> In this architecture, routers are sharing a common trust model and are fo=
rming a <Name-TBD> domain.
> Within this domain, a node can specify a path between itself and any dest=
ination in the domain. <The path may be a forwarding path, a service chaini=
ng path or a combination of both>.

rjs> To clarify here, we define that our domain is under a common trust mod=
el (essentially, under common administrative control?), but then go on to t=
alk about inter-domain elsewhere. Can we perhaps clarify (by defining a spe=
cific "<Name-TBD> domain" nomenclature) and say something like:

"In this architecture, routers sharing a common trust model form a <Name-TB=
D> domain. The architecture defined by this working group will allow a node=
 to steer a packet between any source and destination node within the <Name=
-TBD> domain (formed of one or more networks), on any path (shortest, non-s=
hortest, explicit or based on other characteristics specified by segment id=
entifiers)."

> It may then send any packet that passes through it through any path that =
it has specified and that is conform to the security rules. Downstream rout=
ers along the path within the <Name-TBD> domain forward the packet as speci=
fied by the router at the head-end of the path.
>
> The architecture should support centralized and distributed path computat=
ion.
>
>
> Work items :
> ------------------
>
> The <Name-TBD> working group is chartered for the following ordered list =
of work items:
>
> - The first goal of the WG is to identify use-cases.
> - The WG will then define the architecture framework associated with
> the security considerations. The architecture framework and security
> considerations must address the relations between domains (inter domain).

rjs> And then here "networks forming the <Name-TBD> domain"?

Thanks for the efforts,
r.

> - Having identified use-cases, architecture and security, the WG will
> identify gaps between currently available technologies and use-case
> requirements.
> - The WG will then define requirements for extensions to existing
> protocols or new protocols that address gaps that are identified.
> - The WG will first focus on the intra-domain forwarding definition.
>
>
> Documents :
> ------------------
> . Use Cases
> . Architecture including security considerations
> - Protocol extension requirements
> . Interoperability Report
>
>
> Protocol work may be carried out in this working group or in other workin=
g groups responsible for the protocols (ISIS,OSPF,BGP,PCEP ...), in coordin=
ation with this WG, and in agreement with the WG chairs and responsible ADs.
>
>
>
> Hope it helps to progress on the definition.
>
>
> Stephane
>
>
> -----Message d'origine-----
> De : Hannes Gredler [mailto:[email-masked]] Envoy=E9 : vendredi 6
> septembre 2013 18:27 =C0 : LITKOWSKI Stephane DTF/DERX Cc :
> [email-masked] Objet : Re: [Status] Summary of STATUS BOF and the
> next steps
>
> hi stephane,
>
> here is a revised draft charter as per your comments.
>
> ---
>
> <Name-TBD> domain contains a set of routers with the following
> characteristics:
>
> - They form a connected network
> - They can forward traffic through any path within the network using
> shortest path, or any other (e.g., an explicit) path
> - They share a common trust model. In this model, any router within
> the domain can specify a path between itself and any other router  in
> the domain. It may then send any packet that passes through it
> through any path that it has specified and that is conform to the
> security rules. Downstream routers along the path within the
> <Name-TBD>  domain forward the packet as specified by the router at
> the head-end  of the path.
>
> The <Name-TBD> working group is chartered for the following ordered list =
of work items:
>
> - The first goal of the WG is to identify use-cases.
> - The WG will then define the architecture framework associated with
> the security considerations. The architecture framework and security
> considerations must address the relations between domains (interdomain).
> - Having identified use-cases, architecture and security, the WG will
> identify gaps between currently available technologies and use-case
> requirements.
> - The WG will then define requirements for extensions to existing
> protocols or new protocols that address gaps that are identified.
> - The WG will first focus on the intra-domain forwarding definition.
>
> Protocol work may be carried out in this working group or in other workin=
g groups responsible for the protocols, in coordination with this WG, and i=
n agreement with the WG chairs and responsible ADs.
> However, no protocol work will be adopted by a working group to address t=
he identified use-cases until the requirements document motivating the prot=
ocol work has been sent to the IESG for publication as an RFC.
>
> ---
>
> /hannes
>
> On Sep 4, 2013, at 10:02 AM, <[email-masked]> <stephane.li=
[email-masked]> wrote:
>
>> Hannes,
>>
>> In case, we are using only directed forwarding (adjacency segment),
>> could we still talk about tunneling ? (it's a very very small tunnel) Mo=
reover talking about "stacking" is really dataplane agnostic (MPLS) ...
>>
>> In the proposed segment routing architectural concepts, segments are at =
the same "level" and pointer moves on the segment list, then the MPLS insta=
ntiation is performing this using stacking ...
>>
>> IMHO, if we use "Stacked Tunnels", we already talk about a chosen soluti=
on and it's closing the door to something else  ...
>>
>> Finally, about the "routing" word, routing is essentially a "forward" ac=
tion which may limit the scope of what we can do by using a segment list. A=
ctions associated with a segment could be something else than forwarding.
>>
>> Do we want in the charter to limit the scope to routing actions ?
>>
>> I have no solution today to propose for the naming, but I completely agr=
ee with Loa, to first focus on working on the charter, and define a clear s=
cope of the work and then the name will be easier to find.
>>
>> Regarding your charter proposal :
>>
>> --------
>>
>> - They form a connected network
>>       [SLI] InterAS case must be included, but the WG can go step by ste=
p and first release intraAS, and then doing interAS (in relation with IDR ?=
?).
>>
>> - They can forward traffic through the shortest paths or paths other tha=
n the shortest (the latter called explicitly routed paths, or explicit path=
s)
>>       [SLI] There is something else between SPT and Explicit path, you c=
an define other algorithms than SPT to define a path, and it's not explicit=
 path. Moreover I come back to my comment, on do we want to limit the scope=
 to routing ? I would say no.
>>
>> - They share a common trust model. In this model, any router within the =
ERD can specify an explicit path between itself and any other router in the=
 ERD. It can then send any packet that passes through it through any path t=
hat it has specified.
>>       [SLI] Security considerations may have to be addressed in the
>> charter , especially for the interAS case (trust yes, but not sure
>> access to everything may not be good)
>>
>> Downstream routers within the ERD forward the packet as specified by the=
 router at the head-end of the path.
>> [SLI] Yes, but any router in the middle may be able to change the end to=
 end explicit path.
>>
>>
>>
>> - The first goal of the STER WG is to identify use-cases for ERDs.
>> - Having identified use-cases, the WG will identify gaps between current=
ly available technologies and use-case requirements.
>> - The WG will then define requirements for extensions to existing protoc=
ols or new protocols that address gaps that are identified.
>>
>> [SLI] Agree, I would add :
>> - defining the architecture framework
>> - analysing the security considerisations
>>
>>
>> ---------
>>
>>
>> Here would be my proposal to extend yours :
>>
>> A <named to be defined> domain contains a set of routers with the follow=
ing characteristics:
>>
>> - They form a connected network
>> - They can forward traffic through any path within the network using
>> shortest path, non shortest path or explicit path
>> - They may provide other types of services than forwarding and they can =
enforce service actions in the path.
>> - They share a common trust model. In this model, any router within the =
domain can specify a path between itself and any other router in the domain=
. It may then send any packet that passes through it through any path that =
it has specified and that is conform to the security rules. Downstream rout=
ers within the ERD forward the packet as specified by the router at the hea=
d-end of the path.
>>
>> The <name> working group is chartered for the following ordered list of =
work items:
>>
>> - The first goal of the WG is to identify use-cases.
>> - The WG will then define the architecture framework associated with the=
 security considerations. The architecture framework and security considera=
tions must address the relations between domains (interdomain).
>> - Having identified use-cases, architecture and security, the WG will id=
entify gaps between currently available technologies and use-case requireme=
nts.
>> - The WG will then define requirements for extensions to existing protoc=
ols or new protocols that address gaps that are identified.
>> - The WG will first focus on the intra-domain forwarding definition.
>>
>> Protocol work may be carried out in this working group or in other worki=
ng groups responsible for the protocols, in coordination with this WG, and =
in agreement with the WG chairs and responsible ADs. However, no protocol w=
ork will be adopted by a working group to address the ERD use-cases until t=
he requirements document motivating the protocol work has been sent to the =
IESG for publication as an RFC.
>>
>> -----Message d'origine-----
>> De : [email-masked] [mailto:[email-masked]] De la
>> part de Hannes Gredler Envoy=E9 : mardi 3 septembre 2013 18:31 =C0 : Loa
>> Andersson Cc : [email-masked] Objet : Re: [Status] Summary of STATUS
>> BOF and the next steps
>>
>> good point - what about this charter proposal ?
>>
>> ---
>>
>> Stacked Tunnels for Explicit Routing (STER)
>> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
>>
>> A explicit routing domain (ERD) contains a set of routers with the follo=
wing characteristics:
>>
>> - They form a connected network
>> - They can forward traffic through the shortest paths or paths other
>> than the shortest (the latter called explicitly routed paths, or
>> explicit paths)
>> - They share a common trust model. In this model, any router within the =
ERD can specify an explicit path between itself and any other router in the=
 ERD. It can then send any packet that passes through it through any path t=
hat it has specified. Downstream routers within the ERD forward the packet =
as specified by the router at the head-end of the path.
>>
>> The STER working group is chartered for the following ordered list of wo=
rk items:
>>
>> - The first goal of the STER WG is to identify use-cases for ERDs.
>> - Having identified use-cases, the WG will identify gaps between current=
ly available technologies and use-case requirements.
>> - The WG will then define requirements for extensions to existing protoc=
ols or new protocols that address gaps that are identified.
>>
>> Protocol work may be carried out in this working group or in other worki=
ng groups responsible for the protocols, in coordination with this WG, and =
in agreement with the WG chairs and responsible ADs. However, no protocol w=
ork will be adopted by a working group to address the ERD use-cases until t=
he requirements document motivating the protocol work has been sent to the =
IESG for publication as an RFC.
>>
>> ---
>>
>> <flame suit on>
>>
>> /hannes
>>
>>
>> On Sep 3, 2013, at 5:31 PM, Loa Andersson wrote:
>>
>>> Folks,
>>>
>>> Excuse me if I'm slightly out of the loop, but so far I have not
>>> seen a charter proposal, if there is one please point me to it.
>>>
>>> It seems a bit odd to put the cart (what the wg should do) before
>>> the horse (wg name). If we drill down the the charter first the wg
>>> name might be easier to figure out.
>>>
>>> /Loa
>>>
>>> PS
>>> OK I understand that the horse and cart analogy limps a  bit :).
>>>
>>>
>>>
>>> On 2013-09-03 17:22, AshwoodsmithPeter wrote:
>>>> " If the WG charter is limited to source routing, how will we handle t=
he "non source routing" use cases of segment routing ? In another working g=
roup ? So we will go back to the WG synchronization issue that has been rai=
sed for this technology ..."
>>>>
>>>> That's why I suggested SRV2. We are revisiting source routing with new=
 concepts. More generic number/action behavior.
>>>>
>>>> Peter
>>>>
>>>> -----Original Message-----
>>>> From: [email-masked] [mailto:[email-masked]] On
>>>> Behalf Of [email-masked]
>>>> Sent: Tuesday, September 03, 2013 10:43 AM
>>>> To: AshwoodsmithPeter
>>>> Cc: [email-masked]
>>>> Subject: Re: [Status] Summary of STATUS BOF and the next steps
>>>>
>>>>
>>>> There was a misunderstanding in my small comment :) so I will explain =
more :
>>>>
>>>> In segment routing, you have more than basic source routing : segment =
routing is just associate a segment number to an action and then combine se=
gment as you want, yes you can do source routing, but you also can do more.
>>>>
>>>> In the other hand, I completely agree with your statement that
>>>> source routing is generic and dataplane agnostic, as segment routing i=
s ...
>>>> (segment routing is not a new dataplane ...)
>>>>
>>>> Now the definition of the WG naming must be inline with the charter
>>>> that will be defined ... (draft today)
>>>>
>>>> Based on the already existing consensus (at least for MPLS dataplane) =
brought up during Berlin STATUS BOF meeting, segment routing sounds to be a=
 good target candidate.
>>>>
>>>> So now, do we want to do more in the WG charter than just make progres=
sing segment routing architecture and uses cases document and ensure coordi=
nation for the standardization of this technology ?
>>>>
>>>> Do we want to standardize other technologies in this WG ? I don't thin=
k so, based on Stewart's conclusion email from the BOF :"A new WG focused s=
olely on SR therefore needs to be create"
>>>>
>>>> If the WG charter is limited to source routing, how will we handle the=
 "non source routing" use cases of segment routing ? In another working gro=
up ? So we will go back to the WG synchronization issue that has been raise=
d for this technology ...
>>>>
>>>> If the WG is focused on SR, let's use a name in relation with SR.
>>>>
>>>> Feedback ?
>>>>
>>>>
>>>> Stephane
>>>>
>>>>
>>>> -----Message d'origine-----
>>>> De : AshwoodsmithPeter [mailto:[email-masked]]
>>>> Envoy=E9 : mardi 3 septembre 2013 15:27 =C0 : LITKOWSKI Stephane
>>>> DTF/DERX Cc : John E Drake; Mark Townsley; Victor Kuarsingh;
>>>> Roberta Maglione (robmgl); John G. Scudder; Adrian Farrel; Alvaro
>>>> Retana (aretana); [email-masked]; Stewart Bryant (stbryant) Objet : R=
e:
>>>> [Status] Summary of STATUS BOF and the next steps
>>>>
>>>> The term "source routing" has been around for a very long time and is =
data path agnostic. Its also the term used in the literature etc so my pref=
erence is to stick with this existing well known and data path agnostic ter=
m.
>>>>
>>>> Peter
>>>>
>>>> On Sep 3, 2013, at 9:07 AM, "[email-masked]" <stephane.=
[email-masked]> wrote:
>>>>
>>>>> Hi,
>>>>>
>>>>> "Source routing" is just a subcase of segment routing ... as it is fo=
r IP routing ...
>>>>>
>>>>> Stephane
>>>>>
>>>>>
>>>>> -----Message d'origine-----
>>>>> De : [email-masked] [mailto:[email-masked]] De
>>>>> la part de John E Drake Envoy=E9 : mardi 3 septembre 2013 15:02 =C0 :
>>>>> Mark Townsley; Victor Kuarsingh Cc : Roberta Maglione (robmgl); John =
G.
>>>>> Scudder; Alvaro Retana (aretana); Adrian Farrel; [email-masked];
>>>>> Stewart Bryant (stbryant) Objet : Re: [Status] Summary of STATUS
>>>>> BOF and the next steps
>>>>>
>>>>> Hi,
>>>>>
>>>>> What is this 'segment routing' silliness?  The correct term is 'sourc=
e routing'.
>>>>>
>>>>> Yours Irrespectively,
>>>>>
>>>>> John
>>>>>
>>>>>> -----Original Message-----
>>>>>> From: [email-masked] [mailto:[email-masked]] On
>>>>>> Behalf Of Mark Townsley
>>>>>> Sent: Sunday, September 01, 2013 10:08 AM
>>>>>> To: Victor Kuarsingh
>>>>>> Cc: Roberta Maglione (robmgl); John G. Scudder; Adrian Farrel;
>>>>>> Alvaro Retana (aretana); [email-masked]; Stewart Bryant
>>>>>> (stbryant)
>>>>>> Subject: Re: [Status] Summary of STATUS BOF and the next steps
>>>>>>
>>>>>>
>>>>>> On Sep 1, 2013, at 5:38 PM, Victor Kuarsingh wrote:
>>>>>>
>>>>>>> All,
>>>>>>>
>>>>>>> I would also favour "Segment Routing WG" as well.
>>>>>>>
>>>>>>> I note this since attempting to come up with an all encompassing
>>>>>>> acronym will be difficult and Segment Routing is generic enough
>>>>>>> to associate to multiple functions.
>>>>>>
>>>>>> Then we can just use "segroute" for the short name. WGs do not
>>>>>> have to have acronyms, but they do need to have an 8-char limited
>>>>>> short name for the various automated tools not to break.
>>>>>>
>>>>>> - Mark
>>>>>>
>>>>>>>
>>>>>>> Regards,
>>>>>>>
>>>>>>> Victor K
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> On 2013-08-31 6:51 PM, "Roberta Maglione (robmgl)"
>>>>>>> <[email-masked]>
>>>>>>> wrote:
>>>>>>>
>>>>>>>> +1 for Segment Routing WG
>>>>>>>>
>>>>>>>> Roberta
>>>>>>>>
>>>>>>>> Sent from my iPad
>>>>>>>>
>>>>>>>> On 2013-08-30, at 2:55 PM, "Alvaro Retana (aretana)"
>>>>>>>> <[email-masked]>
>>>>>>>> wrote:
>>>>>>>>
>>>>>>>>> Segment Routing WG
>>>>>>>>>
>>>>>>>>> Sent from my iPhone
>>>>>>>>>
>>>>>>>>> On Aug 30, 2013, at 1:39 PM, "Stewart Bryant (stbryant)"
>>>>>>>>> <[email-masked]> wrote:
>>>>>>>>>
>>>>>>>>>> The second task, which hopefully should be relatively easy,
>>>>>>>>>> is to find a better working name for the WG, since it has
>>>>>>>>>> been put to me a number of times that STATUS is going to be
>>>>>>>>>> confusing in text and a difficult search term.
>>>>>>>>> _______________________________________________
>>>>>>>>> status mailing list
>>>>>>>>> [email-masked]
>>>>>>>>> https://www.ietf.org/mailman/listinfo/status
>>>>>>>> _______________________________________________
>>>>>>>> status mailing list
>>>>>>>> [email-masked]
>>>>>>>> https://www.ietf.org/mailman/listinfo/status
>>>>>>>
>>>>>>>
>>>>>>> _______________________________________________
>>>>>>> status mailing list
>>>>>>> [email-masked]
>>>>>>> https://www.ietf.org/mailman/listinfo/status
>>>>>>
>>>>>> _______________________________________________
>>>>>> status mailing list
>>>>>> [email-masked]
>>>>>> https://www.ietf.org/mailman/listinfo/status
>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> status mailing list
>>>>> [email-masked]
>>>>> https://www.ietf.org/mailman/listinfo/status
>>>>>
>>>>> __________________________________________________________________
>>>>> _ _ __ ___________________________________________________
>>>>>
>>>>> Ce message et ses pieces jointes peuvent contenir des informations
>>>>> confidentielles ou privilegiees et ne doivent donc pas etre
>>>>> diffuses, exploites ou copies sans autorisation. Si vous avez recu
>>>>> ce message par erreur, veuillez le signaler a l'expediteur et le detr=
uire ainsi que les pieces jointes. Les messages electroniques etant suscept=
ibles d'alteration, Orange decline toute responsabilite si ce message a ete=
 altere, deforme ou falsifie. Merci.
>>>>>
>>>>> This message and its attachments may contain confidential or
>>>>> privileged information that may be protected by law; they should not =
be distributed, used or copied without authorisation.
>>>>> If you have received this email in error, please notify the sender an=
d delete this message and its attachments.
>>>>> As emails may be altered, Orange is not liable for messages that have=
 been modified, changed or falsified.
>>>>> Thank you.
>>>>>
>>>>> _______________________________________________
>>>>> status mailing list
>>>>> [email-masked]
>>>>> https://www.ietf.org/mailman/listinfo/status
>>>>
>>>> ___________________________________________________________________
>>>> _ _ ____________________________________________________
>>>>
>>>> Ce message et ses pieces jointes peuvent contenir des informations
>>>> confidentielles ou privilegiees et ne doivent donc pas etre
>>>> diffuses, exploites ou copies sans autorisation. Si vous avez recu
>>>> ce message par erreur, veuillez le signaler a l'expediteur et le detru=
ire ainsi que les pieces jointes. Les messages electroniques etant suscepti=
bles d'alteration, Orange decline toute responsabilite si ce message a ete =
altere, deforme ou falsifie. Merci.
>>>>
>>>> This message and its attachments may contain confidential or
>>>> privileged information that may be protected by law; they should not b=
e distributed, used or copied without authorisation.
>>>> If you have received this email in error, please notify the sender and=
 delete this message and its attachments.
>>>> As emails may be altered, Orange is not liable for messages that have =
been modified, changed or falsified.
>>>> Thank you.
>>>>
>>>> _______________________________________________
>>>> status mailing list
>>>> [email-masked]
>>>> https://www.ietf.org/mailman/listinfo/status
>>>> _______________________________________________
>>>> status mailing list
>>>> [email-masked]
>>>> https://www.ietf.org/mailman/listinfo/status
>>>>
>>>
>>> --
>>>
>>>
>>> Loa Andersson                        email: [email-masked]
>>> Senior MPLS Expert                          [email-masked]
>>> Huawei Technologies (consultant)     phone: +46 739 81 21 64
>>> _______________________________________________
>>> status mailing list
>>> [email-masked]
>>> https://www.ietf.org/mailman/listinfo/status
>>>
>>>
>>
>>
>> _______________________________________________
>> status mailing list
>> [email-masked]
>> https://www.ietf.org/mailman/listinfo/status
>>
>> _____________________________________________________________________
>> _ ___________________________________________________
>>
>> Ce message et ses pieces jointes peuvent contenir des informations
>> confidentielles ou privilegiees et ne doivent donc pas etre diffuses,
>> exploites ou copies sans autorisation. Si vous avez recu ce message
>> par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que=
 les pieces jointes. Les messages electroniques etant susceptibles d'altera=
tion, Orange decline toute responsabilite si ce message a ete altere, defor=
me ou falsifie. Merci.
>>
>> This message and its attachments may contain confidential or
>> privileged information that may be protected by law; they should not be =
distributed, used or copied without authorisation.
>> If you have received this email in error, please notify the sender and d=
elete this message and its attachments.
>> As emails may be altered, Orange is not liable for messages that have be=
en modified, changed or falsified.
>> Thank you.
>>
>>
>>
>
>
>
> ______________________________________________________________________
> ___________________________________________________
>
> Ce message et ses pieces jointes peuvent contenir des informations
> confidentielles ou privilegiees et ne doivent donc pas etre diffuses,
> exploites ou copies sans autorisation. Si vous avez recu ce message
> par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que =
les pieces jointes. Les messages electroniques etant susceptibles d'alterat=
ion, Orange decline toute responsabilite si ce message a ete altere, deform=
e ou falsifie. Merci.
>
> This message and its attachments may contain confidential or
> privileged information that may be protected by law; they should not be d=
istributed, used or copied without authorisation.
> If you have received this email in error, please notify the sender and de=
lete this message and its attachments.
> As emails may be altered, Orange is not liable for messages that have bee=
n modified, changed or falsified.
> Thank you.
>
> _______________________________________________
> status mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/status

___________________________________________________________________________=
______________________________________________

Ce message et ses pieces jointes peuvent contenir des informations confiden=
tielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu=
 ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages el=
ectroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou =
falsifie. Merci.

This message and its attachments may contain confidential or privileged inf=
ormation that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and dele=
te this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been =
modified, changed or falsified.
Thank you.

From: Rob Shakir <[email-masked]>
Date: Tue, 10 Sep 2013 09:04:59 +0000
To: <[email-masked]>
Cc: Hannes Gredler <[email-masked]>, "[email-masked]" <[email-masked]>, "Stefano Previdi \(sprevidi\)" <[email-masked]>
Subject: Re: [Status] Good charter proposals from Hannes and Stefano : try to merge ...

Hi Stephane,

Thanks for this, looks good! Comments in-line marked rjs>.

On 10 Sep 2013, at 08:50, <[email-masked]> wrote:

> Hi all,
>=20
> I'm creating a new mail topic because the "Summary of STATUS BOF ..." =
starts to be unreadable :)
>=20
> Hannes and Stefano send to us two charter proposals that sounds good =
to me.
>=20
> The main difference between the two proposals is that Stefano propose =
a segment bound to any type of instruction (forwarding, application or =
service based) while Hannes is focusing on forwarding actions (which is =
the first priority, and I think everybody agree on this).

rjs> Agreed -- I think it would be useful to allow definitions of =
segments to identify different types of "service", since there appear to =
be some use cases (e.g., the explicit exit selection case) which require =
a segment type describing something that is not explicitly IGP-based.

>=20
> It would be interresting to have a feedback from the mailinglist on =
this specific point.
>=20
> IMHO, there is a strong interrest to explore the service actions bound =
to segment in a second step keeping forwarding as a priority.
>=20
> Apart of this problem, here is a merge try of the two good proposals =
(I'm putting '<>' on hot topics :) ) :
>=20
>=20
> -------------------------------------------------------------------
> Name: <TBD>
> Charter:
>=20
>=20
> Introduction
> ------------
> The following use cases:
> . Path computation based on awareness of utilization or performance
>  data, within both centralized and distributed environments, . =
Multi-topology (dual planes, disjoint trees), . Simplification and =
reduction of signaling components (scaling), . Combined application and =
network layer path specification, . Full coverage LFA-FRR, . Topology =
Aware OAM, . etc.
>=20
> have triggered work on the definition of new architecture and protocol =
extensions allowing to combine well known shortest path based routing =
paradigms with source/explicit routing methods. Some of these extensions =
have been implemented already.
>=20
>=20
> Objective
> ---------
>=20
> Define an architecture where a node can steer a packet through a =
network or set of networks (interdomain) on any path (shortest, non =
shortest, explicit, <service or application>).
>=20
> In this architecture, routers are sharing a common trust model and are =
forming a <Name-TBD> domain.
> Within this domain, a node can specify a path between itself and any =
destination in the domain. <The path may be a forwarding path, a service =
chaining path or a combination of both>.

rjs> To clarify here, we define that our domain is under a common trust =
model (essentially, under common administrative control?), but then go =
on to talk about inter-domain elsewhere. Can we perhaps clarify (by =
defining a specific "<Name-TBD> domain" nomenclature) and say something =
like:

"In this architecture, routers sharing a common trust model form a =
<Name-TBD> domain. The architecture defined by this working group will =
allow a node to steer a packet between any source and destination node =
within the <Name-TBD> domain (formed of one or more networks), on any =
path (shortest, non-shortest, explicit or based on other characteristics =
specified by segment identifiers)."

> It may then send any packet that passes through it through any path =
that it has specified and that is conform to the security rules. =
Downstream routers along the path within the <Name-TBD> domain forward =
the packet as specified by the router at the head-end of the path.
>=20
> The architecture should support centralized and distributed path =
computation.
>=20
>=20
> Work items :
> ------------------
>=20
> The <Name-TBD> working group is chartered for the following ordered =
list of work items:
>=20
> - The first goal of the WG is to identify use-cases.
> - The WG will then define the architecture framework associated with
>  the security considerations. The architecture framework and security
>  considerations must address the relations between domains (inter =
domain).

rjs> And then here "networks forming the <Name-TBD> domain"?

Thanks for the efforts,
r.

> - Having identified use-cases, architecture and security, the WG will
>  identify gaps between currently available technologies and use-case
>  requirements.
> - The WG will then define requirements for extensions to existing
>  protocols or new protocols that address gaps that are identified.
> - The WG will first focus on the intra-domain forwarding definition.
>=20
>=20
> Documents :
> ------------------
> . Use Cases
> . Architecture including security considerations
> - Protocol extension requirements
> . Interoperability Report
>=20
>=20
> Protocol work may be carried out in this working group or in other =
working groups responsible for the protocols (ISIS,OSPF,BGP,PCEP ...), =
in coordination with this WG, and in agreement with the WG chairs and =
responsible ADs.
>=20
>=20
>=20
> Hope it helps to progress on the definition.
>=20
>=20
> Stephane
>=20
>=20
> -----Message d'origine-----
> De : Hannes Gredler [mailto:[email-masked]]
> Envoy=E9 : vendredi 6 septembre 2013 18:27
> =C0 : LITKOWSKI Stephane DTF/DERX
> Cc : [email-masked]
> Objet : Re: [Status] Summary of STATUS BOF and the next steps
>=20
> hi stephane,
>=20
> here is a revised draft charter as per your comments.
>=20
> ---
>=20
> <Name-TBD> domain contains a set of routers with the following
> characteristics:
>=20
> - They form a connected network
> - They can forward traffic through any path within the network using
>  shortest path, or any other (e.g., an explicit) path
> - They share a common trust model. In this model, any router within
>  the domain can specify a path between itself and any other router
>  in the domain. It may then send any packet that passes through it
>  through any path that it has specified and that is conform to the
>  security rules. Downstream routers along the path within the =
<Name-TBD>
>  domain forward the packet as specified by the router at the head-end
>  of the path.
>=20
> The <Name-TBD> working group is chartered for the following ordered =
list of work items:
>=20
> - The first goal of the WG is to identify use-cases.
> - The WG will then define the architecture framework associated with
>  the security considerations. The architecture framework and security
>  considerations must address the relations between domains =
(interdomain).
> - Having identified use-cases, architecture and security, the WG will
>  identify gaps between currently available technologies and use-case
>  requirements.
> - The WG will then define requirements for extensions to existing
>  protocols or new protocols that address gaps that are identified.
> - The WG will first focus on the intra-domain forwarding definition.
>=20
> Protocol work may be carried out in this working group or in other =
working groups responsible for the protocols, in coordination with this =
WG, and in agreement with the WG chairs and responsible ADs.
> However, no protocol work will be adopted by a working group to =
address the identified use-cases until the requirements document =
motivating the protocol work has been sent to the IESG for publication =
as an RFC.
>=20
> ---
>=20
> /hannes
>=20
> On Sep 4, 2013, at 10:02 AM, <[email-masked]> =
<[email-masked]> wrote:
>=20
>> Hannes,
>>=20
>> In case, we are using only directed forwarding (adjacency segment),
>> could we still talk about tunneling ? (it's a very very small tunnel) =
Moreover talking about "stacking" is really dataplane agnostic (MPLS) =
...
>>=20
>> In the proposed segment routing architectural concepts, segments are =
at the same "level" and pointer moves on the segment list, then the MPLS =
instantiation is performing this using stacking ...
>>=20
>> IMHO, if we use "Stacked Tunnels", we already talk about a chosen =
solution and it's closing the door to something else  ...
>>=20
>> Finally, about the "routing" word, routing is essentially a "forward" =
action which may limit the scope of what we can do by using a segment =
list. Actions associated with a segment could be something else than =
forwarding.
>>=20
>> Do we want in the charter to limit the scope to routing actions ?
>>=20
>> I have no solution today to propose for the naming, but I completely =
agree with Loa, to first focus on working on the charter, and define a =
clear scope of the work and then the name will be easier to find.
>>=20
>> Regarding your charter proposal :
>>=20
>> --------
>>=20
>> - They form a connected network
>>       [SLI] InterAS case must be included, but the WG can go step by =
step and first release intraAS, and then doing interAS (in relation with =
IDR ??).
>>=20
>> - They can forward traffic through the shortest paths or paths other =
than the shortest (the latter called explicitly routed paths, or =
explicit paths)
>>       [SLI] There is something else between SPT and Explicit path, =
you can define other algorithms than SPT to define a path, and it's not =
explicit path. Moreover I come back to my comment, on do we want to =
limit the scope to routing ? I would say no.
>>=20
>> - They share a common trust model. In this model, any router within =
the ERD can specify an explicit path between itself and any other router =
in the ERD. It can then send any packet that passes through it through =
any path that it has specified.
>>       [SLI] Security considerations may have to be addressed in the
>> charter , especially for the interAS case (trust yes, but not sure
>> access to everything may not be good)
>>=20
>> Downstream routers within the ERD forward the packet as specified by =
the router at the head-end of the path.
>> [SLI] Yes, but any router in the middle may be able to change the end =
to end explicit path.
>>=20
>>=20
>>=20
>> - The first goal of the STER WG is to identify use-cases for ERDs.
>> - Having identified use-cases, the WG will identify gaps between =
currently available technologies and use-case requirements.
>> - The WG will then define requirements for extensions to existing =
protocols or new protocols that address gaps that are identified.
>>=20
>> [SLI] Agree, I would add :
>> - defining the architecture framework
>> - analysing the security considerisations
>>=20
>>=20
>> ---------
>>=20
>>=20
>> Here would be my proposal to extend yours :
>>=20
>> A <named to be defined> domain contains a set of routers with the =
following characteristics:
>>=20
>> - They form a connected network
>> - They can forward traffic through any path within the network using
>> shortest path, non shortest path or explicit path
>> - They may provide other types of services than forwarding and they =
can enforce service actions in the path.
>> - They share a common trust model. In this model, any router within =
the domain can specify a path between itself and any other router in the =
domain. It may then send any packet that passes through it through any =
path that it has specified and that is conform to the security rules. =
Downstream routers within the ERD forward the packet as specified by the =
router at the head-end of the path.
>>=20
>> The <name> working group is chartered for the following ordered list =
of work items:
>>=20
>> - The first goal of the WG is to identify use-cases.
>> - The WG will then define the architecture framework associated with =
the security considerations. The architecture framework and security =
considerations must address the relations between domains (interdomain).
>> - Having identified use-cases, architecture and security, the WG will =
identify gaps between currently available technologies and use-case =
requirements.
>> - The WG will then define requirements for extensions to existing =
protocols or new protocols that address gaps that are identified.
>> - The WG will first focus on the intra-domain forwarding definition.
>>=20
>> Protocol work may be carried out in this working group or in other =
working groups responsible for the protocols, in coordination with this =
WG, and in agreement with the WG chairs and responsible ADs. However, no =
protocol work will be adopted by a working group to address the ERD =
use-cases until the requirements document motivating the protocol work =
has been sent to the IESG for publication as an RFC.
>>=20
>> -----Message d'origine-----
>> De : [email-masked] [mailto:[email-masked]] De la
>> part de Hannes Gredler Envoy=E9 : mardi 3 septembre 2013 18:31 =C0 : =
Loa
>> Andersson Cc : [email-masked] Objet : Re: [Status] Summary of STATUS
>> BOF and the next steps
>>=20
>> good point - what about this charter proposal ?
>>=20
>> ---
>>=20
>> Stacked Tunnels for Explicit Routing (STER)
>> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
>>=20
>> A explicit routing domain (ERD) contains a set of routers with the =
following characteristics:
>>=20
>> - They form a connected network
>> - They can forward traffic through the shortest paths or paths other
>> than the shortest (the latter called explicitly routed paths, or
>> explicit paths)
>> - They share a common trust model. In this model, any router within =
the ERD can specify an explicit path between itself and any other router =
in the ERD. It can then send any packet that passes through it through =
any path that it has specified. Downstream routers within the ERD =
forward the packet as specified by the router at the head-end of the =
path.
>>=20
>> The STER working group is chartered for the following ordered list of =
work items:
>>=20
>> - The first goal of the STER WG is to identify use-cases for ERDs.
>> - Having identified use-cases, the WG will identify gaps between =
currently available technologies and use-case requirements.
>> - The WG will then define requirements for extensions to existing =
protocols or new protocols that address gaps that are identified.
>>=20
>> Protocol work may be carried out in this working group or in other =
working groups responsible for the protocols, in coordination with this =
WG, and in agreement with the WG chairs and responsible ADs. However, no =
protocol work will be adopted by a working group to address the ERD =
use-cases until the requirements document motivating the protocol work =
has been sent to the IESG for publication as an RFC.
>>=20
>> ---
>>=20
>> <flame suit on>
>>=20
>> /hannes
>>=20
>>=20
>> On Sep 3, 2013, at 5:31 PM, Loa Andersson wrote:
>>=20
>>> Folks,
>>>=20
>>> Excuse me if I'm slightly out of the loop, but so far I have not =
seen
>>> a charter proposal, if there is one please point me to it.
>>>=20
>>> It seems a bit odd to put the cart (what the wg should do) before =
the
>>> horse (wg name). If we drill down the the charter first the wg name
>>> might be easier to figure out.
>>>=20
>>> /Loa
>>>=20
>>> PS
>>> OK I understand that the horse and cart analogy limps a  bit :).
>>>=20
>>>=20
>>>=20
>>> On 2013-09-03 17:22, AshwoodsmithPeter wrote:
>>>> " If the WG charter is limited to source routing, how will we =
handle the "non source routing" use cases of segment routing ? In =
another working group ? So we will go back to the WG synchronization =
issue that has been raised for this technology ..."
>>>>=20
>>>> That's why I suggested SRV2. We are revisiting source routing with =
new concepts. More generic number/action behavior.
>>>>=20
>>>> Peter
>>>>=20
>>>> -----Original Message-----
>>>> From: [email-masked] [mailto:[email-masked]] On
>>>> Behalf Of [email-masked]
>>>> Sent: Tuesday, September 03, 2013 10:43 AM
>>>> To: AshwoodsmithPeter
>>>> Cc: [email-masked]
>>>> Subject: Re: [Status] Summary of STATUS BOF and the next steps
>>>>=20
>>>>=20
>>>> There was a misunderstanding in my small comment :) so I will =
explain more :
>>>>=20
>>>> In segment routing, you have more than basic source routing : =
segment routing is just associate a segment number to an action and then =
combine segment as you want, yes you can do source routing, but you also =
can do more.
>>>>=20
>>>> In the other hand, I completely agree with your statement that
>>>> source routing is generic and dataplane agnostic, as segment =
routing is ...
>>>> (segment routing is not a new dataplane ...)
>>>>=20
>>>> Now the definition of the WG naming must be inline with the charter
>>>> that will be defined ... (draft today)
>>>>=20
>>>> Based on the already existing consensus (at least for MPLS =
dataplane) brought up during Berlin STATUS BOF meeting, segment routing =
sounds to be a good target candidate.
>>>>=20
>>>> So now, do we want to do more in the WG charter than just make =
progressing segment routing architecture and uses cases document and =
ensure coordination for the standardization of this technology ?
>>>>=20
>>>> Do we want to standardize other technologies in this WG ? I don't =
think so, based on Stewart's conclusion email from the BOF :"A new WG =
focused solely on SR therefore needs to be create"
>>>>=20
>>>> If the WG charter is limited to source routing, how will we handle =
the "non source routing" use cases of segment routing ? In another =
working group ? So we will go back to the WG synchronization issue that =
has been raised for this technology ...
>>>>=20
>>>> If the WG is focused on SR, let's use a name in relation with SR.
>>>>=20
>>>> Feedback ?
>>>>=20
>>>>=20
>>>> Stephane
>>>>=20
>>>>=20
>>>> -----Message d'origine-----
>>>> De : AshwoodsmithPeter [mailto:[email-masked]]
>>>> Envoy=E9 : mardi 3 septembre 2013 15:27 =C0 : LITKOWSKI Stephane
>>>> DTF/DERX Cc : John E Drake; Mark Townsley; Victor Kuarsingh; =
Roberta
>>>> Maglione (robmgl); John G. Scudder; Adrian Farrel; Alvaro Retana
>>>> (aretana); [email-masked]; Stewart Bryant (stbryant) Objet : Re:
>>>> [Status] Summary of STATUS BOF and the next steps
>>>>=20
>>>> The term "source routing" has been around for a very long time and =
is data path agnostic. Its also the term used in the literature etc so =
my preference is to stick with this existing well known and data path =
agnostic term.
>>>>=20
>>>> Peter
>>>>=20
>>>> On Sep 3, 2013, at 9:07 AM, "[email-masked]" =
<[email-masked]> wrote:
>>>>=20
>>>>> Hi,
>>>>>=20
>>>>> "Source routing" is just a subcase of segment routing ... as it is =
for IP routing ...
>>>>>=20
>>>>> Stephane
>>>>>=20
>>>>>=20
>>>>> -----Message d'origine-----
>>>>> De : [email-masked] [mailto:[email-masked]] De =
la
>>>>> part de John E Drake Envoy=E9 : mardi 3 septembre 2013 15:02 =C0 : =
Mark
>>>>> Townsley; Victor Kuarsingh Cc : Roberta Maglione (robmgl); John G.
>>>>> Scudder; Alvaro Retana (aretana); Adrian Farrel; [email-masked];
>>>>> Stewart Bryant (stbryant) Objet : Re: [Status] Summary of STATUS
>>>>> BOF and the next steps
>>>>>=20
>>>>> Hi,
>>>>>=20
>>>>> What is this 'segment routing' silliness?  The correct term is =
'source routing'.
>>>>>=20
>>>>> Yours Irrespectively,
>>>>>=20
>>>>> John
>>>>>=20
>>>>>> -----Original Message-----
>>>>>> From: [email-masked] [mailto:[email-masked]] On
>>>>>> Behalf Of Mark Townsley
>>>>>> Sent: Sunday, September 01, 2013 10:08 AM
>>>>>> To: Victor Kuarsingh
>>>>>> Cc: Roberta Maglione (robmgl); John G. Scudder; Adrian Farrel;
>>>>>> Alvaro Retana (aretana); [email-masked]; Stewart Bryant
>>>>>> (stbryant)
>>>>>> Subject: Re: [Status] Summary of STATUS BOF and the next steps
>>>>>>=20
>>>>>>=20
>>>>>> On Sep 1, 2013, at 5:38 PM, Victor Kuarsingh wrote:
>>>>>>=20
>>>>>>> All,
>>>>>>>=20
>>>>>>> I would also favour "Segment Routing WG" as well.
>>>>>>>=20
>>>>>>> I note this since attempting to come up with an all encompassing
>>>>>>> acronym will be difficult and Segment Routing is generic enough
>>>>>>> to associate to multiple functions.
>>>>>>=20
>>>>>> Then we can just use "segroute" for the short name. WGs do not
>>>>>> have to have acronyms, but they do need to have an 8-char limited
>>>>>> short name for the various automated tools not to break.
>>>>>>=20
>>>>>> - Mark
>>>>>>=20
>>>>>>>=20
>>>>>>> Regards,
>>>>>>>=20
>>>>>>> Victor K
>>>>>>>=20
>>>>>>>=20
>>>>>>>=20
>>>>>>> On 2013-08-31 6:51 PM, "Roberta Maglione (robmgl)"
>>>>>>> <[email-masked]>
>>>>>>> wrote:
>>>>>>>=20
>>>>>>>> +1 for Segment Routing WG
>>>>>>>>=20
>>>>>>>> Roberta
>>>>>>>>=20
>>>>>>>> Sent from my iPad
>>>>>>>>=20
>>>>>>>> On 2013-08-30, at 2:55 PM, "Alvaro Retana (aretana)"
>>>>>>>> <[email-masked]>
>>>>>>>> wrote:
>>>>>>>>=20
>>>>>>>>> Segment Routing WG
>>>>>>>>>=20
>>>>>>>>> Sent from my iPhone
>>>>>>>>>=20
>>>>>>>>> On Aug 30, 2013, at 1:39 PM, "Stewart Bryant (stbryant)"
>>>>>>>>> <[email-masked]> wrote:
>>>>>>>>>=20
>>>>>>>>>> The second task, which hopefully should be relatively easy, =
is
>>>>>>>>>> to find a better working name for the WG, since it has been
>>>>>>>>>> put to me a number of times that STATUS is going to be
>>>>>>>>>> confusing in text and a difficult search term.
>>>>>>>>> _______________________________________________
>>>>>>>>> status mailing list
>>>>>>>>> [email-masked]
>>>>>>>>> https://www.ietf.org/mailman/listinfo/status
>>>>>>>> _______________________________________________
>>>>>>>> status mailing list
>>>>>>>> [email-masked]
>>>>>>>> https://www.ietf.org/mailman/listinfo/status
>>>>>>>=20
>>>>>>>=20
>>>>>>> _______________________________________________
>>>>>>> status mailing list
>>>>>>> [email-masked]
>>>>>>> https://www.ietf.org/mailman/listinfo/status
>>>>>>=20
>>>>>> _______________________________________________
>>>>>> status mailing list
>>>>>> [email-masked]
>>>>>> https://www.ietf.org/mailman/listinfo/status
>>>>>=20
>>>>>=20
>>>>> _______________________________________________
>>>>> status mailing list
>>>>> [email-masked]
>>>>> https://www.ietf.org/mailman/listinfo/status
>>>>>=20
>>>>> =
___________________________________________________________________
>>>>> _ __ ___________________________________________________
>>>>>=20
>>>>> Ce message et ses pieces jointes peuvent contenir des informations
>>>>> confidentielles ou privilegiees et ne doivent donc pas etre
>>>>> diffuses, exploites ou copies sans autorisation. Si vous avez recu
>>>>> ce message par erreur, veuillez le signaler a l'expediteur et le =
detruire ainsi que les pieces jointes. Les messages electroniques etant =
susceptibles d'alteration, Orange decline toute responsabilite si ce =
message a ete altere, deforme ou falsifie. Merci.
>>>>>=20
>>>>> This message and its attachments may contain confidential or
>>>>> privileged information that may be protected by law; they should =
not be distributed, used or copied without authorisation.
>>>>> If you have received this email in error, please notify the sender =
and delete this message and its attachments.
>>>>> As emails may be altered, Orange is not liable for messages that =
have been modified, changed or falsified.
>>>>> Thank you.
>>>>>=20
>>>>> _______________________________________________
>>>>> status mailing list
>>>>> [email-masked]
>>>>> https://www.ietf.org/mailman/listinfo/status
>>>>=20
>>>> =
____________________________________________________________________
>>>> _ ____________________________________________________
>>>>=20
>>>> Ce message et ses pieces jointes peuvent contenir des informations
>>>> confidentielles ou privilegiees et ne doivent donc pas etre
>>>> diffuses, exploites ou copies sans autorisation. Si vous avez recu
>>>> ce message par erreur, veuillez le signaler a l'expediteur et le =
detruire ainsi que les pieces jointes. Les messages electroniques etant =
susceptibles d'alteration, Orange decline toute responsabilite si ce =
message a ete altere, deforme ou falsifie. Merci.
>>>>=20
>>>> This message and its attachments may contain confidential or
>>>> privileged information that may be protected by law; they should =
not be distributed, used or copied without authorisation.
>>>> If you have received this email in error, please notify the sender =
and delete this message and its attachments.
>>>> As emails may be altered, Orange is not liable for messages that =
have been modified, changed or falsified.
>>>> Thank you.
>>>>=20
>>>> _______________________________________________
>>>> status mailing list
>>>> [email-masked]
>>>> https://www.ietf.org/mailman/listinfo/status
>>>> _______________________________________________
>>>> status mailing list
>>>> [email-masked]
>>>> https://www.ietf.org/mailman/listinfo/status
>>>>=20
>>>=20
>>> --
>>>=20
>>>=20
>>> Loa Andersson                        email: [email-masked]
>>> Senior MPLS Expert                          [email-masked]
>>> Huawei Technologies (consultant)     phone: +46 739 81 21 64
>>> _______________________________________________
>>> status mailing list
>>> [email-masked]
>>> https://www.ietf.org/mailman/listinfo/status
>>>=20
>>>=20
>>=20
>>=20
>> _______________________________________________
>> status mailing list
>> [email-masked]
>> https://www.ietf.org/mailman/listinfo/status
>>=20
>> =
______________________________________________________________________
>> ___________________________________________________
>>=20
>> Ce message et ses pieces jointes peuvent contenir des informations
>> confidentielles ou privilegiees et ne doivent donc pas etre diffuses,
>> exploites ou copies sans autorisation. Si vous avez recu ce message
>> par erreur, veuillez le signaler a l'expediteur et le detruire ainsi =
que les pieces jointes. Les messages electroniques etant susceptibles =
d'alteration, Orange decline toute responsabilite si ce message a ete =
altere, deforme ou falsifie. Merci.
>>=20
>> This message and its attachments may contain confidential or
>> privileged information that may be protected by law; they should not =
be distributed, used or copied without authorisation.
>> If you have received this email in error, please notify the sender =
and delete this message and its attachments.
>> As emails may be altered, Orange is not liable for messages that have =
been modified, changed or falsified.
>> Thank you.
>>=20
>>=20
>>=20
>=20
>=20
>=20
> =
__________________________________________________________________________=
_______________________________________________
>=20
> Ce message et ses pieces jointes peuvent contenir des informations =
confidentielles ou privilegiees et ne doivent donc
> pas etre diffuses, exploites ou copies sans autorisation. Si vous avez =
recu ce message par erreur, veuillez le signaler
> a l'expediteur et le detruire ainsi que les pieces jointes. Les =
messages electroniques etant susceptibles d'alteration,
> Orange decline toute responsabilite si ce message a ete altere, =
deforme ou falsifie. Merci.
>=20
> This message and its attachments may contain confidential or =
privileged information that may be protected by law;
> they should not be distributed, used or copied without authorisation.
> If you have received this email in error, please notify the sender and =
delete this message and its attachments.
> As emails may be altered, Orange is not liable for messages that have =
been modified, changed or falsified.
> Thank you.
>=20
> _______________________________________________
> status mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/status

From: <[email-masked]>
To: Hannes Gredler <[email-masked]>, "Stefano Previdi (sprevidi)" <[email-masked]>
Date: Tue, 10 Sep 2013 10:50:06 +0200
Accept-Language: fr-FR
acceptlanguage: fr-FR
Cc: "[email-masked]" <[email-masked]>
Subject: [Status] Good charter proposals from Hannes and Stefano : try to merge ...

Hi all,

I'm creating a new mail topic because the "Summary of STATUS BOF ..." start=
s to be unreadable :)

Hannes and Stefano send to us two charter proposals that sounds good to me.

The main difference between the two proposals is that Stefano propose a seg=
ment bound to any type of instruction (forwarding, application or service b=
ased) while Hannes is focusing on forwarding actions (which is the first pr=
iority, and I think everybody agree on this).

It would be interresting to have a feedback from the mailinglist on this sp=
ecific point.

IMHO, there is a strong interrest to explore the service actions bound to s=
egment in a second step keeping forwarding as a priority.

Apart of this problem, here is a merge try of the two good proposals (I'm p=
utting '<>' on hot topics :) ) :

-------------------------------------------------------------------
Name: <TBD>
Charter:

Introduction
------------
The following use cases:
. Path computation based on awareness of utilization or performance
  data, within both centralized and distributed environments, . Multi-topol=
ogy (dual planes, disjoint trees), . Simplification and reduction of signal=
ing components (scaling), . Combined application and network layer path spe=
cification, . Full coverage LFA-FRR, . Topology Aware OAM, . etc.

have triggered work on the definition of new architecture and protocol exte=
nsions allowing to combine well known shortest path based routing paradigms=
 with source/explicit routing methods. Some of these extensions have been i=
mplemented already.

Objective
---------

Define an architecture where a node can steer a packet through a network or=
 set of networks (interdomain) on any path (shortest, non shortest, explici=
t, <service or application>).

In this architecture, routers are sharing a common trust model and are form=
ing a <Name-TBD> domain.
Within this domain, a node can specify a path between itself and any destin=
ation in the domain. <The path may be a forwarding path, a service chaining=
 path or a combination of both>.
It may then send any packet that passes through it through any path that it=
 has specified and that is conform to the security rules. Downstream router=
s along the path within the <Name-TBD> domain forward the packet as specifi=
ed by the router at the head-end of the path.

The architecture should support centralized and distributed path computatio=
n.

Work items :
------------------

The <Name-TBD> working group is chartered for the following ordered list of=
 work items:

- The first goal of the WG is to identify use-cases.
- The WG will then define the architecture framework associated with
  the security considerations. The architecture framework and security
  considerations must address the relations between domains (interdomain).
- Having identified use-cases, architecture and security, the WG will
  identify gaps between currently available technologies and use-case
  requirements.
- The WG will then define requirements for extensions to existing
  protocols or new protocols that address gaps that are identified.
- The WG will first focus on the intra-domain forwarding definition.

Documents :
------------------
. Use Cases
. Architecture including security considerations
- Protocol extension requirements
. Interoperability Report

Protocol work may be carried out in this working group or in other working =
groups responsible for the protocols (ISIS,OSPF,BGP,PCEP ...), in coordinat=
ion with this WG, and in agreement with the WG chairs and responsible ADs.

Hope it helps to progress on the definition.

Stephane

-----Message d'origine-----
De : Hannes Gredler [mailto:[email-masked]]
Envoy=E9 : vendredi 6 septembre 2013 18:27
=C0 : LITKOWSKI Stephane DTF/DERX
Cc : [email-masked]
Objet : Re: [Status] Summary of STATUS BOF and the next steps

hi stephane,

here is a revised draft charter as per your comments.

---

<Name-TBD> domain contains a set of routers with the following
characteristics:

- They form a connected network
- They can forward traffic through any path within the network using
  shortest path, or any other (e.g., an explicit) path
- They share a common trust model. In this model, any router within
  the domain can specify a path between itself and any other router
  in the domain. It may then send any packet that passes through it
  through any path that it has specified and that is conform to the
  security rules. Downstream routers along the path within the <Name-TBD>
  domain forward the packet as specified by the router at the head-end
  of the path.

The <Name-TBD> working group is chartered for the following ordered list of=
 work items:

- The first goal of the WG is to identify use-cases.
- The WG will then define the architecture framework associated with
  the security considerations. The architecture framework and security
  considerations must address the relations between domains (interdomain).
- Having identified use-cases, architecture and security, the WG will
  identify gaps between currently available technologies and use-case
  requirements.
- The WG will then define requirements for extensions to existing
  protocols or new protocols that address gaps that are identified.
- The WG will first focus on the intra-domain forwarding definition.

Protocol work may be carried out in this working group or in other working =
groups responsible for the protocols, in coordination with this WG, and in =
agreement with the WG chairs and responsible ADs.
However, no protocol work will be adopted by a working group to address the=
 identified use-cases until the requirements document motivating the protoc=
ol work has been sent to the IESG for publication as an RFC.

---

/hannes

On Sep 4, 2013, at 10:02 AM, <[email-masked]> <stephane.litk=
[email-masked]> wrote:

> Hannes,
>
> In case, we are using only directed forwarding (adjacency segment),
> could we still talk about tunneling ? (it's a very very small tunnel) Mor=
eover talking about "stacking" is really dataplane agnostic (MPLS) ...
>
> In the proposed segment routing architectural concepts, segments are at t=
he same "level" and pointer moves on the segment list, then the MPLS instan=
tiation is performing this using stacking ...
>
> IMHO, if we use "Stacked Tunnels", we already talk about a chosen solutio=
n and it's closing the door to something else  ...
>
> Finally, about the "routing" word, routing is essentially a "forward" act=
ion which may limit the scope of what we can do by using a segment list. Ac=
tions associated with a segment could be something else than forwarding.
>
> Do we want in the charter to limit the scope to routing actions ?
>
> I have no solution today to propose for the naming, but I completely agre=
e with Loa, to first focus on working on the charter, and define a clear sc=
ope of the work and then the name will be easier to find.
>
> Regarding your charter proposal :
>
> --------
>
> - They form a connected network
>        [SLI] InterAS case must be included, but the WG can go step by ste=
p and first release intraAS, and then doing interAS (in relation with IDR ?=
?).
>
> - They can forward traffic through the shortest paths or paths other than=
 the shortest (the latter called explicitly routed paths, or explicit paths)
>        [SLI] There is something else between SPT and Explicit path, you c=
an define other algorithms than SPT to define a path, and it's not explicit=
 path. Moreover I come back to my comment, on do we want to limit the scope=
 to routing ? I would say no.
>
> - They share a common trust model. In this model, any router within the E=
RD can specify an explicit path between itself and any other router in the =
ERD. It can then send any packet that passes through it through any path th=
at it has specified.
>        [SLI] Security considerations may have to be addressed in the
> charter , especially for the interAS case (trust yes, but not sure
> access to everything may not be good)
>
> Downstream routers within the ERD forward the packet as specified by the =
router at the head-end of the path.
> [SLI] Yes, but any router in the middle may be able to change the end to =
end explicit path.
>
>
>
> - The first goal of the STER WG is to identify use-cases for ERDs.
> - Having identified use-cases, the WG will identify gaps between currentl=
y available technologies and use-case requirements.
> - The WG will then define requirements for extensions to existing protoco=
ls or new protocols that address gaps that are identified.
>
> [SLI] Agree, I would add :
> - defining the architecture framework
> - analysing the security considerisations
>
>
> ---------
>
>
> Here would be my proposal to extend yours :
>
> A <named to be defined> domain contains a set of routers with the followi=
ng characteristics:
>
> - They form a connected network
> - They can forward traffic through any path within the network using
> shortest path, non shortest path or explicit path
> - They may provide other types of services than forwarding and they can e=
nforce service actions in the path.
> - They share a common trust model. In this model, any router within the d=
omain can specify a path between itself and any other router in the domain.=
 It may then send any packet that passes through it through any path that i=
t has specified and that is conform to the security rules. Downstream route=
rs within the ERD forward the packet as specified by the router at the head=
-end of the path.
>
> The <name> working group is chartered for the following ordered list of w=
ork items:
>
> - The first goal of the WG is to identify use-cases.
> - The WG will then define the architecture framework associated with the =
security considerations. The architecture framework and security considerat=
ions must address the relations between domains (interdomain).
> - Having identified use-cases, architecture and security, the WG will ide=
ntify gaps between currently available technologies and use-case requiremen=
ts.
> - The WG will then define requirements for extensions to existing protoco=
ls or new protocols that address gaps that are identified.
> - The WG will first focus on the intra-domain forwarding definition.
>
> Protocol work may be carried out in this working group or in other workin=
g groups responsible for the protocols, in coordination with this WG, and i=
n agreement with the WG chairs and responsible ADs. However, no protocol wo=
rk will be adopted by a working group to address the ERD use-cases until th=
e requirements document motivating the protocol work has been sent to the I=
ESG for publication as an RFC.
>
> -----Message d'origine-----
> De : [email-masked] [mailto:[email-masked]] De la
> part de Hannes Gredler Envoy=E9 : mardi 3 septembre 2013 18:31 =C0 : Loa
> Andersson Cc : [email-masked] Objet : Re: [Status] Summary of STATUS
> BOF and the next steps
>
> good point - what about this charter proposal ?
>
> ---
>
> Stacked Tunnels for Explicit Routing (STER)
> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
>
> A explicit routing domain (ERD) contains a set of routers with the follow=
ing characteristics:
>
> - They form a connected network
> - They can forward traffic through the shortest paths or paths other
> than the shortest (the latter called explicitly routed paths, or
> explicit paths)
> - They share a common trust model. In this model, any router within the E=
RD can specify an explicit path between itself and any other router in the =
ERD. It can then send any packet that passes through it through any path th=
at it has specified. Downstream routers within the ERD forward the packet a=
s specified by the router at the head-end of the path.
>
> The STER working group is chartered for the following ordered list of wor=
k items:
>
> - The first goal of the STER WG is to identify use-cases for ERDs.
> - Having identified use-cases, the WG will identify gaps between currentl=
y available technologies and use-case requirements.
> - The WG will then define requirements for extensions to existing protoco=
ls or new protocols that address gaps that are identified.
>
> Protocol work may be carried out in this working group or in other workin=
g groups responsible for the protocols, in coordination with this WG, and i=
n agreement with the WG chairs and responsible ADs. However, no protocol wo=
rk will be adopted by a working group to address the ERD use-cases until th=
e requirements document motivating the protocol work has been sent to the I=
ESG for publication as an RFC.
>
> ---
>
> <flame suit on>
>
> /hannes
>
>
> On Sep 3, 2013, at 5:31 PM, Loa Andersson wrote:
>
>> Folks,
>>
>> Excuse me if I'm slightly out of the loop, but so far I have not seen
>> a charter proposal, if there is one please point me to it.
>>
>> It seems a bit odd to put the cart (what the wg should do) before the
>> horse (wg name). If we drill down the the charter first the wg name
>> might be easier to figure out.
>>
>> /Loa
>>
>> PS
>> OK I understand that the horse and cart analogy limps a  bit :).
>>
>>
>>
>> On 2013-09-03 17:22, AshwoodsmithPeter wrote:
>>> " If the WG charter is limited to source routing, how will we handle th=
e "non source routing" use cases of segment routing ? In another working gr=
oup ? So we will go back to the WG synchronization issue that has been rais=
ed for this technology ..."
>>>
>>> That's why I suggested SRV2. We are revisiting source routing with new =
concepts. More generic number/action behavior.
>>>
>>> Peter
>>>
>>> -----Original Message-----
>>> From: [email-masked] [mailto:[email-masked]] On
>>> Behalf Of [email-masked]
>>> Sent: Tuesday, September 03, 2013 10:43 AM
>>> To: AshwoodsmithPeter
>>> Cc: [email-masked]
>>> Subject: Re: [Status] Summary of STATUS BOF and the next steps
>>>
>>>
>>> There was a misunderstanding in my small comment :) so I will explain m=
ore :
>>>
>>> In segment routing, you have more than basic source routing : segment r=
outing is just associate a segment number to an action and then combine seg=
ment as you want, yes you can do source routing, but you also can do more.
>>>
>>> In the other hand, I completely agree with your statement that
>>> source routing is generic and dataplane agnostic, as segment routing is=
 ...
>>> (segment routing is not a new dataplane ...)
>>>
>>> Now the definition of the WG naming must be inline with the charter
>>> that will be defined ... (draft today)
>>>
>>> Based on the already existing consensus (at least for MPLS dataplane) b=
rought up during Berlin STATUS BOF meeting, segment routing sounds to be a =
good target candidate.
>>>
>>> So now, do we want to do more in the WG charter than just make progress=
ing segment routing architecture and uses cases document and ensure coordin=
ation for the standardization of this technology ?
>>>
>>> Do we want to standardize other technologies in this WG ? I don't think=
 so, based on Stewart's conclusion email from the BOF :"A new WG focused so=
lely on SR therefore needs to be create"
>>>
>>> If the WG charter is limited to source routing, how will we handle the =
"non source routing" use cases of segment routing ? In another working grou=
p ? So we will go back to the WG synchronization issue that has been raised=
 for this technology ...
>>>
>>> If the WG is focused on SR, let's use a name in relation with SR.
>>>
>>> Feedback ?
>>>
>>>
>>> Stephane
>>>
>>>
>>> -----Message d'origine-----
>>> De : AshwoodsmithPeter [mailto:[email-masked]]
>>> Envoy=E9 : mardi 3 septembre 2013 15:27 =C0 : LITKOWSKI Stephane
>>> DTF/DERX Cc : John E Drake; Mark Townsley; Victor Kuarsingh; Roberta
>>> Maglione (robmgl); John G. Scudder; Adrian Farrel; Alvaro Retana
>>> (aretana); [email-masked]; Stewart Bryant (stbryant) Objet : Re:
>>> [Status] Summary of STATUS BOF and the next steps
>>>
>>> The term "source routing" has been around for a very long time and is d=
ata path agnostic. Its also the term used in the literature etc so my prefe=
rence is to stick with this existing well known and data path agnostic term.
>>>
>>> Peter
>>>
>>> On Sep 3, 2013, at 9:07 AM, "[email-masked]" <stephane.l=
[email-masked]> wrote:
>>>
>>>> Hi,
>>>>
>>>> "Source routing" is just a subcase of segment routing ... as it is for=
 IP routing ...
>>>>
>>>> Stephane
>>>>
>>>>
>>>> -----Message d'origine-----
>>>> De : [email-masked] [mailto:[email-masked]] De la
>>>> part de John E Drake Envoy=E9 : mardi 3 septembre 2013 15:02 =C0 : Mark
>>>> Townsley; Victor Kuarsingh Cc : Roberta Maglione (robmgl); John G.
>>>> Scudder; Alvaro Retana (aretana); Adrian Farrel; [email-masked];
>>>> Stewart Bryant (stbryant) Objet : Re: [Status] Summary of STATUS
>>>> BOF and the next steps
>>>>
>>>> Hi,
>>>>
>>>> What is this 'segment routing' silliness?  The correct term is 'source=
 routing'.
>>>>
>>>> Yours Irrespectively,
>>>>
>>>> John
>>>>
>>>>> -----Original Message-----
>>>>> From: [email-masked] [mailto:[email-masked]] On
>>>>> Behalf Of Mark Townsley
>>>>> Sent: Sunday, September 01, 2013 10:08 AM
>>>>> To: Victor Kuarsingh
>>>>> Cc: Roberta Maglione (robmgl); John G. Scudder; Adrian Farrel;
>>>>> Alvaro Retana (aretana); [email-masked]; Stewart Bryant
>>>>> (stbryant)
>>>>> Subject: Re: [Status] Summary of STATUS BOF and the next steps
>>>>>
>>>>>
>>>>> On Sep 1, 2013, at 5:38 PM, Victor Kuarsingh wrote:
>>>>>
>>>>>> All,
>>>>>>
>>>>>> I would also favour "Segment Routing WG" as well.
>>>>>>
>>>>>> I note this since attempting to come up with an all encompassing
>>>>>> acronym will be difficult and Segment Routing is generic enough
>>>>>> to associate to multiple functions.
>>>>>
>>>>> Then we can just use "segroute" for the short name. WGs do not
>>>>> have to have acronyms, but they do need to have an 8-char limited
>>>>> short name for the various automated tools not to break.
>>>>>
>>>>> - Mark
>>>>>
>>>>>>
>>>>>> Regards,
>>>>>>
>>>>>> Victor K
>>>>>>
>>>>>>
>>>>>>
>>>>>> On 2013-08-31 6:51 PM, "Roberta Maglione (robmgl)"
>>>>>> <[email-masked]>
>>>>>> wrote:
>>>>>>
>>>>>>> +1 for Segment Routing WG
>>>>>>>
>>>>>>> Roberta
>>>>>>>
>>>>>>> Sent from my iPad
>>>>>>>
>>>>>>> On 2013-08-30, at 2:55 PM, "Alvaro Retana (aretana)"
>>>>>>> <[email-masked]>
>>>>>>> wrote:
>>>>>>>
>>>>>>>> Segment Routing WG
>>>>>>>>
>>>>>>>> Sent from my iPhone
>>>>>>>>
>>>>>>>> On Aug 30, 2013, at 1:39 PM, "Stewart Bryant (stbryant)"
>>>>>>>> <[email-masked]> wrote:
>>>>>>>>
>>>>>>>>> The second task, which hopefully should be relatively easy, is
>>>>>>>>> to find a better working name for the WG, since it has been
>>>>>>>>> put to me a number of times that STATUS is going to be
>>>>>>>>> confusing in text and a difficult search term.
>>>>>>>> _______________________________________________
>>>>>>>> status mailing list
>>>>>>>> [email-masked]
>>>>>>>> https://www.ietf.org/mailman/listinfo/status
>>>>>>> _______________________________________________
>>>>>>> status mailing list
>>>>>>> [email-masked]
>>>>>>> https://www.ietf.org/mailman/listinfo/status
>>>>>>
>>>>>>
>>>>>> _______________________________________________
>>>>>> status mailing list
>>>>>> [email-masked]
>>>>>> https://www.ietf.org/mailman/listinfo/status
>>>>>
>>>>> _______________________________________________
>>>>> status mailing list
>>>>> [email-masked]
>>>>> https://www.ietf.org/mailman/listinfo/status
>>>>
>>>>
>>>> _______________________________________________
>>>> status mailing list
>>>> [email-masked]
>>>> https://www.ietf.org/mailman/listinfo/status
>>>>
>>>> ___________________________________________________________________
>>>> _ __ ___________________________________________________
>>>>
>>>> Ce message et ses pieces jointes peuvent contenir des informations
>>>> confidentielles ou privilegiees et ne doivent donc pas etre
>>>> diffuses, exploites ou copies sans autorisation. Si vous avez recu
>>>> ce message par erreur, veuillez le signaler a l'expediteur et le detru=
ire ainsi que les pieces jointes. Les messages electroniques etant suscepti=
bles d'alteration, Orange decline toute responsabilite si ce message a ete =
altere, deforme ou falsifie. Merci.
>>>>
>>>> This message and its attachments may contain confidential or
>>>> privileged information that may be protected by law; they should not b=
e distributed, used or copied without authorisation.
>>>> If you have received this email in error, please notify the sender and=
 delete this message and its attachments.
>>>> As emails may be altered, Orange is not liable for messages that have =
been modified, changed or falsified.
>>>> Thank you.
>>>>
>>>> _______________________________________________
>>>> status mailing list
>>>> [email-masked]
>>>> https://www.ietf.org/mailman/listinfo/status
>>>
>>> ____________________________________________________________________
>>> _ ____________________________________________________
>>>
>>> Ce message et ses pieces jointes peuvent contenir des informations
>>> confidentielles ou privilegiees et ne doivent donc pas etre
>>> diffuses, exploites ou copies sans autorisation. Si vous avez recu
>>> ce message par erreur, veuillez le signaler a l'expediteur et le detrui=
re ainsi que les pieces jointes. Les messages electroniques etant susceptib=
les d'alteration, Orange decline toute responsabilite si ce message a ete a=
ltere, deforme ou falsifie. Merci.
>>>
>>> This message and its attachments may contain confidential or
>>> privileged information that may be protected by law; they should not be=
 distributed, used or copied without authorisation.
>>> If you have received this email in error, please notify the sender and =
delete this message and its attachments.
>>> As emails may be altered, Orange is not liable for messages that have b=
een modified, changed or falsified.
>>> Thank you.
>>>
>>> _______________________________________________
>>> status mailing list
>>> [email-masked]
>>> https://www.ietf.org/mailman/listinfo/status
>>> _______________________________________________
>>> status mailing list
>>> [email-masked]
>>> https://www.ietf.org/mailman/listinfo/status
>>>
>>
>> --
>>
>>
>> Loa Andersson                        email: [email-masked]
>> Senior MPLS Expert                          [email-masked]
>> Huawei Technologies (consultant)     phone: +46 739 81 21 64
>> _______________________________________________
>> status mailing list
>> [email-masked]
>> https://www.ietf.org/mailman/listinfo/status
>>
>>
>
>
> _______________________________________________
> status mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/status
>
> ______________________________________________________________________
> ___________________________________________________
>
> Ce message et ses pieces jointes peuvent contenir des informations
> confidentielles ou privilegiees et ne doivent donc pas etre diffuses,
> exploites ou copies sans autorisation. Si vous avez recu ce message
> par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que =
les pieces jointes. Les messages electroniques etant susceptibles d'alterat=
ion, Orange decline toute responsabilite si ce message a ete altere, deform=
e ou falsifie. Merci.
>
> This message and its attachments may contain confidential or
> privileged information that may be protected by law; they should not be d=
istributed, used or copied without authorisation.
> If you have received this email in error, please notify the sender and de=
lete this message and its attachments.
> As emails may be altered, Orange is not liable for messages that have bee=
n modified, changed or falsified.
> Thank you.
>
>
>

___________________________________________________________________________=
______________________________________________

Ce message et ses pieces jointes peuvent contenir des informations confiden=
tielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu=
 ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages el=
ectroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou =
falsifie. Merci.

This message and its attachments may contain confidential or privileged inf=
ormation that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and dele=
te this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been =
modified, changed or falsified.
Thank you.

Sender: [email-masked]
Date: Mon, 9 Sep 2013 20:25:25 +0200
From: Robert Raszuk <[email-masked]>
To: Yakov Rekhter <[email-masked]>
Cc: "[email-masked]" <[email-masked]>
Subject: Re: [Status] Summary of STATUS BOF and the next steps

Hi Yakov,

> please point to the document that describes how "trivial"
> it is to accomplish one of those items, namely p2mp path
> construction with SR.

p2mp paths can be created in two ways:

A. Via multicast routing protocol in distributed fashion (ex mLDP, PIM etc ...)

B. Via controller programming replication points.

My claim was referring to the latter where using (for example I2RS
IETF protocol) replication points of segment X to segment Y, Z etc ...
can be programmed from controller to network elements.

Segment Routing is really helpful in this as notion of domain wide
labels allows easy traffic mapping to segments and on a per segment
base data plane traffic handling without any need for explicit path
signalling.

Note that this is not to say that I dismiss the need for former (point
A) and as you noticed in subsequent email to Hannes I clearly made the
distinction that mLDP is not something I would consider to be
replaced.

An interesting exercise could be undertaken to accomplish B with
today's locally significant MPLS without SR. I think it is doable
however it will require much more controller to network signalling as
well as clearly additional data plane support on today's network
equipment.

Best regards,
R.

> On Mon, Sep 9, 2013 at 7:01 PM, Yakov Rekhter <[email-masked]> wrote:
> Robert,
>
>> > i haven't yet identified the code to be deleted, if SR is going
>> > to be a success ;-)
>>
>> How about LDP as starter ?
>>
>> Which of the below are solved by LDP ? Which LDP functionality will
>> not be covered by SR ?
>>
>> >>  1. LSP bandwidth reservation
>> >>  2. LSP preemption
>> >>  3. p2mp path construction
>>
>> Note that those are all done today in the control plane. Therefor it
>> seems pretty trivial to accomplish all of those with SR using number
>> of PCE or PCE like controllers rather then use RSVP-TE for explicit
>> path signalling.
>
> Since you claim that it is "pretty trivial to accompish all of those
> with SR..." please point to the document that describes how "trivial"
> it is to accomplish one of those items, namely p2mp path construction,
> with SR.
>
> Yakov.
>

To: Rob Shakir <[email-masked]>
Date: Mon, 9 Sep 2013 10:20:01 -0700
From: Yakov Rekhter <[email-masked]>
Cc: Hannes Gredler <[email-masked]>, "[email-masked]" <[email-masked]>, [email-masked]
Subject: Re: [Status] Summary of STATUS BOF and the next steps

Rob,

> Hannes,
> 
> In-line as rjs>.

in-line...

> On 6 Sep 2013, at 16:27, Hannes Gredler <[email-masked]> wrote:
> 
> > hi stephane,
> > 
> > here is a revised draft charter as per your comments.
> > 
> > ---
> > 
> > <Name-TBD> domain contains a set of routers with the following
> > characteristics:
> > 
> > - They form a connected network
> > - They can forward traffic through any path within the network using
> >  shortest path, or any other (e.g., an explicit) path
> > - They share a common trust model. In this model, any router within
> >  the domain can specify a path between itself and any other router
> >  in the domain. It may then send any packet that passes through it
> >  through any path that it has specified and that is conform to the
> >  security rules. Downstream routers along the path within the <Name-TBD>
> >  domain forward the packet as specified by the router at the head-end
> >  of the path.
> > 
> > The <Name-TBD> working group is chartered for the following ordered
> > list of work items:
> > 
> > - The first goal of the WG is to identify use-cases.
> > - The WG will then define the architecture framework associated with
> >  the security considerations. The architecture framework and security
> >  considerations must address the relations between domains (inter domain).

rjs> It seems a little odd to me that we would identify that there are inter-
rjs> domain issues to solve when there is no suggested use case that seemed 
rjs> to relate to this as a requirement. Any extensions of the technology 
rjs> developed within the WG to be inter-domain can be for future study.

Please note that the above bullet about the security considerations
and inter-domain has been taken verbatim from Stephane's proposal
to extend Hannes' proposed charter. See
http://www.ietf.org/mail-archive/web/status/current/msg00129.html.

Yakov. 

To: Robert Raszuk <[email-masked]>
Date: Mon, 9 Sep 2013 10:01:28 -0700
From: Yakov Rekhter <[email-masked]>
Cc: "[email-masked]" <[email-masked]>
Subject: Re: [Status] Summary of STATUS BOF and the next steps

Robert,

> > i haven't yet identified the code to be deleted, if SR is going 
> > to be a success ;-)
> 
> How about LDP as starter ?
> 
> Which of the below are solved by LDP ? Which LDP functionality will
> not be covered by SR ?
> 
> >>  1. LSP bandwidth reservation
> >>  2. LSP preemption
> >>  3. p2mp path construction
> 
> Note that those are all done today in the control plane. Therefor it
> seems pretty trivial to accomplish all of those with SR using number
> of PCE or PCE like controllers rather then use RSVP-TE for explicit
> path signalling.

Since you claim that it is "pretty trivial to accompish all of those
with SR..." please point to the document that describes how "trivial"
it is to accomplish one of those items, namely p2mp path construction,
with SR.

Yakov.

Date: Mon, 9 Sep 2013 12:50:58 -0400
From: Alia Atlas <[email-masked]>
To: [email-masked]
Cc: Hannes Gredler <[email-masked]>, "[email-masked]" <[email-masked]>, Robert Raszuk <[email-masked]>
Subject: Re: [Status] Summary of STATUS BOF and the next steps

--047d7bdc9db251bce104e5f631ac
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

Hi Stephane,

On Mon, Sep 9, 2013 at 11:51 AM, <[email-masked]> wrote:

> **
> I think the discussion is moving to reviewing details rather than focusin=
g
> anymore on the charter ... :) Let's keep this discussion for the WG
> discussion when it will exist and have a charter and a name :)
>

[Alia] Sure - that discussion was triggered by a claim that a limitation of
SR isn't at all an issue.  Given that one of the discussion points is how
fast to just dive into protocol-extensions because all this architecture
and use-cases isn't critical, I think it is important to consider some of
the assumptions of capability and their implications.

>  Now regarding the points from the last long email exchanges :
>
> - I would also be in favor that interAS discussion must be part of the
> charter : intra-AS is first priority, but interAS is clearly needed : we
> have multiple ASes that would be able to run SR, so interdomain
> SR discussion would be interresting for us. Use case of multiple internal
> ASes is interresting, but dealing with Partners that are also running SR =
in
> their network is interresting also (including security concerns).
>

[Alia] This is useful to hear.

>  - I agree with Hannes point, that we are not here to say SR will replace
> this protocol or this protocol. We have some use case that must be
> addressed, let's find a solution for these. If some people can replace
> totally LDP or RSVP-TE in their network, it's good for them. If some othe=
r
> people are happy with what they have today and they want to keep RSVP-TE
> and LDP, it's fine too ...
> Please just focus on the use case and solutions ...
> I agree that today SR, as its is defined now, may not be able to replace
> LDP or RSVP-TE depending of the use case. And replacing LDP and RSVP-TE i=
s
> not a target ... Many networks, many different use case, many protocol
> usage ! Let's keep a place for everyone :)
>
> - For FRR node protection, let's wait a couple of weeks/months to have th=
e
> WG starting ...  we may probably find something new in this area ... so w=
e
> must not condamn SR today in this area ... it's just starting ... We must
> list this as a use case, and then propose a solution ...
>

[Alia] If we don't have an architecture that supports it, our options are
less.  Fully describing the use-case would be good.  A strong motivation
for RSVP-TE has been its good fast-reroute solutions - covering link, node,
and SRLG.

Regards,
Alia

>  Stephane
>
>
>
>  ------------------------------
> *De :* [email-masked] [mailto:[email-masked]] *De la
> part de* Alia Atlas
> *Envoy=E9 :* lundi 9 septembre 2013 16:57
> *=C0 :* Robert Raszuk
> *Cc :* Hannes Gredler; [email-masked]
>
> *Objet :* Re: [Status] Summary of STATUS BOF and the next steps
>
> Hi Robert,
>
> On Monday, September 9, 2013, Robert Raszuk wrote:
>
>> Hi Alia,
>>
>> >> Creating LFA bypass of each node with when required SR segment going
>> >> far enough that loops are guaranteed not to occur looks like pretty
>> >> easy exercise.
>> >>
>> >> Sorry I have no math prove that this will address any network
>> >> topology, but I also see no reason why it would not.
>> >
>> > [Alia] Robert, you are missing the problem.  The end of each segment
>> has the
>> > same egress
>> > and ingress protection problems that any LSP has.  If a segment just
>> > describes the next interface
>> > or router, how is that router's failure protected against?
>>
>> Why is that difficult ?
>>
>> When I am a transit node and I am forwarding packets to the end of
>> segment  (egress) the awareness of egress being down (from directly
>> connected detection protocol of your choice) I have ability to bypass
>> the failed node with a fixup of removing the end of segment
>> label/header from the packet's header.
>
>
> [Alia] It requires looking beyond the the top/current segment and
> understanding what
> is beneath.  More than just that,it requires setting up the necessary
> different forwarding
> state for all possible combinations.  Of course, if a segment points to a=
n
> LSP or an algorithmically
> computed segment, the next-hop of that is not known by the router before
> the segment starts.
>
> So - to summarize - it requires a router to make forwarding decisions
> based on labels under the
> top of stack (if MPLS) or beyond the current pointer, it blows up the
> forwarding state needed, and
> the router may not know what the segment underneath means in terms of
> next-next hop(s).
>
> If only 1-hop segments are considered, the state expansion and added info
> to read are still needed.
> There are also the concerns about label stack expansion and MTU.
>
> Regards,
> Alia
>
>
>
>
>
>
> and
>>
>> That way the failed egress is bypassed/protected as long as failure
>> continues. The operation is local and uses to it's advantage the
>> global (domain wide) property of repair paths. It in fact get's better
>> as by looking at the next header the steering of the repair traffic
>> can be made optimal.
>>
>> Contrary with labels of local significance such repair will not be
>> possible without employing yet another signalling protocol and I see
>> no good way to make it optimal at all.
>>
>> Regards,
>> R.
>>
> _________________________________________________________________________=
________________________________________________
>
> Ce message et ses pieces jointes peuvent contenir des informations confid=
entielles ou privilegiees et ne doivent donc
> pas etre diffuses, exploites ou copies sans autorisation. Si vous avez re=
cu ce message par erreur, veuillez le signaler
> a l'expediteur et le detruire ainsi que les pieces jointes. Les messages =
electroniques etant susceptibles d'alteration,
> Orange decline toute responsabilite si ce message a ete altere, deforme o=
u falsifie. Merci.
>
> This message and its attachments may contain confidential or privileged i=
nformation that may be protected by law;
> they should not be distributed, used or copied without authorisation.
> If you have received this email in error, please notify the sender and de=
lete this message and its attachments.
> As emails may be altered, Orange is not liable for messages that have bee=
n modified, changed or falsified.
> Thank you.
>
>

--047d7bdc9db251bce104e5f631ac
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">Hi Stephane,<br><div class=3D"gmail_extra"><br><br><div cl=
ass=3D"gmail_quote">On Mon, Sep 9, 2013 at 11:51 AM,  <span dir=3D"ltr">&lt=
;<a href=3D"mailto:[email-masked]" target=3D"_blank">stephan=
[email-masked]</a>&gt;</span> wrote:<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex"><u></u>

<div>
<div dir=3D"ltr" align=3D"left"><span><font face=3D"Arial">I=20
think the discussion is moving to reviewing details rather than focusing an=
ymore=20
on the charter ... :) Let&#39;s keep this discussion for the WG discussion =
when it=20
will exist and have a charter and a name :)</font></span></div></div></bloc=
kquote><div><br></div><div>[Alia] Sure - that discussion was triggered by a=
 claim that a limitation of SR isn&#39;t at all an issue. =A0Given that one=
 of the discussion points is how fast to just dive into protocol-extensions=
 because all this architecture and use-cases isn&#39;t critical, I think it=
 is important to consider some of the assumptions of capability and their i=
mplications. =A0=A0</div>
<div>=A0</div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;=
border-left:1px #ccc solid;padding-left:1ex"><div><div dir=3D"ltr" align=3D=
"left">=A0<span style=3D"font-family:Arial">Now regarding the points from t=
he last long email exchanges=20
:</span></div>
<div dir=3D"ltr" align=3D"left"><span><font face=3D"Arial"></font></span>=
=A0</div>
<div dir=3D"ltr" align=3D"left"><span><font face=3D"Arial">-=20
I would also be in favor that interAS discussion must be part of the charte=
r :=20
intra-AS is first priority, but interAS is clearly needed : we have multipl=
e=20
ASes that would be able to run SR, so interdomain SR=A0discussion would be=
=20
interresting for us. Use case of multiple internal ASes is interresting, bu=
t=20
dealing with Partners that are also running SR in their network is interres=
ting=20
also (including security concerns).</font></span></div></div></blockquote><=
div><br></div><div>[Alia] This is useful to hear. =A0</div><div>=A0</div><b=
lockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px =
#ccc solid;padding-left:1ex">
<div>
<div dir=3D"ltr" align=3D"left"><span><font face=3D"Arial"></font></span>=
=A0<span style=3D"font-family:Arial">-=20
I agree with Hannes point, that we are not here to say SR will replace this=
=20
protocol or this protocol. We have some use case that must be addressed, le=
t&#39;s=20
find a solution for these. If some people can replace totally LDP or RSVP-T=
E in=20
their network, it&#39;s good for them. If some other people are happy with =
what they=20
have today and they want to keep RSVP-TE and LDP, it&#39;s fine too=20
...</span></div>
<div dir=3D"ltr" align=3D"left"><span><font face=3D"Arial">Please just focu=
s on the use case and solutions ... </font></span></div>
<div dir=3D"ltr" align=3D"left"><span><font face=3D"Arial">I=20
agree that today SR, as its is defined now, may not be able to replace LDP =
or=20
RSVP-TE depending of the use case. And replacing LDP and RSVP-TE is not a t=
arget=20
... Many networks, many different use case, many protocol usage !=20
Let&#39;s=A0keep a place for everyone :)</font></span></div>
<div dir=3D"ltr" align=3D"left"><span><font face=3D"Arial"></font></span>=
=A0</div>
<div dir=3D"ltr" align=3D"left"><span><font face=3D"Arial">-=20
For FRR node protection, let&#39;s wait a couple of weeks/months to have th=
e WG=20
starting ...=A0 we may probably find something new in this area ... so we=
=20
must not condamn SR today in this area ... it&#39;s just starting ... We mu=
st list=20
this as a use case, and then propose a solution ...</font></span></div></di=
v></blockquote><div><br></div><div>[Alia] If we don&#39;t have an architect=
ure that supports it, our options are less. =A0Fully describing the use-cas=
e would be good. =A0A strong motivation for RSVP-TE has been its good fast-=
reroute solutions - covering link, node, and SRLG.</div>
<div><br></div><div>Regards,</div><div>Alia</div><div>=A0</div><blockquote =
class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid=
;padding-left:1ex"><div>
<div dir=3D"ltr" align=3D"left"><span><font face=3D"Arial"></font></span>=
=A0<span style=3D"font-family:Arial">Stephane</span></div>
<div dir=3D"ltr" align=3D"left"><span>=A0</span></div>
<div dir=3D"ltr" align=3D"left"><span><font face=3D"Arial"></font></span>=
=A0</div><br>
<blockquote dir=3D"ltr" style=3D"MARGIN-RIGHT:0px">
  <div lang=3D"fr" dir=3D"ltr" align=3D"left">
  <hr>
  <font face=3D"Tahoma"><b>De=A0:</b> <a href=3D"mailto:status-bounces@ietf=
.org" target=3D"_blank">[email-masked]</a>=20
  [mailto:<a href=3D"mailto:[email-masked]" target=3D"_blank">stat=
[email-masked]</a>] <b>De la part de</b> Alia=20
  Atlas<br><b>Envoy=E9=A0:</b> lundi 9 septembre 2013 16:57<br><b>=C0=A0:</=
b>=20
  Robert Raszuk<br><b>Cc=A0:</b> Hannes Gredler;=20
  <a href=3D"mailto:[email-masked]" target=3D"_blank">[email-masked]</a><=
div class=3D"im"><br><b>Objet=A0:</b> Re: [Status] Summary of STATUS BOF an=
d=20
  the next steps<br></div></font><br></div><div><div class=3D"h5">
  <div></div>Hi Robert,<br><br>On Monday, September 9, 2013, Robert Raszuk=
=20
  wrote:<br>
  <blockquote class=3D"gmail_quote" style=3D"PADDING-LEFT:1ex;MARGIN:0px 0p=
x 0px 0.8ex;BORDER-LEFT:#ccc 1px solid">Hi=20
    Alia,<br><br>&gt;&gt; Creating LFA bypass of each node with when requir=
ed SR=20
    segment going<br>&gt;&gt; far enough that loops are guaranteed not to o=
ccur=20
    looks like pretty<br>&gt;&gt; easy exercise.<br>&gt;&gt;<br>&gt;&gt; So=
rry I=20
    have no math prove that this will address any network<br>&gt;&gt; topol=
ogy,=20
    but I also see no reason why it would not.<br>&gt;<br>&gt; [Alia] Rober=
t,=20
    you are missing the problem. =A0The end of each segment has the<br>&gt;=
=20
    same egress<br>&gt; and ingress protection problems that any LSP has.=
=20
    =A0If a segment just<br>&gt; describes the next interface<br>&gt; or=20
    router, how is that router&#39;s failure protected against?<br><br>Why =
is that=20
    difficult ?<br><br>When I am a transit node and I am forwarding packets=
 to=20
    the end of<br>segment =A0(egress) the awareness of egress being down=20
    (from directly<br>connected detection protocol of your choice) I have=
=20
    ability to bypass<br>the failed node with a fixup of removing the end o=
f=20
    segment<br>label/header from the packet&#39;s header.</blockquote>
  <div><br></div>
  <div>[Alia] It requires looking beyond the the top/current segment and=20
  understanding what</div>
  <div>is beneath. =A0More than just that,it requires setting up the=20
  necessary different forwarding</div>
  <div>state for all possible combinations. =A0Of course, if a segment poin=
ts=20
  to an LSP or an algorithmically</div>
  <div>computed segment, the next-hop of that is not known by the router be=
fore=20
  the segment starts.</div>
  <div><br></div>
  <div>So - to summarize - it requires a router to make forwarding decision=
s=20
  based on labels under the</div>
  <div>top of stack (if MPLS) or beyond the current pointer, it blows up th=
e=20
  forwarding state needed, and</div>
  <div>the router may not know what the segment underneath means in terms o=
f=20
  next-next hop(s).</div>
  <div><br></div>
  <div>If only 1-hop segments are considered, the state expansion and added=
 info=20
  to read are still needed.</div>
  <div>There are also the concerns about label stack expansion and=20
  MTU.<span></span></div>
  <div><br></div>
  <div>Regards,</div>
  <div>Alia</div>
  <div><br></div>
  <div><br></div>
  <div><br></div>
  <div><br></div>
  <div><br></div>
  <div><br></div>and
  <blockquote class=3D"gmail_quote" style=3D"PADDING-LEFT:1ex;MARGIN:0px 0p=
x 0px 0.8ex;BORDER-LEFT:#ccc 1px solid">That=20
    way the failed egress is bypassed/protected as long as failure<br>conti=
nues.=20
    The operation is local and uses to it&#39;s advantage the<br>global (do=
main=20
    wide) property of repair paths. It in fact get&#39;s better<br>as by lo=
oking at=20
    the next header the steering of the repair traffic<br>can be made=20
    optimal.<br><br>Contrary with labels of local significance such repair =
will=20
    not be<br>possible without employing yet another signalling protocol an=
d I=20
    see<br>no good way to make it optimal at=20
  all.<br><br>Regards,<br>R.<br></blockquote></div></div></blockquote><div =
class=3D"im"><pre>_________________________________________________________=
________________________________________________________________

Ce message et ses pieces jointes peuvent contenir des informations confiden=
tielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu=
 ce message par erreur, veuillez le signaler
a l&#39;expediteur et le detruire ainsi que les pieces jointes. Les message=
s electroniques etant susceptibles d&#39;alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou =
falsifie. Merci.

This message and its attachments may contain confidential or privileged inf=
ormation that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and dele=
te this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been =
modified, changed or falsified.
Thank you.
</pre></div></div>
</blockquote></div><br></div></div>

--047d7bdc9db251bce104e5f631ac--

Date: Mon, 9 Sep 2013 12:45:07 -0400
From: Alia Atlas <[email-masked]>
To: Robert Raszuk <[email-masked]>
Cc: Hannes Gredler <[email-masked]>, "[email-masked]" <[email-masked]>
Subject: Re: [Status] Summary of STATUS BOF and the next steps

--047d7b10cf0d5f6f4404e5f61c8f
Content-Type: text/plain; charset=ISO-8859-1

Hi Robert,

Here's my last message on this - because the key point is not really the
details of how and at what cost this could be done, but that there can be
architectural implications and the proper architecture and use-cases needs
to be nailed down before the protocol aspects.

On Mon, Sep 9, 2013 at 11:44 AM, Robert Raszuk <[email-masked]> wrote:

> > unless you are also stripping the segment extensions.
>
> Of course you should strip it. What's the point to keep it if you know
> the segment endpoint is down ?
>

[Alia] First, this would be stripping all the segment information from the
IPv6 packet to ensure it doesn't loop again.  I assume the alternate would
be to move the context past the current segment to newly inserted segments
for the alternate.  Presumably, keeping the history of segments crossed is
valuable for IPv6 or else the proposed IPv6 extensions wouldn't focus on
that.

> > router respects the  segments, then this will still require reading
> ahead in
> > the segment list - with all of the extra microcode and handling that
> > implies.
>
> True.
>
> > Instead of 1 forwarding entry per neighbor, a router will need 1 for each
> > neighbor's neighbor and that assumes label or segment manipulation
> doesn't
> > need to be differentiated.
>
> Not really "neighbor's neighbor". At most to each segment end point,
> but again subject to grouping.

[Alia] No - EXACTLY to each neighbor's neighbor.  For each segment that
ends at a neighbor N, the traffic in that segment would need to be looked
up (using MPLS terms) in the context of neighbor N and, having prepopulated
what label to swap to, be forwarded to the appropriate neighbor X of N.
The point is to protect the segment end-points.  This would have to be done
for protecting traffic going to every neighbor Y of N because N's
advertised segments and whether traffic is using them is unknown.

[Alia] An alternate, of course, is to advertise 1-hop+ segments where the
segment says end at N but the next-next-hop should be X.  That removes the
need for context label space at the cost of additional flooding - and
wouldn't work as well for algorithmically-based segments because of
reflooding upon topology changes.

> This would only work for 1-hop globally understood segments - though with
> > more computation, it might be possible for some algorithmically-based
> > segments to be figured out.
>
> I am not sure where "1-hop" limitation comes from.
>
[Alia] How does the router S know what its neighbor N meant by segment-id L
in specific terms of the next-hop that N would forward the packet to?

> > To be clear,  IMHO,  there are some interesting use-cases for
> > segment-routing, but it also has limitations that need to be
> > well-understood.  We need to define the architecture clearly and the
> > requirements and trade-offs.  We can't just assume that it will all work.
>
> I fully agree.

[Alia] For the charter discussion, that's the important part.  I,
personally, want to see the architecture and use-cases clearly written out
(and there are some good starts) in a WG consensus process so that what is
and isn't feasible would be well understood.

Regards,
Alia

--047d7b10cf0d5f6f4404e5f61c8f
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">Hi Robert,<br><div class=3D"gmail_extra"><br></div><div cl=
ass=3D"gmail_extra">Here&#39;s my last message on this - because the key po=
int is not really the details of how and at what cost this could be done, b=
ut that there can be architectural implications and the proper architecture=
 and use-cases needs to be nailed down before the protocol aspects.<br>
<br><div class=3D"gmail_quote">On Mon, Sep 9, 2013 at 11:44 AM, Robert Rasz=
uk <span dir=3D"ltr">&lt;<a href=3D"mailto:[email-masked]" target=3D"_bl=
ank">[email-masked]</a>&gt;</span> wrote:<br><blockquote class=3D"gmail_=
quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1=
ex">
<div class=3D"im">&gt; unless you are also stripping the segment extensions=
.<br>
<br>
</div>Of course you should strip it. What&#39;s the point to keep it if you=
 know<br>
the segment endpoint is down ?<br></blockquote><div><br></div><div>[Alia] F=
irst, this would be stripping all the segment information from the IPv6 pac=
ket to ensure it doesn&#39;t loop again. =A0I assume the alternate would be=
 to move the context past the current segment to newly inserted segments fo=
r the alternate. =A0Presumably, keeping the history of segments crossed is =
valuable for IPv6 or else the proposed IPv6 extensions wouldn&#39;t focus o=
n that.</div>
<div>=A0</div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;=
border-left:1px #ccc solid;padding-left:1ex">
<div class=3D"im">&gt; router respects the =A0segments, then this will stil=
l require reading ahead in<br>
&gt; the segment list - with all of the extra microcode and handling that<b=
r>
&gt; implies.<br>
<br>
</div>True.<br>
<div class=3D"im"><br>
&gt; Instead of 1 forwarding entry per neighbor, a router will need 1 for e=
ach<br>
&gt; neighbor&#39;s neighbor and that assumes label or segment manipulation=
 doesn&#39;t<br>
&gt; need to be differentiated.<br>
<br>
</div>Not really &quot;neighbor&#39;s neighbor&quot;. At most to each segme=
nt end point,<br>
but again subject to grouping.</blockquote><div>=A0</div><div>[Alia] No - E=
XACTLY to each neighbor&#39;s neighbor. =A0For each segment that ends at a =
neighbor N, the traffic in that segment would need to be looked up (using M=
PLS terms) in the context of neighbor N and, having prepopulated what label=
 to swap to, be forwarded to the appropriate neighbor X of N. =A0 The point=
 is to protect the segment end-points. =A0This would have to be done for pr=
otecting traffic going to every neighbor Y of N because N&#39;s advertised =
segments and whether traffic is using them is unknown.</div>
<div><br></div><div>[Alia] An alternate, of course, is to advertise 1-hop+ =
segments where the segment says end at N but the next-next-hop should be X.=
 =A0That removes the need for context label space at the cost of additional=
 flooding - and wouldn&#39;t work as well for algorithmically-based segment=
s because of reflooding upon topology changes.</div>
<div><br></div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex=
;border-left:1px #ccc solid;padding-left:1ex"><div class=3D"im">
&gt; This would only work for 1-hop globally understood segments - though w=
ith<br>
&gt; more computation, it might be possible for some algorithmically-based<=
br>
&gt; segments to be figured out.<br>
<br>
</div>I am not sure where &quot;1-hop&quot; limitation comes from.<br></blo=
ckquote><div>[Alia] How does the router S know what its neighbor N meant by=
 segment-id L in specific terms of the next-hop that N would forward the pa=
cket to?</div>
<div>=A0</div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;=
border-left:1px #ccc solid;padding-left:1ex">
<div class=3D"im">&gt; To be clear, =A0IMHO, =A0there are some interesting =
use-cases for<br>
&gt; segment-routing, but it also has limitations that need to be<br>
&gt; well-understood. =A0We need to define the architecture clearly and the=
<br>
&gt; requirements and trade-offs. =A0We can&#39;t just assume that it will =
all work.<br>
<br>
</div>I fully agree.</blockquote><div>=A0</div></div>[Alia] For the charter=
 discussion, that&#39;s the important part. =A0I, personally, want to see t=
he architecture and use-cases clearly written out (and there are some good =
starts) in a WG consensus process so that what is and isn&#39;t feasible wo=
uld be well understood.</div>
<div class=3D"gmail_extra"><br></div><div class=3D"gmail_extra">Regards,</d=
iv><div class=3D"gmail_extra">Alia</div></div>

--047d7b10cf0d5f6f4404e5f61c8f--

Sender: [email-masked]
Date: Mon, 9 Sep 2013 17:44:22 +0200
From: Robert Raszuk <[email-masked]>
To: Alia Atlas <[email-masked]>
Cc: Hannes Gredler <[email-masked]>, "[email-masked]" <[email-masked]>
Subject: Re: [Status] Summary of STATUS BOF and the next steps

> unless you are also stripping the segment extensions.

Of course you should strip it. What's the point to keep it if you know
the segment endpoint is down ?

> router respects the  segments, then this will still require reading ahead in
> the segment list - with all of the extra microcode and handling that
> implies.

True.

> Instead of 1 forwarding entry per neighbor, a router will need 1 for each
> neighbor's neighbor and that assumes label or segment manipulation doesn't
> need to be differentiated.

Not really "neighbor's neighbor". At most to each segment end point,
but again subject to grouping.

> This would only work for 1-hop globally understood segments - though with
> more computation, it might be possible for some algorithmically-based
> segments to be figured out.

I am not sure where "1-hop" limitation comes from.

> To be clear,  IMHO,  there are some interesting use-cases for
> segment-routing, but it also has limitations that need to be
> well-understood.  We need to define the architecture clearly and the
> requirements and trade-offs.  We can't just assume that it will all work.

I fully agree.

r.

From: <[email-masked]>
To: Alia Atlas <[email-masked]>, Robert Raszuk <[email-masked]>
Date: Mon, 9 Sep 2013 17:51:52 +0200
Accept-Language: fr-FR
acceptlanguage: fr-FR
Cc: Hannes Gredler <[email-masked]>, "[email-masked]" <[email-masked]>
Subject: Re: [Status] Summary of STATUS BOF and the next steps

--_000_EEE55384044474429A926C625D0FCC81096327908EPUEXCB2Fnante_
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

I think the discussion is moving to reviewing details rather than focusing =
anymore on the charter ... :) Let's keep this discussion for the WG discuss=
ion when it will exist and have a charter and a name :)

Now regarding the points from the last long email exchanges :

- I would also be in favor that interAS discussion must be part of the char=
ter : intra-AS is first priority, but interAS is clearly needed : we have m=
ultiple ASes that would be able to run SR, so interdomain SR discussion wou=
ld be interresting for us. Use case of multiple internal ASes is interresti=
ng, but dealing with Partners that are also running SR in their network is =
interresting also (including security concerns).

- I agree with Hannes point, that we are not here to say SR will replace th=
is protocol or this protocol. We have some use case that must be addressed,=
 let's find a solution for these. If some people can replace totally LDP or=
 RSVP-TE in their network, it's good for them. If some other people are hap=
py with what they have today and they want to keep RSVP-TE and LDP, it's fi=
ne too ...
Please just focus on the use case and solutions ...
I agree that today SR, as its is defined now, may not be able to replace LD=
P or RSVP-TE depending of the use case. And replacing LDP and RSVP-TE is no=
t a target ... Many networks, many different use case, many protocol usage =
! Let's keep a place for everyone :)

- For FRR node protection, let's wait a couple of weeks/months to have the =
WG starting ...  we may probably find something new in this area ... so we =
must not condamn SR today in this area ... it's just starting ... We must l=
ist this as a use case, and then propose a solution ...

Stephane

________________________________
De : [email-masked] [mailto:[email-masked]] De la part de=
 Alia Atlas
Envoy=E9 : lundi 9 septembre 2013 16:57
=C0 : Robert Raszuk
Cc : Hannes Gredler; [email-masked]
Objet : Re: [Status] Summary of STATUS BOF and the next steps

Hi Robert,

On Monday, September 9, 2013, Robert Raszuk wrote:
Hi Alia,

>> Creating LFA bypass of each node with when required SR segment going
>> far enough that loops are guaranteed not to occur looks like pretty
>> easy exercise.
>>
>> Sorry I have no math prove that this will address any network
>> topology, but I also see no reason why it would not.
>
> [Alia] Robert, you are missing the problem.  The end of each segment has =
the
> same egress
> and ingress protection problems that any LSP has.  If a segment just
> describes the next interface
> or router, how is that router's failure protected against?

Why is that difficult ?

When I am a transit node and I am forwarding packets to the end of
segment  (egress) the awareness of egress being down (from directly
connected detection protocol of your choice) I have ability to bypass
the failed node with a fixup of removing the end of segment
label/header from the packet's header.

[Alia] It requires looking beyond the the top/current segment and understan=
ding what
is beneath.  More than just that,it requires setting up the necessary diffe=
rent forwarding
state for all possible combinations.  Of course, if a segment points to an =
LSP or an algorithmically
computed segment, the next-hop of that is not known by the router before th=
e segment starts.

So - to summarize - it requires a router to make forwarding decisions based=
 on labels under the
top of stack (if MPLS) or beyond the current pointer, it blows up the forwa=
rding state needed, and
the router may not know what the segment underneath means in terms of next-=
next hop(s).

If only 1-hop segments are considered, the state expansion and added info t=
o read are still needed.
There are also the concerns about label stack expansion and MTU.

Regards,
Alia

and
That way the failed egress is bypassed/protected as long as failure
continues. The operation is local and uses to it's advantage the
global (domain wide) property of repair paths. It in fact get's better
as by looking at the next header the steering of the repair traffic
can be made optimal.

Contrary with labels of local significance such repair will not be
possible without employing yet another signalling protocol and I see
no good way to make it optimal at all.

Regards,
R.

___________________________________________________________________________=
______________________________________________

Ce message et ses pieces jointes peuvent contenir des informations confiden=
tielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu=
 ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages el=
ectroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou =
falsifie. Merci.

This message and its attachments may contain confidential or privileged inf=
ormation that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and dele=
te this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been =
modified, changed or falsified.
Thank you.

--_000_EEE55384044474429A926C625D0FCC81096327908EPUEXCB2Fnante_
Content-Type: text/html; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META http-equiv=3DContent-Type content=3D"text/html; charset=3Diso-8859-1">
<META content=3D"MSHTML 6.00.6000.21264" name=3DGENERATOR></HEAD>
<BODY>
<DIV dir=3Dltr align=3Dleft><SPAN class=3D083113815-09092013><FONT face=3DA=
rial size=3D2>I=20
think the discussion is moving to reviewing details rather than focusing an=
ymore=20
on the charter ... :) Let's keep this discussion for the WG discussion when=
 it=20
will exist and have a charter and a name :)</FONT></SPAN></DIV>
<DIV dir=3Dltr align=3Dleft><SPAN class=3D083113815-09092013><FONT face=3DA=
rial=20
size=3D2></FONT></SPAN>&nbsp;</DIV>
<DIV dir=3Dltr align=3Dleft><SPAN class=3D083113815-09092013><FONT face=3DA=
rial=20
size=3D2>Now regarding the points from the last long email exchanges=20
:</FONT></SPAN></DIV>
<DIV dir=3Dltr align=3Dleft><SPAN class=3D083113815-09092013><FONT face=3DA=
rial=20
size=3D2></FONT></SPAN>&nbsp;</DIV>
<DIV dir=3Dltr align=3Dleft><SPAN class=3D083113815-09092013><FONT face=3DA=
rial size=3D2>-=20
I would also be in favor that interAS discussion must be part of the charte=
r :=20
intra-AS is first priority, but interAS is clearly needed : we have multipl=
e=20
ASes that would be able to run SR, so interdomain SR&nbsp;discussion would =
be=20
interresting for us. Use case of multiple internal ASes is interresting, bu=
t=20
dealing with Partners that are also running SR in their network is interres=
ting=20
also (including security concerns).</FONT></SPAN></DIV>
<DIV dir=3Dltr align=3Dleft><SPAN class=3D083113815-09092013><FONT face=3DA=
rial=20
size=3D2></FONT></SPAN>&nbsp;</DIV>
<DIV dir=3Dltr align=3Dleft><SPAN class=3D083113815-09092013><FONT face=3DA=
rial size=3D2>-=20
I agree with Hannes point, that we are not here to say SR will replace this=
=20
protocol or this protocol. We have some use case that must be addressed, le=
t's=20
find a solution for these. If some people can replace totally LDP or RSVP-T=
E in=20
their network, it's good for them. If some other people are happy with what=
 they=20
have today and they want to keep RSVP-TE and LDP, it's fine too=20
...</FONT></SPAN></DIV>
<DIV dir=3Dltr align=3Dleft><SPAN class=3D083113815-09092013><FONT face=3DA=
rial=20
size=3D2>Please just focus on the use case and solutions ... </FONT></SPAN>=
</DIV>
<DIV dir=3Dltr align=3Dleft><SPAN class=3D083113815-09092013><FONT face=3DA=
rial size=3D2>I=20
agree that today SR, as its is defined now, may not be able to replace LDP =
or=20
RSVP-TE depending of the use case. And replacing LDP and RSVP-TE is not a t=
arget=20
... Many networks, many different use case, many protocol usage !=20
Let's&nbsp;keep a place for everyone :)</FONT></SPAN></DIV>
<DIV dir=3Dltr align=3Dleft><SPAN class=3D083113815-09092013><FONT face=3DA=
rial=20
size=3D2></FONT></SPAN>&nbsp;</DIV>
<DIV dir=3Dltr align=3Dleft><SPAN class=3D083113815-09092013><FONT face=3DA=
rial size=3D2>-=20
For FRR node protection, let's wait a couple of weeks/months to have the WG=
=20
starting ...&nbsp; we may probably find something new in this area ... so w=
e=20
must not condamn SR today in this area ... it's just starting ... We must l=
ist=20
this as a use case, and then propose a solution ...</FONT></SPAN></DIV>
<DIV dir=3Dltr align=3Dleft><SPAN class=3D083113815-09092013><FONT face=3DA=
rial=20
size=3D2></FONT></SPAN>&nbsp;</DIV>
<DIV dir=3Dltr align=3Dleft><SPAN class=3D083113815-09092013><FONT face=3DA=
rial=20
size=3D2></FONT></SPAN>&nbsp;</DIV>
<DIV dir=3Dltr align=3Dleft><SPAN class=3D083113815-09092013><FONT face=3DA=
rial=20
size=3D2></FONT></SPAN>&nbsp;</DIV>
<DIV dir=3Dltr align=3Dleft><SPAN class=3D083113815-09092013><FONT face=3DA=
rial=20
size=3D2>Stephane</FONT></SPAN></DIV>
<DIV dir=3Dltr align=3Dleft><SPAN class=3D083113815-09092013>&nbsp;</SPAN><=
/DIV>
<DIV dir=3Dltr align=3Dleft><SPAN class=3D083113815-09092013><FONT face=3DA=
rial=20
size=3D2></FONT></SPAN>&nbsp;</DIV><BR>
<BLOCKQUOTE dir=3Dltr style=3D"MARGIN-RIGHT: 0px">
  <DIV class=3DOutlookMessageHeader lang=3Dfr dir=3Dltr align=3Dleft>
  <HR tabIndex=3D-1>
  <FONT face=3DTahoma size=3D2><B>De&nbsp;:</B> [email-masked]=20
  [mailto:[email-masked]] <B>De la part de</B> Alia=20
  Atlas<BR><B>Envoy=E9&nbsp;:</B> lundi 9 septembre 2013 16:57<BR><B>=C0&nb=
sp;:</B>=20
  Robert Raszuk<BR><B>Cc&nbsp;:</B> Hannes Gredler;=20
  [email-masked]<BR><B>Objet&nbsp;:</B> Re: [Status] Summary of STATUS BOF=
 and=20
  the next steps<BR></FONT><BR></DIV>
  <DIV></DIV>Hi Robert,<BR><BR>On Monday, September 9, 2013, Robert Raszuk=
=20
  wrote:<BR>
  <BLOCKQUOTE class=3Dgmail_quote=20
  style=3D"PADDING-LEFT: 1ex; MARGIN: 0px 0px 0px 0.8ex; BORDER-LEFT: #ccc =
1px solid">Hi=20
    Alia,<BR><BR>&gt;&gt; Creating LFA bypass of each node with when requir=
ed SR=20
    segment going<BR>&gt;&gt; far enough that loops are guaranteed not to o=
ccur=20
    looks like pretty<BR>&gt;&gt; easy exercise.<BR>&gt;&gt;<BR>&gt;&gt; So=
rry I=20
    have no math prove that this will address any network<BR>&gt;&gt; topol=
ogy,=20
    but I also see no reason why it would not.<BR>&gt;<BR>&gt; [Alia] Rober=
t,=20
    you are missing the problem. &nbsp;The end of each segment has the<BR>&=
gt;=20
    same egress<BR>&gt; and ingress protection problems that any LSP has.=
=20
    &nbsp;If a segment just<BR>&gt; describes the next interface<BR>&gt; or=
=20
    router, how is that router's failure protected against?<BR><BR>Why is t=
hat=20
    difficult ?<BR><BR>When I am a transit node and I am forwarding packets=
 to=20
    the end of<BR>segment &nbsp;(egress) the awareness of egress being down=
=20
    (from directly<BR>connected detection protocol of your choice) I have=
=20
    ability to bypass<BR>the failed node with a fixup of removing the end o=
f=20
    segment<BR>label/header from the packet's header.</BLOCKQUOTE>
  <DIV><BR></DIV>
  <DIV>[Alia] It requires looking beyond the the top/current segment and=20
  understanding what</DIV>
  <DIV>is beneath. &nbsp;More than just that,it requires setting up the=20
  necessary different forwarding</DIV>
  <DIV>state for all possible combinations. &nbsp;Of course, if a segment p=
oints=20
  to an LSP or an algorithmically</DIV>
  <DIV>computed segment, the next-hop of that is not known by the router be=
fore=20
  the segment starts.</DIV>
  <DIV><BR></DIV>
  <DIV>So - to summarize - it requires a router to make forwarding decision=
s=20
  based on labels under the</DIV>
  <DIV>top of stack (if MPLS) or beyond the current pointer, it blows up th=
e=20
  forwarding state needed, and</DIV>
  <DIV>the router may not know what the segment underneath means in terms o=
f=20
  next-next hop(s).</DIV>
  <DIV><BR></DIV>
  <DIV>If only 1-hop segments are considered, the state expansion and added=
 info=20
  to read are still needed.</DIV>
  <DIV>There are also the concerns about label stack expansion and=20
  MTU.<SPAN></SPAN></DIV>
  <DIV><BR></DIV>
  <DIV>Regards,</DIV>
  <DIV>Alia</DIV>
  <DIV><BR></DIV>
  <DIV><BR></DIV>
  <DIV><BR></DIV>
  <DIV><BR></DIV>
  <DIV><BR></DIV>
  <DIV><BR></DIV>and
  <BLOCKQUOTE class=3Dgmail_quote=20
  style=3D"PADDING-LEFT: 1ex; MARGIN: 0px 0px 0px 0.8ex; BORDER-LEFT: #ccc =
1px solid">That=20
    way the failed egress is bypassed/protected as long as failure<BR>conti=
nues.=20
    The operation is local and uses to it's advantage the<BR>global (domain=
=20
    wide) property of repair paths. It in fact get's better<BR>as by lookin=
g at=20
    the next header the steering of the repair traffic<BR>can be made=20
    optimal.<BR><BR>Contrary with labels of local significance such repair =
will=20
    not be<BR>possible without employing yet another signalling protocol an=
d I=20
    see<BR>no good way to make it optimal at=20
  all.<BR><BR>Regards,<BR>R.<BR></BLOCKQUOTE></BLOCKQUOTE><PRE>____________=
___________________________________________________________________________=
__________________________________

Ce message et ses pieces jointes peuvent contenir des informations confiden=
tielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu=
 ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages el=
ectroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou =
falsifie. Merci.

This message and its attachments may contain confidential or privileged inf=
ormation that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and dele=
te this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been =
modified, changed or falsified.
Thank you.
</PRE></BODY></HTML>

--_000_EEE55384044474429A926C625D0FCC81096327908EPUEXCB2Fnante_--

Date: Mon, 9 Sep 2013 11:31:38 -0400
From: Alia Atlas <[email-masked]>
To: Robert Raszuk <[email-masked]>
Cc: Hannes Gredler <[email-masked]>, [email-masked]
Subject: Re: [Status] Summary of STATUS BOF and the next steps

--047d7bd76bb29ae99004e5f515c5
Content-Type: text/plain; charset=ISO-8859-1

On Sep 9, 2013 11:08 AM, "Robert Raszuk" <[email-masked]> wrote:
>
> Please notice that if we assume IPv6 forwarding the IPv6 header will
> always contain destination IP address (most often BGP next hop in the
> overlay) and included extension headers will provide just hints for
> the segments.
>
> Therefor the complication you describe with MPLS based forwarding I
> see non existent with IP forwarding paradigm.

[Alia] A strong desire doesn't make it so.   First, in IPv6, if the segment
info is just a hint, then ignoring it on failure could cause the traffic to
loop unless you are also stripping the segment extensions.  Second, if the
router respects the  segments, then this will still require reading ahead
in the segment list - with all of the extra microcode and handling that
implies.  It doesn't violate the existing architecture only because that
hasn't been fully defined.

> As far as state explosion .. I easily see a lot of room for
> optimization as it will be very often the case that bypass can be
> shared by many destinations.

Instead of 1 forwarding entry per neighbor, a router will need 1 for each
neighbor's neighbor and that assumes label or segment manipulation doesn't
need to be differentiated.

This would only work for 1-hop globally understood segments - though with
more computation, it might be possible for some algorithmically-based
segments to be figured out.

There are also the details around updating the segment list for
fast-reroute and what impact that has.

To be clear,  IMHO,  there are some interesting use-cases for
segment-routing, but it also has limitations that need to be
well-understood.  We need to define the architecture clearly and the
requirements and trade-offs.  We can't just assume that it will all work.

Alia

> Best regards,
> R.
>
>
>
> On Mon, Sep 9, 2013 at 4:56 PM, Alia Atlas <[email-masked]> wrote:
> > Hi Robert,
> >
> >
> > On Monday, September 9, 2013, Robert Raszuk wrote:
> >>
> >> Hi Alia,
> >>
> >> >> Creating LFA bypass of each node with when required SR segment going
> >> >> far enough that loops are guaranteed not to occur looks like pretty
> >> >> easy exercise.
> >> >>
> >> >> Sorry I have no math prove that this will address any network
> >> >> topology, but I also see no reason why it would not.
> >> >
> >> > [Alia] Robert, you are missing the problem.  The end of each segment
has
> >> > the
> >> > same egress
> >> > and ingress protection problems that any LSP has.  If a segment just
> >> > describes the next interface
> >> > or router, how is that router's failure protected against?
> >>
> >> Why is that difficult ?
> >>
> >> When I am a transit node and I am forwarding packets to the end of
> >> segment  (egress) the awareness of egress being down (from directly
> >> connected detection protocol of your choice) I have ability to bypass
> >> the failed node with a fixup of removing the end of segment
> >> label/header from the packet's header.
> >
> >
> > [Alia] It requires looking beyond the the top/current segment and
> > understanding what
> > is beneath.  More than just that,it requires setting up the necessary
> > different forwarding
> > state for all possible combinations.  Of course, if a segment points to
an
> > LSP or an algorithmically
> > computed segment, the next-hop of that is not known by the router
before the
> > segment starts.
> >
> > So - to summarize - it requires a router to make forwarding decisions
based
> > on labels under the
> > top of stack (if MPLS) or beyond the current pointer, it blows up the
> > forwarding state needed, and
> > the router may not know what the segment underneath means in terms of
> > next-next hop(s).
> >
> > If only 1-hop segments are considered, the state expansion and added
info to
> > read are still needed.
> > There are also the concerns about label stack expansion and MTU.
> >
> > Regards,
> > Alia
> >
> >
> >
> >
> >
> >
> > and
> >>
> >> That way the failed egress is bypassed/protected as long as failure
> >> continues. The operation is local and uses to it's advantage the
> >> global (domain wide) property of repair paths. It in fact get's better
> >> as by looking at the next header the steering of the repair traffic
> >> can be made optimal.
> >>
> >> Contrary with labels of local significance such repair will not be
> >> possible without employing yet another signalling protocol and I see
> >> no good way to make it optimal at all.
> >>
> >> Regards,
> >> R.

--047d7bd76bb29ae99004e5f515c5
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<p dir=3D"ltr"><br>
On Sep 9, 2013 11:08 AM, &quot;Robert Raszuk&quot; &lt;<a href=3D"mailto:ro=
[email-masked]">[email-masked]</a>&gt; wrote:<br>
&gt;<br>
&gt; Please notice that if we assume IPv6 forwarding the IPv6 header will<b=
r>
&gt; always contain destination IP address (most often BGP next hop in the<=
br>
&gt; overlay) and included extension headers will provide just hints for<br=
>
&gt; the segments.<br>
&gt;<br>
&gt; Therefor the complication you describe with MPLS based forwarding I<br=
>
&gt; see non existent with IP forwarding paradigm.</p>
<p dir=3D"ltr">[Alia] A strong desire doesn&#39;t make it so.=A0=A0 First, =
in IPv6, if the segment info is just a hint, then ignoring it on failure co=
uld cause the traffic to loop unless you are also stripping the segment ext=
ensions.=A0 Second, if the router respects the=A0 segments, then this will =
still require reading ahead in the segment list - with all of the extra mic=
rocode and handling that implies.=A0 It doesn&#39;t violate the existing ar=
chitecture only because that hasn&#39;t been fully defined.</p>

<p dir=3D"ltr">&gt; As far as state explosion .. I easily see a lot of room=
 for<br>
&gt; optimization as it will be very often the case that bypass can be<br>
&gt; shared by many destinations.</p>
<p dir=3D"ltr">Instead of 1 forwarding entry per neighbor, a router will ne=
ed 1 for each neighbor&#39;s neighbor and that assumes label or segment man=
ipulation doesn&#39;t need to be differentiated.</p>
<p dir=3D"ltr">This would only work for 1-hop globally understood segments =
- though with more computation, it might be possible for some algorithmical=
ly-based segments to be figured out.</p>
<p dir=3D"ltr">There are also the details around updating the segment list =
for fast-reroute and what impact that has.</p>
<p dir=3D"ltr">To be clear,=A0 IMHO,=A0 there are some interesting use-case=
s for segment-routing, but it also has limitations that need to be well-und=
erstood.=A0 We need to define the architecture clearly and the requirements=
 and trade-offs.=A0 We can&#39;t just assume that it will all work.</p>

<p dir=3D"ltr">Alia</p>
<p dir=3D"ltr">&gt; Best regards,<br>
&gt; R.<br>
&gt;<br>
&gt;<br>
&gt;<br>
&gt; On Mon, Sep 9, 2013 at 4:56 PM, Alia Atlas &lt;<a href=3D"mailto:akatl=
[email-masked]">[email-masked]</a>&gt; wrote:<br>
&gt; &gt; Hi Robert,<br>
&gt; &gt;<br>
&gt; &gt;<br>
&gt; &gt; On Monday, September 9, 2013, Robert Raszuk wrote:<br>
&gt; &gt;&gt;<br>
&gt; &gt;&gt; Hi Alia,<br>
&gt; &gt;&gt;<br>
&gt; &gt;&gt; &gt;&gt; Creating LFA bypass of each node with when required =
SR segment going<br>
&gt; &gt;&gt; &gt;&gt; far enough that loops are guaranteed not to occur lo=
oks like pretty<br>
&gt; &gt;&gt; &gt;&gt; easy exercise.<br>
&gt; &gt;&gt; &gt;&gt;<br>
&gt; &gt;&gt; &gt;&gt; Sorry I have no math prove that this will address an=
y network<br>
&gt; &gt;&gt; &gt;&gt; topology, but I also see no reason why it would not.=
<br>
&gt; &gt;&gt; &gt;<br>
&gt; &gt;&gt; &gt; [Alia] Robert, you are missing the problem. =A0The end o=
f each segment has<br>
&gt; &gt;&gt; &gt; the<br>
&gt; &gt;&gt; &gt; same egress<br>
&gt; &gt;&gt; &gt; and ingress protection problems that any LSP has. =A0If =
a segment just<br>
&gt; &gt;&gt; &gt; describes the next interface<br>
&gt; &gt;&gt; &gt; or router, how is that router&#39;s failure protected ag=
ainst?<br>
&gt; &gt;&gt;<br>
&gt; &gt;&gt; Why is that difficult ?<br>
&gt; &gt;&gt;<br>
&gt; &gt;&gt; When I am a transit node and I am forwarding packets to the e=
nd of<br>
&gt; &gt;&gt; segment =A0(egress) the awareness of egress being down (from =
directly<br>
&gt; &gt;&gt; connected detection protocol of your choice) I have ability t=
o bypass<br>
&gt; &gt;&gt; the failed node with a fixup of removing the end of segment<b=
r>
&gt; &gt;&gt; label/header from the packet&#39;s header.<br>
&gt; &gt;<br>
&gt; &gt;<br>
&gt; &gt; [Alia] It requires looking beyond the the top/current segment and=
<br>
&gt; &gt; understanding what<br>
&gt; &gt; is beneath. =A0More than just that,it requires setting up the nec=
essary<br>
&gt; &gt; different forwarding<br>
&gt; &gt; state for all possible combinations. =A0Of course, if a segment p=
oints to an<br>
&gt; &gt; LSP or an algorithmically<br>
&gt; &gt; computed segment, the next-hop of that is not known by the router=
 before the<br>
&gt; &gt; segment starts.<br>
&gt; &gt;<br>
&gt; &gt; So - to summarize - it requires a router to make forwarding decis=
ions based<br>
&gt; &gt; on labels under the<br>
&gt; &gt; top of stack (if MPLS) or beyond the current pointer, it blows up=
 the<br>
&gt; &gt; forwarding state needed, and<br>
&gt; &gt; the router may not know what the segment underneath means in term=
s of<br>
&gt; &gt; next-next hop(s).<br>
&gt; &gt;<br>
&gt; &gt; If only 1-hop segments are considered, the state expansion and ad=
ded info to<br>
&gt; &gt; read are still needed.<br>
&gt; &gt; There are also the concerns about label stack expansion and MTU.<=
br>
&gt; &gt;<br>
&gt; &gt; Regards,<br>
&gt; &gt; Alia<br>
&gt; &gt;<br>
&gt; &gt;<br>
&gt; &gt;<br>
&gt; &gt;<br>
&gt; &gt;<br>
&gt; &gt;<br>
&gt; &gt; and<br>
&gt; &gt;&gt;<br>
&gt; &gt;&gt; That way the failed egress is bypassed/protected as long as f=
ailure<br>
&gt; &gt;&gt; continues. The operation is local and uses to it&#39;s advant=
age the<br>
&gt; &gt;&gt; global (domain wide) property of repair paths. It in fact get=
&#39;s better<br>
&gt; &gt;&gt; as by looking at the next header the steering of the repair t=
raffic<br>
&gt; &gt;&gt; can be made optimal.<br>
&gt; &gt;&gt;<br>
&gt; &gt;&gt; Contrary with labels of local significance such repair will n=
ot be<br>
&gt; &gt;&gt; possible without employing yet another signalling protocol an=
d I see<br>
&gt; &gt;&gt; no good way to make it optimal at all.<br>
&gt; &gt;&gt;<br>
&gt; &gt;&gt; Regards,<br>
&gt; &gt;&gt; R.<br>
</p>

--047d7bd76bb29ae99004e5f515c5--

Sender: [email-masked]
Date: Mon, 9 Sep 2013 17:08:33 +0200
From: Robert Raszuk <[email-masked]>
To: Alia Atlas <[email-masked]>
Cc: Hannes Gredler <[email-masked]>, "[email-masked]" <[email-masked]>
Subject: Re: [Status] Summary of STATUS BOF and the next steps

Please notice that if we assume IPv6 forwarding the IPv6 header will
always contain destination IP address (most often BGP next hop in the
overlay) and included extension headers will provide just hints for
the segments.

Therefor the complication you describe with MPLS based forwarding I
see non existent with IP forwarding paradigm.

As far as state explosion .. I easily see a lot of room for
optimization as it will be very often the case that bypass can be
shared by many destinations.

Best regards,
R.

On Mon, Sep 9, 2013 at 4:56 PM, Alia Atlas <[email-masked]> wrote:
> Hi Robert,
>
>
> On Monday, September 9, 2013, Robert Raszuk wrote:
>>
>> Hi Alia,
>>
>> >> Creating LFA bypass of each node with when required SR segment going
>> >> far enough that loops are guaranteed not to occur looks like pretty
>> >> easy exercise.
>> >>
>> >> Sorry I have no math prove that this will address any network
>> >> topology, but I also see no reason why it would not.
>> >
>> > [Alia] Robert, you are missing the problem.  The end of each segment has
>> > the
>> > same egress
>> > and ingress protection problems that any LSP has.  If a segment just
>> > describes the next interface
>> > or router, how is that router's failure protected against?
>>
>> Why is that difficult ?
>>
>> When I am a transit node and I am forwarding packets to the end of
>> segment  (egress) the awareness of egress being down (from directly
>> connected detection protocol of your choice) I have ability to bypass
>> the failed node with a fixup of removing the end of segment
>> label/header from the packet's header.
>
>
> [Alia] It requires looking beyond the the top/current segment and
> understanding what
> is beneath.  More than just that,it requires setting up the necessary
> different forwarding
> state for all possible combinations.  Of course, if a segment points to an
> LSP or an algorithmically
> computed segment, the next-hop of that is not known by the router before the
> segment starts.
>
> So - to summarize - it requires a router to make forwarding decisions based
> on labels under the
> top of stack (if MPLS) or beyond the current pointer, it blows up the
> forwarding state needed, and
> the router may not know what the segment underneath means in terms of
> next-next hop(s).
>
> If only 1-hop segments are considered, the state expansion and added info to
> read are still needed.
> There are also the concerns about label stack expansion and MTU.
>
> Regards,
> Alia
>
>
>
>
>
>
> and
>>
>> That way the failed egress is bypassed/protected as long as failure
>> continues. The operation is local and uses to it's advantage the
>> global (domain wide) property of repair paths. It in fact get's better
>> as by looking at the next header the steering of the repair traffic
>> can be made optimal.
>>
>> Contrary with labels of local significance such repair will not be
>> possible without employing yet another signalling protocol and I see
>> no good way to make it optimal at all.
>>
>> Regards,
>> R.

Date: Mon, 9 Sep 2013 10:56:46 -0400
From: Alia Atlas <[email-masked]>
To: Robert Raszuk <[email-masked]>
Cc: Hannes Gredler <[email-masked]>, "[email-masked]" <[email-masked]>
Subject: Re: [Status] Summary of STATUS BOF and the next steps

--e89a8ff1cefee8939504e5f4987a
Content-Type: text/plain; charset=ISO-8859-1

Hi Robert,

On Monday, September 9, 2013, Robert Raszuk wrote:

> Hi Alia,
>
> >> Creating LFA bypass of each node with when required SR segment going
> >> far enough that loops are guaranteed not to occur looks like pretty
> >> easy exercise.
> >>
> >> Sorry I have no math prove that this will address any network
> >> topology, but I also see no reason why it would not.
> >
> > [Alia] Robert, you are missing the problem.  The end of each segment has
> the
> > same egress
> > and ingress protection problems that any LSP has.  If a segment just
> > describes the next interface
> > or router, how is that router's failure protected against?
>
> Why is that difficult ?
>
> When I am a transit node and I am forwarding packets to the end of
> segment  (egress) the awareness of egress being down (from directly
> connected detection protocol of your choice) I have ability to bypass
> the failed node with a fixup of removing the end of segment
> label/header from the packet's header.

[Alia] It requires looking beyond the the top/current segment and
understanding what
is beneath.  More than just that,it requires setting up the necessary
different forwarding
state for all possible combinations.  Of course, if a segment points to an
LSP or an algorithmically
computed segment, the next-hop of that is not known by the router before
the segment starts.

So - to summarize - it requires a router to make forwarding decisions based
on labels under the
top of stack (if MPLS) or beyond the current pointer, it blows up the
forwarding state needed, and
the router may not know what the segment underneath means in terms of
next-next hop(s).

If only 1-hop segments are considered, the state expansion and added info
to read are still needed.
There are also the concerns about label stack expansion and MTU.

Regards,
Alia

and
>
> That way the failed egress is bypassed/protected as long as failure
> continues. The operation is local and uses to it's advantage the
> global (domain wide) property of repair paths. It in fact get's better
> as by looking at the next header the steering of the repair traffic
> can be made optimal.
>
> Contrary with labels of local significance such repair will not be
> possible without employing yet another signalling protocol and I see
> no good way to make it optimal at all.
>
> Regards,
> R.
>

--e89a8ff1cefee8939504e5f4987a
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

Hi Robert,<br><br>On Monday, September 9, 2013, Robert Raszuk  wrote:<br><b=
lockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px =
#ccc solid;padding-left:1ex">Hi Alia,<br>
<br>
&gt;&gt; Creating LFA bypass of each node with when required SR segment goi=
ng<br>
&gt;&gt; far enough that loops are guaranteed not to occur looks like prett=
y<br>
&gt;&gt; easy exercise.<br>
&gt;&gt;<br>
&gt;&gt; Sorry I have no math prove that this will address any network<br>
&gt;&gt; topology, but I also see no reason why it would not.<br>
&gt;<br>
&gt; [Alia] Robert, you are missing the problem. =A0The end of each segment=
 has the<br>
&gt; same egress<br>
&gt; and ingress protection problems that any LSP has. =A0If a segment just=
<br>
&gt; describes the next interface<br>
&gt; or router, how is that router&#39;s failure protected against?<br>
<br>
Why is that difficult ?<br>
<br>
When I am a transit node and I am forwarding packets to the end of<br>
segment =A0(egress) the awareness of egress being down (from directly<br>
connected detection protocol of your choice) I have ability to bypass<br>
the failed node with a fixup of removing the end of segment<br>
label/header from the packet&#39;s header.</blockquote><div><br></div><div>=
[Alia] It requires looking beyond the the top/current segment and understan=
ding what</div><div>is beneath. =A0More than just that,it requires setting =
up the necessary different forwarding</div>
<div>state for all possible combinations. =A0Of course, if a segment points=
 to an LSP or an algorithmically</div><div>computed segment, the next-hop o=
f that is not known by the router before the segment starts.</div><div><br>
</div><div>So - to summarize - it requires a router to make forwarding deci=
sions based on labels under the</div><div>top of stack (if MPLS) or beyond =
the current pointer, it blows up the forwarding state needed, and</div>
<div>the router may not know what the segment underneath means in terms of =
next-next hop(s).</div><div><br></div><div>If only 1-hop segments are consi=
dered, the state expansion and added info to read are still needed.</div>
<div>There are also the concerns about label stack expansion and MTU.<span>=
</span></div><div><br></div><div>Regards,</div><div>Alia</div><div><br></di=
v><div><br></div><div><br></div><div><br></div><div><br></div><div><br>
</div>and<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;borde=
r-left:1px #ccc solid;padding-left:1ex">
That way the failed egress is bypassed/protected as long as failure<br>
continues. The operation is local and uses to it&#39;s advantage the<br>
global (domain wide) property of repair paths. It in fact get&#39;s better<=
br>
as by looking at the next header the steering of the repair traffic<br>
can be made optimal.<br>
<br>
Contrary with labels of local significance such repair will not be<br>
possible without employing yet another signalling protocol and I see<br>
no good way to make it optimal at all.<br>
<br>
Regards,<br>
R.<br>
</blockquote>

--e89a8ff1cefee8939504e5f4987a--

Sender: [email-masked]
Date: Mon, 9 Sep 2013 16:41:56 +0200
From: Robert Raszuk <[email-masked]>
To: Alia Atlas <[email-masked]>
Cc: Hannes Gredler <[email-masked]>, "[email-masked]" <[email-masked]>
Subject: Re: [Status] Summary of STATUS BOF and the next steps

Hi Alia,

>> Creating LFA bypass of each node with when required SR segment going
>> far enough that loops are guaranteed not to occur looks like pretty
>> easy exercise.
>>
>> Sorry I have no math prove that this will address any network
>> topology, but I also see no reason why it would not.
>
> [Alia] Robert, you are missing the problem.  The end of each segment has the
> same egress
> and ingress protection problems that any LSP has.  If a segment just
> describes the next interface
> or router, how is that router's failure protected against?

Why is that difficult ?

When I am a transit node and I am forwarding packets to the end of
segment  (egress) the awareness of egress being down (from directly
connected detection protocol of your choice) I have ability to bypass
the failed node with a fixup of removing the end of segment
label/header from the packet's header.

That way the failed egress is bypassed/protected as long as failure
continues. The operation is local and uses to it's advantage the
global (domain wide) property of repair paths. It in fact get's better
as by looking at the next header the steering of the repair traffic
can be made optimal.

Contrary with labels of local significance such repair will not be
possible without employing yet another signalling protocol and I see
no good way to make it optimal at all.

Regards,
R.

Date: Mon, 9 Sep 2013 10:26:40 -0400
From: Alia Atlas <[email-masked]>
To: Robert Raszuk <[email-masked]>
Cc: Hannes Gredler <[email-masked]>, "[email-masked]" <[email-masked]>
Subject: Re: [Status] Summary of STATUS BOF and the next steps

--047d7b3a99f84ab8fc04e5f42d1e
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: quoted-printable

On Monday, September 9, 2013, Robert Raszuk wrote:
>
> >>>> 5. FRR node-protection
> >>
> >> As you know computing LFA sort of addresses this topic pretty well.
> >  ^^^^^^^^^^^
> >
> > no i don't - and for my own education would be really interested to lea=
rn
> > how to provide node-protection for 1-hop (per-adjacency) labels.
>
> Creating LFA bypass of each node with when required SR segment going
> far enough that loops are guaranteed not to occur looks like pretty
> easy exercise.
>
> Sorry I have no math prove that this will address any network
> topology, but I also see no reason why it would not.

[Alia] Robert, you are missing the problem.  The end of each segment has
the same egress
and ingress protection problems that any LSP has.  If a segment just
describes the next interface
or router, how is that router's failure protected against?

>
> >> Moreover SR may complete topologies where today LFA may not be
> >> possible in 100% of coverage.
> >
> > i am afraid SR is still not there -
>
> Perfect topic for this WG to make it be there. Can we add this to the
> charter ?
>
> Alia] I believe that all hop-by-hop fast-reroute techniques are in charte=
r
already for RTGWG.
The need for arbitrarily long explicitly routed paths for complete coverage
with the rLFA (PQ-tunnels approach) is part of why the approach was
discarded in favor of not-via by its authors.  That said, RTGWG is in the
process of standardizing MRT-FRR, which provides 100% link and node
protection in any topologies without risk of looping traffic.

> trouble is that LFA is like "star wars" - there are many episodes =85
>
> [Alia] A complete solution is preferable to the need for continuing
episodes.

Alia

--047d7b3a99f84ab8fc04e5f42d1e
Content-Type: text/html; charset=windows-1252
Content-Transfer-Encoding: quoted-printable

<br><br>On Monday, September 9, 2013, Robert Raszuk wrote:<blockquote class=
=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padd=
ing-left:1ex">
&gt;&gt;&gt;&gt; 5. FRR node-protection<br>
&gt;&gt;<br>
&gt;&gt; As you know computing LFA sort of addresses this topic pretty well=
.<br>
&gt; =A0^^^^^^^^^^^<br>
&gt;<br>
&gt; no i don&#39;t - and for my own education would be really interested t=
o learn<br>
&gt; how to provide node-protection for 1-hop (per-adjacency) labels.<br>
<br>
Creating LFA bypass of each node with when required SR segment going<br>
far enough that loops are guaranteed not to occur looks like pretty<br>
easy exercise.<br>
<br>
Sorry I have no math prove that this will address any network<br>
topology, but I also see no reason why it would not.</blockquote><blockquot=
e class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc sol=
id;padding-left:1ex"></blockquote><div><br></div><div>[Alia] Robert, you ar=
e missing the problem. =A0The end of each segment has the same egress</div>
<div>and ingress=A0protection problems that any LSP has. =A0If a segment ju=
st describes the next interface</div><div>or router, how is that router&#39=
;s failure protected against?</div><blockquote class=3D"gmail_quote" style=
=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br></blockquote><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8=
ex;border-left:1px #ccc solid;padding-left:1ex">
&gt;&gt; Moreover SR may complete topologies where today LFA may not be<br>
&gt;&gt; possible in 100% of coverage.<br>
&gt;<br>
&gt; i am afraid SR is still not there -<br>
<br>
Perfect topic for this WG to make it be there. Can we add this to the chart=
er ?<br>
<br></blockquote><div>Alia]=A0I believe that all hop-by-hop fast-reroute te=
chniques are in charter already for RTGWG.</div><div>The need for arbitrari=
ly long explicitly routed paths for complete coverage with the rLFA (PQ-tun=
nels approach) is part of why the approach was discarded in favor of not-vi=
a by its authors. =A0That said, RTGWG is in the process of standardizing MR=
T-FRR, which provides 100% link and node protection in any topologies witho=
ut risk of looping traffic.=A0</div>
<div><br></div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex=
;border-left:1px #ccc solid;padding-left:1ex">
&gt; trouble is that LFA is like &quot;star wars&quot; - there are many epi=
sodes =85<br><br></blockquote><div>[Alia] A complete solution is preferable=
 to the need for continuing episodes.=A0</div><div><br></div><div>Alia<span=
></span></div>

--047d7b3a99f84ab8fc04e5f42d1e--

From: Rob Shakir <[email-masked]>
Date: Mon, 9 Sep 2013 13:48:54 +0000
To: Hannes Gredler <[email-masked]>
Cc: [email-masked], Robert Raszuk <[email-masked]>
Subject: Re: [Status] Summary of STATUS BOF and the next steps

Hannes,

On 9 Sep 2013, at 12:13, Hannes Gredler <[email-masked]> wrote:

>  so what SR does wrt to TE is essentially shifting functionality =
around
>  rather than solving it in any better way.

As there has been significant effort to try and cover in the existing =
drafts, there are two classes of explicit routing problems (~=3D =
"traffic engineering" problems).

1) those that require admission control into resources,
2) those that require only placement away from the SPT, with no =
admission control.

With RSVP-TE we have to incur per-hop state for both cases - which means =
we must also perform signalling per-LSP, and incur mid-point load during =
re-signalling. This has real and practical problems which result in =
RSVP-TE not being deployed or SPs restricting their RSVP-TE deployment's =
scale. This, to me, is enough of a reason for us to determine that we'd =
like to try and find something that would solve 2), where we can remove =
the constraint on the # of LSPs.

If we develop something akin to this, then we are not so much "moving =
functionality around", but removing the need for the state which gives =
us no value for LSP type 1) (no constraint is specified where the =
mid-point would return a PathErr in RSVP-TE terms, so why do we keep it =
anywhere?).

For 1), we now have two choices, we can add the admission control =
centrally, or we can do it in a distributed fashion. Different planning =
approaches (for different organisations) will lend themselves to =
different approaches being taken. I can foresee that some networks will =
run RSVP-TE for 1) and IGP labels/SR LSPs for 2). Others will want =
stricter control on the paths requiring 1), such that they will want =
central computation instantiated in the data plane in the same manner as =
those in 2). I don't see a reason to restrict these approaches being =
available to operators such that they can make their own choices.

Additionally, we should bear in mind that RSVP-TE itself is not a =
panacea to centralised computation -- if we want to take consideration =
of information that is not immediately visible to the head-end PEs then =
we are likely to need ways that we can give each head-end device a hint =
(e.g., ERO) to describe how to route services.

Cheers,
r.

From: Rob Shakir <[email-masked]>
Date: Mon, 9 Sep 2013 13:28:19 +0000
To: Hannes Gredler <[email-masked]>
Cc: [email-masked]
Subject: Re: [Status] Summary of STATUS BOF and the next steps

Hi Hannes,

On 9 Sep 2013, at 11:04, Hannes Gredler <[email-masked]> wrote:

> hi rob,
>=20
>>>=20
>> rjs> Isn't this an intra-domain use case? As I read it, ASBR{1,2} =
allocate the label and advertise it within the AS1 IGP. There is no =
labelled traffic passed between AS1 and AS{3,4,5,6} as both the ASBRs =
program a pop operation. I read inter-domain as segments being used to =
influence routing within two separate autonomous systems which are not =
within the same trust domain.
>=20
> HG> it is =85 now think for a moment if there would be one AS =
in-between
>   the egress link - as per the illustration below:
>   the ingress router is in AS1 and it wants to control the exit link =
of AS2-->AS3.
>=20
>   AS1--AS2--AS3

rjs> I haven't seen any demand for this use case though. Similarly to =
the lack of demand (from my perspective) of inter-domain explicit =
routing/path placement.

rjs> I am going to go out on a limb here, and assert that there a huge =
set of other problems if one starts allowing AS1 to explicitly define =
routes within AS2 when they are outside different trust-domains. If we =
try and bring anything like this in scope in the initial phase, then I =
think we need to consult with the wider operational community as to how =
AS2 looks after its own interests, before considering what the =
technology solution is. Too often there are suggestions that we should =
develop technology solutions, where the current operational reality is =
that they are not implementable (based on commercial constraints, or =
requirements for deterministic behaviour).

rjs> So, based on this, let's tackle the intra-domain cases to start =
with. If and when we have operators who have requirements for this to be =
inter-domain, but intra-trust domain, then we can debate whether these =
are of interest to the WG, similarly to the debate we can have when =
there are operators raising requirements that need inter-domain, =
inter-trust domain functionality. However, I do not see why we should =
delay the implementation of intra-domain cases based on a possible =
future extension :-)

>> <=85snip=85>
>> rjs> I can't comment on the assertions of others, and do not wish to =
do so. In my view, there are pragmatic use cases (defined by a number of =
operators) which are gaps that we cannot meet today. Let's identify =
those, and work on those, and allow further uses of the technology going =
forward if there is a convincing case to do so.
>=20
> HG> agreed.
>=20
>> rjs> I don't disagree that we should stay disciplined, but I do not =
see the requirement to mandate that a document must be sent to the IESG =
to be published *before* solutions drafts are adopted. Having a =
requirement that the adopted solutions drafts should address the use =
cases within previously adopted documents puts the same focus safe-guard =
in as far as I can see.
>=20
> HG> that seems reasonable to me as well - do you have a suggestion for =
the actual text ?
>=20

original> Protocol work may be carried out in this working group or in =
other
original> working groups responsible for the protocols, in coordination =
with
original> this WG, and in agreement with the WG chairs and responsible =
ADs.
original> However, no protocol work will be adopted by a working group =
to
original> address the identified use-cases until the requirements =
document
original> motivating the protocol work has been sent to the IESG for
original> publication as an RFC.

revised> The <Name-TBD> working group will initially produce =
descriptions of=20
revised> use cases, and requirements to be addressed. Where there is =
consensus
revised> within the WG for these use cases to be solved (demonstrated =
through
revised> WG adoption, and/or agreement with the chairs and responsible =
ADs),
revised> architectural specifications and requirements for protocol =
extensions=20
revised> will be developed. Where new protocol extensions are developed, =
the
revised> relevant working groups (e.g., IS-IS, OSPF, IDR, PCEP=85) will =
develop
revised> these, in conjunction with the WG.

rjs> Not perfect, but maybe a reasonable starting point?

r.

>=20
>>>>> On Sep 4, 2013, at 10:02 AM, <[email-masked]> =
<[email-masked]> wrote:
>>>>>=20
>>>>>> Hannes,
>>>>>>=20
>>>>>> In case, we are using only directed forwarding (adjacency =
segment), could we still talk about tunneling ? (it's a very very small =
tunnel)
>>>>>> Moreover talking about "stacking" is really dataplane agnostic =
(MPLS) ...
>>>>>>=20
>>>>>> In the proposed segment routing architectural concepts, segments =
are at the same "level" and pointer moves on the segment list, then the =
MPLS instantiation is performing this using stacking ...
>>>>>>=20
>>>>>> IMHO, if we use "Stacked Tunnels", we already talk about a chosen =
solution and it's closing the door to something else  ...
>>>>>>=20
>>>>>> Finally, about the "routing" word, routing is essentially a =
"forward" action which may limit the scope of what we can do by using a =
segment list. Actions associated with a segment could be something else =
than forwarding.
>>>>>>=20
>>>>>> Do we want in the charter to limit the scope to routing actions ?
>>>>>>=20
>>>>>> I have no solution today to propose for the naming, but I =
completely agree with Loa, to first focus on working on the charter, and =
define a clear scope of the work and then the name will be easier to =
find.
>>>>>>=20
>>>>>> Regarding your charter proposal :
>>>>>>=20
>>>>>> --------
>>>>>>=20
>>>>>> - They form a connected network
>>>>>>  [SLI] InterAS case must be included, but the WG can go step by =
step and first release intraAS, and then doing interAS (in relation with =
IDR ??).
>>>>>>=20
>>>>>> - They can forward traffic through the shortest paths or paths =
other than the shortest (the latter called explicitly routed paths, or =
explicit paths)
>>>>>>  [SLI] There is something else between SPT and Explicit path, you =
can define other algorithms than SPT to define a path, and it's not =
explicit path. Moreover I come back to my comment, on do we want to =
limit the scope to routing ? I would say no.
>>>>>>=20
>>>>>> - They share a common trust model. In this model, any router =
within the ERD can specify an explicit path between itself and any other =
router in the ERD. It can then send any packet that passes through it =
through any path that it has specified.
>>>>>>  [SLI] Security considerations may have to be addressed in the =
charter , especially for the interAS case (trust yes, but not sure =
access to everything may not be good)
>>>>>>=20
>>>>>> Downstream routers within the ERD forward the packet as specified =
by the router at the head-end of the path.
>>>>>> [SLI] Yes, but any router in the middle may be able to change the =
end to end explicit path.
>>>>>>=20
>>>>>>=20
>>>>>>=20
>>>>>> - The first goal of the STER WG is to identify use-cases for =
ERDs.
>>>>>> - Having identified use-cases, the WG will identify gaps between =
currently available technologies and use-case requirements.
>>>>>> - The WG will then define requirements for extensions to existing =
protocols or new protocols that address gaps that are identified.
>>>>>>=20
>>>>>> [SLI] Agree, I would add :
>>>>>> - defining the architecture framework
>>>>>> - analysing the security considerisations
>>>>>>=20
>>>>>>=20
>>>>>> ---------
>>>>>>=20
>>>>>>=20
>>>>>> Here would be my proposal to extend yours :
>>>>>>=20
>>>>>> A <named to be defined> domain contains a set of routers with the =
following characteristics:
>>>>>>=20
>>>>>> - They form a connected network
>>>>>> - They can forward traffic through any path within the network =
using shortest path, non shortest path or explicit path
>>>>>> - They may provide other types of services than forwarding and =
they can enforce service actions in the path.
>>>>>> - They share a common trust model. In this model, any router =
within the domain can specify a path between itself and any other router =
in the domain. It may then send any packet that passes through it =
through any path that it has specified and that is conform to the =
security rules. Downstream routers within the ERD forward the packet as =
specified by the router at the head-end of the path.
>>>>>>=20
>>>>>> The <name> working group is chartered for the following ordered =
list of work items:
>>>>>>=20
>>>>>> - The first goal of the WG is to identify use-cases.
>>>>>> - The WG will then define the architecture framework associated =
with the security considerations. The architecture framework and =
security considerations must address the relations between domains =
(interdomain).
>>>>>> - Having identified use-cases, architecture and security, the WG =
will identify gaps between currently available technologies and use-case =
requirements.
>>>>>> - The WG will then define requirements for extensions to existing =
protocols or new protocols that address gaps that are identified.
>>>>>> - The WG will first focus on the intra-domain forwarding =
definition.
>>>>>>=20
>>>>>> Protocol work may be carried out in this working group or in =
other working groups responsible for the protocols, in coordination with =
this WG, and in agreement with the WG chairs and responsible ADs. =
However, no protocol work will be adopted by a working group to address =
the ERD use-cases until the requirements document motivating the =
protocol work has been sent to the IESG for publication as an RFC.
>>>>>>=20
>>>>>> -----Message d'origine-----
>>>>>> De : [email-masked] [mailto:[email-masked]] De =
la part de Hannes Gredler
>>>>>> Envoy=E9 : mardi 3 septembre 2013 18:31
>>>>>> =C0 : Loa Andersson
>>>>>> Cc : [email-masked]
>>>>>> Objet : Re: [Status] Summary of STATUS BOF and the next steps
>>>>>>=20
>>>>>> good point - what about this charter proposal ?
>>>>>>=20
>>>>>> ---
>>>>>>=20
>>>>>> Stacked Tunnels for Explicit Routing (STER) =
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
>>>>>>=20
>>>>>> A explicit routing domain (ERD) contains a set of routers with =
the following characteristics:
>>>>>>=20
>>>>>> - They form a connected network
>>>>>> - They can forward traffic through the shortest paths or paths =
other than the shortest (the latter called explicitly routed paths, or =
explicit paths)
>>>>>> - They share a common trust model. In this model, any router =
within the ERD can specify an explicit path between itself and any other =
router in the ERD. It can then send any packet that passes through it =
through any path that it has specified. Downstream routers within the =
ERD forward the packet as specified by the router at the head-end of the =
path.
>>>>>>=20
>>>>>> The STER working group is chartered for the following ordered =
list of work items:
>>>>>>=20
>>>>>> - The first goal of the STER WG is to identify use-cases for =
ERDs.
>>>>>> - Having identified use-cases, the WG will identify gaps between =
currently available technologies and use-case requirements.
>>>>>> - The WG will then define requirements for extensions to existing =
protocols or new protocols that address gaps that are identified.
>>>>>>=20
>>>>>> Protocol work may be carried out in this working group or in =
other working groups responsible for the protocols, in coordination with =
this WG, and in agreement with the WG chairs and responsible ADs. =
However, no protocol work will be adopted by a working group to address =
the ERD use-cases until the requirements document motivating the =
protocol work has been sent to the IESG for publication as an RFC.
>>>>>>=20
>>>>>> ---
>>>>>>=20
>>>>>> <flame suit on>
>>>>>>=20
>>>>>> /hannes
>>>>>>=20
>>>>>>=20
>>>>>> On Sep 3, 2013, at 5:31 PM, Loa Andersson wrote:
>>>>>>=20
>>>>>>> Folks,
>>>>>>>=20
>>>>>>> Excuse me if I'm slightly out of the loop, but so far I have not =
seen
>>>>>>> a charter proposal, if there is one please point me to it.
>>>>>>>=20
>>>>>>> It seems a bit odd to put the cart (what the wg should do) =
before the
>>>>>>> horse (wg name). If we drill down the the charter first the wg =
name
>>>>>>> might be easier to figure out.
>>>>>>>=20
>>>>>>> /Loa
>>>>>>>=20
>>>>>>> PS
>>>>>>> OK I understand that the horse and cart analogy limps a  bit :).
>>>>>>>=20
>>>>>>>=20
>>>>>>>=20
>>>>>>> On 2013-09-03 17:22, AshwoodsmithPeter wrote:
>>>>>>>> " If the WG charter is limited to source routing, how will we =
handle the "non source routing" use cases of segment routing ? In =
another working group ? So we will go back to the WG synchronization =
issue that has been raised for this technology ..."
>>>>>>>>=20
>>>>>>>> That's why I suggested SRV2. We are revisiting source routing =
with new concepts. More generic number/action behavior.
>>>>>>>>=20
>>>>>>>> Peter
>>>>>>>>=20
>>>>>>>> -----Original Message-----
>>>>>>>> From: [email-masked] [mailto:[email-masked]] =
On
>>>>>>>> Behalf Of [email-masked]
>>>>>>>> Sent: Tuesday, September 03, 2013 10:43 AM
>>>>>>>> To: AshwoodsmithPeter
>>>>>>>> Cc: [email-masked]
>>>>>>>> Subject: Re: [Status] Summary of STATUS BOF and the next steps
>>>>>>>>=20
>>>>>>>>=20
>>>>>>>> There was a misunderstanding in my small comment :) so I will =
explain more :
>>>>>>>>=20
>>>>>>>> In segment routing, you have more than basic source routing : =
segment routing is just associate a segment number to an action and then =
combine segment as you want, yes you can do source routing, but you also =
can do more.
>>>>>>>>=20
>>>>>>>> In the other hand, I completely agree with your statement that =
source
>>>>>>>> routing is generic and dataplane agnostic, as segment routing =
is ...
>>>>>>>> (segment routing is not a new dataplane ...)
>>>>>>>>=20
>>>>>>>> Now the definition of the WG naming must be inline with the =
charter
>>>>>>>> that will be defined ... (draft today)
>>>>>>>>=20
>>>>>>>> Based on the already existing consensus (at least for MPLS =
dataplane) brought up during Berlin STATUS BOF meeting, segment routing =
sounds to be a good target candidate.
>>>>>>>>=20
>>>>>>>> So now, do we want to do more in the WG charter than just make =
progressing segment routing architecture and uses cases document and =
ensure coordination for the standardization of this technology ?
>>>>>>>>=20
>>>>>>>> Do we want to standardize other technologies in this WG ? I =
don't think so, based on Stewart's conclusion email from the BOF :"A new =
WG focused solely on SR therefore needs to be create"
>>>>>>>>=20
>>>>>>>> If the WG charter is limited to source routing, how will we =
handle the "non source routing" use cases of segment routing ? In =
another working group ? So we will go back to the WG synchronization =
issue that has been raised for this technology ...
>>>>>>>>=20
>>>>>>>> If the WG is focused on SR, let's use a name in relation with =
SR.
>>>>>>>>=20
>>>>>>>> Feedback ?
>>>>>>>>=20
>>>>>>>>=20
>>>>>>>> Stephane
>>>>>>>>=20
>>>>>>>>=20
>>>>>>>> -----Message d'origine-----
>>>>>>>> De : AshwoodsmithPeter [mailto:[email-masked]]
>>>>>>>> Envoy=E9 : mardi 3 septembre 2013 15:27 =C0 : LITKOWSKI =
Stephane DTF/DERX
>>>>>>>> Cc : John E Drake; Mark Townsley; Victor Kuarsingh; Roberta =
Maglione
>>>>>>>> (robmgl); John G. Scudder; Adrian Farrel; Alvaro Retana =
(aretana);
>>>>>>>> [email-masked]; Stewart Bryant (stbryant) Objet : Re: [Status]
>>>>>>>> Summary of STATUS BOF and the next steps
>>>>>>>>=20
>>>>>>>> The term "source routing" has been around for a very long time =
and is data path agnostic. Its also the term used in the literature etc =
so my preference is to stick with this existing well known and data path =
agnostic term.
>>>>>>>>=20
>>>>>>>> Peter
>>>>>>>>=20
>>>>>>>> On Sep 3, 2013, at 9:07 AM, "[email-masked]" =
<[email-masked]> wrote:
>>>>>>>>=20
>>>>>>>>> Hi,
>>>>>>>>>=20
>>>>>>>>> "Source routing" is just a subcase of segment routing ... as =
it is for IP routing ...
>>>>>>>>>=20
>>>>>>>>> Stephane
>>>>>>>>>=20
>>>>>>>>>=20
>>>>>>>>> -----Message d'origine-----
>>>>>>>>> De : [email-masked] [mailto:[email-masked]] =
De la
>>>>>>>>> part de John E Drake Envoy=E9 : mardi 3 septembre 2013 15:02 =C0=
 : Mark
>>>>>>>>> Townsley; Victor Kuarsingh Cc : Roberta Maglione (robmgl); =
John G.
>>>>>>>>> Scudder; Alvaro Retana (aretana); Adrian Farrel; =
[email-masked];
>>>>>>>>> Stewart Bryant (stbryant) Objet : Re: [Status] Summary of =
STATUS BOF
>>>>>>>>> and the next steps
>>>>>>>>>=20
>>>>>>>>> Hi,
>>>>>>>>>=20
>>>>>>>>> What is this 'segment routing' silliness?  The correct term is =
'source routing'.
>>>>>>>>>=20
>>>>>>>>> Yours Irrespectively,
>>>>>>>>>=20
>>>>>>>>> John
>>>>>>>>>=20
>>>>>>>>>> -----Original Message-----
>>>>>>>>>> From: [email-masked] =
[mailto:[email-masked]] On
>>>>>>>>>> Behalf Of Mark Townsley
>>>>>>>>>> Sent: Sunday, September 01, 2013 10:08 AM
>>>>>>>>>> To: Victor Kuarsingh
>>>>>>>>>> Cc: Roberta Maglione (robmgl); John G. Scudder; Adrian =
Farrel;
>>>>>>>>>> Alvaro Retana (aretana); [email-masked]; Stewart Bryant =
(stbryant)
>>>>>>>>>> Subject: Re: [Status] Summary of STATUS BOF and the next =
steps
>>>>>>>>>>=20
>>>>>>>>>>=20
>>>>>>>>>> On Sep 1, 2013, at 5:38 PM, Victor Kuarsingh wrote:
>>>>>>>>>>=20
>>>>>>>>>>> All,
>>>>>>>>>>>=20
>>>>>>>>>>> I would also favour "Segment Routing WG" as well.
>>>>>>>>>>>=20
>>>>>>>>>>> I note this since attempting to come up with an all =
encompassing
>>>>>>>>>>> acronym will be difficult and Segment Routing is generic =
enough to
>>>>>>>>>>> associate to multiple functions.
>>>>>>>>>>=20
>>>>>>>>>> Then we can just use "segroute" for the short name. WGs do =
not have
>>>>>>>>>> to have acronyms, but they do need to have an 8-char limited =
short
>>>>>>>>>> name for the various automated tools not to break.
>>>>>>>>>>=20
>>>>>>>>>> - Mark
>>>>>>>>>>=20
>>>>>>>>>>>=20
>>>>>>>>>>> Regards,
>>>>>>>>>>>=20
>>>>>>>>>>> Victor K
>>>>>>>>>>>=20
>>>>>>>>>>>=20
>>>>>>>>>>>=20
>>>>>>>>>>> On 2013-08-31 6:51 PM, "Roberta Maglione (robmgl)"
>>>>>>>>>>> <[email-masked]>
>>>>>>>>>>> wrote:
>>>>>>>>>>>=20
>>>>>>>>>>>> +1 for Segment Routing WG
>>>>>>>>>>>>=20
>>>>>>>>>>>> Roberta
>>>>>>>>>>>>=20
>>>>>>>>>>>> Sent from my iPad
>>>>>>>>>>>>=20
>>>>>>>>>>>> On 2013-08-30, at 2:55 PM, "Alvaro Retana (aretana)"
>>>>>>>>>>>> <[email-masked]>
>>>>>>>>>>>> wrote:
>>>>>>>>>>>>=20
>>>>>>>>>>>>> Segment Routing WG
>>>>>>>>>>>>>=20
>>>>>>>>>>>>> Sent from my iPhone
>>>>>>>>>>>>>=20
>>>>>>>>>>>>> On Aug 30, 2013, at 1:39 PM, "Stewart Bryant (stbryant)"
>>>>>>>>>>>>> <[email-masked]> wrote:
>>>>>>>>>>>>>=20
>>>>>>>>>>>>>> The second task, which hopefully should be relatively =
easy, is
>>>>>>>>>>>>>> to find a better working name for the WG, since it has =
been put
>>>>>>>>>>>>>> to me a number of times that STATUS is going to be =
confusing in
>>>>>>>>>>>>>> text and a difficult search term.
>>>>>>>>>>>>> _______________________________________________
>>>>>>>>>>>>> status mailing list
>>>>>>>>>>>>> [email-masked]
>>>>>>>>>>>>> https://www.ietf.org/mailman/listinfo/status
>>>>>>>>>>>> _______________________________________________
>>>>>>>>>>>> status mailing list
>>>>>>>>>>>> [email-masked]
>>>>>>>>>>>> https://www.ietf.org/mailman/listinfo/status
>>>>>>>>>>>=20
>>>>>>>>>>>=20
>>>>>>>>>>> _______________________________________________
>>>>>>>>>>> status mailing list
>>>>>>>>>>> [email-masked]
>>>>>>>>>>> https://www.ietf.org/mailman/listinfo/status
>>>>>>>>>>=20
>>>>>>>>>> _______________________________________________
>>>>>>>>>> status mailing list
>>>>>>>>>> [email-masked]
>>>>>>>>>> https://www.ietf.org/mailman/listinfo/status
>>>>>>>>>=20
>>>>>>>>>=20
>>>>>>>>> _______________________________________________
>>>>>>>>> status mailing list
>>>>>>>>> [email-masked]
>>>>>>>>> https://www.ietf.org/mailman/listinfo/status
>>>>>>>>>=20
>>>>>>>>> =
____________________________________________________________________
>>>>>>>>> __ ___________________________________________________
>>>>>>>>>=20
>>>>>>>>> Ce message et ses pieces jointes peuvent contenir des =
informations
>>>>>>>>> confidentielles ou privilegiees et ne doivent donc pas etre
>>>>>>>>> diffuses, exploites ou copies sans autorisation. Si vous avez =
recu
>>>>>>>>> ce message par erreur, veuillez le signaler a l'expediteur et =
le detruire ainsi que les pieces jointes. Les messages electroniques =
etant susceptibles d'alteration, Orange decline toute responsabilite si =
ce message a ete altere, deforme ou falsifie. Merci.
>>>>>>>>>=20
>>>>>>>>> This message and its attachments may contain confidential or
>>>>>>>>> privileged information that may be protected by law; they =
should not be distributed, used or copied without authorisation.
>>>>>>>>> If you have received this email in error, please notify the =
sender and delete this message and its attachments.
>>>>>>>>> As emails may be altered, Orange is not liable for messages =
that have been modified, changed or falsified.
>>>>>>>>> Thank you.
>>>>>>>>>=20
>>>>>>>>> _______________________________________________
>>>>>>>>> status mailing list
>>>>>>>>> [email-masked]
>>>>>>>>> https://www.ietf.org/mailman/listinfo/status
>>>>>>>>=20
>>>>>>>> =
_____________________________________________________________________
>>>>>>>> ____________________________________________________
>>>>>>>>=20
>>>>>>>> Ce message et ses pieces jointes peuvent contenir des =
informations
>>>>>>>> confidentielles ou privilegiees et ne doivent donc pas etre =
diffuses,
>>>>>>>> exploites ou copies sans autorisation. Si vous avez recu ce =
message
>>>>>>>> par erreur, veuillez le signaler a l'expediteur et le detruire =
ainsi que les pieces jointes. Les messages electroniques etant =
susceptibles d'alteration, Orange decline toute responsabilite si ce =
message a ete altere, deforme ou falsifie. Merci.
>>>>>>>>=20
>>>>>>>> This message and its attachments may contain confidential or
>>>>>>>> privileged information that may be protected by law; they =
should not be distributed, used or copied without authorisation.
>>>>>>>> If you have received this email in error, please notify the =
sender and delete this message and its attachments.
>>>>>>>> As emails may be altered, Orange is not liable for messages =
that have been modified, changed or falsified.
>>>>>>>> Thank you.
>>>>>>>>=20
>>>>>>>> _______________________________________________
>>>>>>>> status mailing list
>>>>>>>> [email-masked]
>>>>>>>> https://www.ietf.org/mailman/listinfo/status
>>>>>>>> _______________________________________________
>>>>>>>> status mailing list
>>>>>>>> [email-masked]
>>>>>>>> https://www.ietf.org/mailman/listinfo/status
>>>>>>>>=20
>>>>>>>=20
>>>>>>> --
>>>>>>>=20
>>>>>>>=20
>>>>>>> Loa Andersson                        email: =
[email-masked]
>>>>>>> Senior MPLS Expert                          [email-masked]
>>>>>>> Huawei Technologies (consultant)     phone: +46 739 81 21 64
>>>>>>> _______________________________________________
>>>>>>> status mailing list
>>>>>>> [email-masked]
>>>>>>> https://www.ietf.org/mailman/listinfo/status
>>>>>>>=20
>>>>>>>=20
>>>>>>=20
>>>>>>=20
>>>>>> _______________________________________________
>>>>>> status mailing list
>>>>>> [email-masked]
>>>>>> https://www.ietf.org/mailman/listinfo/status
>>>>>>=20
>>>>>> =
__________________________________________________________________________=
_______________________________________________
>>>>>>=20
>>>>>> Ce message et ses pieces jointes peuvent contenir des =
informations confidentielles ou privilegiees et ne doivent donc
>>>>>> pas etre diffuses, exploites ou copies sans autorisation. Si vous =
avez recu ce message par erreur, veuillez le signaler
>>>>>> a l'expediteur et le detruire ainsi que les pieces jointes. Les =
messages electroniques etant susceptibles d'alteration,
>>>>>> Orange decline toute responsabilite si ce message a ete altere, =
deforme ou falsifie. Merci.
>>>>>>=20
>>>>>> This message and its attachments may contain confidential or =
privileged information that may be protected by law;
>>>>>> they should not be distributed, used or copied without =
authorisation.
>>>>>> If you have received this email in error, please notify the =
sender and delete this message and its attachments.
>>>>>> As emails may be altered, Orange is not liable for messages that =
have been modified, changed or falsified.
>>>>>> Thank you.
>>>>>>=20
>>>>>>=20
>>>>>>=20
>>>>>=20
>>>>>=20
>>>>> _______________________________________________
>>>>> status mailing list
>>>>> [email-masked]
>>>>> https://www.ietf.org/mailman/listinfo/status
>>>>=20
>>>>=20
>>>>=20
>>>=20
>>>=20
>>> _______________________________________________
>>> status mailing list
>>> [email-masked]
>>> https://www.ietf.org/mailman/listinfo/status
>>=20
>> _______________________________________________
>> status mailing list
>> [email-masked]
>> https://www.ietf.org/mailman/listinfo/status
>>=20
>>=20
>=20
>=20
> _______________________________________________
> status mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/status

From: <[email-masked]>
To: <[email-masked]>
Date: Mon, 9 Sep 2013 14:54:38 +0200
Accept-Language: en-US, de-DE
acceptlanguage: en-US, de-DE
Cc: [email-masked]
Subject: Re: [Status] Summary of STATUS BOF and the next steps

Hannes,

I've talked about MPLS LSP monitoring. IPv6 to me is of interest in RFC4379=
 context only. As ECMP and tracing or adressing ECMP paths helps to reduce =
label stacks, ECMP related RFC4379 functionality is desireable with SR too,=
 I think.

I'm not yet interested native IPv6 OAM functions.

Regards,

Ruediger

-----Original Message-----
From: Hannes Gredler [mailto:[email-masked]]
Sent: Monday, September 09, 2013 2:19 PM
To: Geib, R=FCdiger
Cc: [email-masked]
Subject: Re: [Status] Summary of STATUS BOF and the next steps

On Sep 9, 2013, at 1:58 PM, <[email-masked]> <Ruediger.Geib@telek=
om.de> wrote:

> [ ... ]
> In addition, SR will allow for very scaleable LSP monitoring OAM. Trying =
to to this with todays features is very complex (we've done that).

> SR can simplify LSP monitoring OAM as compared to what's available today.

thats fine - and the OAM use case is an undisputed one - no worries;

the question to you is:

for doing OAM do you need an IPv6-SR flavor and if so why ?

> Finally, if you prefer to do analysis and planning work, then why shouldn=
't you? In parallel to those commencing work on specifying SR.

you cannot build a house without a plan beforehand, right ?

> -----Original Message-----
> From: Hannes Gredler [mailto:[email-masked]]
> Sent: Monday, September 09, 2013 12:49 PM
> To: Geib, R=FCdiger
> Cc: [email-masked]
> Subject: Re: [Status] Summary of STATUS BOF and the next steps
>
> ruediger,
>
> On Sep 9, 2013, at 11:26 AM, <[email-masked]> wrote:
>> sorry, but why should the ISPs interested in standardising SR worry abou=
t issues ocurring for ISPs who are not interested in migrating to SR? I don=
't think, SR should look for replacements, SR should work on simplification=
s. That's what the charter should express. I'm not interested in working wi=
thin a "LDP and RSVP-TE replacement WG". Sorry if my first mail was oversta=
ted to that regard ("...get rid of").
>
> if its not 'obsoleting' something, then it is by definition an 'extension=
' of something.
> in other words the complexity of the 'something' will be going up and nev=
er down.
> i haven't yet identified the code to be deleted, if SR is going to be a s=
uccess ;-)
>
>> DT so far does not utilise RSVP TE in parts of the backbone, but is inte=
rested in SR based features offering similar routing properties. Bandwidth =
reservation and preemption are completely irrelevant to me.
>
> that is fine and yet for the industry as a whole doing distributed
> bandwidth reservation *is* a relevant functionality.
>
>> If there are issues, we will (dis)cover them while we work on the techno=
logy. But discovering issues and analysing them shouldn't be core part of a=
 charter - the features to be developed should be.
>
> i'd rather do the analysis and planning exercise
> before commencing work.
>
>> [ ... ]
>
>
> /hannes
>
>> -----Original Message-----
>> From: Hannes Gredler [mailto:[email-masked]]
>> Sent: Monday, September 09, 2013 10:57 AM
>> To: Geib, R=FCdiger
>> Cc: [email-masked]
>> Subject: Re: [Status] Summary of STATUS BOF and the next steps
>>
>> ruediger,
>>
>> On Sep 9, 2013, at 9:08 AM, <[email-masked]> wrote:
>>> I'm worried about the proposal below, which seem to miss the most impor=
tant points of SR (I call it that):
>>>
>>> - SR allows to reduce complexity by getting rid of RSVP TE and LDP.
>>  ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
>>
>> that seem to be a gross misunderstanding on your side;
>>
>> 'reducing complexity' means *obsoleting* technology A with technology B.
>>
>> the issue is that introduction of SR does *neither* obsolete LDP *nor* R=
SVP,
>> simply because SR is not a 100% replacement of LDP and RSVP functionalit=
ies.
>>
>> SR lacks functionality in areas of:
>>
>> 1. LSP bandwidth reservation
>> 2. LSP preemption
>> 3. p2mp path construction
>> 4. PW signaling
>> 5. FRR node-protection
>>
>> adding the IGP as a label distribution protocol to the stack of protocol=
s
>> allows the network to do tunnel discovery and with that capability we ca=
n arguably fix
>> a couple of interesting problems, but does this single capability
>> make it a panacea for networking ?
>>
>>> - I don't fully understand why the SR work must address inter domain re=
lations, if
>>> it is supposed to be primarily chartered with intra domain control plan=
e issues.
>>> - My take is, that intra-domain MPLS forwarding will remain as is initi=
ally with SR.
>>
>> there are SPs which operate multi-AS domains and the implications
>> to connect those ASes using label-stacking technology should be worked o=
n.
>>
>>> - Your last bullet point means todays MPLS is out of scope, as no forwa=
rding
>>> definitions need to be changed?
>>
>> not sure if we can get away with zero changes - issues that we need to t=
alk about are:
>>
>> 1. MPLS source labels
>> 2. Entropy label implications of label stacking
>> 3. Hardware capabilites (Maxpushlabels) and management
>>
>>> - We agreed not work on protocols within the SR WG. Why has that been c=
hanged?
>>
>> there might be a a need to work on protocols which do not fit into exist=
ing WGs.
>>
>> HTH,
>>
>> /hannes
>>
>>> ---------------
>>>
>>> The <Name-TBD> working group is chartered for the following ordered lis=
t of work items:
>>>
>>> - The first goal of the WG is to identify use-cases.
>>> - The WG will then define the architecture framework associated with
>>> the security considerations. The architecture framework and security
>>> considerations must address the relations between domains (interdomain)=
.
>>> - Having identified use-cases, architecture and security, the WG will
>>> identify gaps between currently available technologies and use-case
>>> requirements.
>>> - The WG will then define requirements for extensions to existing
>>> protocols or new protocols that address gaps that are identified.
>>> - The WG will first focus on the intra-domain forwarding definition.
>>>
>>> Protocol work may be carried out in this working group or in other work=
ing groups responsible for the protocols, in coordination with this WG, and=
 in agreement with the WG chairs and responsible ADs.
>>> However, no protocol work will be adopted by a working group to address=
 the identified use-cases until the requirements document motivating the pr=
otocol work has been sent to the IESG for publication as an RFC.
>>>
>>> ---
>>>
>>> /hannes
>>>
>>> On Sep 4, 2013, at 10:02 AM, <[email-masked]> <stephane.=
[email-masked]> wrote:
>>>
>>>> Hannes,
>>>>
>>>> In case, we are using only directed forwarding (adjacency segment),
>>>> could we still talk about tunneling ? (it's a very very small tunnel) =
Moreover talking about "stacking" is really dataplane agnostic (MPLS) ...
>>>>
>>>> In the proposed segment routing architectural concepts, segments are a=
t the same "level" and pointer moves on the segment list, then the MPLS ins=
tantiation is performing this using stacking ...
>>>>
>>>> IMHO, if we use "Stacked Tunnels", we already talk about a chosen solu=
tion and it's closing the door to something else  ...
>>>>
>>>> Finally, about the "routing" word, routing is essentially a "forward" =
action which may limit the scope of what we can do by using a segment list.=
 Actions associated with a segment could be something else than forwarding.
>>>>
>>>> Do we want in the charter to limit the scope to routing actions ?
>>>>
>>>> I have no solution today to propose for the naming, but I completely a=
gree with Loa, to first focus on working on the charter, and define a clear=
 scope of the work and then the name will be easier to find.
>>>>
>>>> Regarding your charter proposal :
>>>>
>>>> --------
>>>>
>>>> - They form a connected network
>>>>     [SLI] InterAS case must be included, but the WG can go step by ste=
p and first release intraAS, and then doing interAS (in relation with IDR ?=
?).
>>>>
>>>> - They can forward traffic through the shortest paths or paths other t=
han the shortest (the latter called explicitly routed paths, or explicit pa=
ths)
>>>>     [SLI] There is something else between SPT and Explicit path, you c=
an define other algorithms than SPT to define a path, and it's not explicit=
 path. Moreover I come back to my comment, on do we want to limit the scope=
 to routing ? I would say no.
>>>>
>>>> - They share a common trust model. In this model, any router within th=
e ERD can specify an explicit path between itself and any other router in t=
he ERD. It can then send any packet that passes through it through any path=
 that it has specified.
>>>>     [SLI] Security considerations may have to be addressed in the
>>>> charter , especially for the interAS case (trust yes, but not sure
>>>> access to everything may not be good)
>>>>
>>>> Downstream routers within the ERD forward the packet as specified by t=
he router at the head-end of the path.
>>>> [SLI] Yes, but any router in the middle may be able to change the end =
to end explicit path.
>>>>
>>>>
>>>>
>>>> - The first goal of the STER WG is to identify use-cases for ERDs.
>>>> - Having identified use-cases, the WG will identify gaps between curre=
ntly available technologies and use-case requirements.
>>>> - The WG will then define requirements for extensions to existing prot=
ocols or new protocols that address gaps that are identified.
>>>>
>>>> [SLI] Agree, I would add :
>>>> - defining the architecture framework
>>>> - analysing the security considerisations
>>>>
>>>>
>>>> ---------
>>>>
>>>>
>>>> Here would be my proposal to extend yours :
>>>>
>>>> A <named to be defined> domain contains a set of routers with the foll=
owing characteristics:
>>>>
>>>> - They form a connected network
>>>> - They can forward traffic through any path within the network using
>>>> shortest path, non shortest path or explicit path
>>>> - They may provide other types of services than forwarding and they ca=
n enforce service actions in the path.
>>>> - They share a common trust model. In this model, any router within th=
e domain can specify a path between itself and any other router in the doma=
in. It may then send any packet that passes through it through any path tha=
t it has specified and that is conform to the security rules. Downstream ro=
uters within the ERD forward the packet as specified by the router at the h=
ead-end of the path.
>>>>
>>>> The <name> working group is chartered for the following ordered list o=
f work items:
>>>>
>>>> - The first goal of the WG is to identify use-cases.
>>>> - The WG will then define the architecture framework associated with t=
he security considerations. The architecture framework and security conside=
rations must address the relations between domains (interdomain).
>>>> - Having identified use-cases, architecture and security, the WG will =
identify gaps between currently available technologies and use-case require=
ments.
>>>> - The WG will then define requirements for extensions to existing prot=
ocols or new protocols that address gaps that are identified.
>>>> - The WG will first focus on the intra-domain forwarding definition.
>>>>
>>>> Protocol work may be carried out in this working group or in other wor=
king groups responsible for the protocols, in coordination with this WG, an=
d in agreement with the WG chairs and responsible ADs. However, no protocol=
 work will be adopted by a working group to address the ERD use-cases until=
 the requirements document motivating the protocol work has been sent to th=
e IESG for publication as an RFC.
>>>>
>>>> -----Message d'origine-----
>>>> De : [email-masked] [mailto:[email-masked]] De la
>>>> part de Hannes Gredler Envoy=E9 : mardi 3 septembre 2013 18:31 =C0 : L=
oa
>>>> Andersson Cc : [email-masked] Objet : Re: [Status] Summary of STATUS
>>>> BOF and the next steps
>>>>
>>>> good point - what about this charter proposal ?
>>>>
>>>> ---
>>>>
>>>> Stacked Tunnels for Explicit Routing (STER)
>>>> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
>>>>
>>>> A explicit routing domain (ERD) contains a set of routers with the fol=
lowing characteristics:
>>>>
>>>> - They form a connected network
>>>> - They can forward traffic through the shortest paths or paths other
>>>> than the shortest (the latter called explicitly routed paths, or
>>>> explicit paths)
>>>> - They share a common trust model. In this model, any router within th=
e ERD can specify an explicit path between itself and any other router in t=
he ERD. It can then send any packet that passes through it through any path=
 that it has specified. Downstream routers within the ERD forward the packe=
t as specified by the router at the head-end of the path.
>>>>
>>>> The STER working group is chartered for the following ordered list of =
work items:
>>>>
>>>> - The first goal of the STER WG is to identify use-cases for ERDs.
>>>> - Having identified use-cases, the WG will identify gaps between curre=
ntly available technologies and use-case requirements.
>>>> - The WG will then define requirements for extensions to existing prot=
ocols or new protocols that address gaps that are identified.
>>>>
>>>> Protocol work may be carried out in this working group or in other wor=
king groups responsible for the protocols, in coordination with this WG, an=
d in agreement with the WG chairs and responsible ADs. However, no protocol=
 work will be adopted by a working group to address the ERD use-cases until=
 the requirements document motivating the protocol work has been sent to th=
e IESG for publication as an RFC.
>>>>
>>>> ---
>>>>
>>>> <flame suit on>
>>>>
>>>> /hannes
>>>>
>>>>
>>>> On Sep 3, 2013, at 5:31 PM, Loa Andersson wrote:
>>>>
>>>>> Folks,
>>>>>
>>>>> Excuse me if I'm slightly out of the loop, but so far I have not seen
>>>>> a charter proposal, if there is one please point me to it.
>>>>>
>>>>> It seems a bit odd to put the cart (what the wg should do) before the
>>>>> horse (wg name). If we drill down the the charter first the wg name
>>>>> might be easier to figure out.
>>>>>
>>>>> /Loa
>>>>>
>>>>> PS
>>>>> OK I understand that the horse and cart analogy limps a  bit :).
>>>>>
>>>>>
>>>>>
>>>>> On 2013-09-03 17:22, AshwoodsmithPeter wrote:
>>>>>> " If the WG charter is limited to source routing, how will we handle=
 the "non source routing" use cases of segment routing ? In another working=
 group ? So we will go back to the WG synchronization issue that has been r=
aised for this technology ..."
>>>>>>
>>>>>> That's why I suggested SRV2. We are revisiting source routing with n=
ew concepts. More generic number/action behavior.
>>>>>>
>>>>>> Peter
>>>>>>
>>>>>> -----Original Message-----
>>>>>> From: [email-masked] [mailto:[email-masked]] On
>>>>>> Behalf Of [email-masked]
>>>>>> Sent: Tuesday, September 03, 2013 10:43 AM
>>>>>> To: AshwoodsmithPeter
>>>>>> Cc: [email-masked]
>>>>>> Subject: Re: [Status] Summary of STATUS BOF and the next steps
>>>>>>
>>>>>>
>>>>>> There was a misunderstanding in my small comment :) so I will explai=
n more :
>>>>>>
>>>>>> In segment routing, you have more than basic source routing : segmen=
t routing is just associate a segment number to an action and then combine =
segment as you want, yes you can do source routing, but you also can do mor=
e.
>>>>>>
>>>>>> In the other hand, I completely agree with your statement that
>>>>>> source routing is generic and dataplane agnostic, as segment routing=
 is ...
>>>>>> (segment routing is not a new dataplane ...)
>>>>>>
>>>>>> Now the definition of the WG naming must be inline with the charter
>>>>>> that will be defined ... (draft today)
>>>>>>
>>>>>> Based on the already existing consensus (at least for MPLS dataplane=
) brought up during Berlin STATUS BOF meeting, segment routing sounds to be=
 a good target candidate.
>>>>>>
>>>>>> So now, do we want to do more in the WG charter than just make progr=
essing segment routing architecture and uses cases document and ensure coor=
dination for the standardization of this technology ?
>>>>>>
>>>>>> Do we want to standardize other technologies in this WG ? I don't th=
ink so, based on Stewart's conclusion email from the BOF :"A new WG focused=
 solely on SR therefore needs to be create"
>>>>>>
>>>>>> If the WG charter is limited to source routing, how will we handle t=
he "non source routing" use cases of segment routing ? In another working g=
roup ? So we will go back to the WG synchronization issue that has been rai=
sed for this technology ...
>>>>>>
>>>>>> If the WG is focused on SR, let's use a name in relation with SR.
>>>>>>
>>>>>> Feedback ?
>>>>>>
>>>>>>
>>>>>> Stephane
>>>>>>
>>>>>>
>>>>>> -----Message d'origine-----
>>>>>> De : AshwoodsmithPeter [mailto:[email-masked]]
>>>>>> Envoy=E9 : mardi 3 septembre 2013 15:27 =C0 : LITKOWSKI Stephane
>>>>>> DTF/DERX Cc : John E Drake; Mark Townsley; Victor Kuarsingh; Roberta
>>>>>> Maglione (robmgl); John G. Scudder; Adrian Farrel; Alvaro Retana
>>>>>> (aretana); [email-masked]; Stewart Bryant (stbryant) Objet : Re:
>>>>>> [Status] Summary of STATUS BOF and the next steps
>>>>>>
>>>>>> The term "source routing" has been around for a very long time and i=
s data path agnostic. Its also the term used in the literature etc so my pr=
eference is to stick with this existing well known and data path agnostic t=
erm.
>>>>>>
>>>>>> Peter
>>>>>>
>>>>>> On Sep 3, 2013, at 9:07 AM, "[email-masked]" <stephan=
[email-masked]> wrote:
>>>>>>
>>>>>>> Hi,
>>>>>>>
>>>>>>> "Source routing" is just a subcase of segment routing ... as it is =
for IP routing ...
>>>>>>>
>>>>>>> Stephane
>>>>>>>
>>>>>>>
>>>>>>> -----Message d'origine-----
>>>>>>> De : [email-masked] [mailto:[email-masked]] De la
>>>>>>> part de John E Drake Envoy=E9 : mardi 3 septembre 2013 15:02 =C0 : =
Mark
>>>>>>> Townsley; Victor Kuarsingh Cc : Roberta Maglione (robmgl); John G.
>>>>>>> Scudder; Alvaro Retana (aretana); Adrian Farrel; [email-masked];
>>>>>>> Stewart Bryant (stbryant) Objet : Re: [Status] Summary of STATUS
>>>>>>> BOF and the next steps
>>>>>>>
>>>>>>> Hi,
>>>>>>>
>>>>>>> What is this 'segment routing' silliness?  The correct term is 'sou=
rce routing'.
>>>>>>>
>>>>>>> Yours Irrespectively,
>>>>>>>
>>>>>>> John
>>>>>>>
>>>>>>>> -----Original Message-----
>>>>>>>> From: [email-masked] [mailto:[email-masked]] On
>>>>>>>> Behalf Of Mark Townsley
>>>>>>>> Sent: Sunday, September 01, 2013 10:08 AM
>>>>>>>> To: Victor Kuarsingh
>>>>>>>> Cc: Roberta Maglione (robmgl); John G. Scudder; Adrian Farrel;
>>>>>>>> Alvaro Retana (aretana); [email-masked]; Stewart Bryant
>>>>>>>> (stbryant)
>>>>>>>> Subject: Re: [Status] Summary of STATUS BOF and the next steps
>>>>>>>>
>>>>>>>>
>>>>>>>> On Sep 1, 2013, at 5:38 PM, Victor Kuarsingh wrote:
>>>>>>>>
>>>>>>>>> All,
>>>>>>>>>
>>>>>>>>> I would also favour "Segment Routing WG" as well.
>>>>>>>>>
>>>>>>>>> I note this since attempting to come up with an all encompassing
>>>>>>>>> acronym will be difficult and Segment Routing is generic enough
>>>>>>>>> to associate to multiple functions.
>>>>>>>>
>>>>>>>> Then we can just use "segroute" for the short name. WGs do not
>>>>>>>> have to have acronyms, but they do need to have an 8-char limited
>>>>>>>> short name for the various automated tools not to break.
>>>>>>>>
>>>>>>>> - Mark
>>>>>>>>
>>>>>>>>>
>>>>>>>>> Regards,
>>>>>>>>>
>>>>>>>>> Victor K
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> On 2013-08-31 6:51 PM, "Roberta Maglione (robmgl)"
>>>>>>>>> <[email-masked]>
>>>>>>>>> wrote:
>>>>>>>>>
>>>>>>>>>> +1 for Segment Routing WG
>>>>>>>>>>
>>>>>>>>>> Roberta
>>>>>>>>>>
>>>>>>>>>> Sent from my iPad
>>>>>>>>>>
>>>>>>>>>> On 2013-08-30, at 2:55 PM, "Alvaro Retana (aretana)"
>>>>>>>>>> <[email-masked]>
>>>>>>>>>> wrote:
>>>>>>>>>>
>>>>>>>>>>> Segment Routing WG
>>>>>>>>>>>
>>>>>>>>>>> Sent from my iPhone
>>>>>>>>>>>
>>>>>>>>>>> On Aug 30, 2013, at 1:39 PM, "Stewart Bryant (stbryant)"
>>>>>>>>>>> <[email-masked]> wrote:
>>>>>>>>>>>
>>>>>>>>>>>> The second task, which hopefully should be relatively easy, is
>>>>>>>>>>>> to find a better working name for the WG, since it has been
>>>>>>>>>>>> put to me a number of times that STATUS is going to be
>>>>>>>>>>>> confusing in text and a difficult search term.
>>>>>>>>>>> _______________________________________________
>>>>>>>>>>> status mailing list
>>>>>>>>>>> [email-masked]
>>>>>>>>>>> https://www.ietf.org/mailman/listinfo/status
>>>>>>>>>> _______________________________________________
>>>>>>>>>> status mailing list
>>>>>>>>>> [email-masked]
>>>>>>>>>> https://www.ietf.org/mailman/listinfo/status
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> _______________________________________________
>>>>>>>>> status mailing list
>>>>>>>>> [email-masked]
>>>>>>>>> https://www.ietf.org/mailman/listinfo/status
>>>>>>>>
>>>>>>>> _______________________________________________
>>>>>>>> status mailing list
>>>>>>>> [email-masked]
>>>>>>>> https://www.ietf.org/mailman/listinfo/status
>>>>>>>
>>>>>>>
>>>>>>> _______________________________________________
>>>>>>> status mailing list
>>>>>>> [email-masked]
>>>>>>> https://www.ietf.org/mailman/listinfo/status
>>>>>>>
>>>>>>> ___________________________________________________________________
>>>>>>> _ __ ___________________________________________________
>>>>>>>
>>>>>>> Ce message et ses pieces jointes peuvent contenir des informations
>>>>>>> confidentielles ou privilegiees et ne doivent donc pas etre
>>>>>>> diffuses, exploites ou copies sans autorisation. Si vous avez recu
>>>>>>> ce message par erreur, veuillez le signaler a l'expediteur et le de=
truire ainsi que les pieces jointes. Les messages electroniques etant susce=
ptibles d'alteration, Orange decline toute responsabilite si ce message a e=
te altere, deforme ou falsifie. Merci.
>>>>>>>
>>>>>>> This message and its attachments may contain confidential or
>>>>>>> privileged information that may be protected by law; they should no=
t be distributed, used or copied without authorisation.
>>>>>>> If you have received this email in error, please notify the sender =
and delete this message and its attachments.
>>>>>>> As emails may be altered, Orange is not liable for messages that ha=
ve been modified, changed or falsified.
>>>>>>> Thank you.
>>>>>>>
>>>>>>> _______________________________________________
>>>>>>> status mailing list
>>>>>>> [email-masked]
>>>>>>> https://www.ietf.org/mailman/listinfo/status
>>>>>>
>>>>>> ____________________________________________________________________
>>>>>> _ ____________________________________________________
>>>>>>
>>>>>> Ce message et ses pieces jointes peuvent contenir des informations
>>>>>> confidentielles ou privilegiees et ne doivent donc pas etre
>>>>>> diffuses, exploites ou copies sans autorisation. Si vous avez recu
>>>>>> ce message par erreur, veuillez le signaler a l'expediteur et le det=
ruire ainsi que les pieces jointes. Les messages electroniques etant suscep=
tibles d'alteration, Orange decline toute responsabilite si ce message a et=
e altere, deforme ou falsifie. Merci.
>>>>>>
>>>>>> This message and its attachments may contain confidential or
>>>>>> privileged information that may be protected by law; they should not=
 be distributed, used or copied without authorisation.
>>>>>> If you have received this email in error, please notify the sender a=
nd delete this message and its attachments.
>>>>>> As emails may be altered, Orange is not liable for messages that hav=
e been modified, changed or falsified.
>>>>>> Thank you.
>>>>>>
>>>>>> _______________________________________________
>>>>>> status mailing list
>>>>>> [email-masked]
>>>>>> https://www.ietf.org/mailman/listinfo/status
>>>>>> _______________________________________________
>>>>>> status mailing list
>>>>>> [email-masked]
>>>>>> https://www.ietf.org/mailman/listinfo/status
>>>>>>
>>>>>
>>>>> --
>>>>>
>>>>>
>>>>> Loa Andersson                        email: [email-masked]
>>>>> Senior MPLS Expert                          [email-masked]
>>>>> Huawei Technologies (consultant)     phone: +46 739 81 21 64
>>>>> _______________________________________________
>>>>> status mailing list
>>>>> [email-masked]
>>>>> https://www.ietf.org/mailman/listinfo/status
>>>>>
>>>>>
>>>>
>>>>
>>>> _______________________________________________
>>>> status mailing list
>>>> [email-masked]
>>>> https://www.ietf.org/mailman/listinfo/status
>>>>
>>>> ______________________________________________________________________
>>>> ___________________________________________________
>>>>
>>>> Ce message et ses pieces jointes peuvent contenir des informations
>>>> confidentielles ou privilegiees et ne doivent donc pas etre diffuses,
>>>> exploites ou copies sans autorisation. Si vous avez recu ce message
>>>> par erreur, veuillez le signaler a l'expediteur et le detruire ainsi q=
ue les pieces jointes. Les messages electroniques etant susceptibles d'alte=
ration, Orange decline toute responsabilite si ce message a ete altere, def=
orme ou falsifie. Merci.
>>>>
>>>> This message and its attachments may contain confidential or
>>>> privileged information that may be protected by law; they should not b=
e distributed, used or copied without authorisation.
>>>> If you have received this email in error, please notify the sender and=
 delete this message and its attachments.
>>>> As emails may be altered, Orange is not liable for messages that have =
been modified, changed or falsified.
>>>> Thank you.
>>>>
>>>>
>>>>
>>>
>>>
>>> _______________________________________________
>>> status mailing list
>>> [email-masked]
>>> https://www.ietf.org/mailman/listinfo/status
>>>
>>>
>>
>>
>>
>>
>
>
>
>

Sender: [email-masked]
Date: Mon, 9 Sep 2013 14:44:39 +0200
From: Robert Raszuk <[email-masked]>
To: Hannes Gredler <[email-masked]>
Cc: "[email-masked]" <[email-masked]>
Subject: Re: [Status] Summary of STATUS BOF and the next steps

Hi Hannes,

>> How about LDP as starter ?
>
> this would really disappoint my RFC4447 (LDP pseudo wire) customers
> if i'd remove LDP support in favor of SR.

Pseudowires is an overlay application/service. As such a mechanism
which is much better suited to signal overlays should be recommended.

Hint: RFC4761 BGP works pretty well for p2mp discovery and signalling
... I see no reason to use bunch of LDP p2p sessions for that. Recall
discussions about LDP reflectors ;) ?

Likewise there are new emerging ways to signal overlay services, but I
think this is not the right place to discuss those.

>> Which of the below are solved by LDP ? Which LDP functionality will
>> not be covered by SR ?
>
> (3) is solved by mLDP and RSVP-TE.
> (1) and (2) is solved by RSVP-TE
>
>>>> 1. LSP bandwidth reservation
>>>> 2. LSP preemption
>>>> 3. p2mp path construction

mLDP has not much in common with LDP other then name. It is PIM ported
to signal MPLS bindings. I did not say to get rid of mLDP.

>> Note that those are all done today in the control plane. Therefor it
>> seems pretty trivial to accomplish all of those with SR using number
>        ^^^^^^^^^^^^^^
>> of PCE or PCE like controllers rather then use RSVP-TE for explicit
>> path signaling.
>
> "In theory there is no difference between theory and practice. In practic=
e there is."

You don't need to be that explicit .... ;-))

>   so lets discuss about the  *practical* side of things.
>
>   assume for a second that we have a single TE controller
>   that updates potentially thousands of PCE clients.
>   how long would it take to react after a topology change ?
>   (=3Drecompute and upload new explicit routes).
>   is it order of milliseconds ? order of seconds if not order of minutes =
?

As compared with what ? With today the same single controller
instructing all headends to do the re- signalling

Note that I am of the strong opinion that reaction to failures should
be precomputed and preinstalled ahead of failure in any technology we
use. Then upon failure control plane can take as much as needed to
"converge".

>   it is obvious that somehow you need to distribute the
>   TE-controller functionality such that you can re-act fast enough
>   to process topology changes. - the more distributed the controller gets
>   the more reactive the TE-controller system gets.

See above ... I would argue that link state flooding is much more
faster then hop by hop RSVP signalling. You may not agree ...

>   next lets assume that every PCE client gets its own PCE server, co-loca=
ted
>   with a zero-latency path and you will discover that this is no
>   different than what we have today.

If you follow some of the PCE discussions you would see that this
model does not allow for required optimization for number of traffic
distributions needs. Hint: Google centralized PCE model described in
public papers and presentations.

>   so what SR does wrt to TE is essentially shifting functionality around
>   rather than solving it in any better way.

It solves the signalling issue. The domain wide coordination of
computation of paths is still the same.

>>>> 5. FRR node-protection
>>
>> As you know computing LFA sort of addresses this topic pretty well.
>  ^^^^^^^^^^^
>
> no i don't - and for my own education would be really interested to learn
> how to provide node-protection for 1-hop (per-adjacency) labels.

Creating LFA bypass of each node with when required SR segment going
far enough that loops are guaranteed not to occur looks like pretty
easy exercise.

Sorry I have no math prove that this will address any network
topology, but I also see no reason why it would not.

>> Moreover SR may complete topologies where today LFA may not be
>> possible in 100% of coverage.
>
> i am afraid SR is still not there -

Perfect topic for this WG to make it be there. Can we add this to the chart=
er ?

> trouble is that LFA is like "star wars" - there are many episodes =85
>
> episode 1: rfc5286
> episode 2: remote-LFA
> episode 3: remote-LFA + DF
>
> note that even at this stage we haven't arrived at "100% coverage - no ma=
tter what"
> so likely there will be:
>
> episode 4: remote-LFA + recursive DF

And that's actually a great indication why issues are related and why
it would be productive to work on SR documents in RTGWG. I am sure
your familiarity with science-fiction movies could easily turn SR into
series of "start trek" episodes ...

> MPLS is a useful technology and most important the MPLS data plane
> is available today.

Sure. But as we do know MPLS lacks well defined inter-domain NNI, as
well as it's adoption in number of emerging solutions (DC fabrics) is
rather non existent.

> i have learned over the years that the pundits of "simpler, better
> cheaper" are very creative minds in omitting details which matter,
> (but do not necessarily work into their favor).

I am not afraid to discuss details. But discussing details is very
different in practice from building the wall of let's just discuss
missing gaps from what we have today. I am afraid this time it will
not work that way .. sorry.

Cheers,
R.

From: Hannes Gredler <[email-masked]>
Date: Mon, 9 Sep 2013 14:19:29 +0200
To: <[email-masked]>
Cc: [email-masked]
Subject: Re: [Status] Summary of STATUS BOF and the next steps

On Sep 9, 2013, at 1:58 PM, <[email-masked]> =
<[email-masked]> wrote:

> [ =85 ]
> In addition, SR will allow for very scaleable LSP monitoring OAM. =
Trying to to this with todays features is very complex (we've done =
that).

> SR can simplify LSP monitoring OAM as compared to what's available =
today.

thats fine - and the OAM use case is an undisputed one - no worries;

the question to you is:

for doing OAM do you need an IPv6-SR flavor and if so why ?

> Finally, if you prefer to do analysis and planning work, then why =
shouldn't you? In parallel to those commencing work on specifying SR.

you cannot build a house without a plan beforehand, right ?

> -----Original Message-----
> From: Hannes Gredler [mailto:[email-masked]]
> Sent: Monday, September 09, 2013 12:49 PM
> To: Geib, R=FCdiger
> Cc: [email-masked]
> Subject: Re: [Status] Summary of STATUS BOF and the next steps
>=20
> ruediger,
>=20
> On Sep 9, 2013, at 11:26 AM, <[email-masked]> wrote:
>> sorry, but why should the ISPs interested in standardising SR worry =
about issues ocurring for ISPs who are not interested in migrating to =
SR? I don't think, SR should look for replacements, SR should work on =
simplifications. That's what the charter should express. I'm not =
interested in working within a "LDP and RSVP-TE replacement WG". Sorry =
if my first mail was overstated to that regard ("...get rid of").
>=20
> if its not 'obsoleting' something, then it is by definition an =
'extension' of something.
> in other words the complexity of the 'something' will be going up and =
never down.
> i haven't yet identified the code to be deleted, if SR is going to be =
a success ;-)
>=20
>> DT so far does not utilise RSVP TE in parts of the backbone, but is =
interested in SR based features offering similar routing properties. =
Bandwidth reservation and preemption are completely irrelevant to me.
>=20
> that is fine and yet for the industry as a whole doing distributed
> bandwidth reservation *is* a relevant functionality.
>=20
>> If there are issues, we will (dis)cover them while we work on the =
technology. But discovering issues and analysing them shouldn't be core =
part of a charter - the features to be developed should be.
>=20
> i'd rather do the analysis and planning exercise
> before commencing work.
>=20
>> [ ... ]
>=20
>=20
> /hannes
>=20
>> -----Original Message-----
>> From: Hannes Gredler [mailto:[email-masked]]
>> Sent: Monday, September 09, 2013 10:57 AM
>> To: Geib, R=FCdiger
>> Cc: [email-masked]
>> Subject: Re: [Status] Summary of STATUS BOF and the next steps
>>=20
>> ruediger,
>>=20
>> On Sep 9, 2013, at 9:08 AM, <[email-masked]> wrote:
>>> I'm worried about the proposal below, which seem to miss the most =
important points of SR (I call it that):
>>>=20
>>> - SR allows to reduce complexity by getting rid of RSVP TE and LDP.
>>  ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
>>=20
>> that seem to be a gross misunderstanding on your side;
>>=20
>> 'reducing complexity' means *obsoleting* technology A with technology =
B.
>>=20
>> the issue is that introduction of SR does *neither* obsolete LDP =
*nor* RSVP,
>> simply because SR is not a 100% replacement of LDP and RSVP =
functionalities.
>>=20
>> SR lacks functionality in areas of:
>>=20
>> 1. LSP bandwidth reservation
>> 2. LSP preemption
>> 3. p2mp path construction
>> 4. PW signaling
>> 5. FRR node-protection
>>=20
>> adding the IGP as a label distribution protocol to the stack of =
protocols
>> allows the network to do tunnel discovery and with that capability we =
can arguably fix
>> a couple of interesting problems, but does this single capability
>> make it a panacea for networking ?
>>=20
>>> - I don't fully understand why the SR work must address inter domain =
relations, if
>>> it is supposed to be primarily chartered with intra domain control =
plane issues.
>>> - My take is, that intra-domain MPLS forwarding will remain as is =
initially with SR.
>>=20
>> there are SPs which operate multi-AS domains and the implications
>> to connect those ASes using label-stacking technology should be =
worked on.
>>=20
>>> - Your last bullet point means todays MPLS is out of scope, as no =
forwarding
>>> definitions need to be changed?
>>=20
>> not sure if we can get away with zero changes - issues that we need =
to talk about are:
>>=20
>> 1. MPLS source labels
>> 2. Entropy label implications of label stacking
>> 3. Hardware capabilites (Maxpushlabels) and management
>>=20
>>> - We agreed not work on protocols within the SR WG. Why has that =
been changed?
>>=20
>> there might be a a need to work on protocols which do not fit into =
existing WGs.
>>=20
>> HTH,
>>=20
>> /hannes
>>=20
>>> ---------------
>>>=20
>>> The <Name-TBD> working group is chartered for the following ordered =
list of work items:
>>>=20
>>> - The first goal of the WG is to identify use-cases.
>>> - The WG will then define the architecture framework associated with
>>> the security considerations. The architecture framework and security
>>> considerations must address the relations between domains =
(interdomain).
>>> - Having identified use-cases, architecture and security, the WG =
will
>>> identify gaps between currently available technologies and use-case
>>> requirements.
>>> - The WG will then define requirements for extensions to existing
>>> protocols or new protocols that address gaps that are identified.
>>> - The WG will first focus on the intra-domain forwarding definition.
>>>=20
>>> Protocol work may be carried out in this working group or in other =
working groups responsible for the protocols, in coordination with this =
WG, and in agreement with the WG chairs and responsible ADs.
>>> However, no protocol work will be adopted by a working group to =
address the identified use-cases until the requirements document =
motivating the protocol work has been sent to the IESG for publication =
as an RFC.
>>>=20
>>> ---
>>>=20
>>> /hannes
>>>=20
>>> On Sep 4, 2013, at 10:02 AM, <[email-masked]> =
<[email-masked]> wrote:
>>>=20
>>>> Hannes,
>>>>=20
>>>> In case, we are using only directed forwarding (adjacency segment),
>>>> could we still talk about tunneling ? (it's a very very small =
tunnel) Moreover talking about "stacking" is really dataplane agnostic =
(MPLS) ...
>>>>=20
>>>> In the proposed segment routing architectural concepts, segments =
are at the same "level" and pointer moves on the segment list, then the =
MPLS instantiation is performing this using stacking ...
>>>>=20
>>>> IMHO, if we use "Stacked Tunnels", we already talk about a chosen =
solution and it's closing the door to something else  ...
>>>>=20
>>>> Finally, about the "routing" word, routing is essentially a =
"forward" action which may limit the scope of what we can do by using a =
segment list. Actions associated with a segment could be something else =
than forwarding.
>>>>=20
>>>> Do we want in the charter to limit the scope to routing actions ?
>>>>=20
>>>> I have no solution today to propose for the naming, but I =
completely agree with Loa, to first focus on working on the charter, and =
define a clear scope of the work and then the name will be easier to =
find.
>>>>=20
>>>> Regarding your charter proposal :
>>>>=20
>>>> --------
>>>>=20
>>>> - They form a connected network
>>>>     [SLI] InterAS case must be included, but the WG can go step by =
step and first release intraAS, and then doing interAS (in relation with =
IDR ??).
>>>>=20
>>>> - They can forward traffic through the shortest paths or paths =
other than the shortest (the latter called explicitly routed paths, or =
explicit paths)
>>>>     [SLI] There is something else between SPT and Explicit path, =
you can define other algorithms than SPT to define a path, and it's not =
explicit path. Moreover I come back to my comment, on do we want to =
limit the scope to routing ? I would say no.
>>>>=20
>>>> - They share a common trust model. In this model, any router within =
the ERD can specify an explicit path between itself and any other router =
in the ERD. It can then send any packet that passes through it through =
any path that it has specified.
>>>>     [SLI] Security considerations may have to be addressed in the
>>>> charter , especially for the interAS case (trust yes, but not sure
>>>> access to everything may not be good)
>>>>=20
>>>> Downstream routers within the ERD forward the packet as specified =
by the router at the head-end of the path.
>>>> [SLI] Yes, but any router in the middle may be able to change the =
end to end explicit path.
>>>>=20
>>>>=20
>>>>=20
>>>> - The first goal of the STER WG is to identify use-cases for ERDs.
>>>> - Having identified use-cases, the WG will identify gaps between =
currently available technologies and use-case requirements.
>>>> - The WG will then define requirements for extensions to existing =
protocols or new protocols that address gaps that are identified.
>>>>=20
>>>> [SLI] Agree, I would add :
>>>> - defining the architecture framework
>>>> - analysing the security considerisations
>>>>=20
>>>>=20
>>>> ---------
>>>>=20
>>>>=20
>>>> Here would be my proposal to extend yours :
>>>>=20
>>>> A <named to be defined> domain contains a set of routers with the =
following characteristics:
>>>>=20
>>>> - They form a connected network
>>>> - They can forward traffic through any path within the network =
using
>>>> shortest path, non shortest path or explicit path
>>>> - They may provide other types of services than forwarding and they =
can enforce service actions in the path.
>>>> - They share a common trust model. In this model, any router within =
the domain can specify a path between itself and any other router in the =
domain. It may then send any packet that passes through it through any =
path that it has specified and that is conform to the security rules. =
Downstream routers within the ERD forward the packet as specified by the =
router at the head-end of the path.
>>>>=20
>>>> The <name> working group is chartered for the following ordered =
list of work items:
>>>>=20
>>>> - The first goal of the WG is to identify use-cases.
>>>> - The WG will then define the architecture framework associated =
with the security considerations. The architecture framework and =
security considerations must address the relations between domains =
(interdomain).
>>>> - Having identified use-cases, architecture and security, the WG =
will identify gaps between currently available technologies and use-case =
requirements.
>>>> - The WG will then define requirements for extensions to existing =
protocols or new protocols that address gaps that are identified.
>>>> - The WG will first focus on the intra-domain forwarding =
definition.
>>>>=20
>>>> Protocol work may be carried out in this working group or in other =
working groups responsible for the protocols, in coordination with this =
WG, and in agreement with the WG chairs and responsible ADs. However, no =
protocol work will be adopted by a working group to address the ERD =
use-cases until the requirements document motivating the protocol work =
has been sent to the IESG for publication as an RFC.
>>>>=20
>>>> -----Message d'origine-----
>>>> De : [email-masked] [mailto:[email-masked]] De la
>>>> part de Hannes Gredler Envoy=E9 : mardi 3 septembre 2013 18:31 =C0 =
: Loa
>>>> Andersson Cc : [email-masked] Objet : Re: [Status] Summary of =
STATUS
>>>> BOF and the next steps
>>>>=20
>>>> good point - what about this charter proposal ?
>>>>=20
>>>> ---
>>>>=20
>>>> Stacked Tunnels for Explicit Routing (STER)
>>>> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
>>>>=20
>>>> A explicit routing domain (ERD) contains a set of routers with the =
following characteristics:
>>>>=20
>>>> - They form a connected network
>>>> - They can forward traffic through the shortest paths or paths =
other
>>>> than the shortest (the latter called explicitly routed paths, or
>>>> explicit paths)
>>>> - They share a common trust model. In this model, any router within =
the ERD can specify an explicit path between itself and any other router =
in the ERD. It can then send any packet that passes through it through =
any path that it has specified. Downstream routers within the ERD =
forward the packet as specified by the router at the head-end of the =
path.
>>>>=20
>>>> The STER working group is chartered for the following ordered list =
of work items:
>>>>=20
>>>> - The first goal of the STER WG is to identify use-cases for ERDs.
>>>> - Having identified use-cases, the WG will identify gaps between =
currently available technologies and use-case requirements.
>>>> - The WG will then define requirements for extensions to existing =
protocols or new protocols that address gaps that are identified.
>>>>=20
>>>> Protocol work may be carried out in this working group or in other =
working groups responsible for the protocols, in coordination with this =
WG, and in agreement with the WG chairs and responsible ADs. However, no =
protocol work will be adopted by a working group to address the ERD =
use-cases until the requirements document motivating the protocol work =
has been sent to the IESG for publication as an RFC.
>>>>=20
>>>> ---
>>>>=20
>>>> <flame suit on>
>>>>=20
>>>> /hannes
>>>>=20
>>>>=20
>>>> On Sep 3, 2013, at 5:31 PM, Loa Andersson wrote:
>>>>=20
>>>>> Folks,
>>>>>=20
>>>>> Excuse me if I'm slightly out of the loop, but so far I have not =
seen
>>>>> a charter proposal, if there is one please point me to it.
>>>>>=20
>>>>> It seems a bit odd to put the cart (what the wg should do) before =
the
>>>>> horse (wg name). If we drill down the the charter first the wg =
name
>>>>> might be easier to figure out.
>>>>>=20
>>>>> /Loa
>>>>>=20
>>>>> PS
>>>>> OK I understand that the horse and cart analogy limps a  bit :).
>>>>>=20
>>>>>=20
>>>>>=20
>>>>> On 2013-09-03 17:22, AshwoodsmithPeter wrote:
>>>>>> " If the WG charter is limited to source routing, how will we =
handle the "non source routing" use cases of segment routing ? In =
another working group ? So we will go back to the WG synchronization =
issue that has been raised for this technology ..."
>>>>>>=20
>>>>>> That's why I suggested SRV2. We are revisiting source routing =
with new concepts. More generic number/action behavior.
>>>>>>=20
>>>>>> Peter
>>>>>>=20
>>>>>> -----Original Message-----
>>>>>> From: [email-masked] [mailto:[email-masked]] On
>>>>>> Behalf Of [email-masked]
>>>>>> Sent: Tuesday, September 03, 2013 10:43 AM
>>>>>> To: AshwoodsmithPeter
>>>>>> Cc: [email-masked]
>>>>>> Subject: Re: [Status] Summary of STATUS BOF and the next steps
>>>>>>=20
>>>>>>=20
>>>>>> There was a misunderstanding in my small comment :) so I will =
explain more :
>>>>>>=20
>>>>>> In segment routing, you have more than basic source routing : =
segment routing is just associate a segment number to an action and then =
combine segment as you want, yes you can do source routing, but you also =
can do more.
>>>>>>=20
>>>>>> In the other hand, I completely agree with your statement that
>>>>>> source routing is generic and dataplane agnostic, as segment =
routing is ...
>>>>>> (segment routing is not a new dataplane ...)
>>>>>>=20
>>>>>> Now the definition of the WG naming must be inline with the =
charter
>>>>>> that will be defined ... (draft today)
>>>>>>=20
>>>>>> Based on the already existing consensus (at least for MPLS =
dataplane) brought up during Berlin STATUS BOF meeting, segment routing =
sounds to be a good target candidate.
>>>>>>=20
>>>>>> So now, do we want to do more in the WG charter than just make =
progressing segment routing architecture and uses cases document and =
ensure coordination for the standardization of this technology ?
>>>>>>=20
>>>>>> Do we want to standardize other technologies in this WG ? I don't =
think so, based on Stewart's conclusion email from the BOF :"A new WG =
focused solely on SR therefore needs to be create"
>>>>>>=20
>>>>>> If the WG charter is limited to source routing, how will we =
handle the "non source routing" use cases of segment routing ? In =
another working group ? So we will go back to the WG synchronization =
issue that has been raised for this technology ...
>>>>>>=20
>>>>>> If the WG is focused on SR, let's use a name in relation with SR.
>>>>>>=20
>>>>>> Feedback ?
>>>>>>=20
>>>>>>=20
>>>>>> Stephane
>>>>>>=20
>>>>>>=20
>>>>>> -----Message d'origine-----
>>>>>> De : AshwoodsmithPeter [mailto:[email-masked]]
>>>>>> Envoy=E9 : mardi 3 septembre 2013 15:27 =C0 : LITKOWSKI Stephane
>>>>>> DTF/DERX Cc : John E Drake; Mark Townsley; Victor Kuarsingh; =
Roberta
>>>>>> Maglione (robmgl); John G. Scudder; Adrian Farrel; Alvaro Retana
>>>>>> (aretana); [email-masked]; Stewart Bryant (stbryant) Objet : Re:
>>>>>> [Status] Summary of STATUS BOF and the next steps
>>>>>>=20
>>>>>> The term "source routing" has been around for a very long time =
and is data path agnostic. Its also the term used in the literature etc =
so my preference is to stick with this existing well known and data path =
agnostic term.
>>>>>>=20
>>>>>> Peter
>>>>>>=20
>>>>>> On Sep 3, 2013, at 9:07 AM, "[email-masked]" =
<[email-masked]> wrote:
>>>>>>=20
>>>>>>> Hi,
>>>>>>>=20
>>>>>>> "Source routing" is just a subcase of segment routing ... as it =
is for IP routing ...
>>>>>>>=20
>>>>>>> Stephane
>>>>>>>=20
>>>>>>>=20
>>>>>>> -----Message d'origine-----
>>>>>>> De : [email-masked] [mailto:[email-masked]] De =
la
>>>>>>> part de John E Drake Envoy=E9 : mardi 3 septembre 2013 15:02 =C0 =
: Mark
>>>>>>> Townsley; Victor Kuarsingh Cc : Roberta Maglione (robmgl); John =
G.
>>>>>>> Scudder; Alvaro Retana (aretana); Adrian Farrel; =
[email-masked];
>>>>>>> Stewart Bryant (stbryant) Objet : Re: [Status] Summary of STATUS
>>>>>>> BOF and the next steps
>>>>>>>=20
>>>>>>> Hi,
>>>>>>>=20
>>>>>>> What is this 'segment routing' silliness?  The correct term is =
'source routing'.
>>>>>>>=20
>>>>>>> Yours Irrespectively,
>>>>>>>=20
>>>>>>> John
>>>>>>>=20
>>>>>>>> -----Original Message-----
>>>>>>>> From: [email-masked] [mailto:[email-masked]] =
On
>>>>>>>> Behalf Of Mark Townsley
>>>>>>>> Sent: Sunday, September 01, 2013 10:08 AM
>>>>>>>> To: Victor Kuarsingh
>>>>>>>> Cc: Roberta Maglione (robmgl); John G. Scudder; Adrian Farrel;
>>>>>>>> Alvaro Retana (aretana); [email-masked]; Stewart Bryant
>>>>>>>> (stbryant)
>>>>>>>> Subject: Re: [Status] Summary of STATUS BOF and the next steps
>>>>>>>>=20
>>>>>>>>=20
>>>>>>>> On Sep 1, 2013, at 5:38 PM, Victor Kuarsingh wrote:
>>>>>>>>=20
>>>>>>>>> All,
>>>>>>>>>=20
>>>>>>>>> I would also favour "Segment Routing WG" as well.
>>>>>>>>>=20
>>>>>>>>> I note this since attempting to come up with an all =
encompassing
>>>>>>>>> acronym will be difficult and Segment Routing is generic =
enough
>>>>>>>>> to associate to multiple functions.
>>>>>>>>=20
>>>>>>>> Then we can just use "segroute" for the short name. WGs do not
>>>>>>>> have to have acronyms, but they do need to have an 8-char =
limited
>>>>>>>> short name for the various automated tools not to break.
>>>>>>>>=20
>>>>>>>> - Mark
>>>>>>>>=20
>>>>>>>>>=20
>>>>>>>>> Regards,
>>>>>>>>>=20
>>>>>>>>> Victor K
>>>>>>>>>=20
>>>>>>>>>=20
>>>>>>>>>=20
>>>>>>>>> On 2013-08-31 6:51 PM, "Roberta Maglione (robmgl)"
>>>>>>>>> <[email-masked]>
>>>>>>>>> wrote:
>>>>>>>>>=20
>>>>>>>>>> +1 for Segment Routing WG
>>>>>>>>>>=20
>>>>>>>>>> Roberta
>>>>>>>>>>=20
>>>>>>>>>> Sent from my iPad
>>>>>>>>>>=20
>>>>>>>>>> On 2013-08-30, at 2:55 PM, "Alvaro Retana (aretana)"
>>>>>>>>>> <[email-masked]>
>>>>>>>>>> wrote:
>>>>>>>>>>=20
>>>>>>>>>>> Segment Routing WG
>>>>>>>>>>>=20
>>>>>>>>>>> Sent from my iPhone
>>>>>>>>>>>=20
>>>>>>>>>>> On Aug 30, 2013, at 1:39 PM, "Stewart Bryant (stbryant)"
>>>>>>>>>>> <[email-masked]> wrote:
>>>>>>>>>>>=20
>>>>>>>>>>>> The second task, which hopefully should be relatively easy, =
is
>>>>>>>>>>>> to find a better working name for the WG, since it has been
>>>>>>>>>>>> put to me a number of times that STATUS is going to be
>>>>>>>>>>>> confusing in text and a difficult search term.
>>>>>>>>>>> _______________________________________________
>>>>>>>>>>> status mailing list
>>>>>>>>>>> [email-masked]
>>>>>>>>>>> https://www.ietf.org/mailman/listinfo/status
>>>>>>>>>> _______________________________________________
>>>>>>>>>> status mailing list
>>>>>>>>>> [email-masked]
>>>>>>>>>> https://www.ietf.org/mailman/listinfo/status
>>>>>>>>>=20
>>>>>>>>>=20
>>>>>>>>> _______________________________________________
>>>>>>>>> status mailing list
>>>>>>>>> [email-masked]
>>>>>>>>> https://www.ietf.org/mailman/listinfo/status
>>>>>>>>=20
>>>>>>>> _______________________________________________
>>>>>>>> status mailing list
>>>>>>>> [email-masked]
>>>>>>>> https://www.ietf.org/mailman/listinfo/status
>>>>>>>=20
>>>>>>>=20
>>>>>>> _______________________________________________
>>>>>>> status mailing list
>>>>>>> [email-masked]
>>>>>>> https://www.ietf.org/mailman/listinfo/status
>>>>>>>=20
>>>>>>> =
___________________________________________________________________
>>>>>>> _ __ ___________________________________________________
>>>>>>>=20
>>>>>>> Ce message et ses pieces jointes peuvent contenir des =
informations
>>>>>>> confidentielles ou privilegiees et ne doivent donc pas etre
>>>>>>> diffuses, exploites ou copies sans autorisation. Si vous avez =
recu
>>>>>>> ce message par erreur, veuillez le signaler a l'expediteur et le =
detruire ainsi que les pieces jointes. Les messages electroniques etant =
susceptibles d'alteration, Orange decline toute responsabilite si ce =
message a ete altere, deforme ou falsifie. Merci.
>>>>>>>=20
>>>>>>> This message and its attachments may contain confidential or
>>>>>>> privileged information that may be protected by law; they should =
not be distributed, used or copied without authorisation.
>>>>>>> If you have received this email in error, please notify the =
sender and delete this message and its attachments.
>>>>>>> As emails may be altered, Orange is not liable for messages that =
have been modified, changed or falsified.
>>>>>>> Thank you.
>>>>>>>=20
>>>>>>> _______________________________________________
>>>>>>> status mailing list
>>>>>>> [email-masked]
>>>>>>> https://www.ietf.org/mailman/listinfo/status
>>>>>>=20
>>>>>> =
____________________________________________________________________
>>>>>> _ ____________________________________________________
>>>>>>=20
>>>>>> Ce message et ses pieces jointes peuvent contenir des =
informations
>>>>>> confidentielles ou privilegiees et ne doivent donc pas etre
>>>>>> diffuses, exploites ou copies sans autorisation. Si vous avez =
recu
>>>>>> ce message par erreur, veuillez le signaler a l'expediteur et le =
detruire ainsi que les pieces jointes. Les messages electroniques etant =
susceptibles d'alteration, Orange decline toute responsabilite si ce =
message a ete altere, deforme ou falsifie. Merci.
>>>>>>=20
>>>>>> This message and its attachments may contain confidential or
>>>>>> privileged information that may be protected by law; they should =
not be distributed, used or copied without authorisation.
>>>>>> If you have received this email in error, please notify the =
sender and delete this message and its attachments.
>>>>>> As emails may be altered, Orange is not liable for messages that =
have been modified, changed or falsified.
>>>>>> Thank you.
>>>>>>=20
>>>>>> _______________________________________________
>>>>>> status mailing list
>>>>>> [email-masked]
>>>>>> https://www.ietf.org/mailman/listinfo/status
>>>>>> _______________________________________________
>>>>>> status mailing list
>>>>>> [email-masked]
>>>>>> https://www.ietf.org/mailman/listinfo/status
>>>>>>=20
>>>>>=20
>>>>> --
>>>>>=20
>>>>>=20
>>>>> Loa Andersson                        email: [email-masked]
>>>>> Senior MPLS Expert                          [email-masked]
>>>>> Huawei Technologies (consultant)     phone: +46 739 81 21 64
>>>>> _______________________________________________
>>>>> status mailing list
>>>>> [email-masked]
>>>>> https://www.ietf.org/mailman/listinfo/status
>>>>>=20
>>>>>=20
>>>>=20
>>>>=20
>>>> _______________________________________________
>>>> status mailing list
>>>> [email-masked]
>>>> https://www.ietf.org/mailman/listinfo/status
>>>>=20
>>>> =
______________________________________________________________________
>>>> ___________________________________________________
>>>>=20
>>>> Ce message et ses pieces jointes peuvent contenir des informations
>>>> confidentielles ou privilegiees et ne doivent donc pas etre =
diffuses,
>>>> exploites ou copies sans autorisation. Si vous avez recu ce message
>>>> par erreur, veuillez le signaler a l'expediteur et le detruire =
ainsi que les pieces jointes. Les messages electroniques etant =
susceptibles d'alteration, Orange decline toute responsabilite si ce =
message a ete altere, deforme ou falsifie. Merci.
>>>>=20
>>>> This message and its attachments may contain confidential or
>>>> privileged information that may be protected by law; they should =
not be distributed, used or copied without authorisation.
>>>> If you have received this email in error, please notify the sender =
and delete this message and its attachments.
>>>> As emails may be altered, Orange is not liable for messages that =
have been modified, changed or falsified.
>>>> Thank you.
>>>>=20
>>>>=20
>>>>=20
>>>=20
>>>=20
>>> _______________________________________________
>>> status mailing list
>>> [email-masked]
>>> https://www.ietf.org/mailman/listinfo/status
>>>=20
>>>=20
>>=20
>>=20
>>=20
>>=20
>=20
>=20
>=20
>=20

From: Hannes Gredler <[email-masked]>
Date: Mon, 9 Sep 2013 14:13:02 +0200
To: Robert Raszuk <[email-masked]>
Cc: [email-masked]
Subject: Re: [Status] Summary of STATUS BOF and the next steps

robert,

On Sep 9, 2013, at 1:03 PM, Robert Raszuk wrote:

>> i haven't yet identified the code to be deleted, if SR is going to be =
a success ;-)
>=20
> How about LDP as starter ?

this would really disappoint my RFC4447 (LDP pseudo wire) customers
if i'd remove LDP support in favor of SR.

> Which of the below are solved by LDP ? Which LDP functionality will
> not be covered by SR ?

(3) is solved by mLDP and RSVP-TE.
(1) and (2) is solved by RSVP-TE

>>> 1. LSP bandwidth reservation
>>> 2. LSP preemption
>>> 3. p2mp path construction
>=20
> Note that those are all done today in the control plane. Therefor it
> seems pretty trivial to accomplish all of those with SR using number
       ^^^^^^^^^^^^^^
> of PCE or PCE like controllers rather then use RSVP-TE for explicit
> path signaling.

"In theory there is no difference between theory and practice. In =
practice there is."

  so lets discuss about the  *practical* side of things.

  assume for a second that we have a single TE controller
  that updates potentially thousands of PCE clients.
  how long would it take to react after a topology change ?
  (=3Drecompute and upload new explicit routes).
  is it order of milliseconds ? order of seconds if not order of minutes =
?

  it is obvious that somehow you need to distribute the
  TE-controller functionality such that you can re-act fast enough
  to process topology changes. - the more distributed the controller =
gets
  the more reactive the TE-controller system gets.

  next lets assume that every PCE client gets its own PCE server, =
co-located
  with a zero-latency path and you will discover that this is no
  different than what we have today.

  so what SR does wrt to TE is essentially shifting functionality around
  rather than solving it in any better way.

>>> 5. FRR node-protection
>=20
> As you know computing LFA sort of addresses this topic pretty well.
 ^^^^^^^^^^^

no i don't - and for my own education would be really interested to =
learn
how to provide node-protection for 1-hop (per-adjacency) labels.

> Moreover SR may complete topologies where today LFA may not be
> possible in 100% of coverage.

i am afraid SR is still not there -
trouble is that LFA is like "star wars" - there are many episodes =85

episode 1: rfc5286=20
episode 2: remote-LFA
episode 3: remote-LFA + DF

note that even at this stage we haven't arrived at "100% coverage - no =
matter what"
so likely there will be:

episode 4: remote-LFA + recursive DF

>>> a couple of interesting problems, but does this single capability
>>> make it a panacea for networking ?
>=20
> Some folks think that MPLS is a panacea for networking .. SR with IP
> encap can prove it is not ;) That's the beauty of it.

do we really want to revamp 15 years old discussions - get over it ;-)

MPLS is a useful technology and most important the MPLS data plane
is available today.

>> apart from that i simply fail to see the need for developing =
redundant
>> technology within IETF.
>=20
> Why not since the redundant technology has much better scaling and
 ^^^^^^^
> operational properties. It simplifies control plane and that alone
> should be sufficient reason.

i have learned over the years that the pundits of "simpler, better
cheaper" are very creative minds in omitting details which matter,
(but do not necessarily work into their favor).

/hannes

From: <[email-masked]>
To: <[email-masked]>
Date: Mon, 9 Sep 2013 13:58:04 +0200
Accept-Language: en-US, de-DE
acceptlanguage: en-US, de-DE
Cc: [email-masked]
Subject: Re: [Status] Summary of STATUS BOF and the next steps

Hannes,

please try to bring the discussion forward.

- I do not support deployment of RSVP TE in the DT backbone because
  this adds undesired complexity. Why should I worry about
  obsoleting RSVP-TE or aim on that, if I think the cost of deploying
  RSVP-TE is too high as compared to the gain?

- I'm happy extending ISIS, if this allows for an additional
  range of TE (and OAM) functions. That's what I'll gain if SR is a success=
.

I think my point is clear. I don't want to keep you from discussing RSVP-TE=
 related topics with others and I fully respect if others have RSVP-TE rela=
ted issues.

In addition, SR will allow for very scaleable LSP monitoring OAM. Trying to=
 to this with todays features is very complex (we've done that).

SR can simplify LSP monitoring OAM as compared to what's available today.

Finally, if you prefer to do analysis and planning work, then why shouldn't=
 you? In parallel to those commencing work on specifying SR.

Regards,

Ruediger

-----Original Message-----
From: Hannes Gredler [mailto:[email-masked]]
Sent: Monday, September 09, 2013 12:49 PM
To: Geib, R=FCdiger
Cc: [email-masked]
Subject: Re: [Status] Summary of STATUS BOF and the next steps

ruediger,

On Sep 9, 2013, at 11:26 AM, <[email-masked]> wrote:
> sorry, but why should the ISPs interested in standardising SR worry about=
 issues ocurring for ISPs who are not interested in migrating to SR? I don'=
t think, SR should look for replacements, SR should work on simplifications=
. That's what the charter should express. I'm not interested in working wit=
hin a "LDP and RSVP-TE replacement WG". Sorry if my first mail was overstat=
ed to that regard ("...get rid of").

if its not 'obsoleting' something, then it is by definition an 'extension' =
of something.
in other words the complexity of the 'something' will be going up and never=
 down.
i haven't yet identified the code to be deleted, if SR is going to be a suc=
cess ;-)

> DT so far does not utilise RSVP TE in parts of the backbone, but is inter=
ested in SR based features offering similar routing properties. Bandwidth r=
eservation and preemption are completely irrelevant to me.

that is fine and yet for the industry as a whole doing distributed
bandwidth reservation *is* a relevant functionality.

> If there are issues, we will (dis)cover them while we work on the technol=
ogy. But discovering issues and analysing them shouldn't be core part of a =
charter - the features to be developed should be.

i'd rather do the analysis and planning exercise
before commencing work.

> [ ... ]

/hannes

> -----Original Message-----
> From: Hannes Gredler [mailto:[email-masked]]
> Sent: Monday, September 09, 2013 10:57 AM
> To: Geib, R=FCdiger
> Cc: [email-masked]
> Subject: Re: [Status] Summary of STATUS BOF and the next steps
>
> ruediger,
>
> On Sep 9, 2013, at 9:08 AM, <[email-masked]> wrote:
>> I'm worried about the proposal below, which seem to miss the most import=
ant points of SR (I call it that):
>>
>> - SR allows to reduce complexity by getting rid of RSVP TE and LDP.
>   ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
>
> that seem to be a gross misunderstanding on your side;
>
> 'reducing complexity' means *obsoleting* technology A with technology B.
>
> the issue is that introduction of SR does *neither* obsolete LDP *nor* RS=
VP,
> simply because SR is not a 100% replacement of LDP and RSVP functionaliti=
es.
>
> SR lacks functionality in areas of:
>
>  1. LSP bandwidth reservation
>  2. LSP preemption
>  3. p2mp path construction
>  4. PW signaling
>  5. FRR node-protection
>
> adding the IGP as a label distribution protocol to the stack of protocols
> allows the network to do tunnel discovery and with that capability we can=
 arguably fix
> a couple of interesting problems, but does this single capability
> make it a panacea for networking ?
>
>> - I don't fully understand why the SR work must address inter domain rel=
ations, if
>> it is supposed to be primarily chartered with intra domain control plane=
 issues.
>> - My take is, that intra-domain MPLS forwarding will remain as is initia=
lly with SR.
>
> there are SPs which operate multi-AS domains and the implications
> to connect those ASes using label-stacking technology should be worked on=
.
>
>> - Your last bullet point means todays MPLS is out of scope, as no forwar=
ding
>> definitions need to be changed?
>
> not sure if we can get away with zero changes - issues that we need to ta=
lk about are:
>
> 1. MPLS source labels
> 2. Entropy label implications of label stacking
> 3. Hardware capabilites (Maxpushlabels) and management
>
>> - We agreed not work on protocols within the SR WG. Why has that been ch=
anged?
>
> there might be a a need to work on protocols which do not fit into existi=
ng WGs.
>
> HTH,
>
> /hannes
>
>> ---------------
>>
>> The <Name-TBD> working group is chartered for the following ordered list=
 of work items:
>>
>> - The first goal of the WG is to identify use-cases.
>> - The WG will then define the architecture framework associated with
>> the security considerations. The architecture framework and security
>> considerations must address the relations between domains (interdomain).
>> - Having identified use-cases, architecture and security, the WG will
>> identify gaps between currently available technologies and use-case
>> requirements.
>> - The WG will then define requirements for extensions to existing
>> protocols or new protocols that address gaps that are identified.
>> - The WG will first focus on the intra-domain forwarding definition.
>>
>> Protocol work may be carried out in this working group or in other worki=
ng groups responsible for the protocols, in coordination with this WG, and =
in agreement with the WG chairs and responsible ADs.
>> However, no protocol work will be adopted by a working group to address =
the identified use-cases until the requirements document motivating the pro=
tocol work has been sent to the IESG for publication as an RFC.
>>
>> ---
>>
>> /hannes
>>
>> On Sep 4, 2013, at 10:02 AM, <[email-masked]> <stephane.l=
[email-masked]> wrote:
>>
>>> Hannes,
>>>
>>> In case, we are using only directed forwarding (adjacency segment),
>>> could we still talk about tunneling ? (it's a very very small tunnel) M=
oreover talking about "stacking" is really dataplane agnostic (MPLS) ...
>>>
>>> In the proposed segment routing architectural concepts, segments are at=
 the same "level" and pointer moves on the segment list, then the MPLS inst=
antiation is performing this using stacking ...
>>>
>>> IMHO, if we use "Stacked Tunnels", we already talk about a chosen solut=
ion and it's closing the door to something else  ...
>>>
>>> Finally, about the "routing" word, routing is essentially a "forward" a=
ction which may limit the scope of what we can do by using a segment list. =
Actions associated with a segment could be something else than forwarding.
>>>
>>> Do we want in the charter to limit the scope to routing actions ?
>>>
>>> I have no solution today to propose for the naming, but I completely ag=
ree with Loa, to first focus on working on the charter, and define a clear =
scope of the work and then the name will be easier to find.
>>>
>>> Regarding your charter proposal :
>>>
>>> --------
>>>
>>> - They form a connected network
>>>      [SLI] InterAS case must be included, but the WG can go step by ste=
p and first release intraAS, and then doing interAS (in relation with IDR ?=
?).
>>>
>>> - They can forward traffic through the shortest paths or paths other th=
an the shortest (the latter called explicitly routed paths, or explicit pat=
hs)
>>>      [SLI] There is something else between SPT and Explicit path, you c=
an define other algorithms than SPT to define a path, and it's not explicit=
 path. Moreover I come back to my comment, on do we want to limit the scope=
 to routing ? I would say no.
>>>
>>> - They share a common trust model. In this model, any router within the=
 ERD can specify an explicit path between itself and any other router in th=
e ERD. It can then send any packet that passes through it through any path =
that it has specified.
>>>      [SLI] Security considerations may have to be addressed in the
>>> charter , especially for the interAS case (trust yes, but not sure
>>> access to everything may not be good)
>>>
>>> Downstream routers within the ERD forward the packet as specified by th=
e router at the head-end of the path.
>>> [SLI] Yes, but any router in the middle may be able to change the end t=
o end explicit path.
>>>
>>>
>>>
>>> - The first goal of the STER WG is to identify use-cases for ERDs.
>>> - Having identified use-cases, the WG will identify gaps between curren=
tly available technologies and use-case requirements.
>>> - The WG will then define requirements for extensions to existing proto=
cols or new protocols that address gaps that are identified.
>>>
>>> [SLI] Agree, I would add :
>>> - defining the architecture framework
>>> - analysing the security considerisations
>>>
>>>
>>> ---------
>>>
>>>
>>> Here would be my proposal to extend yours :
>>>
>>> A <named to be defined> domain contains a set of routers with the follo=
wing characteristics:
>>>
>>> - They form a connected network
>>> - They can forward traffic through any path within the network using
>>> shortest path, non shortest path or explicit path
>>> - They may provide other types of services than forwarding and they can=
 enforce service actions in the path.
>>> - They share a common trust model. In this model, any router within the=
 domain can specify a path between itself and any other router in the domai=
n. It may then send any packet that passes through it through any path that=
 it has specified and that is conform to the security rules. Downstream rou=
ters within the ERD forward the packet as specified by the router at the he=
ad-end of the path.
>>>
>>> The <name> working group is chartered for the following ordered list of=
 work items:
>>>
>>> - The first goal of the WG is to identify use-cases.
>>> - The WG will then define the architecture framework associated with th=
e security considerations. The architecture framework and security consider=
ations must address the relations between domains (interdomain).
>>> - Having identified use-cases, architecture and security, the WG will i=
dentify gaps between currently available technologies and use-case requirem=
ents.
>>> - The WG will then define requirements for extensions to existing proto=
cols or new protocols that address gaps that are identified.
>>> - The WG will first focus on the intra-domain forwarding definition.
>>>
>>> Protocol work may be carried out in this working group or in other work=
ing groups responsible for the protocols, in coordination with this WG, and=
 in agreement with the WG chairs and responsible ADs. However, no protocol =
work will be adopted by a working group to address the ERD use-cases until =
the requirements document motivating the protocol work has been sent to the=
 IESG for publication as an RFC.
>>>
>>> -----Message d'origine-----
>>> De : [email-masked] [mailto:[email-masked]] De la
>>> part de Hannes Gredler Envoy=E9 : mardi 3 septembre 2013 18:31 =C0 : Lo=
a
>>> Andersson Cc : [email-masked] Objet : Re: [Status] Summary of STATUS
>>> BOF and the next steps
>>>
>>> good point - what about this charter proposal ?
>>>
>>> ---
>>>
>>> Stacked Tunnels for Explicit Routing (STER)
>>> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
>>>
>>> A explicit routing domain (ERD) contains a set of routers with the foll=
owing characteristics:
>>>
>>> - They form a connected network
>>> - They can forward traffic through the shortest paths or paths other
>>> than the shortest (the latter called explicitly routed paths, or
>>> explicit paths)
>>> - They share a common trust model. In this model, any router within the=
 ERD can specify an explicit path between itself and any other router in th=
e ERD. It can then send any packet that passes through it through any path =
that it has specified. Downstream routers within the ERD forward the packet=
 as specified by the router at the head-end of the path.
>>>
>>> The STER working group is chartered for the following ordered list of w=
ork items:
>>>
>>> - The first goal of the STER WG is to identify use-cases for ERDs.
>>> - Having identified use-cases, the WG will identify gaps between curren=
tly available technologies and use-case requirements.
>>> - The WG will then define requirements for extensions to existing proto=
cols or new protocols that address gaps that are identified.
>>>
>>> Protocol work may be carried out in this working group or in other work=
ing groups responsible for the protocols, in coordination with this WG, and=
 in agreement with the WG chairs and responsible ADs. However, no protocol =
work will be adopted by a working group to address the ERD use-cases until =
the requirements document motivating the protocol work has been sent to the=
 IESG for publication as an RFC.
>>>
>>> ---
>>>
>>> <flame suit on>
>>>
>>> /hannes
>>>
>>>
>>> On Sep 3, 2013, at 5:31 PM, Loa Andersson wrote:
>>>
>>>> Folks,
>>>>
>>>> Excuse me if I'm slightly out of the loop, but so far I have not seen
>>>> a charter proposal, if there is one please point me to it.
>>>>
>>>> It seems a bit odd to put the cart (what the wg should do) before the
>>>> horse (wg name). If we drill down the the charter first the wg name
>>>> might be easier to figure out.
>>>>
>>>> /Loa
>>>>
>>>> PS
>>>> OK I understand that the horse and cart analogy limps a  bit :).
>>>>
>>>>
>>>>
>>>> On 2013-09-03 17:22, AshwoodsmithPeter wrote:
>>>>> " If the WG charter is limited to source routing, how will we handle =
the "non source routing" use cases of segment routing ? In another working =
group ? So we will go back to the WG synchronization issue that has been ra=
ised for this technology ..."
>>>>>
>>>>> That's why I suggested SRV2. We are revisiting source routing with ne=
w concepts. More generic number/action behavior.
>>>>>
>>>>> Peter
>>>>>
>>>>> -----Original Message-----
>>>>> From: [email-masked] [mailto:[email-masked]] On
>>>>> Behalf Of [email-masked]
>>>>> Sent: Tuesday, September 03, 2013 10:43 AM
>>>>> To: AshwoodsmithPeter
>>>>> Cc: [email-masked]
>>>>> Subject: Re: [Status] Summary of STATUS BOF and the next steps
>>>>>
>>>>>
>>>>> There was a misunderstanding in my small comment :) so I will explain=
 more :
>>>>>
>>>>> In segment routing, you have more than basic source routing : segment=
 routing is just associate a segment number to an action and then combine s=
egment as you want, yes you can do source routing, but you also can do more=
.
>>>>>
>>>>> In the other hand, I completely agree with your statement that
>>>>> source routing is generic and dataplane agnostic, as segment routing =
is ...
>>>>> (segment routing is not a new dataplane ...)
>>>>>
>>>>> Now the definition of the WG naming must be inline with the charter
>>>>> that will be defined ... (draft today)
>>>>>
>>>>> Based on the already existing consensus (at least for MPLS dataplane)=
 brought up during Berlin STATUS BOF meeting, segment routing sounds to be =
a good target candidate.
>>>>>
>>>>> So now, do we want to do more in the WG charter than just make progre=
ssing segment routing architecture and uses cases document and ensure coord=
ination for the standardization of this technology ?
>>>>>
>>>>> Do we want to standardize other technologies in this WG ? I don't thi=
nk so, based on Stewart's conclusion email from the BOF :"A new WG focused =
solely on SR therefore needs to be create"
>>>>>
>>>>> If the WG charter is limited to source routing, how will we handle th=
e "non source routing" use cases of segment routing ? In another working gr=
oup ? So we will go back to the WG synchronization issue that has been rais=
ed for this technology ...
>>>>>
>>>>> If the WG is focused on SR, let's use a name in relation with SR.
>>>>>
>>>>> Feedback ?
>>>>>
>>>>>
>>>>> Stephane
>>>>>
>>>>>
>>>>> -----Message d'origine-----
>>>>> De : AshwoodsmithPeter [mailto:[email-masked]]
>>>>> Envoy=E9 : mardi 3 septembre 2013 15:27 =C0 : LITKOWSKI Stephane
>>>>> DTF/DERX Cc : John E Drake; Mark Townsley; Victor Kuarsingh; Roberta
>>>>> Maglione (robmgl); John G. Scudder; Adrian Farrel; Alvaro Retana
>>>>> (aretana); [email-masked]; Stewart Bryant (stbryant) Objet : Re:
>>>>> [Status] Summary of STATUS BOF and the next steps
>>>>>
>>>>> The term "source routing" has been around for a very long time and is=
 data path agnostic. Its also the term used in the literature etc so my pre=
ference is to stick with this existing well known and data path agnostic te=
rm.
>>>>>
>>>>> Peter
>>>>>
>>>>> On Sep 3, 2013, at 9:07 AM, "[email-masked]" <stephane=
[email-masked]> wrote:
>>>>>
>>>>>> Hi,
>>>>>>
>>>>>> "Source routing" is just a subcase of segment routing ... as it is f=
or IP routing ...
>>>>>>
>>>>>> Stephane
>>>>>>
>>>>>>
>>>>>> -----Message d'origine-----
>>>>>> De : [email-masked] [mailto:[email-masked]] De la
>>>>>> part de John E Drake Envoy=E9 : mardi 3 septembre 2013 15:02 =C0 : M=
ark
>>>>>> Townsley; Victor Kuarsingh Cc : Roberta Maglione (robmgl); John G.
>>>>>> Scudder; Alvaro Retana (aretana); Adrian Farrel; [email-masked];
>>>>>> Stewart Bryant (stbryant) Objet : Re: [Status] Summary of STATUS
>>>>>> BOF and the next steps
>>>>>>
>>>>>> Hi,
>>>>>>
>>>>>> What is this 'segment routing' silliness?  The correct term is 'sour=
ce routing'.
>>>>>>
>>>>>> Yours Irrespectively,
>>>>>>
>>>>>> John
>>>>>>
>>>>>>> -----Original Message-----
>>>>>>> From: [email-masked] [mailto:[email-masked]] On
>>>>>>> Behalf Of Mark Townsley
>>>>>>> Sent: Sunday, September 01, 2013 10:08 AM
>>>>>>> To: Victor Kuarsingh
>>>>>>> Cc: Roberta Maglione (robmgl); John G. Scudder; Adrian Farrel;
>>>>>>> Alvaro Retana (aretana); [email-masked]; Stewart Bryant
>>>>>>> (stbryant)
>>>>>>> Subject: Re: [Status] Summary of STATUS BOF and the next steps
>>>>>>>
>>>>>>>
>>>>>>> On Sep 1, 2013, at 5:38 PM, Victor Kuarsingh wrote:
>>>>>>>
>>>>>>>> All,
>>>>>>>>
>>>>>>>> I would also favour "Segment Routing WG" as well.
>>>>>>>>
>>>>>>>> I note this since attempting to come up with an all encompassing
>>>>>>>> acronym will be difficult and Segment Routing is generic enough
>>>>>>>> to associate to multiple functions.
>>>>>>>
>>>>>>> Then we can just use "segroute" for the short name. WGs do not
>>>>>>> have to have acronyms, but they do need to have an 8-char limited
>>>>>>> short name for the various automated tools not to break.
>>>>>>>
>>>>>>> - Mark
>>>>>>>
>>>>>>>>
>>>>>>>> Regards,
>>>>>>>>
>>>>>>>> Victor K
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> On 2013-08-31 6:51 PM, "Roberta Maglione (robmgl)"
>>>>>>>> <[email-masked]>
>>>>>>>> wrote:
>>>>>>>>
>>>>>>>>> +1 for Segment Routing WG
>>>>>>>>>
>>>>>>>>> Roberta
>>>>>>>>>
>>>>>>>>> Sent from my iPad
>>>>>>>>>
>>>>>>>>> On 2013-08-30, at 2:55 PM, "Alvaro Retana (aretana)"
>>>>>>>>> <[email-masked]>
>>>>>>>>> wrote:
>>>>>>>>>
>>>>>>>>>> Segment Routing WG
>>>>>>>>>>
>>>>>>>>>> Sent from my iPhone
>>>>>>>>>>
>>>>>>>>>> On Aug 30, 2013, at 1:39 PM, "Stewart Bryant (stbryant)"
>>>>>>>>>> <[email-masked]> wrote:
>>>>>>>>>>
>>>>>>>>>>> The second task, which hopefully should be relatively easy, is
>>>>>>>>>>> to find a better working name for the WG, since it has been
>>>>>>>>>>> put to me a number of times that STATUS is going to be
>>>>>>>>>>> confusing in text and a difficult search term.
>>>>>>>>>> _______________________________________________
>>>>>>>>>> status mailing list
>>>>>>>>>> [email-masked]
>>>>>>>>>> https://www.ietf.org/mailman/listinfo/status
>>>>>>>>> _______________________________________________
>>>>>>>>> status mailing list
>>>>>>>>> [email-masked]
>>>>>>>>> https://www.ietf.org/mailman/listinfo/status
>>>>>>>>
>>>>>>>>
>>>>>>>> _______________________________________________
>>>>>>>> status mailing list
>>>>>>>> [email-masked]
>>>>>>>> https://www.ietf.org/mailman/listinfo/status
>>>>>>>
>>>>>>> _______________________________________________
>>>>>>> status mailing list
>>>>>>> [email-masked]
>>>>>>> https://www.ietf.org/mailman/listinfo/status
>>>>>>
>>>>>>
>>>>>> _______________________________________________
>>>>>> status mailing list
>>>>>> [email-masked]
>>>>>> https://www.ietf.org/mailman/listinfo/status
>>>>>>
>>>>>> ___________________________________________________________________
>>>>>> _ __ ___________________________________________________
>>>>>>
>>>>>> Ce message et ses pieces jointes peuvent contenir des informations
>>>>>> confidentielles ou privilegiees et ne doivent donc pas etre
>>>>>> diffuses, exploites ou copies sans autorisation. Si vous avez recu
>>>>>> ce message par erreur, veuillez le signaler a l'expediteur et le det=
ruire ainsi que les pieces jointes. Les messages electroniques etant suscep=
tibles d'alteration, Orange decline toute responsabilite si ce message a et=
e altere, deforme ou falsifie. Merci.
>>>>>>
>>>>>> This message and its attachments may contain confidential or
>>>>>> privileged information that may be protected by law; they should not=
 be distributed, used or copied without authorisation.
>>>>>> If you have received this email in error, please notify the sender a=
nd delete this message and its attachments.
>>>>>> As emails may be altered, Orange is not liable for messages that hav=
e been modified, changed or falsified.
>>>>>> Thank you.
>>>>>>
>>>>>> _______________________________________________
>>>>>> status mailing list
>>>>>> [email-masked]
>>>>>> https://www.ietf.org/mailman/listinfo/status
>>>>>
>>>>> ____________________________________________________________________
>>>>> _ ____________________________________________________
>>>>>
>>>>> Ce message et ses pieces jointes peuvent contenir des informations
>>>>> confidentielles ou privilegiees et ne doivent donc pas etre
>>>>> diffuses, exploites ou copies sans autorisation. Si vous avez recu
>>>>> ce message par erreur, veuillez le signaler a l'expediteur et le detr=
uire ainsi que les pieces jointes. Les messages electroniques etant suscept=
ibles d'alteration, Orange decline toute responsabilite si ce message a ete=
 altere, deforme ou falsifie. Merci.
>>>>>
>>>>> This message and its attachments may contain confidential or
>>>>> privileged information that may be protected by law; they should not =
be distributed, used or copied without authorisation.
>>>>> If you have received this email in error, please notify the sender an=
d delete this message and its attachments.
>>>>> As emails may be altered, Orange is not liable for messages that have=
 been modified, changed or falsified.
>>>>> Thank you.
>>>>>
>>>>> _______________________________________________
>>>>> status mailing list
>>>>> [email-masked]
>>>>> https://www.ietf.org/mailman/listinfo/status
>>>>> _______________________________________________
>>>>> status mailing list
>>>>> [email-masked]
>>>>> https://www.ietf.org/mailman/listinfo/status
>>>>>
>>>>
>>>> --
>>>>
>>>>
>>>> Loa Andersson                        email: [email-masked]
>>>> Senior MPLS Expert                          [email-masked]
>>>> Huawei Technologies (consultant)     phone: +46 739 81 21 64
>>>> _______________________________________________
>>>> status mailing list
>>>> [email-masked]
>>>> https://www.ietf.org/mailman/listinfo/status
>>>>
>>>>
>>>
>>>
>>> _______________________________________________
>>> status mailing list
>>> [email-masked]
>>> https://www.ietf.org/mailman/listinfo/status
>>>
>>> ______________________________________________________________________
>>> ___________________________________________________
>>>
>>> Ce message et ses pieces jointes peuvent contenir des informations
>>> confidentielles ou privilegiees et ne doivent donc pas etre diffuses,
>>> exploites ou copies sans autorisation. Si vous avez recu ce message
>>> par erreur, veuillez le signaler a l'expediteur et le detruire ainsi qu=
e les pieces jointes. Les messages electroniques etant susceptibles d'alter=
ation, Orange decline toute responsabilite si ce message a ete altere, defo=
rme ou falsifie. Merci.
>>>
>>> This message and its attachments may contain confidential or
>>> privileged information that may be protected by law; they should not be=
 distributed, used or copied without authorisation.
>>> If you have received this email in error, please notify the sender and =
delete this message and its attachments.
>>> As emails may be altered, Orange is not liable for messages that have b=
een modified, changed or falsified.
>>> Thank you.
>>>
>>>
>>>
>>
>>
>> _______________________________________________
>> status mailing list
>> [email-masked]
>> https://www.ietf.org/mailman/listinfo/status
>>
>>
>
>
>
>

From: Hannes Gredler <[email-masked]>
Date: Mon, 9 Sep 2013 13:04:58 +0200
To: Rob Shakir <[email-masked]>
Cc: [email-masked]
Subject: Re: [Status] Summary of STATUS BOF and the next steps

hi rob,

On Sep 9, 2013, at 11:40 AM, Rob Shakir wrote:

> Hi Hannes,
>=20
> On 9 Sep 2013, at 09:23, Hannes Gredler <[email-masked]> wrote:
>=20
>> hi rob,
>>=20
>>>> <..snip..>
>>>=20
>>> rjs> It seems a little odd to me that we would identify that there =
are inter-domain issues to solve when there is no suggested use case =
that seemed to relate to this as a requirement. Any extensions of the =
technology developed within the WG to be inter-domain can be for future =
study.
>>=20
>> HG> here is an example of an inter domain use-case:
>> =
http://tools.ietf.org/html/draft-gredler-rtgwg-igp-label-advertisement-05#=
section-3.2
> rjs> Isn't this an intra-domain use case? As I read it, ASBR{1,2} =
allocate the label and advertise it within the AS1 IGP. There is no =
labelled traffic passed between AS1 and AS{3,4,5,6} as both the ASBRs =
program a pop operation. I read inter-domain as segments being used to =
influence routing within two separate autonomous systems which are not =
within the same trust domain.

HG> it is =85 now think for a moment if there would be one AS in-between
   the egress link - as per the illustration below:
   the ingress router is in AS1 and it wants to control the exit link of =
AS2-->AS3.

   AS1--AS2--AS3

>>> rjs> I do not see the need to place this restriction on the WG -- =
often we can shape and re-discuss requirements as we work through the =
details of solutions, based on the practicality of realising particular =
functions, or the complexity of supporting particular capabilities. =
Since we do not have this restriction in other WGs, I'm not clear that =
we need it defined here?
>>>=20
>>=20
>> HG> you are right that hacking protocols without use-cases and =
requirements has been
>> done in the past in other WGs, but its not a good habit. and since =
the snake-oil
>> dealers are already overselling this technology and what it can do, =
we should
>> stay very disciplined.
>=20
> rjs> I can't comment on the assertions of others, and do not wish to =
do so. In my view, there are pragmatic use cases (defined by a number of =
operators) which are gaps that we cannot meet today. Let's identify =
those, and work on those, and allow further uses of the technology going =
forward if there is a convincing case to do so.

HG> agreed.

> rjs> I don't disagree that we should stay disciplined, but I do not =
see the requirement to mandate that a document must be sent to the IESG =
to be published *before* solutions drafts are adopted. Having a =
requirement that the adopted solutions drafts should address the use =
cases within previously adopted documents puts the same focus safe-guard =
in as far as I can see.

HG> that seems reasonable to me as well - do you have a suggestion for =
the actual text ?

>>>> On Sep 4, 2013, at 10:02 AM, <[email-masked]> =
<[email-masked]> wrote:
>>>>=20
>>>>> Hannes,
>>>>>=20
>>>>> In case, we are using only directed forwarding (adjacency =
segment), could we still talk about tunneling ? (it's a very very small =
tunnel)
>>>>> Moreover talking about "stacking" is really dataplane agnostic =
(MPLS) ...
>>>>>=20
>>>>> In the proposed segment routing architectural concepts, segments =
are at the same "level" and pointer moves on the segment list, then the =
MPLS instantiation is performing this using stacking ...
>>>>>=20
>>>>> IMHO, if we use "Stacked Tunnels", we already talk about a chosen =
solution and it's closing the door to something else  ...
>>>>>=20
>>>>> Finally, about the "routing" word, routing is essentially a =
"forward" action which may limit the scope of what we can do by using a =
segment list. Actions associated with a segment could be something else =
than forwarding.
>>>>>=20
>>>>> Do we want in the charter to limit the scope to routing actions ?
>>>>>=20
>>>>> I have no solution today to propose for the naming, but I =
completely agree with Loa, to first focus on working on the charter, and =
define a clear scope of the work and then the name will be easier to =
find.
>>>>>=20
>>>>> Regarding your charter proposal :
>>>>>=20
>>>>> --------
>>>>>=20
>>>>> - They form a connected network
>>>>>   [SLI] InterAS case must be included, but the WG can go step by =
step and first release intraAS, and then doing interAS (in relation with =
IDR ??).
>>>>>=20
>>>>> - They can forward traffic through the shortest paths or paths =
other than the shortest (the latter called explicitly routed paths, or =
explicit paths)
>>>>>   [SLI] There is something else between SPT and Explicit path, you =
can define other algorithms than SPT to define a path, and it's not =
explicit path. Moreover I come back to my comment, on do we want to =
limit the scope to routing ? I would say no.
>>>>>=20
>>>>> - They share a common trust model. In this model, any router =
within the ERD can specify an explicit path between itself and any other =
router in the ERD. It can then send any packet that passes through it =
through any path that it has specified.
>>>>>   [SLI] Security considerations may have to be addressed in the =
charter , especially for the interAS case (trust yes, but not sure =
access to everything may not be good)
>>>>>=20
>>>>> Downstream routers within the ERD forward the packet as specified =
by the router at the head-end of the path.
>>>>> [SLI] Yes, but any router in the middle may be able to change the =
end to end explicit path.
>>>>>=20
>>>>>=20
>>>>>=20
>>>>> - The first goal of the STER WG is to identify use-cases for ERDs.
>>>>> - Having identified use-cases, the WG will identify gaps between =
currently available technologies and use-case requirements.
>>>>> - The WG will then define requirements for extensions to existing =
protocols or new protocols that address gaps that are identified.
>>>>>=20
>>>>> [SLI] Agree, I would add :
>>>>> - defining the architecture framework
>>>>> - analysing the security considerisations
>>>>>=20
>>>>>=20
>>>>> ---------
>>>>>=20
>>>>>=20
>>>>> Here would be my proposal to extend yours :
>>>>>=20
>>>>> A <named to be defined> domain contains a set of routers with the =
following characteristics:
>>>>>=20
>>>>> - They form a connected network
>>>>> - They can forward traffic through any path within the network =
using shortest path, non shortest path or explicit path
>>>>> - They may provide other types of services than forwarding and =
they can enforce service actions in the path.
>>>>> - They share a common trust model. In this model, any router =
within the domain can specify a path between itself and any other router =
in the domain. It may then send any packet that passes through it =
through any path that it has specified and that is conform to the =
security rules. Downstream routers within the ERD forward the packet as =
specified by the router at the head-end of the path.
>>>>>=20
>>>>> The <name> working group is chartered for the following ordered =
list of work items:
>>>>>=20
>>>>> - The first goal of the WG is to identify use-cases.
>>>>> - The WG will then define the architecture framework associated =
with the security considerations. The architecture framework and =
security considerations must address the relations between domains =
(interdomain).
>>>>> - Having identified use-cases, architecture and security, the WG =
will identify gaps between currently available technologies and use-case =
requirements.
>>>>> - The WG will then define requirements for extensions to existing =
protocols or new protocols that address gaps that are identified.
>>>>> - The WG will first focus on the intra-domain forwarding =
definition.
>>>>>=20
>>>>> Protocol work may be carried out in this working group or in other =
working groups responsible for the protocols, in coordination with this =
WG, and in agreement with the WG chairs and responsible ADs. However, no =
protocol work will be adopted by a working group to address the ERD =
use-cases until the requirements document motivating the protocol work =
has been sent to the IESG for publication as an RFC.
>>>>>=20
>>>>> -----Message d'origine-----
>>>>> De : [email-masked] [mailto:[email-masked]] De =
la part de Hannes Gredler
>>>>> Envoy=E9 : mardi 3 septembre 2013 18:31
>>>>> =C0 : Loa Andersson
>>>>> Cc : [email-masked]
>>>>> Objet : Re: [Status] Summary of STATUS BOF and the next steps
>>>>>=20
>>>>> good point - what about this charter proposal ?
>>>>>=20
>>>>> ---
>>>>>=20
>>>>> Stacked Tunnels for Explicit Routing (STER) =
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
>>>>>=20
>>>>> A explicit routing domain (ERD) contains a set of routers with the =
following characteristics:
>>>>>=20
>>>>> - They form a connected network
>>>>> - They can forward traffic through the shortest paths or paths =
other than the shortest (the latter called explicitly routed paths, or =
explicit paths)
>>>>> - They share a common trust model. In this model, any router =
within the ERD can specify an explicit path between itself and any other =
router in the ERD. It can then send any packet that passes through it =
through any path that it has specified. Downstream routers within the =
ERD forward the packet as specified by the router at the head-end of the =
path.
>>>>>=20
>>>>> The STER working group is chartered for the following ordered list =
of work items:
>>>>>=20
>>>>> - The first goal of the STER WG is to identify use-cases for ERDs.
>>>>> - Having identified use-cases, the WG will identify gaps between =
currently available technologies and use-case requirements.
>>>>> - The WG will then define requirements for extensions to existing =
protocols or new protocols that address gaps that are identified.
>>>>>=20
>>>>> Protocol work may be carried out in this working group or in other =
working groups responsible for the protocols, in coordination with this =
WG, and in agreement with the WG chairs and responsible ADs. However, no =
protocol work will be adopted by a working group to address the ERD =
use-cases until the requirements document motivating the protocol work =
has been sent to the IESG for publication as an RFC.
>>>>>=20
>>>>> ---
>>>>>=20
>>>>> <flame suit on>
>>>>>=20
>>>>> /hannes
>>>>>=20
>>>>>=20
>>>>> On Sep 3, 2013, at 5:31 PM, Loa Andersson wrote:
>>>>>=20
>>>>>> Folks,
>>>>>>=20
>>>>>> Excuse me if I'm slightly out of the loop, but so far I have not =
seen
>>>>>> a charter proposal, if there is one please point me to it.
>>>>>>=20
>>>>>> It seems a bit odd to put the cart (what the wg should do) before =
the
>>>>>> horse (wg name). If we drill down the the charter first the wg =
name
>>>>>> might be easier to figure out.
>>>>>>=20
>>>>>> /Loa
>>>>>>=20
>>>>>> PS
>>>>>> OK I understand that the horse and cart analogy limps a  bit :).
>>>>>>=20
>>>>>>=20
>>>>>>=20
>>>>>> On 2013-09-03 17:22, AshwoodsmithPeter wrote:
>>>>>>> " If the WG charter is limited to source routing, how will we =
handle the "non source routing" use cases of segment routing ? In =
another working group ? So we will go back to the WG synchronization =
issue that has been raised for this technology ..."
>>>>>>>=20
>>>>>>> That's why I suggested SRV2. We are revisiting source routing =
with new concepts. More generic number/action behavior.
>>>>>>>=20
>>>>>>> Peter
>>>>>>>=20
>>>>>>> -----Original Message-----
>>>>>>> From: [email-masked] [mailto:[email-masked]] =
On
>>>>>>> Behalf Of [email-masked]
>>>>>>> Sent: Tuesday, September 03, 2013 10:43 AM
>>>>>>> To: AshwoodsmithPeter
>>>>>>> Cc: [email-masked]
>>>>>>> Subject: Re: [Status] Summary of STATUS BOF and the next steps
>>>>>>>=20
>>>>>>>=20
>>>>>>> There was a misunderstanding in my small comment :) so I will =
explain more :
>>>>>>>=20
>>>>>>> In segment routing, you have more than basic source routing : =
segment routing is just associate a segment number to an action and then =
combine segment as you want, yes you can do source routing, but you also =
can do more.
>>>>>>>=20
>>>>>>> In the other hand, I completely agree with your statement that =
source
>>>>>>> routing is generic and dataplane agnostic, as segment routing is =
...
>>>>>>> (segment routing is not a new dataplane ...)
>>>>>>>=20
>>>>>>> Now the definition of the WG naming must be inline with the =
charter
>>>>>>> that will be defined ... (draft today)
>>>>>>>=20
>>>>>>> Based on the already existing consensus (at least for MPLS =
dataplane) brought up during Berlin STATUS BOF meeting, segment routing =
sounds to be a good target candidate.
>>>>>>>=20
>>>>>>> So now, do we want to do more in the WG charter than just make =
progressing segment routing architecture and uses cases document and =
ensure coordination for the standardization of this technology ?
>>>>>>>=20
>>>>>>> Do we want to standardize other technologies in this WG ? I =
don't think so, based on Stewart's conclusion email from the BOF :"A new =
WG focused solely on SR therefore needs to be create"
>>>>>>>=20
>>>>>>> If the WG charter is limited to source routing, how will we =
handle the "non source routing" use cases of segment routing ? In =
another working group ? So we will go back to the WG synchronization =
issue that has been raised for this technology ...
>>>>>>>=20
>>>>>>> If the WG is focused on SR, let's use a name in relation with =
SR.
>>>>>>>=20
>>>>>>> Feedback ?
>>>>>>>=20
>>>>>>>=20
>>>>>>> Stephane
>>>>>>>=20
>>>>>>>=20
>>>>>>> -----Message d'origine-----
>>>>>>> De : AshwoodsmithPeter [mailto:[email-masked]]
>>>>>>> Envoy=E9 : mardi 3 septembre 2013 15:27 =C0 : LITKOWSKI Stephane =
DTF/DERX
>>>>>>> Cc : John E Drake; Mark Townsley; Victor Kuarsingh; Roberta =
Maglione
>>>>>>> (robmgl); John G. Scudder; Adrian Farrel; Alvaro Retana =
(aretana);
>>>>>>> [email-masked]; Stewart Bryant (stbryant) Objet : Re: [Status]
>>>>>>> Summary of STATUS BOF and the next steps
>>>>>>>=20
>>>>>>> The term "source routing" has been around for a very long time =
and is data path agnostic. Its also the term used in the literature etc =
so my preference is to stick with this existing well known and data path =
agnostic term.
>>>>>>>=20
>>>>>>> Peter
>>>>>>>=20
>>>>>>> On Sep 3, 2013, at 9:07 AM, "[email-masked]" =
<[email-masked]> wrote:
>>>>>>>=20
>>>>>>>> Hi,
>>>>>>>>=20
>>>>>>>> "Source routing" is just a subcase of segment routing ... as it =
is for IP routing ...
>>>>>>>>=20
>>>>>>>> Stephane
>>>>>>>>=20
>>>>>>>>=20
>>>>>>>> -----Message d'origine-----
>>>>>>>> De : [email-masked] [mailto:[email-masked]] =
De la
>>>>>>>> part de John E Drake Envoy=E9 : mardi 3 septembre 2013 15:02 =C0 =
: Mark
>>>>>>>> Townsley; Victor Kuarsingh Cc : Roberta Maglione (robmgl); John =
G.
>>>>>>>> Scudder; Alvaro Retana (aretana); Adrian Farrel; =
[email-masked];
>>>>>>>> Stewart Bryant (stbryant) Objet : Re: [Status] Summary of =
STATUS BOF
>>>>>>>> and the next steps
>>>>>>>>=20
>>>>>>>> Hi,
>>>>>>>>=20
>>>>>>>> What is this 'segment routing' silliness?  The correct term is =
'source routing'.
>>>>>>>>=20
>>>>>>>> Yours Irrespectively,
>>>>>>>>=20
>>>>>>>> John
>>>>>>>>=20
>>>>>>>>> -----Original Message-----
>>>>>>>>> From: [email-masked] [mailto:[email-masked]] =
On
>>>>>>>>> Behalf Of Mark Townsley
>>>>>>>>> Sent: Sunday, September 01, 2013 10:08 AM
>>>>>>>>> To: Victor Kuarsingh
>>>>>>>>> Cc: Roberta Maglione (robmgl); John G. Scudder; Adrian Farrel;
>>>>>>>>> Alvaro Retana (aretana); [email-masked]; Stewart Bryant =
(stbryant)
>>>>>>>>> Subject: Re: [Status] Summary of STATUS BOF and the next steps
>>>>>>>>>=20
>>>>>>>>>=20
>>>>>>>>> On Sep 1, 2013, at 5:38 PM, Victor Kuarsingh wrote:
>>>>>>>>>=20
>>>>>>>>>> All,
>>>>>>>>>>=20
>>>>>>>>>> I would also favour "Segment Routing WG" as well.
>>>>>>>>>>=20
>>>>>>>>>> I note this since attempting to come up with an all =
encompassing
>>>>>>>>>> acronym will be difficult and Segment Routing is generic =
enough to
>>>>>>>>>> associate to multiple functions.
>>>>>>>>>=20
>>>>>>>>> Then we can just use "segroute" for the short name. WGs do not =
have
>>>>>>>>> to have acronyms, but they do need to have an 8-char limited =
short
>>>>>>>>> name for the various automated tools not to break.
>>>>>>>>>=20
>>>>>>>>> - Mark
>>>>>>>>>=20
>>>>>>>>>>=20
>>>>>>>>>> Regards,
>>>>>>>>>>=20
>>>>>>>>>> Victor K
>>>>>>>>>>=20
>>>>>>>>>>=20
>>>>>>>>>>=20
>>>>>>>>>> On 2013-08-31 6:51 PM, "Roberta Maglione (robmgl)"
>>>>>>>>>> <[email-masked]>
>>>>>>>>>> wrote:
>>>>>>>>>>=20
>>>>>>>>>>> +1 for Segment Routing WG
>>>>>>>>>>>=20
>>>>>>>>>>> Roberta
>>>>>>>>>>>=20
>>>>>>>>>>> Sent from my iPad
>>>>>>>>>>>=20
>>>>>>>>>>> On 2013-08-30, at 2:55 PM, "Alvaro Retana (aretana)"
>>>>>>>>>>> <[email-masked]>
>>>>>>>>>>> wrote:
>>>>>>>>>>>=20
>>>>>>>>>>>> Segment Routing WG
>>>>>>>>>>>>=20
>>>>>>>>>>>> Sent from my iPhone
>>>>>>>>>>>>=20
>>>>>>>>>>>> On Aug 30, 2013, at 1:39 PM, "Stewart Bryant (stbryant)"
>>>>>>>>>>>> <[email-masked]> wrote:
>>>>>>>>>>>>=20
>>>>>>>>>>>>> The second task, which hopefully should be relatively =
easy, is
>>>>>>>>>>>>> to find a better working name for the WG, since it has =
been put
>>>>>>>>>>>>> to me a number of times that STATUS is going to be =
confusing in
>>>>>>>>>>>>> text and a difficult search term.
>>>>>>>>>>>> _______________________________________________
>>>>>>>>>>>> status mailing list
>>>>>>>>>>>> [email-masked]
>>>>>>>>>>>> https://www.ietf.org/mailman/listinfo/status
>>>>>>>>>>> _______________________________________________
>>>>>>>>>>> status mailing list
>>>>>>>>>>> [email-masked]
>>>>>>>>>>> https://www.ietf.org/mailman/listinfo/status
>>>>>>>>>>=20
>>>>>>>>>>=20
>>>>>>>>>> _______________________________________________
>>>>>>>>>> status mailing list
>>>>>>>>>> [email-masked]
>>>>>>>>>> https://www.ietf.org/mailman/listinfo/status
>>>>>>>>>=20
>>>>>>>>> _______________________________________________
>>>>>>>>> status mailing list
>>>>>>>>> [email-masked]
>>>>>>>>> https://www.ietf.org/mailman/listinfo/status
>>>>>>>>=20
>>>>>>>>=20
>>>>>>>> _______________________________________________
>>>>>>>> status mailing list
>>>>>>>> [email-masked]
>>>>>>>> https://www.ietf.org/mailman/listinfo/status
>>>>>>>>=20
>>>>>>>> =
____________________________________________________________________
>>>>>>>> __ ___________________________________________________
>>>>>>>>=20
>>>>>>>> Ce message et ses pieces jointes peuvent contenir des =
informations
>>>>>>>> confidentielles ou privilegiees et ne doivent donc pas etre
>>>>>>>> diffuses, exploites ou copies sans autorisation. Si vous avez =
recu
>>>>>>>> ce message par erreur, veuillez le signaler a l'expediteur et =
le detruire ainsi que les pieces jointes. Les messages electroniques =
etant susceptibles d'alteration, Orange decline toute responsabilite si =
ce message a ete altere, deforme ou falsifie. Merci.
>>>>>>>>=20
>>>>>>>> This message and its attachments may contain confidential or
>>>>>>>> privileged information that may be protected by law; they =
should not be distributed, used or copied without authorisation.
>>>>>>>> If you have received this email in error, please notify the =
sender and delete this message and its attachments.
>>>>>>>> As emails may be altered, Orange is not liable for messages =
that have been modified, changed or falsified.
>>>>>>>> Thank you.
>>>>>>>>=20
>>>>>>>> _______________________________________________
>>>>>>>> status mailing list
>>>>>>>> [email-masked]
>>>>>>>> https://www.ietf.org/mailman/listinfo/status
>>>>>>>=20
>>>>>>> =
_____________________________________________________________________
>>>>>>> ____________________________________________________
>>>>>>>=20
>>>>>>> Ce message et ses pieces jointes peuvent contenir des =
informations
>>>>>>> confidentielles ou privilegiees et ne doivent donc pas etre =
diffuses,
>>>>>>> exploites ou copies sans autorisation. Si vous avez recu ce =
message
>>>>>>> par erreur, veuillez le signaler a l'expediteur et le detruire =
ainsi que les pieces jointes. Les messages electroniques etant =
susceptibles d'alteration, Orange decline toute responsabilite si ce =
message a ete altere, deforme ou falsifie. Merci.
>>>>>>>=20
>>>>>>> This message and its attachments may contain confidential or
>>>>>>> privileged information that may be protected by law; they should =
not be distributed, used or copied without authorisation.
>>>>>>> If you have received this email in error, please notify the =
sender and delete this message and its attachments.
>>>>>>> As emails may be altered, Orange is not liable for messages that =
have been modified, changed or falsified.
>>>>>>> Thank you.
>>>>>>>=20
>>>>>>> _______________________________________________
>>>>>>> status mailing list
>>>>>>> [email-masked]
>>>>>>> https://www.ietf.org/mailman/listinfo/status
>>>>>>> _______________________________________________
>>>>>>> status mailing list
>>>>>>> [email-masked]
>>>>>>> https://www.ietf.org/mailman/listinfo/status
>>>>>>>=20
>>>>>>=20
>>>>>> --
>>>>>>=20
>>>>>>=20
>>>>>> Loa Andersson                        email: [email-masked]
>>>>>> Senior MPLS Expert                          [email-masked]
>>>>>> Huawei Technologies (consultant)     phone: +46 739 81 21 64
>>>>>> _______________________________________________
>>>>>> status mailing list
>>>>>> [email-masked]
>>>>>> https://www.ietf.org/mailman/listinfo/status
>>>>>>=20
>>>>>>=20
>>>>>=20
>>>>>=20
>>>>> _______________________________________________
>>>>> status mailing list
>>>>> [email-masked]
>>>>> https://www.ietf.org/mailman/listinfo/status
>>>>>=20
>>>>> =
__________________________________________________________________________=
_______________________________________________
>>>>>=20
>>>>> Ce message et ses pieces jointes peuvent contenir des informations =
confidentielles ou privilegiees et ne doivent donc
>>>>> pas etre diffuses, exploites ou copies sans autorisation. Si vous =
avez recu ce message par erreur, veuillez le signaler
>>>>> a l'expediteur et le detruire ainsi que les pieces jointes. Les =
messages electroniques etant susceptibles d'alteration,
>>>>> Orange decline toute responsabilite si ce message a ete altere, =
deforme ou falsifie. Merci.
>>>>>=20
>>>>> This message and its attachments may contain confidential or =
privileged information that may be protected by law;
>>>>> they should not be distributed, used or copied without =
authorisation.
>>>>> If you have received this email in error, please notify the sender =
and delete this message and its attachments.
>>>>> As emails may be altered, Orange is not liable for messages that =
have been modified, changed or falsified.
>>>>> Thank you.
>>>>>=20
>>>>>=20
>>>>>=20
>>>>=20
>>>>=20
>>>> _______________________________________________
>>>> status mailing list
>>>> [email-masked]
>>>> https://www.ietf.org/mailman/listinfo/status
>>>=20
>>>=20
>>>=20
>>=20
>>=20
>> _______________________________________________
>> status mailing list
>> [email-masked]
>> https://www.ietf.org/mailman/listinfo/status
>=20
> _______________________________________________
> status mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/status
>=20
>=20

Sender: [email-masked]
Date: Mon, 9 Sep 2013 13:03:55 +0200
From: Robert Raszuk <[email-masked]>
To: Hannes Gredler <[email-masked]>
Cc: [email-masked], "[email-masked]" <[email-masked]>
Subject: Re: [Status] Summary of STATUS BOF and the next steps

> i haven't yet identified the code to be deleted, if SR is going to be a success ;-)

How about LDP as starter ?

Which of the below are solved by LDP ? Which LDP functionality will
not be covered by SR ?

>>  1. LSP bandwidth reservation
>>  2. LSP preemption
>>  3. p2mp path construction

Note that those are all done today in the control plane. Therefor it
seems pretty trivial to accomplish all of those with SR using number
of PCE or PCE like controllers rather then use RSVP-TE for explicit
path signalling.

>>  5. FRR node-protection

As you know computing LFA sort of addresses this topic pretty well.
Moreover SR may complete topologies where today LFA may not be
possible in 100% of coverage.

>> a couple of interesting problems, but does this single capability
>> make it a panacea for networking ?

Some folks think that MPLS is a panacea for networking .. SR with IP
encap can prove it is not ;) That's the beauty of it.

> apart from that i simply fail to see the need for developing redundant
> technology within IETF.

Why not since the redundant technology has much better scaling and
operational properties. It simplifies control plane and that alone
should be sufficient reason.

Cheers,
R.

From: Hannes Gredler <[email-masked]>
Date: Mon, 9 Sep 2013 12:49:00 +0200
To: <[email-masked]>
Cc: [email-masked]
Subject: Re: [Status] Summary of STATUS BOF and the next steps

ruediger,

On Sep 9, 2013, at 11:26 AM, <[email-masked]> wrote:
> sorry, but why should the ISPs interested in standardising SR worry =
about issues ocurring for ISPs who are not interested in migrating to =
SR? I don't think, SR should look for replacements, SR should work on =
simplifications. That's what the charter should express. I'm not =
interested in working within a "LDP and RSVP-TE replacement WG". Sorry =
if my first mail was overstated to that regard ("...get rid of").

if its not 'obsoleting' something, then it is by definition an =
'extension' of something.
in other words the complexity of the 'something' will be going up and =
never down.
i haven't yet identified the code to be deleted, if SR is going to be a =
success ;-)

> DT so far does not utilise RSVP TE in parts of the backbone, but is =
interested in SR based features offering similar routing properties. =
Bandwidth reservation and preemption are completely irrelevant to me.

that is fine and yet for the industry as a whole doing distributed
bandwidth reservation *is* a relevant functionality.

> If there are issues, we will (dis)cover them while we work on the =
technology. But discovering issues and analysing them shouldn't be core =
part of a charter - the features to be developed should be.

i'd rather do the analysis and planning exercise
before commencing work.

> [ =85 ]

/hannes

> -----Original Message-----
> From: Hannes Gredler [mailto:[email-masked]]
> Sent: Monday, September 09, 2013 10:57 AM
> To: Geib, R=FCdiger
> Cc: [email-masked]
> Subject: Re: [Status] Summary of STATUS BOF and the next steps
>=20
> ruediger,
>=20
> On Sep 9, 2013, at 9:08 AM, <[email-masked]> wrote:
>> I'm worried about the proposal below, which seem to miss the most =
important points of SR (I call it that):
>>=20
>> - SR allows to reduce complexity by getting rid of RSVP TE and LDP.
>   ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
>=20
> that seem to be a gross misunderstanding on your side;
>=20
> 'reducing complexity' means *obsoleting* technology A with technology =
B.
>=20
> the issue is that introduction of SR does *neither* obsolete LDP *nor* =
RSVP,
> simply because SR is not a 100% replacement of LDP and RSVP =
functionalities.
>=20
> SR lacks functionality in areas of:
>=20
>  1. LSP bandwidth reservation
>  2. LSP preemption
>  3. p2mp path construction
>  4. PW signaling
>  5. FRR node-protection
>=20
> adding the IGP as a label distribution protocol to the stack of =
protocols
> allows the network to do tunnel discovery and with that capability we =
can arguably fix
> a couple of interesting problems, but does this single capability
> make it a panacea for networking ?
>=20
>> - I don't fully understand why the SR work must address inter domain =
relations, if
>> it is supposed to be primarily chartered with intra domain control =
plane issues.
>> - My take is, that intra-domain MPLS forwarding will remain as is =
initially with SR.
>=20
> there are SPs which operate multi-AS domains and the implications
> to connect those ASes using label-stacking technology should be worked =
on.
>=20
>> - Your last bullet point means todays MPLS is out of scope, as no =
forwarding
>> definitions need to be changed?
>=20
> not sure if we can get away with zero changes - issues that we need to =
talk about are:
>=20
> 1. MPLS source labels
> 2. Entropy label implications of label stacking
> 3. Hardware capabilites (Maxpushlabels) and management
>=20
>> - We agreed not work on protocols within the SR WG. Why has that been =
changed?
>=20
> there might be a a need to work on protocols which do not fit into =
existing WGs.
>=20
> HTH,
>=20
> /hannes
>=20
>> ---------------
>>=20
>> The <Name-TBD> working group is chartered for the following ordered =
list of work items:
>>=20
>> - The first goal of the WG is to identify use-cases.
>> - The WG will then define the architecture framework associated with
>> the security considerations. The architecture framework and security
>> considerations must address the relations between domains =
(interdomain).
>> - Having identified use-cases, architecture and security, the WG will
>> identify gaps between currently available technologies and use-case
>> requirements.
>> - The WG will then define requirements for extensions to existing
>> protocols or new protocols that address gaps that are identified.
>> - The WG will first focus on the intra-domain forwarding definition.
>>=20
>> Protocol work may be carried out in this working group or in other =
working groups responsible for the protocols, in coordination with this =
WG, and in agreement with the WG chairs and responsible ADs.
>> However, no protocol work will be adopted by a working group to =
address the identified use-cases until the requirements document =
motivating the protocol work has been sent to the IESG for publication =
as an RFC.
>>=20
>> ---
>>=20
>> /hannes
>>=20
>> On Sep 4, 2013, at 10:02 AM, <[email-masked]> =
<[email-masked]> wrote:
>>=20
>>> Hannes,
>>>=20
>>> In case, we are using only directed forwarding (adjacency segment),
>>> could we still talk about tunneling ? (it's a very very small =
tunnel) Moreover talking about "stacking" is really dataplane agnostic =
(MPLS) ...
>>>=20
>>> In the proposed segment routing architectural concepts, segments are =
at the same "level" and pointer moves on the segment list, then the MPLS =
instantiation is performing this using stacking ...
>>>=20
>>> IMHO, if we use "Stacked Tunnels", we already talk about a chosen =
solution and it's closing the door to something else  ...
>>>=20
>>> Finally, about the "routing" word, routing is essentially a =
"forward" action which may limit the scope of what we can do by using a =
segment list. Actions associated with a segment could be something else =
than forwarding.
>>>=20
>>> Do we want in the charter to limit the scope to routing actions ?
>>>=20
>>> I have no solution today to propose for the naming, but I completely =
agree with Loa, to first focus on working on the charter, and define a =
clear scope of the work and then the name will be easier to find.
>>>=20
>>> Regarding your charter proposal :
>>>=20
>>> --------
>>>=20
>>> - They form a connected network
>>>      [SLI] InterAS case must be included, but the WG can go step by =
step and first release intraAS, and then doing interAS (in relation with =
IDR ??).
>>>=20
>>> - They can forward traffic through the shortest paths or paths other =
than the shortest (the latter called explicitly routed paths, or =
explicit paths)
>>>      [SLI] There is something else between SPT and Explicit path, =
you can define other algorithms than SPT to define a path, and it's not =
explicit path. Moreover I come back to my comment, on do we want to =
limit the scope to routing ? I would say no.
>>>=20
>>> - They share a common trust model. In this model, any router within =
the ERD can specify an explicit path between itself and any other router =
in the ERD. It can then send any packet that passes through it through =
any path that it has specified.
>>>      [SLI] Security considerations may have to be addressed in the
>>> charter , especially for the interAS case (trust yes, but not sure
>>> access to everything may not be good)
>>>=20
>>> Downstream routers within the ERD forward the packet as specified by =
the router at the head-end of the path.
>>> [SLI] Yes, but any router in the middle may be able to change the =
end to end explicit path.
>>>=20
>>>=20
>>>=20
>>> - The first goal of the STER WG is to identify use-cases for ERDs.
>>> - Having identified use-cases, the WG will identify gaps between =
currently available technologies and use-case requirements.
>>> - The WG will then define requirements for extensions to existing =
protocols or new protocols that address gaps that are identified.
>>>=20
>>> [SLI] Agree, I would add :
>>> - defining the architecture framework
>>> - analysing the security considerisations
>>>=20
>>>=20
>>> ---------
>>>=20
>>>=20
>>> Here would be my proposal to extend yours :
>>>=20
>>> A <named to be defined> domain contains a set of routers with the =
following characteristics:
>>>=20
>>> - They form a connected network
>>> - They can forward traffic through any path within the network using
>>> shortest path, non shortest path or explicit path
>>> - They may provide other types of services than forwarding and they =
can enforce service actions in the path.
>>> - They share a common trust model. In this model, any router within =
the domain can specify a path between itself and any other router in the =
domain. It may then send any packet that passes through it through any =
path that it has specified and that is conform to the security rules. =
Downstream routers within the ERD forward the packet as specified by the =
router at the head-end of the path.
>>>=20
>>> The <name> working group is chartered for the following ordered list =
of work items:
>>>=20
>>> - The first goal of the WG is to identify use-cases.
>>> - The WG will then define the architecture framework associated with =
the security considerations. The architecture framework and security =
considerations must address the relations between domains (interdomain).
>>> - Having identified use-cases, architecture and security, the WG =
will identify gaps between currently available technologies and use-case =
requirements.
>>> - The WG will then define requirements for extensions to existing =
protocols or new protocols that address gaps that are identified.
>>> - The WG will first focus on the intra-domain forwarding definition.
>>>=20
>>> Protocol work may be carried out in this working group or in other =
working groups responsible for the protocols, in coordination with this =
WG, and in agreement with the WG chairs and responsible ADs. However, no =
protocol work will be adopted by a working group to address the ERD =
use-cases until the requirements document motivating the protocol work =
has been sent to the IESG for publication as an RFC.
>>>=20
>>> -----Message d'origine-----
>>> De : [email-masked] [mailto:[email-masked]] De la
>>> part de Hannes Gredler Envoy=E9 : mardi 3 septembre 2013 18:31 =C0 : =
Loa
>>> Andersson Cc : [email-masked] Objet : Re: [Status] Summary of =
STATUS
>>> BOF and the next steps
>>>=20
>>> good point - what about this charter proposal ?
>>>=20
>>> ---
>>>=20
>>> Stacked Tunnels for Explicit Routing (STER)
>>> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
>>>=20
>>> A explicit routing domain (ERD) contains a set of routers with the =
following characteristics:
>>>=20
>>> - They form a connected network
>>> - They can forward traffic through the shortest paths or paths other
>>> than the shortest (the latter called explicitly routed paths, or
>>> explicit paths)
>>> - They share a common trust model. In this model, any router within =
the ERD can specify an explicit path between itself and any other router =
in the ERD. It can then send any packet that passes through it through =
any path that it has specified. Downstream routers within the ERD =
forward the packet as specified by the router at the head-end of the =
path.
>>>=20
>>> The STER working group is chartered for the following ordered list =
of work items:
>>>=20
>>> - The first goal of the STER WG is to identify use-cases for ERDs.
>>> - Having identified use-cases, the WG will identify gaps between =
currently available technologies and use-case requirements.
>>> - The WG will then define requirements for extensions to existing =
protocols or new protocols that address gaps that are identified.
>>>=20
>>> Protocol work may be carried out in this working group or in other =
working groups responsible for the protocols, in coordination with this =
WG, and in agreement with the WG chairs and responsible ADs. However, no =
protocol work will be adopted by a working group to address the ERD =
use-cases until the requirements document motivating the protocol work =
has been sent to the IESG for publication as an RFC.
>>>=20
>>> ---
>>>=20
>>> <flame suit on>
>>>=20
>>> /hannes
>>>=20
>>>=20
>>> On Sep 3, 2013, at 5:31 PM, Loa Andersson wrote:
>>>=20
>>>> Folks,
>>>>=20
>>>> Excuse me if I'm slightly out of the loop, but so far I have not =
seen
>>>> a charter proposal, if there is one please point me to it.
>>>>=20
>>>> It seems a bit odd to put the cart (what the wg should do) before =
the
>>>> horse (wg name). If we drill down the the charter first the wg name
>>>> might be easier to figure out.
>>>>=20
>>>> /Loa
>>>>=20
>>>> PS
>>>> OK I understand that the horse and cart analogy limps a  bit :).
>>>>=20
>>>>=20
>>>>=20
>>>> On 2013-09-03 17:22, AshwoodsmithPeter wrote:
>>>>> " If the WG charter is limited to source routing, how will we =
handle the "non source routing" use cases of segment routing ? In =
another working group ? So we will go back to the WG synchronization =
issue that has been raised for this technology ..."
>>>>>=20
>>>>> That's why I suggested SRV2. We are revisiting source routing with =
new concepts. More generic number/action behavior.
>>>>>=20
>>>>> Peter
>>>>>=20
>>>>> -----Original Message-----
>>>>> From: [email-masked] [mailto:[email-masked]] On
>>>>> Behalf Of [email-masked]
>>>>> Sent: Tuesday, September 03, 2013 10:43 AM
>>>>> To: AshwoodsmithPeter
>>>>> Cc: [email-masked]
>>>>> Subject: Re: [Status] Summary of STATUS BOF and the next steps
>>>>>=20
>>>>>=20
>>>>> There was a misunderstanding in my small comment :) so I will =
explain more :
>>>>>=20
>>>>> In segment routing, you have more than basic source routing : =
segment routing is just associate a segment number to an action and then =
combine segment as you want, yes you can do source routing, but you also =
can do more.
>>>>>=20
>>>>> In the other hand, I completely agree with your statement that
>>>>> source routing is generic and dataplane agnostic, as segment =
routing is ...
>>>>> (segment routing is not a new dataplane ...)
>>>>>=20
>>>>> Now the definition of the WG naming must be inline with the =
charter
>>>>> that will be defined ... (draft today)
>>>>>=20
>>>>> Based on the already existing consensus (at least for MPLS =
dataplane) brought up during Berlin STATUS BOF meeting, segment routing =
sounds to be a good target candidate.
>>>>>=20
>>>>> So now, do we want to do more in the WG charter than just make =
progressing segment routing architecture and uses cases document and =
ensure coordination for the standardization of this technology ?
>>>>>=20
>>>>> Do we want to standardize other technologies in this WG ? I don't =
think so, based on Stewart's conclusion email from the BOF :"A new WG =
focused solely on SR therefore needs to be create"
>>>>>=20
>>>>> If the WG charter is limited to source routing, how will we handle =
the "non source routing" use cases of segment routing ? In another =
working group ? So we will go back to the WG synchronization issue that =
has been raised for this technology ...
>>>>>=20
>>>>> If the WG is focused on SR, let's use a name in relation with SR.
>>>>>=20
>>>>> Feedback ?
>>>>>=20
>>>>>=20
>>>>> Stephane
>>>>>=20
>>>>>=20
>>>>> -----Message d'origine-----
>>>>> De : AshwoodsmithPeter [mailto:[email-masked]]
>>>>> Envoy=E9 : mardi 3 septembre 2013 15:27 =C0 : LITKOWSKI Stephane
>>>>> DTF/DERX Cc : John E Drake; Mark Townsley; Victor Kuarsingh; =
Roberta
>>>>> Maglione (robmgl); John G. Scudder; Adrian Farrel; Alvaro Retana
>>>>> (aretana); [email-masked]; Stewart Bryant (stbryant) Objet : Re:
>>>>> [Status] Summary of STATUS BOF and the next steps
>>>>>=20
>>>>> The term "source routing" has been around for a very long time and =
is data path agnostic. Its also the term used in the literature etc so =
my preference is to stick with this existing well known and data path =
agnostic term.
>>>>>=20
>>>>> Peter
>>>>>=20
>>>>> On Sep 3, 2013, at 9:07 AM, "[email-masked]" =
<[email-masked]> wrote:
>>>>>=20
>>>>>> Hi,
>>>>>>=20
>>>>>> "Source routing" is just a subcase of segment routing ... as it =
is for IP routing ...
>>>>>>=20
>>>>>> Stephane
>>>>>>=20
>>>>>>=20
>>>>>> -----Message d'origine-----
>>>>>> De : [email-masked] [mailto:[email-masked]] De =
la
>>>>>> part de John E Drake Envoy=E9 : mardi 3 septembre 2013 15:02 =C0 =
: Mark
>>>>>> Townsley; Victor Kuarsingh Cc : Roberta Maglione (robmgl); John =
G.
>>>>>> Scudder; Alvaro Retana (aretana); Adrian Farrel; [email-masked];
>>>>>> Stewart Bryant (stbryant) Objet : Re: [Status] Summary of STATUS
>>>>>> BOF and the next steps
>>>>>>=20
>>>>>> Hi,
>>>>>>=20
>>>>>> What is this 'segment routing' silliness?  The correct term is =
'source routing'.
>>>>>>=20
>>>>>> Yours Irrespectively,
>>>>>>=20
>>>>>> John
>>>>>>=20
>>>>>>> -----Original Message-----
>>>>>>> From: [email-masked] [mailto:[email-masked]] =
On
>>>>>>> Behalf Of Mark Townsley
>>>>>>> Sent: Sunday, September 01, 2013 10:08 AM
>>>>>>> To: Victor Kuarsingh
>>>>>>> Cc: Roberta Maglione (robmgl); John G. Scudder; Adrian Farrel;
>>>>>>> Alvaro Retana (aretana); [email-masked]; Stewart Bryant
>>>>>>> (stbryant)
>>>>>>> Subject: Re: [Status] Summary of STATUS BOF and the next steps
>>>>>>>=20
>>>>>>>=20
>>>>>>> On Sep 1, 2013, at 5:38 PM, Victor Kuarsingh wrote:
>>>>>>>=20
>>>>>>>> All,
>>>>>>>>=20
>>>>>>>> I would also favour "Segment Routing WG" as well.
>>>>>>>>=20
>>>>>>>> I note this since attempting to come up with an all =
encompassing
>>>>>>>> acronym will be difficult and Segment Routing is generic enough
>>>>>>>> to associate to multiple functions.
>>>>>>>=20
>>>>>>> Then we can just use "segroute" for the short name. WGs do not
>>>>>>> have to have acronyms, but they do need to have an 8-char =
limited
>>>>>>> short name for the various automated tools not to break.
>>>>>>>=20
>>>>>>> - Mark
>>>>>>>=20
>>>>>>>>=20
>>>>>>>> Regards,
>>>>>>>>=20
>>>>>>>> Victor K
>>>>>>>>=20
>>>>>>>>=20
>>>>>>>>=20
>>>>>>>> On 2013-08-31 6:51 PM, "Roberta Maglione (robmgl)"
>>>>>>>> <[email-masked]>
>>>>>>>> wrote:
>>>>>>>>=20
>>>>>>>>> +1 for Segment Routing WG
>>>>>>>>>=20
>>>>>>>>> Roberta
>>>>>>>>>=20
>>>>>>>>> Sent from my iPad
>>>>>>>>>=20
>>>>>>>>> On 2013-08-30, at 2:55 PM, "Alvaro Retana (aretana)"
>>>>>>>>> <[email-masked]>
>>>>>>>>> wrote:
>>>>>>>>>=20
>>>>>>>>>> Segment Routing WG
>>>>>>>>>>=20
>>>>>>>>>> Sent from my iPhone
>>>>>>>>>>=20
>>>>>>>>>> On Aug 30, 2013, at 1:39 PM, "Stewart Bryant (stbryant)"
>>>>>>>>>> <[email-masked]> wrote:
>>>>>>>>>>=20
>>>>>>>>>>> The second task, which hopefully should be relatively easy, =
is
>>>>>>>>>>> to find a better working name for the WG, since it has been
>>>>>>>>>>> put to me a number of times that STATUS is going to be
>>>>>>>>>>> confusing in text and a difficult search term.
>>>>>>>>>> _______________________________________________
>>>>>>>>>> status mailing list
>>>>>>>>>> [email-masked]
>>>>>>>>>> https://www.ietf.org/mailman/listinfo/status
>>>>>>>>> _______________________________________________
>>>>>>>>> status mailing list
>>>>>>>>> [email-masked]
>>>>>>>>> https://www.ietf.org/mailman/listinfo/status
>>>>>>>>=20
>>>>>>>>=20
>>>>>>>> _______________________________________________
>>>>>>>> status mailing list
>>>>>>>> [email-masked]
>>>>>>>> https://www.ietf.org/mailman/listinfo/status
>>>>>>>=20
>>>>>>> _______________________________________________
>>>>>>> status mailing list
>>>>>>> [email-masked]
>>>>>>> https://www.ietf.org/mailman/listinfo/status
>>>>>>=20
>>>>>>=20
>>>>>> _______________________________________________
>>>>>> status mailing list
>>>>>> [email-masked]
>>>>>> https://www.ietf.org/mailman/listinfo/status
>>>>>>=20
>>>>>> =
___________________________________________________________________
>>>>>> _ __ ___________________________________________________
>>>>>>=20
>>>>>> Ce message et ses pieces jointes peuvent contenir des =
informations
>>>>>> confidentielles ou privilegiees et ne doivent donc pas etre
>>>>>> diffuses, exploites ou copies sans autorisation. Si vous avez =
recu
>>>>>> ce message par erreur, veuillez le signaler a l'expediteur et le =
detruire ainsi que les pieces jointes. Les messages electroniques etant =
susceptibles d'alteration, Orange decline toute responsabilite si ce =
message a ete altere, deforme ou falsifie. Merci.
>>>>>>=20
>>>>>> This message and its attachments may contain confidential or
>>>>>> privileged information that may be protected by law; they should =
not be distributed, used or copied without authorisation.
>>>>>> If you have received this email in error, please notify the =
sender and delete this message and its attachments.
>>>>>> As emails may be altered, Orange is not liable for messages that =
have been modified, changed or falsified.
>>>>>> Thank you.
>>>>>>=20
>>>>>> _______________________________________________
>>>>>> status mailing list
>>>>>> [email-masked]
>>>>>> https://www.ietf.org/mailman/listinfo/status
>>>>>=20
>>>>> =
____________________________________________________________________
>>>>> _ ____________________________________________________
>>>>>=20
>>>>> Ce message et ses pieces jointes peuvent contenir des informations
>>>>> confidentielles ou privilegiees et ne doivent donc pas etre
>>>>> diffuses, exploites ou copies sans autorisation. Si vous avez recu
>>>>> ce message par erreur, veuillez le signaler a l'expediteur et le =
detruire ainsi que les pieces jointes. Les messages electroniques etant =
susceptibles d'alteration, Orange decline toute responsabilite si ce =
message a ete altere, deforme ou falsifie. Merci.
>>>>>=20
>>>>> This message and its attachments may contain confidential or
>>>>> privileged information that may be protected by law; they should =
not be distributed, used or copied without authorisation.
>>>>> If you have received this email in error, please notify the sender =
and delete this message and its attachments.
>>>>> As emails may be altered, Orange is not liable for messages that =
have been modified, changed or falsified.
>>>>> Thank you.
>>>>>=20
>>>>> _______________________________________________
>>>>> status mailing list
>>>>> [email-masked]
>>>>> https://www.ietf.org/mailman/listinfo/status
>>>>> _______________________________________________
>>>>> status mailing list
>>>>> [email-masked]
>>>>> https://www.ietf.org/mailman/listinfo/status
>>>>>=20
>>>>=20
>>>> --
>>>>=20
>>>>=20
>>>> Loa Andersson                        email: [email-masked]
>>>> Senior MPLS Expert                          [email-masked]
>>>> Huawei Technologies (consultant)     phone: +46 739 81 21 64
>>>> _______________________________________________
>>>> status mailing list
>>>> [email-masked]
>>>> https://www.ietf.org/mailman/listinfo/status
>>>>=20
>>>>=20
>>>=20
>>>=20
>>> _______________________________________________
>>> status mailing list
>>> [email-masked]
>>> https://www.ietf.org/mailman/listinfo/status
>>>=20
>>> =
______________________________________________________________________
>>> ___________________________________________________
>>>=20
>>> Ce message et ses pieces jointes peuvent contenir des informations
>>> confidentielles ou privilegiees et ne doivent donc pas etre =
diffuses,
>>> exploites ou copies sans autorisation. Si vous avez recu ce message
>>> par erreur, veuillez le signaler a l'expediteur et le detruire ainsi =
que les pieces jointes. Les messages electroniques etant susceptibles =
d'alteration, Orange decline toute responsabilite si ce message a ete =
altere, deforme ou falsifie. Merci.
>>>=20
>>> This message and its attachments may contain confidential or
>>> privileged information that may be protected by law; they should not =
be distributed, used or copied without authorisation.
>>> If you have received this email in error, please notify the sender =
and delete this message and its attachments.
>>> As emails may be altered, Orange is not liable for messages that =
have been modified, changed or falsified.
>>> Thank you.
>>>=20
>>>=20
>>>=20
>>=20
>>=20
>> _______________________________________________
>> status mailing list
>> [email-masked]
>> https://www.ietf.org/mailman/listinfo/status
>>=20
>>=20
>=20
>=20
>=20
>=20

From: Hannes Gredler <[email-masked]>
Date: Mon, 9 Sep 2013 12:06:08 +0200
To: Robert Raszuk <[email-masked]>
Cc: [email-masked]
Subject: Re: [Status] Summary of STATUS BOF and the next steps

robert,

i am glad that you haven't discovered the hidden anagrams in the=20
proposed draft agenda, yet - it would have revealed a larger conspiracy
and their satanic plan for removing free speech and freedom on the =
internet.

apart from that i simply fail to see the need for developing redundant
technology within IETF.

/hannes

On Sep 6, 2013, at 6:52 PM, Robert Raszuk wrote:
>=20
>> - Having identified use-cases, architecture and security, the WG will
>>  identify gaps between currently available technologies and use-case
>> requirements.
>>=20
>> - The WG will then define requirements for extensions to existing
>>  protocols or new protocols that address gaps that are identified.
>=20
>=20
> So this effectively says that if there is a way in today's protocols
> to accomplish use-cases - no matter how operationally and deployment
> difficult this turns out to be in practice - there would be no gaps -
> hence no hope for the operators to see any new protocol extensions"
> work to proceed.
>=20
> I find those two sentences quoted above not acceptable.
>=20
> Of course let's also observe that there is going to be clearly
> difficulty - which we have already seen at the "BOF" - to evaluate
> proposed use-cases and consider them as valid or not valid. Who will
> be the judge and the jury - chairs ? ADs ? IESG ? Rough consensus ?
[ =85 ]=

From: Rob Shakir <[email-masked]>
Date: Mon, 9 Sep 2013 09:40:33 +0000
To: Hannes Gredler <[email-masked]>
Cc: [email-masked], "[email-masked]" <[email-masked]>
Subject: Re: [Status] Summary of STATUS BOF and the next steps

Hi Hannes,

On 9 Sep 2013, at 09:23, Hannes Gredler <[email-masked]> wrote:

> hi rob,
>=20
>>> <..snip..>
>>=20
>> rjs> It seems a little odd to me that we would identify that there =
are inter-domain issues to solve when there is no suggested use case =
that seemed to relate to this as a requirement. Any extensions of the =
technology developed within the WG to be inter-domain can be for future =
study.
>=20
> HG> here is an example of an inter domain use-case:
> =
http://tools.ietf.org/html/draft-gredler-rtgwg-igp-label-advertisement-05#=
section-3.2

rjs> Isn't this an intra-domain use case? As I read it, ASBR{1,2} =
allocate the label and advertise it within the AS1 IGP. There is no =
labelled traffic passed between AS1 and AS{3,4,5,6} as both the ASBRs =
program a pop operation. I read inter-domain as segments being used to =
influence routing within two separate autonomous systems which are not =
within the same trust domain.

>> rjs> I do not see the need to place this restriction on the WG -- =
often we can shape and re-discuss requirements as we work through the =
details of solutions, based on the practicality of realising particular =
functions, or the complexity of supporting particular capabilities. =
Since we do not have this restriction in other WGs, I'm not clear that =
we need it defined here?
>>=20
>=20
> HG> you are right that hacking protocols without use-cases and =
requirements has been
> done in the past in other WGs, but its not a good habit. and since the =
snake-oil
> dealers are already overselling this technology and what it can do, we =
should
> stay very disciplined.

rjs> I can't comment on the assertions of others, and do not wish to do =
so. In my view, there are pragmatic use cases (defined by a number of =
operators) which are gaps that we cannot meet today. Let's identify =
those, and work on those, and allow further uses of the technology going =
forward if there is a convincing case to do so.

rjs> I don't disagree that we should stay disciplined, but I do not see =
the requirement to mandate that a document must be sent to the IESG to =
be published *before* solutions drafts are adopted. Having a requirement =
that the adopted solutions drafts should address the use cases within =
previously adopted documents puts the same focus safe-guard in as far as =
I can see.

Kind regards,
r.

>=20
>>> On Sep 4, 2013, at 10:02 AM, <[email-masked]> =
<[email-masked]> wrote:
>>>=20
>>>> Hannes,
>>>>=20
>>>> In case, we are using only directed forwarding (adjacency segment), =
could we still talk about tunneling ? (it's a very very small tunnel)
>>>> Moreover talking about "stacking" is really dataplane agnostic =
(MPLS) ...
>>>>=20
>>>> In the proposed segment routing architectural concepts, segments =
are at the same "level" and pointer moves on the segment list, then the =
MPLS instantiation is performing this using stacking ...
>>>>=20
>>>> IMHO, if we use "Stacked Tunnels", we already talk about a chosen =
solution and it's closing the door to something else  ...
>>>>=20
>>>> Finally, about the "routing" word, routing is essentially a =
"forward" action which may limit the scope of what we can do by using a =
segment list. Actions associated with a segment could be something else =
than forwarding.
>>>>=20
>>>> Do we want in the charter to limit the scope to routing actions ?
>>>>=20
>>>> I have no solution today to propose for the naming, but I =
completely agree with Loa, to first focus on working on the charter, and =
define a clear scope of the work and then the name will be easier to =
find.
>>>>=20
>>>> Regarding your charter proposal :
>>>>=20
>>>> --------
>>>>=20
>>>> - They form a connected network
>>>>    [SLI] InterAS case must be included, but the WG can go step by =
step and first release intraAS, and then doing interAS (in relation with =
IDR ??).
>>>>=20
>>>> - They can forward traffic through the shortest paths or paths =
other than the shortest (the latter called explicitly routed paths, or =
explicit paths)
>>>>    [SLI] There is something else between SPT and Explicit path, you =
can define other algorithms than SPT to define a path, and it's not =
explicit path. Moreover I come back to my comment, on do we want to =
limit the scope to routing ? I would say no.
>>>>=20
>>>> - They share a common trust model. In this model, any router within =
the ERD can specify an explicit path between itself and any other router =
in the ERD. It can then send any packet that passes through it through =
any path that it has specified.
>>>>    [SLI] Security considerations may have to be addressed in the =
charter , especially for the interAS case (trust yes, but not sure =
access to everything may not be good)
>>>>=20
>>>> Downstream routers within the ERD forward the packet as specified =
by the router at the head-end of the path.
>>>> [SLI] Yes, but any router in the middle may be able to change the =
end to end explicit path.
>>>>=20
>>>>=20
>>>>=20
>>>> - The first goal of the STER WG is to identify use-cases for ERDs.
>>>> - Having identified use-cases, the WG will identify gaps between =
currently available technologies and use-case requirements.
>>>> - The WG will then define requirements for extensions to existing =
protocols or new protocols that address gaps that are identified.
>>>>=20
>>>> [SLI] Agree, I would add :
>>>> - defining the architecture framework
>>>> - analysing the security considerisations
>>>>=20
>>>>=20
>>>> ---------
>>>>=20
>>>>=20
>>>> Here would be my proposal to extend yours :
>>>>=20
>>>> A <named to be defined> domain contains a set of routers with the =
following characteristics:
>>>>=20
>>>> - They form a connected network
>>>> - They can forward traffic through any path within the network =
using shortest path, non shortest path or explicit path
>>>> - They may provide other types of services than forwarding and they =
can enforce service actions in the path.
>>>> - They share a common trust model. In this model, any router within =
the domain can specify a path between itself and any other router in the =
domain. It may then send any packet that passes through it through any =
path that it has specified and that is conform to the security rules. =
Downstream routers within the ERD forward the packet as specified by the =
router at the head-end of the path.
>>>>=20
>>>> The <name> working group is chartered for the following ordered =
list of work items:
>>>>=20
>>>> - The first goal of the WG is to identify use-cases.
>>>> - The WG will then define the architecture framework associated =
with the security considerations. The architecture framework and =
security considerations must address the relations between domains =
(interdomain).
>>>> - Having identified use-cases, architecture and security, the WG =
will identify gaps between currently available technologies and use-case =
requirements.
>>>> - The WG will then define requirements for extensions to existing =
protocols or new protocols that address gaps that are identified.
>>>> - The WG will first focus on the intra-domain forwarding =
definition.
>>>>=20
>>>> Protocol work may be carried out in this working group or in other =
working groups responsible for the protocols, in coordination with this =
WG, and in agreement with the WG chairs and responsible ADs. However, no =
protocol work will be adopted by a working group to address the ERD =
use-cases until the requirements document motivating the protocol work =
has been sent to the IESG for publication as an RFC.
>>>>=20
>>>> -----Message d'origine-----
>>>> De : [email-masked] [mailto:[email-masked]] De la =
part de Hannes Gredler
>>>> Envoy=E9 : mardi 3 septembre 2013 18:31
>>>> =C0 : Loa Andersson
>>>> Cc : [email-masked]
>>>> Objet : Re: [Status] Summary of STATUS BOF and the next steps
>>>>=20
>>>> good point - what about this charter proposal ?
>>>>=20
>>>> ---
>>>>=20
>>>> Stacked Tunnels for Explicit Routing (STER) =
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
>>>>=20
>>>> A explicit routing domain (ERD) contains a set of routers with the =
following characteristics:
>>>>=20
>>>> - They form a connected network
>>>> - They can forward traffic through the shortest paths or paths =
other than the shortest (the latter called explicitly routed paths, or =
explicit paths)
>>>> - They share a common trust model. In this model, any router within =
the ERD can specify an explicit path between itself and any other router =
in the ERD. It can then send any packet that passes through it through =
any path that it has specified. Downstream routers within the ERD =
forward the packet as specified by the router at the head-end of the =
path.
>>>>=20
>>>> The STER working group is chartered for the following ordered list =
of work items:
>>>>=20
>>>> - The first goal of the STER WG is to identify use-cases for ERDs.
>>>> - Having identified use-cases, the WG will identify gaps between =
currently available technologies and use-case requirements.
>>>> - The WG will then define requirements for extensions to existing =
protocols or new protocols that address gaps that are identified.
>>>>=20
>>>> Protocol work may be carried out in this working group or in other =
working groups responsible for the protocols, in coordination with this =
WG, and in agreement with the WG chairs and responsible ADs. However, no =
protocol work will be adopted by a working group to address the ERD =
use-cases until the requirements document motivating the protocol work =
has been sent to the IESG for publication as an RFC.
>>>>=20
>>>> ---
>>>>=20
>>>> <flame suit on>
>>>>=20
>>>> /hannes
>>>>=20
>>>>=20
>>>> On Sep 3, 2013, at 5:31 PM, Loa Andersson wrote:
>>>>=20
>>>>> Folks,
>>>>>=20
>>>>> Excuse me if I'm slightly out of the loop, but so far I have not =
seen
>>>>> a charter proposal, if there is one please point me to it.
>>>>>=20
>>>>> It seems a bit odd to put the cart (what the wg should do) before =
the
>>>>> horse (wg name). If we drill down the the charter first the wg =
name
>>>>> might be easier to figure out.
>>>>>=20
>>>>> /Loa
>>>>>=20
>>>>> PS
>>>>> OK I understand that the horse and cart analogy limps a  bit :).
>>>>>=20
>>>>>=20
>>>>>=20
>>>>> On 2013-09-03 17:22, AshwoodsmithPeter wrote:
>>>>>> " If the WG charter is limited to source routing, how will we =
handle the "non source routing" use cases of segment routing ? In =
another working group ? So we will go back to the WG synchronization =
issue that has been raised for this technology ..."
>>>>>>=20
>>>>>> That's why I suggested SRV2. We are revisiting source routing =
with new concepts. More generic number/action behavior.
>>>>>>=20
>>>>>> Peter
>>>>>>=20
>>>>>> -----Original Message-----
>>>>>> From: [email-masked] [mailto:[email-masked]] On
>>>>>> Behalf Of [email-masked]
>>>>>> Sent: Tuesday, September 03, 2013 10:43 AM
>>>>>> To: AshwoodsmithPeter
>>>>>> Cc: [email-masked]
>>>>>> Subject: Re: [Status] Summary of STATUS BOF and the next steps
>>>>>>=20
>>>>>>=20
>>>>>> There was a misunderstanding in my small comment :) so I will =
explain more :
>>>>>>=20
>>>>>> In segment routing, you have more than basic source routing : =
segment routing is just associate a segment number to an action and then =
combine segment as you want, yes you can do source routing, but you also =
can do more.
>>>>>>=20
>>>>>> In the other hand, I completely agree with your statement that =
source
>>>>>> routing is generic and dataplane agnostic, as segment routing is =
...
>>>>>> (segment routing is not a new dataplane ...)
>>>>>>=20
>>>>>> Now the definition of the WG naming must be inline with the =
charter
>>>>>> that will be defined ... (draft today)
>>>>>>=20
>>>>>> Based on the already existing consensus (at least for MPLS =
dataplane) brought up during Berlin STATUS BOF meeting, segment routing =
sounds to be a good target candidate.
>>>>>>=20
>>>>>> So now, do we want to do more in the WG charter than just make =
progressing segment routing architecture and uses cases document and =
ensure coordination for the standardization of this technology ?
>>>>>>=20
>>>>>> Do we want to standardize other technologies in this WG ? I don't =
think so, based on Stewart's conclusion email from the BOF :"A new WG =
focused solely on SR therefore needs to be create"
>>>>>>=20
>>>>>> If the WG charter is limited to source routing, how will we =
handle the "non source routing" use cases of segment routing ? In =
another working group ? So we will go back to the WG synchronization =
issue that has been raised for this technology ...
>>>>>>=20
>>>>>> If the WG is focused on SR, let's use a name in relation with SR.
>>>>>>=20
>>>>>> Feedback ?
>>>>>>=20
>>>>>>=20
>>>>>> Stephane
>>>>>>=20
>>>>>>=20
>>>>>> -----Message d'origine-----
>>>>>> De : AshwoodsmithPeter [mailto:[email-masked]]
>>>>>> Envoy=E9 : mardi 3 septembre 2013 15:27 =C0 : LITKOWSKI Stephane =
DTF/DERX
>>>>>> Cc : John E Drake; Mark Townsley; Victor Kuarsingh; Roberta =
Maglione
>>>>>> (robmgl); John G. Scudder; Adrian Farrel; Alvaro Retana =
(aretana);
>>>>>> [email-masked]; Stewart Bryant (stbryant) Objet : Re: [Status]
>>>>>> Summary of STATUS BOF and the next steps
>>>>>>=20
>>>>>> The term "source routing" has been around for a very long time =
and is data path agnostic. Its also the term used in the literature etc =
so my preference is to stick with this existing well known and data path =
agnostic term.
>>>>>>=20
>>>>>> Peter
>>>>>>=20
>>>>>> On Sep 3, 2013, at 9:07 AM, "[email-masked]" =
<[email-masked]> wrote:
>>>>>>=20
>>>>>>> Hi,
>>>>>>>=20
>>>>>>> "Source routing" is just a subcase of segment routing ... as it =
is for IP routing ...
>>>>>>>=20
>>>>>>> Stephane
>>>>>>>=20
>>>>>>>=20
>>>>>>> -----Message d'origine-----
>>>>>>> De : [email-masked] [mailto:[email-masked]] De =
la
>>>>>>> part de John E Drake Envoy=E9 : mardi 3 septembre 2013 15:02 =C0 =
: Mark
>>>>>>> Townsley; Victor Kuarsingh Cc : Roberta Maglione (robmgl); John =
G.
>>>>>>> Scudder; Alvaro Retana (aretana); Adrian Farrel; =
[email-masked];
>>>>>>> Stewart Bryant (stbryant) Objet : Re: [Status] Summary of STATUS =
BOF
>>>>>>> and the next steps
>>>>>>>=20
>>>>>>> Hi,
>>>>>>>=20
>>>>>>> What is this 'segment routing' silliness?  The correct term is =
'source routing'.
>>>>>>>=20
>>>>>>> Yours Irrespectively,
>>>>>>>=20
>>>>>>> John
>>>>>>>=20
>>>>>>>> -----Original Message-----
>>>>>>>> From: [email-masked] [mailto:[email-masked]] =
On
>>>>>>>> Behalf Of Mark Townsley
>>>>>>>> Sent: Sunday, September 01, 2013 10:08 AM
>>>>>>>> To: Victor Kuarsingh
>>>>>>>> Cc: Roberta Maglione (robmgl); John G. Scudder; Adrian Farrel;
>>>>>>>> Alvaro Retana (aretana); [email-masked]; Stewart Bryant =
(stbryant)
>>>>>>>> Subject: Re: [Status] Summary of STATUS BOF and the next steps
>>>>>>>>=20
>>>>>>>>=20
>>>>>>>> On Sep 1, 2013, at 5:38 PM, Victor Kuarsingh wrote:
>>>>>>>>=20
>>>>>>>>> All,
>>>>>>>>>=20
>>>>>>>>> I would also favour "Segment Routing WG" as well.
>>>>>>>>>=20
>>>>>>>>> I note this since attempting to come up with an all =
encompassing
>>>>>>>>> acronym will be difficult and Segment Routing is generic =
enough to
>>>>>>>>> associate to multiple functions.
>>>>>>>>=20
>>>>>>>> Then we can just use "segroute" for the short name. WGs do not =
have
>>>>>>>> to have acronyms, but they do need to have an 8-char limited =
short
>>>>>>>> name for the various automated tools not to break.
>>>>>>>>=20
>>>>>>>> - Mark
>>>>>>>>=20
>>>>>>>>>=20
>>>>>>>>> Regards,
>>>>>>>>>=20
>>>>>>>>> Victor K
>>>>>>>>>=20
>>>>>>>>>=20
>>>>>>>>>=20
>>>>>>>>> On 2013-08-31 6:51 PM, "Roberta Maglione (robmgl)"
>>>>>>>>> <[email-masked]>
>>>>>>>>> wrote:
>>>>>>>>>=20
>>>>>>>>>> +1 for Segment Routing WG
>>>>>>>>>>=20
>>>>>>>>>> Roberta
>>>>>>>>>>=20
>>>>>>>>>> Sent from my iPad
>>>>>>>>>>=20
>>>>>>>>>> On 2013-08-30, at 2:55 PM, "Alvaro Retana (aretana)"
>>>>>>>>>> <[email-masked]>
>>>>>>>>>> wrote:
>>>>>>>>>>=20
>>>>>>>>>>> Segment Routing WG
>>>>>>>>>>>=20
>>>>>>>>>>> Sent from my iPhone
>>>>>>>>>>>=20
>>>>>>>>>>> On Aug 30, 2013, at 1:39 PM, "Stewart Bryant (stbryant)"
>>>>>>>>>>> <[email-masked]> wrote:
>>>>>>>>>>>=20
>>>>>>>>>>>> The second task, which hopefully should be relatively easy, =
is
>>>>>>>>>>>> to find a better working name for the WG, since it has been =
put
>>>>>>>>>>>> to me a number of times that STATUS is going to be =
confusing in
>>>>>>>>>>>> text and a difficult search term.
>>>>>>>>>>> _______________________________________________
>>>>>>>>>>> status mailing list
>>>>>>>>>>> [email-masked]
>>>>>>>>>>> https://www.ietf.org/mailman/listinfo/status
>>>>>>>>>> _______________________________________________
>>>>>>>>>> status mailing list
>>>>>>>>>> [email-masked]
>>>>>>>>>> https://www.ietf.org/mailman/listinfo/status
>>>>>>>>>=20
>>>>>>>>>=20
>>>>>>>>> _______________________________________________
>>>>>>>>> status mailing list
>>>>>>>>> [email-masked]
>>>>>>>>> https://www.ietf.org/mailman/listinfo/status
>>>>>>>>=20
>>>>>>>> _______________________________________________
>>>>>>>> status mailing list
>>>>>>>> [email-masked]
>>>>>>>> https://www.ietf.org/mailman/listinfo/status
>>>>>>>=20
>>>>>>>=20
>>>>>>> _______________________________________________
>>>>>>> status mailing list
>>>>>>> [email-masked]
>>>>>>> https://www.ietf.org/mailman/listinfo/status
>>>>>>>=20
>>>>>>> =
____________________________________________________________________
>>>>>>> __ ___________________________________________________
>>>>>>>=20
>>>>>>> Ce message et ses pieces jointes peuvent contenir des =
informations
>>>>>>> confidentielles ou privilegiees et ne doivent donc pas etre
>>>>>>> diffuses, exploites ou copies sans autorisation. Si vous avez =
recu
>>>>>>> ce message par erreur, veuillez le signaler a l'expediteur et le =
detruire ainsi que les pieces jointes. Les messages electroniques etant =
susceptibles d'alteration, Orange decline toute responsabilite si ce =
message a ete altere, deforme ou falsifie. Merci.
>>>>>>>=20
>>>>>>> This message and its attachments may contain confidential or
>>>>>>> privileged information that may be protected by law; they should =
not be distributed, used or copied without authorisation.
>>>>>>> If you have received this email in error, please notify the =
sender and delete this message and its attachments.
>>>>>>> As emails may be altered, Orange is not liable for messages that =
have been modified, changed or falsified.
>>>>>>> Thank you.
>>>>>>>=20
>>>>>>> _______________________________________________
>>>>>>> status mailing list
>>>>>>> [email-masked]
>>>>>>> https://www.ietf.org/mailman/listinfo/status
>>>>>>=20
>>>>>> =
_____________________________________________________________________
>>>>>> ____________________________________________________
>>>>>>=20
>>>>>> Ce message et ses pieces jointes peuvent contenir des =
informations
>>>>>> confidentielles ou privilegiees et ne doivent donc pas etre =
diffuses,
>>>>>> exploites ou copies sans autorisation. Si vous avez recu ce =
message
>>>>>> par erreur, veuillez le signaler a l'expediteur et le detruire =
ainsi que les pieces jointes. Les messages electroniques etant =
susceptibles d'alteration, Orange decline toute responsabilite si ce =
message a ete altere, deforme ou falsifie. Merci.
>>>>>>=20
>>>>>> This message and its attachments may contain confidential or
>>>>>> privileged information that may be protected by law; they should =
not be distributed, used or copied without authorisation.
>>>>>> If you have received this email in error, please notify the =
sender and delete this message and its attachments.
>>>>>> As emails may be altered, Orange is not liable for messages that =
have been modified, changed or falsified.
>>>>>> Thank you.
>>>>>>=20
>>>>>> _______________________________________________
>>>>>> status mailing list
>>>>>> [email-masked]
>>>>>> https://www.ietf.org/mailman/listinfo/status
>>>>>> _______________________________________________
>>>>>> status mailing list
>>>>>> [email-masked]
>>>>>> https://www.ietf.org/mailman/listinfo/status
>>>>>>=20
>>>>>=20
>>>>> --
>>>>>=20
>>>>>=20
>>>>> Loa Andersson                        email: [email-masked]
>>>>> Senior MPLS Expert                          [email-masked]
>>>>> Huawei Technologies (consultant)     phone: +46 739 81 21 64
>>>>> _______________________________________________
>>>>> status mailing list
>>>>> [email-masked]
>>>>> https://www.ietf.org/mailman/listinfo/status
>>>>>=20
>>>>>=20
>>>>=20
>>>>=20
>>>> _______________________________________________
>>>> status mailing list
>>>> [email-masked]
>>>> https://www.ietf.org/mailman/listinfo/status
>>>>=20
>>>> =
__________________________________________________________________________=
_______________________________________________
>>>>=20
>>>> Ce message et ses pieces jointes peuvent contenir des informations =
confidentielles ou privilegiees et ne doivent donc
>>>> pas etre diffuses, exploites ou copies sans autorisation. Si vous =
avez recu ce message par erreur, veuillez le signaler
>>>> a l'expediteur et le detruire ainsi que les pieces jointes. Les =
messages electroniques etant susceptibles d'alteration,
>>>> Orange decline toute responsabilite si ce message a ete altere, =
deforme ou falsifie. Merci.
>>>>=20
>>>> This message and its attachments may contain confidential or =
privileged information that may be protected by law;
>>>> they should not be distributed, used or copied without =
authorisation.
>>>> If you have received this email in error, please notify the sender =
and delete this message and its attachments.
>>>> As emails may be altered, Orange is not liable for messages that =
have been modified, changed or falsified.
>>>> Thank you.
>>>>=20
>>>>=20
>>>>=20
>>>=20
>>>=20
>>> _______________________________________________
>>> status mailing list
>>> [email-masked]
>>> https://www.ietf.org/mailman/listinfo/status
>>=20
>>=20
>>=20
>=20
>=20
> _______________________________________________
> status mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/status

From: <[email-masked]>
To: <[email-masked]>
Date: Mon, 9 Sep 2013 11:26:10 +0200
Accept-Language: en-US, de-DE
acceptlanguage: en-US, de-DE
Cc: [email-masked]
Subject: Re: [Status] Summary of STATUS BOF and the next steps

Hannes,

sorry, but why should the ISPs interested in standardising SR worry about i=
ssues ocurring for ISPs who are not interested in migrating to SR? I don't =
think, SR should look for replacements, SR should work on simplifications. =
That's what the charter should express. I'm not interested in working withi=
n a "LDP and RSVP-TE replacement WG". Sorry if my first mail was overstated=
 to that regard ("...get rid of").

DT so far does not utilise RSVP TE in parts of the backbone, but is interes=
ted in SR based features offering similar routing properties. Bandwidth res=
ervation and preemption are completely irrelevant to me.

If there are issues, we will (dis)cover them while we work on the technolog=
y. But discovering issues and analysing them shouldn't be core part of a ch=
arter - the features to be developed should be.

Serious issues on non core-aspects identified in advance may be removed fro=
m the charter (I'd regard that as usual).

Regards,

Ruediger

-----Original Message-----
From: Hannes Gredler [mailto:[email-masked]]
Sent: Monday, September 09, 2013 10:57 AM
To: Geib, R=FCdiger
Cc: [email-masked]
Subject: Re: [Status] Summary of STATUS BOF and the next steps

ruediger,

On Sep 9, 2013, at 9:08 AM, <[email-masked]> wrote:
> I'm worried about the proposal below, which seem to miss the most importa=
nt points of SR (I call it that):
>
> - SR allows to reduce complexity by getting rid of RSVP TE and LDP.
   ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

that seem to be a gross misunderstanding on your side;

'reducing complexity' means *obsoleting* technology A with technology B.

the issue is that introduction of SR does *neither* obsolete LDP *nor* RSVP=
,
simply because SR is not a 100% replacement of LDP and RSVP functionalities=
.

SR lacks functionality in areas of:

  1. LSP bandwidth reservation
  2. LSP preemption
  3. p2mp path construction
  4. PW signaling
  5. FRR node-protection

adding the IGP as a label distribution protocol to the stack of protocols
allows the network to do tunnel discovery and with that capability we can a=
rguably fix
a couple of interesting problems, but does this single capability
make it a panacea for networking ?

> - I don't fully understand why the SR work must address inter domain rela=
tions, if
>  it is supposed to be primarily chartered with intra domain control plane=
 issues.
> - My take is, that intra-domain MPLS forwarding will remain as is initial=
ly with SR.

there are SPs which operate multi-AS domains and the implications
to connect those ASes using label-stacking technology should be worked on.

> - Your last bullet point means todays MPLS is out of scope, as no forward=
ing
>  definitions need to be changed?

not sure if we can get away with zero changes - issues that we need to talk=
 about are:

1. MPLS source labels
2. Entropy label implications of label stacking
3. Hardware capabilites (Maxpushlabels) and management

> - We agreed not work on protocols within the SR WG. Why has that been cha=
nged?

there might be a a need to work on protocols which do not fit into existing=
 WGs.

HTH,

/hannes

> ---------------
>
> The <Name-TBD> working group is chartered for the following ordered list =
of work items:
>
> - The first goal of the WG is to identify use-cases.
> - The WG will then define the architecture framework associated with
>  the security considerations. The architecture framework and security
>  considerations must address the relations between domains (interdomain).
> - Having identified use-cases, architecture and security, the WG will
>  identify gaps between currently available technologies and use-case
>  requirements.
> - The WG will then define requirements for extensions to existing
>  protocols or new protocols that address gaps that are identified.
> - The WG will first focus on the intra-domain forwarding definition.
>
> Protocol work may be carried out in this working group or in other workin=
g groups responsible for the protocols, in coordination with this WG, and i=
n agreement with the WG chairs and responsible ADs.
> However, no protocol work will be adopted by a working group to address t=
he identified use-cases until the requirements document motivating the prot=
ocol work has been sent to the IESG for publication as an RFC.
>
> ---
>
> /hannes
>
> On Sep 4, 2013, at 10:02 AM, <[email-masked]> <stephane.li=
[email-masked]> wrote:
>
>> Hannes,
>>
>> In case, we are using only directed forwarding (adjacency segment),
>> could we still talk about tunneling ? (it's a very very small tunnel) Mo=
reover talking about "stacking" is really dataplane agnostic (MPLS) ...
>>
>> In the proposed segment routing architectural concepts, segments are at =
the same "level" and pointer moves on the segment list, then the MPLS insta=
ntiation is performing this using stacking ...
>>
>> IMHO, if we use "Stacked Tunnels", we already talk about a chosen soluti=
on and it's closing the door to something else  ...
>>
>> Finally, about the "routing" word, routing is essentially a "forward" ac=
tion which may limit the scope of what we can do by using a segment list. A=
ctions associated with a segment could be something else than forwarding.
>>
>> Do we want in the charter to limit the scope to routing actions ?
>>
>> I have no solution today to propose for the naming, but I completely agr=
ee with Loa, to first focus on working on the charter, and define a clear s=
cope of the work and then the name will be easier to find.
>>
>> Regarding your charter proposal :
>>
>> --------
>>
>> - They form a connected network
>>       [SLI] InterAS case must be included, but the WG can go step by ste=
p and first release intraAS, and then doing interAS (in relation with IDR ?=
?).
>>
>> - They can forward traffic through the shortest paths or paths other tha=
n the shortest (the latter called explicitly routed paths, or explicit path=
s)
>>       [SLI] There is something else between SPT and Explicit path, you c=
an define other algorithms than SPT to define a path, and it's not explicit=
 path. Moreover I come back to my comment, on do we want to limit the scope=
 to routing ? I would say no.
>>
>> - They share a common trust model. In this model, any router within the =
ERD can specify an explicit path between itself and any other router in the=
 ERD. It can then send any packet that passes through it through any path t=
hat it has specified.
>>       [SLI] Security considerations may have to be addressed in the
>> charter , especially for the interAS case (trust yes, but not sure
>> access to everything may not be good)
>>
>> Downstream routers within the ERD forward the packet as specified by the=
 router at the head-end of the path.
>> [SLI] Yes, but any router in the middle may be able to change the end to=
 end explicit path.
>>
>>
>>
>> - The first goal of the STER WG is to identify use-cases for ERDs.
>> - Having identified use-cases, the WG will identify gaps between current=
ly available technologies and use-case requirements.
>> - The WG will then define requirements for extensions to existing protoc=
ols or new protocols that address gaps that are identified.
>>
>> [SLI] Agree, I would add :
>> - defining the architecture framework
>> - analysing the security considerisations
>>
>>
>> ---------
>>
>>
>> Here would be my proposal to extend yours :
>>
>> A <named to be defined> domain contains a set of routers with the follow=
ing characteristics:
>>
>> - They form a connected network
>> - They can forward traffic through any path within the network using
>> shortest path, non shortest path or explicit path
>> - They may provide other types of services than forwarding and they can =
enforce service actions in the path.
>> - They share a common trust model. In this model, any router within the =
domain can specify a path between itself and any other router in the domain=
. It may then send any packet that passes through it through any path that =
it has specified and that is conform to the security rules. Downstream rout=
ers within the ERD forward the packet as specified by the router at the hea=
d-end of the path.
>>
>> The <name> working group is chartered for the following ordered list of =
work items:
>>
>> - The first goal of the WG is to identify use-cases.
>> - The WG will then define the architecture framework associated with the=
 security considerations. The architecture framework and security considera=
tions must address the relations between domains (interdomain).
>> - Having identified use-cases, architecture and security, the WG will id=
entify gaps between currently available technologies and use-case requireme=
nts.
>> - The WG will then define requirements for extensions to existing protoc=
ols or new protocols that address gaps that are identified.
>> - The WG will first focus on the intra-domain forwarding definition.
>>
>> Protocol work may be carried out in this working group or in other worki=
ng groups responsible for the protocols, in coordination with this WG, and =
in agreement with the WG chairs and responsible ADs. However, no protocol w=
ork will be adopted by a working group to address the ERD use-cases until t=
he requirements document motivating the protocol work has been sent to the =
IESG for publication as an RFC.
>>
>> -----Message d'origine-----
>> De : [email-masked] [mailto:[email-masked]] De la
>> part de Hannes Gredler Envoy=E9 : mardi 3 septembre 2013 18:31 =C0 : Loa
>> Andersson Cc : [email-masked] Objet : Re: [Status] Summary of STATUS
>> BOF and the next steps
>>
>> good point - what about this charter proposal ?
>>
>> ---
>>
>> Stacked Tunnels for Explicit Routing (STER)
>> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
>>
>> A explicit routing domain (ERD) contains a set of routers with the follo=
wing characteristics:
>>
>> - They form a connected network
>> - They can forward traffic through the shortest paths or paths other
>> than the shortest (the latter called explicitly routed paths, or
>> explicit paths)
>> - They share a common trust model. In this model, any router within the =
ERD can specify an explicit path between itself and any other router in the=
 ERD. It can then send any packet that passes through it through any path t=
hat it has specified. Downstream routers within the ERD forward the packet =
as specified by the router at the head-end of the path.
>>
>> The STER working group is chartered for the following ordered list of wo=
rk items:
>>
>> - The first goal of the STER WG is to identify use-cases for ERDs.
>> - Having identified use-cases, the WG will identify gaps between current=
ly available technologies and use-case requirements.
>> - The WG will then define requirements for extensions to existing protoc=
ols or new protocols that address gaps that are identified.
>>
>> Protocol work may be carried out in this working group or in other worki=
ng groups responsible for the protocols, in coordination with this WG, and =
in agreement with the WG chairs and responsible ADs. However, no protocol w=
ork will be adopted by a working group to address the ERD use-cases until t=
he requirements document motivating the protocol work has been sent to the =
IESG for publication as an RFC.
>>
>> ---
>>
>> <flame suit on>
>>
>> /hannes
>>
>>
>> On Sep 3, 2013, at 5:31 PM, Loa Andersson wrote:
>>
>>> Folks,
>>>
>>> Excuse me if I'm slightly out of the loop, but so far I have not seen
>>> a charter proposal, if there is one please point me to it.
>>>
>>> It seems a bit odd to put the cart (what the wg should do) before the
>>> horse (wg name). If we drill down the the charter first the wg name
>>> might be easier to figure out.
>>>
>>> /Loa
>>>
>>> PS
>>> OK I understand that the horse and cart analogy limps a  bit :).
>>>
>>>
>>>
>>> On 2013-09-03 17:22, AshwoodsmithPeter wrote:
>>>> " If the WG charter is limited to source routing, how will we handle t=
he "non source routing" use cases of segment routing ? In another working g=
roup ? So we will go back to the WG synchronization issue that has been rai=
sed for this technology ..."
>>>>
>>>> That's why I suggested SRV2. We are revisiting source routing with new=
 concepts. More generic number/action behavior.
>>>>
>>>> Peter
>>>>
>>>> -----Original Message-----
>>>> From: [email-masked] [mailto:[email-masked]] On
>>>> Behalf Of [email-masked]
>>>> Sent: Tuesday, September 03, 2013 10:43 AM
>>>> To: AshwoodsmithPeter
>>>> Cc: [email-masked]
>>>> Subject: Re: [Status] Summary of STATUS BOF and the next steps
>>>>
>>>>
>>>> There was a misunderstanding in my small comment :) so I will explain =
more :
>>>>
>>>> In segment routing, you have more than basic source routing : segment =
routing is just associate a segment number to an action and then combine se=
gment as you want, yes you can do source routing, but you also can do more.
>>>>
>>>> In the other hand, I completely agree with your statement that
>>>> source routing is generic and dataplane agnostic, as segment routing i=
s ...
>>>> (segment routing is not a new dataplane ...)
>>>>
>>>> Now the definition of the WG naming must be inline with the charter
>>>> that will be defined ... (draft today)
>>>>
>>>> Based on the already existing consensus (at least for MPLS dataplane) =
brought up during Berlin STATUS BOF meeting, segment routing sounds to be a=
 good target candidate.
>>>>
>>>> So now, do we want to do more in the WG charter than just make progres=
sing segment routing architecture and uses cases document and ensure coordi=
nation for the standardization of this technology ?
>>>>
>>>> Do we want to standardize other technologies in this WG ? I don't thin=
k so, based on Stewart's conclusion email from the BOF :"A new WG focused s=
olely on SR therefore needs to be create"
>>>>
>>>> If the WG charter is limited to source routing, how will we handle the=
 "non source routing" use cases of segment routing ? In another working gro=
up ? So we will go back to the WG synchronization issue that has been raise=
d for this technology ...
>>>>
>>>> If the WG is focused on SR, let's use a name in relation with SR.
>>>>
>>>> Feedback ?
>>>>
>>>>
>>>> Stephane
>>>>
>>>>
>>>> -----Message d'origine-----
>>>> De : AshwoodsmithPeter [mailto:[email-masked]]
>>>> Envoy=E9 : mardi 3 septembre 2013 15:27 =C0 : LITKOWSKI Stephane
>>>> DTF/DERX Cc : John E Drake; Mark Townsley; Victor Kuarsingh; Roberta
>>>> Maglione (robmgl); John G. Scudder; Adrian Farrel; Alvaro Retana
>>>> (aretana); [email-masked]; Stewart Bryant (stbryant) Objet : Re:
>>>> [Status] Summary of STATUS BOF and the next steps
>>>>
>>>> The term "source routing" has been around for a very long time and is =
data path agnostic. Its also the term used in the literature etc so my pref=
erence is to stick with this existing well known and data path agnostic ter=
m.
>>>>
>>>> Peter
>>>>
>>>> On Sep 3, 2013, at 9:07 AM, "[email-masked]" <stephane.=
[email-masked]> wrote:
>>>>
>>>>> Hi,
>>>>>
>>>>> "Source routing" is just a subcase of segment routing ... as it is fo=
r IP routing ...
>>>>>
>>>>> Stephane
>>>>>
>>>>>
>>>>> -----Message d'origine-----
>>>>> De : [email-masked] [mailto:[email-masked]] De la
>>>>> part de John E Drake Envoy=E9 : mardi 3 septembre 2013 15:02 =C0 : Ma=
rk
>>>>> Townsley; Victor Kuarsingh Cc : Roberta Maglione (robmgl); John G.
>>>>> Scudder; Alvaro Retana (aretana); Adrian Farrel; [email-masked];
>>>>> Stewart Bryant (stbryant) Objet : Re: [Status] Summary of STATUS
>>>>> BOF and the next steps
>>>>>
>>>>> Hi,
>>>>>
>>>>> What is this 'segment routing' silliness?  The correct term is 'sourc=
e routing'.
>>>>>
>>>>> Yours Irrespectively,
>>>>>
>>>>> John
>>>>>
>>>>>> -----Original Message-----
>>>>>> From: [email-masked] [mailto:[email-masked]] On
>>>>>> Behalf Of Mark Townsley
>>>>>> Sent: Sunday, September 01, 2013 10:08 AM
>>>>>> To: Victor Kuarsingh
>>>>>> Cc: Roberta Maglione (robmgl); John G. Scudder; Adrian Farrel;
>>>>>> Alvaro Retana (aretana); [email-masked]; Stewart Bryant
>>>>>> (stbryant)
>>>>>> Subject: Re: [Status] Summary of STATUS BOF and the next steps
>>>>>>
>>>>>>
>>>>>> On Sep 1, 2013, at 5:38 PM, Victor Kuarsingh wrote:
>>>>>>
>>>>>>> All,
>>>>>>>
>>>>>>> I would also favour "Segment Routing WG" as well.
>>>>>>>
>>>>>>> I note this since attempting to come up with an all encompassing
>>>>>>> acronym will be difficult and Segment Routing is generic enough
>>>>>>> to associate to multiple functions.
>>>>>>
>>>>>> Then we can just use "segroute" for the short name. WGs do not
>>>>>> have to have acronyms, but they do need to have an 8-char limited
>>>>>> short name for the various automated tools not to break.
>>>>>>
>>>>>> - Mark
>>>>>>
>>>>>>>
>>>>>>> Regards,
>>>>>>>
>>>>>>> Victor K
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> On 2013-08-31 6:51 PM, "Roberta Maglione (robmgl)"
>>>>>>> <[email-masked]>
>>>>>>> wrote:
>>>>>>>
>>>>>>>> +1 for Segment Routing WG
>>>>>>>>
>>>>>>>> Roberta
>>>>>>>>
>>>>>>>> Sent from my iPad
>>>>>>>>
>>>>>>>> On 2013-08-30, at 2:55 PM, "Alvaro Retana (aretana)"
>>>>>>>> <[email-masked]>
>>>>>>>> wrote:
>>>>>>>>
>>>>>>>>> Segment Routing WG
>>>>>>>>>
>>>>>>>>> Sent from my iPhone
>>>>>>>>>
>>>>>>>>> On Aug 30, 2013, at 1:39 PM, "Stewart Bryant (stbryant)"
>>>>>>>>> <[email-masked]> wrote:
>>>>>>>>>
>>>>>>>>>> The second task, which hopefully should be relatively easy, is
>>>>>>>>>> to find a better working name for the WG, since it has been
>>>>>>>>>> put to me a number of times that STATUS is going to be
>>>>>>>>>> confusing in text and a difficult search term.
>>>>>>>>> _______________________________________________
>>>>>>>>> status mailing list
>>>>>>>>> [email-masked]
>>>>>>>>> https://www.ietf.org/mailman/listinfo/status
>>>>>>>> _______________________________________________
>>>>>>>> status mailing list
>>>>>>>> [email-masked]
>>>>>>>> https://www.ietf.org/mailman/listinfo/status
>>>>>>>
>>>>>>>
>>>>>>> _______________________________________________
>>>>>>> status mailing list
>>>>>>> [email-masked]
>>>>>>> https://www.ietf.org/mailman/listinfo/status
>>>>>>
>>>>>> _______________________________________________
>>>>>> status mailing list
>>>>>> [email-masked]
>>>>>> https://www.ietf.org/mailman/listinfo/status
>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> status mailing list
>>>>> [email-masked]
>>>>> https://www.ietf.org/mailman/listinfo/status
>>>>>
>>>>> ___________________________________________________________________
>>>>> _ __ ___________________________________________________
>>>>>
>>>>> Ce message et ses pieces jointes peuvent contenir des informations
>>>>> confidentielles ou privilegiees et ne doivent donc pas etre
>>>>> diffuses, exploites ou copies sans autorisation. Si vous avez recu
>>>>> ce message par erreur, veuillez le signaler a l'expediteur et le detr=
uire ainsi que les pieces jointes. Les messages electroniques etant suscept=
ibles d'alteration, Orange decline toute responsabilite si ce message a ete=
 altere, deforme ou falsifie. Merci.
>>>>>
>>>>> This message and its attachments may contain confidential or
>>>>> privileged information that may be protected by law; they should not =
be distributed, used or copied without authorisation.
>>>>> If you have received this email in error, please notify the sender an=
d delete this message and its attachments.
>>>>> As emails may be altered, Orange is not liable for messages that have=
 been modified, changed or falsified.
>>>>> Thank you.
>>>>>
>>>>> _______________________________________________
>>>>> status mailing list
>>>>> [email-masked]
>>>>> https://www.ietf.org/mailman/listinfo/status
>>>>
>>>> ____________________________________________________________________
>>>> _ ____________________________________________________
>>>>
>>>> Ce message et ses pieces jointes peuvent contenir des informations
>>>> confidentielles ou privilegiees et ne doivent donc pas etre
>>>> diffuses, exploites ou copies sans autorisation. Si vous avez recu
>>>> ce message par erreur, veuillez le signaler a l'expediteur et le detru=
ire ainsi que les pieces jointes. Les messages electroniques etant suscepti=
bles d'alteration, Orange decline toute responsabilite si ce message a ete =
altere, deforme ou falsifie. Merci.
>>>>
>>>> This message and its attachments may contain confidential or
>>>> privileged information that may be protected by law; they should not b=
e distributed, used or copied without authorisation.
>>>> If you have received this email in error, please notify the sender and=
 delete this message and its attachments.
>>>> As emails may be altered, Orange is not liable for messages that have =
been modified, changed or falsified.
>>>> Thank you.
>>>>
>>>> _______________________________________________
>>>> status mailing list
>>>> [email-masked]
>>>> https://www.ietf.org/mailman/listinfo/status
>>>> _______________________________________________
>>>> status mailing list
>>>> [email-masked]
>>>> https://www.ietf.org/mailman/listinfo/status
>>>>
>>>
>>> --
>>>
>>>
>>> Loa Andersson                        email: [email-masked]
>>> Senior MPLS Expert                          [email-masked]
>>> Huawei Technologies (consultant)     phone: +46 739 81 21 64
>>> _______________________________________________
>>> status mailing list
>>> [email-masked]
>>> https://www.ietf.org/mailman/listinfo/status
>>>
>>>
>>
>>
>> _______________________________________________
>> status mailing list
>> [email-masked]
>> https://www.ietf.org/mailman/listinfo/status
>>
>> ______________________________________________________________________
>> ___________________________________________________
>>
>> Ce message et ses pieces jointes peuvent contenir des informations
>> confidentielles ou privilegiees et ne doivent donc pas etre diffuses,
>> exploites ou copies sans autorisation. Si vous avez recu ce message
>> par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que=
 les pieces jointes. Les messages electroniques etant susceptibles d'altera=
tion, Orange decline toute responsabilite si ce message a ete altere, defor=
me ou falsifie. Merci.
>>
>> This message and its attachments may contain confidential or
>> privileged information that may be protected by law; they should not be =
distributed, used or copied without authorisation.
>> If you have received this email in error, please notify the sender and d=
elete this message and its attachments.
>> As emails may be altered, Orange is not liable for messages that have be=
en modified, changed or falsified.
>> Thank you.
>>
>>
>>
>
>
> _______________________________________________
> status mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/status
>
>

From: Hannes Gredler <[email-masked]>
Date: Mon, 9 Sep 2013 11:23:01 +0200
To: Rob Shakir <[email-masked]>
Cc: [email-masked], "[email-masked]" <[email-masked]>
Subject: Re: [Status] Summary of STATUS BOF and the next steps

hi rob,

On Sep 9, 2013, at 10:24 AM, Rob Shakir wrote:

> Hannes,
>=20
> In-line as rjs>.
>=20
> On 6 Sep 2013, at 16:27, Hannes Gredler <[email-masked]> wrote:
>=20
>> hi stephane,
>>=20
>> here is a revised draft charter as per your comments.
>>=20
>> ---
>>=20
>> <Name-TBD> domain contains a set of routers with the following
>> characteristics:
>>=20
>> - They form a connected network
>> - They can forward traffic through any path within the network using
>> shortest path, or any other (e.g., an explicit) path
>> - They share a common trust model. In this model, any router within
>> the domain can specify a path between itself and any other router
>> in the domain. It may then send any packet that passes through it
>> through any path that it has specified and that is conform to the
>> security rules. Downstream routers along the path within the =
<Name-TBD>
>> domain forward the packet as specified by the router at the head-end
>> of the path.
>>=20
>> The <Name-TBD> working group is chartered for the following ordered
>> list of work items:
>>=20
>> - The first goal of the WG is to identify use-cases.
>> - The WG will then define the architecture framework associated with
>> the security considerations. The architecture framework and security
>> considerations must address the relations between domains (inter =
domain).
>=20
> rjs> It seems a little odd to me that we would identify that there are =
inter-domain issues to solve when there is no suggested use case that =
seemed to relate to this as a requirement. Any extensions of the =
technology developed within the WG to be inter-domain can be for future =
study.

HG> here is an example of an inter domain use-case:
=
http://tools.ietf.org/html/draft-gredler-rtgwg-igp-label-advertisement-05#=
section-3.2

>> - Having identified use-cases, architecture and security, the WG will
>> identify gaps between currently available technologies and use-case
>> requirements.
>> - The WG will then define requirements for extensions to existing
>> protocols or new protocols that address gaps that are identified.
>> - The WG will first focus on the intra-domain forwarding definition.
>>=20
>> Protocol work may be carried out in this working group or in other
>> working groups responsible for the protocols, in coordination with
>> this WG, and in agreement with the WG chairs and responsible ADs.
>> However, no protocol work will be adopted by a working group to
>> address the identified use-cases until the requirements document
>> motivating the protocol work has been sent to the IESG for
>> publication as an RFC.
>=20
> rjs> I do not see the need to place this restriction on the WG -- =
often we can shape and re-discuss requirements as we work through the =
details of solutions, based on the practicality of realising particular =
functions, or the complexity of supporting particular capabilities. =
Since we do not have this restriction in other WGs, I'm not clear that =
we need it defined here?
>=20

HG> you are right that hacking protocols without use-cases and =
requirements has been
done in the past in other WGs, but its not a good habit. and since the =
snake-oil
dealers are already overselling this technology and what it can do, we =
should
stay very disciplined.

>> On Sep 4, 2013, at 10:02 AM, <[email-masked]> =
<[email-masked]> wrote:
>>=20
>>> Hannes,
>>>=20
>>> In case, we are using only directed forwarding (adjacency segment), =
could we still talk about tunneling ? (it's a very very small tunnel)
>>> Moreover talking about "stacking" is really dataplane agnostic =
(MPLS) ...
>>>=20
>>> In the proposed segment routing architectural concepts, segments are =
at the same "level" and pointer moves on the segment list, then the MPLS =
instantiation is performing this using stacking ...
>>>=20
>>> IMHO, if we use "Stacked Tunnels", we already talk about a chosen =
solution and it's closing the door to something else  ...
>>>=20
>>> Finally, about the "routing" word, routing is essentially a =
"forward" action which may limit the scope of what we can do by using a =
segment list. Actions associated with a segment could be something else =
than forwarding.
>>>=20
>>> Do we want in the charter to limit the scope to routing actions ?
>>>=20
>>> I have no solution today to propose for the naming, but I completely =
agree with Loa, to first focus on working on the charter, and define a =
clear scope of the work and then the name will be easier to find.
>>>=20
>>> Regarding your charter proposal :
>>>=20
>>> --------
>>>=20
>>> - They form a connected network
>>>     [SLI] InterAS case must be included, but the WG can go step by =
step and first release intraAS, and then doing interAS (in relation with =
IDR ??).
>>>=20
>>> - They can forward traffic through the shortest paths or paths other =
than the shortest (the latter called explicitly routed paths, or =
explicit paths)
>>>     [SLI] There is something else between SPT and Explicit path, you =
can define other algorithms than SPT to define a path, and it's not =
explicit path. Moreover I come back to my comment, on do we want to =
limit the scope to routing ? I would say no.
>>>=20
>>> - They share a common trust model. In this model, any router within =
the ERD can specify an explicit path between itself and any other router =
in the ERD. It can then send any packet that passes through it through =
any path that it has specified.
>>>     [SLI] Security considerations may have to be addressed in the =
charter , especially for the interAS case (trust yes, but not sure =
access to everything may not be good)
>>>=20
>>> Downstream routers within the ERD forward the packet as specified by =
the router at the head-end of the path.
>>> [SLI] Yes, but any router in the middle may be able to change the =
end to end explicit path.
>>>=20
>>>=20
>>>=20
>>> - The first goal of the STER WG is to identify use-cases for ERDs.
>>> - Having identified use-cases, the WG will identify gaps between =
currently available technologies and use-case requirements.
>>> - The WG will then define requirements for extensions to existing =
protocols or new protocols that address gaps that are identified.
>>>=20
>>> [SLI] Agree, I would add :
>>> - defining the architecture framework
>>> - analysing the security considerisations
>>>=20
>>>=20
>>> ---------
>>>=20
>>>=20
>>> Here would be my proposal to extend yours :
>>>=20
>>> A <named to be defined> domain contains a set of routers with the =
following characteristics:
>>>=20
>>> - They form a connected network
>>> - They can forward traffic through any path within the network using =
shortest path, non shortest path or explicit path
>>> - They may provide other types of services than forwarding and they =
can enforce service actions in the path.
>>> - They share a common trust model. In this model, any router within =
the domain can specify a path between itself and any other router in the =
domain. It may then send any packet that passes through it through any =
path that it has specified and that is conform to the security rules. =
Downstream routers within the ERD forward the packet as specified by the =
router at the head-end of the path.
>>>=20
>>> The <name> working group is chartered for the following ordered list =
of work items:
>>>=20
>>> - The first goal of the WG is to identify use-cases.
>>> - The WG will then define the architecture framework associated with =
the security considerations. The architecture framework and security =
considerations must address the relations between domains (interdomain).
>>> - Having identified use-cases, architecture and security, the WG =
will identify gaps between currently available technologies and use-case =
requirements.
>>> - The WG will then define requirements for extensions to existing =
protocols or new protocols that address gaps that are identified.
>>> - The WG will first focus on the intra-domain forwarding definition.
>>>=20
>>> Protocol work may be carried out in this working group or in other =
working groups responsible for the protocols, in coordination with this =
WG, and in agreement with the WG chairs and responsible ADs. However, no =
protocol work will be adopted by a working group to address the ERD =
use-cases until the requirements document motivating the protocol work =
has been sent to the IESG for publication as an RFC.
>>>=20
>>> -----Message d'origine-----
>>> De : [email-masked] [mailto:[email-masked]] De la =
part de Hannes Gredler
>>> Envoy=E9 : mardi 3 septembre 2013 18:31
>>> =C0 : Loa Andersson
>>> Cc : [email-masked]
>>> Objet : Re: [Status] Summary of STATUS BOF and the next steps
>>>=20
>>> good point - what about this charter proposal ?
>>>=20
>>> ---
>>>=20
>>> Stacked Tunnels for Explicit Routing (STER) =
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
>>>=20
>>> A explicit routing domain (ERD) contains a set of routers with the =
following characteristics:
>>>=20
>>> - They form a connected network
>>> - They can forward traffic through the shortest paths or paths other =
than the shortest (the latter called explicitly routed paths, or =
explicit paths)
>>> - They share a common trust model. In this model, any router within =
the ERD can specify an explicit path between itself and any other router =
in the ERD. It can then send any packet that passes through it through =
any path that it has specified. Downstream routers within the ERD =
forward the packet as specified by the router at the head-end of the =
path.
>>>=20
>>> The STER working group is chartered for the following ordered list =
of work items:
>>>=20
>>> - The first goal of the STER WG is to identify use-cases for ERDs.
>>> - Having identified use-cases, the WG will identify gaps between =
currently available technologies and use-case requirements.
>>> - The WG will then define requirements for extensions to existing =
protocols or new protocols that address gaps that are identified.
>>>=20
>>> Protocol work may be carried out in this working group or in other =
working groups responsible for the protocols, in coordination with this =
WG, and in agreement with the WG chairs and responsible ADs. However, no =
protocol work will be adopted by a working group to address the ERD =
use-cases until the requirements document motivating the protocol work =
has been sent to the IESG for publication as an RFC.
>>>=20
>>> ---
>>>=20
>>> <flame suit on>
>>>=20
>>> /hannes
>>>=20
>>>=20
>>> On Sep 3, 2013, at 5:31 PM, Loa Andersson wrote:
>>>=20
>>>> Folks,
>>>>=20
>>>> Excuse me if I'm slightly out of the loop, but so far I have not =
seen
>>>> a charter proposal, if there is one please point me to it.
>>>>=20
>>>> It seems a bit odd to put the cart (what the wg should do) before =
the
>>>> horse (wg name). If we drill down the the charter first the wg name
>>>> might be easier to figure out.
>>>>=20
>>>> /Loa
>>>>=20
>>>> PS
>>>> OK I understand that the horse and cart analogy limps a  bit :).
>>>>=20
>>>>=20
>>>>=20
>>>> On 2013-09-03 17:22, AshwoodsmithPeter wrote:
>>>>> " If the WG charter is limited to source routing, how will we =
handle the "non source routing" use cases of segment routing ? In =
another working group ? So we will go back to the WG synchronization =
issue that has been raised for this technology ..."
>>>>>=20
>>>>> That's why I suggested SRV2. We are revisiting source routing with =
new concepts. More generic number/action behavior.
>>>>>=20
>>>>> Peter
>>>>>=20
>>>>> -----Original Message-----
>>>>> From: [email-masked] [mailto:[email-masked]] On
>>>>> Behalf Of [email-masked]
>>>>> Sent: Tuesday, September 03, 2013 10:43 AM
>>>>> To: AshwoodsmithPeter
>>>>> Cc: [email-masked]
>>>>> Subject: Re: [Status] Summary of STATUS BOF and the next steps
>>>>>=20
>>>>>=20
>>>>> There was a misunderstanding in my small comment :) so I will =
explain more :
>>>>>=20
>>>>> In segment routing, you have more than basic source routing : =
segment routing is just associate a segment number to an action and then =
combine segment as you want, yes you can do source routing, but you also =
can do more.
>>>>>=20
>>>>> In the other hand, I completely agree with your statement that =
source
>>>>> routing is generic and dataplane agnostic, as segment routing is =
...
>>>>> (segment routing is not a new dataplane ...)
>>>>>=20
>>>>> Now the definition of the WG naming must be inline with the =
charter
>>>>> that will be defined ... (draft today)
>>>>>=20
>>>>> Based on the already existing consensus (at least for MPLS =
dataplane) brought up during Berlin STATUS BOF meeting, segment routing =
sounds to be a good target candidate.
>>>>>=20
>>>>> So now, do we want to do more in the WG charter than just make =
progressing segment routing architecture and uses cases document and =
ensure coordination for the standardization of this technology ?
>>>>>=20
>>>>> Do we want to standardize other technologies in this WG ? I don't =
think so, based on Stewart's conclusion email from the BOF :"A new WG =
focused solely on SR therefore needs to be create"
>>>>>=20
>>>>> If the WG charter is limited to source routing, how will we handle =
the "non source routing" use cases of segment routing ? In another =
working group ? So we will go back to the WG synchronization issue that =
has been raised for this technology ...
>>>>>=20
>>>>> If the WG is focused on SR, let's use a name in relation with SR.
>>>>>=20
>>>>> Feedback ?
>>>>>=20
>>>>>=20
>>>>> Stephane
>>>>>=20
>>>>>=20
>>>>> -----Message d'origine-----
>>>>> De : AshwoodsmithPeter [mailto:[email-masked]]
>>>>> Envoy=E9 : mardi 3 septembre 2013 15:27 =C0 : LITKOWSKI Stephane =
DTF/DERX
>>>>> Cc : John E Drake; Mark Townsley; Victor Kuarsingh; Roberta =
Maglione
>>>>> (robmgl); John G. Scudder; Adrian Farrel; Alvaro Retana (aretana);
>>>>> [email-masked]; Stewart Bryant (stbryant) Objet : Re: [Status]
>>>>> Summary of STATUS BOF and the next steps
>>>>>=20
>>>>> The term "source routing" has been around for a very long time and =
is data path agnostic. Its also the term used in the literature etc so =
my preference is to stick with this existing well known and data path =
agnostic term.
>>>>>=20
>>>>> Peter
>>>>>=20
>>>>> On Sep 3, 2013, at 9:07 AM, "[email-masked]" =
<[email-masked]> wrote:
>>>>>=20
>>>>>> Hi,
>>>>>>=20
>>>>>> "Source routing" is just a subcase of segment routing ... as it =
is for IP routing ...
>>>>>>=20
>>>>>> Stephane
>>>>>>=20
>>>>>>=20
>>>>>> -----Message d'origine-----
>>>>>> De : [email-masked] [mailto:[email-masked]] De =
la
>>>>>> part de John E Drake Envoy=E9 : mardi 3 septembre 2013 15:02 =C0 =
: Mark
>>>>>> Townsley; Victor Kuarsingh Cc : Roberta Maglione (robmgl); John =
G.
>>>>>> Scudder; Alvaro Retana (aretana); Adrian Farrel; [email-masked];
>>>>>> Stewart Bryant (stbryant) Objet : Re: [Status] Summary of STATUS =
BOF
>>>>>> and the next steps
>>>>>>=20
>>>>>> Hi,
>>>>>>=20
>>>>>> What is this 'segment routing' silliness?  The correct term is =
'source routing'.
>>>>>>=20
>>>>>> Yours Irrespectively,
>>>>>>=20
>>>>>> John
>>>>>>=20
>>>>>>> -----Original Message-----
>>>>>>> From: [email-masked] [mailto:[email-masked]] =
On
>>>>>>> Behalf Of Mark Townsley
>>>>>>> Sent: Sunday, September 01, 2013 10:08 AM
>>>>>>> To: Victor Kuarsingh
>>>>>>> Cc: Roberta Maglione (robmgl); John G. Scudder; Adrian Farrel;
>>>>>>> Alvaro Retana (aretana); [email-masked]; Stewart Bryant =
(stbryant)
>>>>>>> Subject: Re: [Status] Summary of STATUS BOF and the next steps
>>>>>>>=20
>>>>>>>=20
>>>>>>> On Sep 1, 2013, at 5:38 PM, Victor Kuarsingh wrote:
>>>>>>>=20
>>>>>>>> All,
>>>>>>>>=20
>>>>>>>> I would also favour "Segment Routing WG" as well.
>>>>>>>>=20
>>>>>>>> I note this since attempting to come up with an all =
encompassing
>>>>>>>> acronym will be difficult and Segment Routing is generic enough =
to
>>>>>>>> associate to multiple functions.
>>>>>>>=20
>>>>>>> Then we can just use "segroute" for the short name. WGs do not =
have
>>>>>>> to have acronyms, but they do need to have an 8-char limited =
short
>>>>>>> name for the various automated tools not to break.
>>>>>>>=20
>>>>>>> - Mark
>>>>>>>=20
>>>>>>>>=20
>>>>>>>> Regards,
>>>>>>>>=20
>>>>>>>> Victor K
>>>>>>>>=20
>>>>>>>>=20
>>>>>>>>=20
>>>>>>>> On 2013-08-31 6:51 PM, "Roberta Maglione (robmgl)"
>>>>>>>> <[email-masked]>
>>>>>>>> wrote:
>>>>>>>>=20
>>>>>>>>> +1 for Segment Routing WG
>>>>>>>>>=20
>>>>>>>>> Roberta
>>>>>>>>>=20
>>>>>>>>> Sent from my iPad
>>>>>>>>>=20
>>>>>>>>> On 2013-08-30, at 2:55 PM, "Alvaro Retana (aretana)"
>>>>>>>>> <[email-masked]>
>>>>>>>>> wrote:
>>>>>>>>>=20
>>>>>>>>>> Segment Routing WG
>>>>>>>>>>=20
>>>>>>>>>> Sent from my iPhone
>>>>>>>>>>=20
>>>>>>>>>> On Aug 30, 2013, at 1:39 PM, "Stewart Bryant (stbryant)"
>>>>>>>>>> <[email-masked]> wrote:
>>>>>>>>>>=20
>>>>>>>>>>> The second task, which hopefully should be relatively easy, =
is
>>>>>>>>>>> to find a better working name for the WG, since it has been =
put
>>>>>>>>>>> to me a number of times that STATUS is going to be confusing =
in
>>>>>>>>>>> text and a difficult search term.
>>>>>>>>>> _______________________________________________
>>>>>>>>>> status mailing list
>>>>>>>>>> [email-masked]
>>>>>>>>>> https://www.ietf.org/mailman/listinfo/status
>>>>>>>>> _______________________________________________
>>>>>>>>> status mailing list
>>>>>>>>> [email-masked]
>>>>>>>>> https://www.ietf.org/mailman/listinfo/status
>>>>>>>>=20
>>>>>>>>=20
>>>>>>>> _______________________________________________
>>>>>>>> status mailing list
>>>>>>>> [email-masked]
>>>>>>>> https://www.ietf.org/mailman/listinfo/status
>>>>>>>=20
>>>>>>> _______________________________________________
>>>>>>> status mailing list
>>>>>>> [email-masked]
>>>>>>> https://www.ietf.org/mailman/listinfo/status
>>>>>>=20
>>>>>>=20
>>>>>> _______________________________________________
>>>>>> status mailing list
>>>>>> [email-masked]
>>>>>> https://www.ietf.org/mailman/listinfo/status
>>>>>>=20
>>>>>> =
____________________________________________________________________
>>>>>> __ ___________________________________________________
>>>>>>=20
>>>>>> Ce message et ses pieces jointes peuvent contenir des =
informations
>>>>>> confidentielles ou privilegiees et ne doivent donc pas etre
>>>>>> diffuses, exploites ou copies sans autorisation. Si vous avez =
recu
>>>>>> ce message par erreur, veuillez le signaler a l'expediteur et le =
detruire ainsi que les pieces jointes. Les messages electroniques etant =
susceptibles d'alteration, Orange decline toute responsabilite si ce =
message a ete altere, deforme ou falsifie. Merci.
>>>>>>=20
>>>>>> This message and its attachments may contain confidential or
>>>>>> privileged information that may be protected by law; they should =
not be distributed, used or copied without authorisation.
>>>>>> If you have received this email in error, please notify the =
sender and delete this message and its attachments.
>>>>>> As emails may be altered, Orange is not liable for messages that =
have been modified, changed or falsified.
>>>>>> Thank you.
>>>>>>=20
>>>>>> _______________________________________________
>>>>>> status mailing list
>>>>>> [email-masked]
>>>>>> https://www.ietf.org/mailman/listinfo/status
>>>>>=20
>>>>> =
_____________________________________________________________________
>>>>> ____________________________________________________
>>>>>=20
>>>>> Ce message et ses pieces jointes peuvent contenir des informations
>>>>> confidentielles ou privilegiees et ne doivent donc pas etre =
diffuses,
>>>>> exploites ou copies sans autorisation. Si vous avez recu ce =
message
>>>>> par erreur, veuillez le signaler a l'expediteur et le detruire =
ainsi que les pieces jointes. Les messages electroniques etant =
susceptibles d'alteration, Orange decline toute responsabilite si ce =
message a ete altere, deforme ou falsifie. Merci.
>>>>>=20
>>>>> This message and its attachments may contain confidential or
>>>>> privileged information that may be protected by law; they should =
not be distributed, used or copied without authorisation.
>>>>> If you have received this email in error, please notify the sender =
and delete this message and its attachments.
>>>>> As emails may be altered, Orange is not liable for messages that =
have been modified, changed or falsified.
>>>>> Thank you.
>>>>>=20
>>>>> _______________________________________________
>>>>> status mailing list
>>>>> [email-masked]
>>>>> https://www.ietf.org/mailman/listinfo/status
>>>>> _______________________________________________
>>>>> status mailing list
>>>>> [email-masked]
>>>>> https://www.ietf.org/mailman/listinfo/status
>>>>>=20
>>>>=20
>>>> --
>>>>=20
>>>>=20
>>>> Loa Andersson                        email: [email-masked]
>>>> Senior MPLS Expert                          [email-masked]
>>>> Huawei Technologies (consultant)     phone: +46 739 81 21 64
>>>> _______________________________________________
>>>> status mailing list
>>>> [email-masked]
>>>> https://www.ietf.org/mailman/listinfo/status
>>>>=20
>>>>=20
>>>=20
>>>=20
>>> _______________________________________________
>>> status mailing list
>>> [email-masked]
>>> https://www.ietf.org/mailman/listinfo/status
>>>=20
>>> =
__________________________________________________________________________=
_______________________________________________
>>>=20
>>> Ce message et ses pieces jointes peuvent contenir des informations =
confidentielles ou privilegiees et ne doivent donc
>>> pas etre diffuses, exploites ou copies sans autorisation. Si vous =
avez recu ce message par erreur, veuillez le signaler
>>> a l'expediteur et le detruire ainsi que les pieces jointes. Les =
messages electroniques etant susceptibles d'alteration,
>>> Orange decline toute responsabilite si ce message a ete altere, =
deforme ou falsifie. Merci.
>>>=20
>>> This message and its attachments may contain confidential or =
privileged information that may be protected by law;
>>> they should not be distributed, used or copied without =
authorisation.
>>> If you have received this email in error, please notify the sender =
and delete this message and its attachments.
>>> As emails may be altered, Orange is not liable for messages that =
have been modified, changed or falsified.
>>> Thank you.
>>>=20
>>>=20
>>>=20
>>=20
>>=20
>> _______________________________________________
>> status mailing list
>> [email-masked]
>> https://www.ietf.org/mailman/listinfo/status
>=20
>=20
>=20

From: Hannes Gredler <[email-masked]>
Date: Mon, 9 Sep 2013 10:56:56 +0200
To: <[email-masked]>
Cc: [email-masked]
Subject: Re: [Status] Summary of STATUS BOF and the next steps

ruediger,

On Sep 9, 2013, at 9:08 AM, <[email-masked]> wrote:
> I'm worried about the proposal below, which seem to miss the most =
important points of SR (I call it that):
>=20
> - SR allows to reduce complexity by getting rid of RSVP TE and LDP.
   ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

that seem to be a gross misunderstanding on your side;

'reducing complexity' means *obsoleting* technology A with technology B.

the issue is that introduction of SR does *neither* obsolete LDP *nor* =
RSVP,
simply because SR is not a 100% replacement of LDP and RSVP =
functionalities.

SR lacks functionality in areas of:

  1. LSP bandwidth reservation
  2. LSP preemption
  3. p2mp path construction
  4. PW signaling
  5. FRR node-protection

adding the IGP as a label distribution protocol to the stack of =
protocols
allows the network to do tunnel discovery and with that capability we =
can arguably fix
a couple of interesting problems, but does this single capability
make it a panacea for networking ?

> - I don't fully understand why the SR work must address inter domain =
relations, if
>  it is supposed to be primarily chartered with intra domain control =
plane issues.
> - My take is, that intra-domain MPLS forwarding will remain as is =
initially with SR.

there are SPs which operate multi-AS domains and the implications
to connect those ASes using label-stacking technology should be worked =
on.

> - Your last bullet point means todays MPLS is out of scope, as no =
forwarding
>  definitions need to be changed?

not sure if we can get away with zero changes - issues that we need to =
talk about are:

1. MPLS source labels
2. Entropy label implications of label stacking
3. Hardware capabilites (Maxpushlabels) and management

> - We agreed not work on protocols within the SR WG. Why has that been =
changed?

there might be a a need to work on protocols which do not fit into =
existing WGs.

HTH,

/hannes

> ---------------
>=20
> The <Name-TBD> working group is chartered for the following ordered =
list of work items:
>=20
> - The first goal of the WG is to identify use-cases.
> - The WG will then define the architecture framework associated with
>  the security considerations. The architecture framework and security
>  considerations must address the relations between domains =
(interdomain).
> - Having identified use-cases, architecture and security, the WG will
>  identify gaps between currently available technologies and use-case
>  requirements.
> - The WG will then define requirements for extensions to existing
>  protocols or new protocols that address gaps that are identified.
> - The WG will first focus on the intra-domain forwarding definition.
>=20
> Protocol work may be carried out in this working group or in other =
working groups responsible for the protocols, in coordination with this =
WG, and in agreement with the WG chairs and responsible ADs.
> However, no protocol work will be adopted by a working group to =
address the identified use-cases until the requirements document =
motivating the protocol work has been sent to the IESG for publication =
as an RFC.
>=20
> ---
>=20
> /hannes
>=20
> On Sep 4, 2013, at 10:02 AM, <[email-masked]> =
<[email-masked]> wrote:
>=20
>> Hannes,
>>=20
>> In case, we are using only directed forwarding (adjacency segment),
>> could we still talk about tunneling ? (it's a very very small tunnel) =
Moreover talking about "stacking" is really dataplane agnostic (MPLS) =
...
>>=20
>> In the proposed segment routing architectural concepts, segments are =
at the same "level" and pointer moves on the segment list, then the MPLS =
instantiation is performing this using stacking ...
>>=20
>> IMHO, if we use "Stacked Tunnels", we already talk about a chosen =
solution and it's closing the door to something else  ...
>>=20
>> Finally, about the "routing" word, routing is essentially a "forward" =
action which may limit the scope of what we can do by using a segment =
list. Actions associated with a segment could be something else than =
forwarding.
>>=20
>> Do we want in the charter to limit the scope to routing actions ?
>>=20
>> I have no solution today to propose for the naming, but I completely =
agree with Loa, to first focus on working on the charter, and define a =
clear scope of the work and then the name will be easier to find.
>>=20
>> Regarding your charter proposal :
>>=20
>> --------
>>=20
>> - They form a connected network
>>       [SLI] InterAS case must be included, but the WG can go step by =
step and first release intraAS, and then doing interAS (in relation with =
IDR ??).
>>=20
>> - They can forward traffic through the shortest paths or paths other =
than the shortest (the latter called explicitly routed paths, or =
explicit paths)
>>       [SLI] There is something else between SPT and Explicit path, =
you can define other algorithms than SPT to define a path, and it's not =
explicit path. Moreover I come back to my comment, on do we want to =
limit the scope to routing ? I would say no.
>>=20
>> - They share a common trust model. In this model, any router within =
the ERD can specify an explicit path between itself and any other router =
in the ERD. It can then send any packet that passes through it through =
any path that it has specified.
>>       [SLI] Security considerations may have to be addressed in the
>> charter , especially for the interAS case (trust yes, but not sure
>> access to everything may not be good)
>>=20
>> Downstream routers within the ERD forward the packet as specified by =
the router at the head-end of the path.
>> [SLI] Yes, but any router in the middle may be able to change the end =
to end explicit path.
>>=20
>>=20
>>=20
>> - The first goal of the STER WG is to identify use-cases for ERDs.
>> - Having identified use-cases, the WG will identify gaps between =
currently available technologies and use-case requirements.
>> - The WG will then define requirements for extensions to existing =
protocols or new protocols that address gaps that are identified.
>>=20
>> [SLI] Agree, I would add :
>> - defining the architecture framework
>> - analysing the security considerisations
>>=20
>>=20
>> ---------
>>=20
>>=20
>> Here would be my proposal to extend yours :
>>=20
>> A <named to be defined> domain contains a set of routers with the =
following characteristics:
>>=20
>> - They form a connected network
>> - They can forward traffic through any path within the network using
>> shortest path, non shortest path or explicit path
>> - They may provide other types of services than forwarding and they =
can enforce service actions in the path.
>> - They share a common trust model. In this model, any router within =
the domain can specify a path between itself and any other router in the =
domain. It may then send any packet that passes through it through any =
path that it has specified and that is conform to the security rules. =
Downstream routers within the ERD forward the packet as specified by the =
router at the head-end of the path.
>>=20
>> The <name> working group is chartered for the following ordered list =
of work items:
>>=20
>> - The first goal of the WG is to identify use-cases.
>> - The WG will then define the architecture framework associated with =
the security considerations. The architecture framework and security =
considerations must address the relations between domains (interdomain).
>> - Having identified use-cases, architecture and security, the WG will =
identify gaps between currently available technologies and use-case =
requirements.
>> - The WG will then define requirements for extensions to existing =
protocols or new protocols that address gaps that are identified.
>> - The WG will first focus on the intra-domain forwarding definition.
>>=20
>> Protocol work may be carried out in this working group or in other =
working groups responsible for the protocols, in coordination with this =
WG, and in agreement with the WG chairs and responsible ADs. However, no =
protocol work will be adopted by a working group to address the ERD =
use-cases until the requirements document motivating the protocol work =
has been sent to the IESG for publication as an RFC.
>>=20
>> -----Message d'origine-----
>> De : [email-masked] [mailto:[email-masked]] De la
>> part de Hannes Gredler Envoy=E9 : mardi 3 septembre 2013 18:31 =C0 : =
Loa
>> Andersson Cc : [email-masked] Objet : Re: [Status] Summary of STATUS
>> BOF and the next steps
>>=20
>> good point - what about this charter proposal ?
>>=20
>> ---
>>=20
>> Stacked Tunnels for Explicit Routing (STER)
>> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
>>=20
>> A explicit routing domain (ERD) contains a set of routers with the =
following characteristics:
>>=20
>> - They form a connected network
>> - They can forward traffic through the shortest paths or paths other
>> than the shortest (the latter called explicitly routed paths, or
>> explicit paths)
>> - They share a common trust model. In this model, any router within =
the ERD can specify an explicit path between itself and any other router =
in the ERD. It can then send any packet that passes through it through =
any path that it has specified. Downstream routers within the ERD =
forward the packet as specified by the router at the head-end of the =
path.
>>=20
>> The STER working group is chartered for the following ordered list of =
work items:
>>=20
>> - The first goal of the STER WG is to identify use-cases for ERDs.
>> - Having identified use-cases, the WG will identify gaps between =
currently available technologies and use-case requirements.
>> - The WG will then define requirements for extensions to existing =
protocols or new protocols that address gaps that are identified.
>>=20
>> Protocol work may be carried out in this working group or in other =
working groups responsible for the protocols, in coordination with this =
WG, and in agreement with the WG chairs and responsible ADs. However, no =
protocol work will be adopted by a working group to address the ERD =
use-cases until the requirements document motivating the protocol work =
has been sent to the IESG for publication as an RFC.
>>=20
>> ---
>>=20
>> <flame suit on>
>>=20
>> /hannes
>>=20
>>=20
>> On Sep 3, 2013, at 5:31 PM, Loa Andersson wrote:
>>=20
>>> Folks,
>>>=20
>>> Excuse me if I'm slightly out of the loop, but so far I have not =
seen
>>> a charter proposal, if there is one please point me to it.
>>>=20
>>> It seems a bit odd to put the cart (what the wg should do) before =
the
>>> horse (wg name). If we drill down the the charter first the wg name
>>> might be easier to figure out.
>>>=20
>>> /Loa
>>>=20
>>> PS
>>> OK I understand that the horse and cart analogy limps a  bit :).
>>>=20
>>>=20
>>>=20
>>> On 2013-09-03 17:22, AshwoodsmithPeter wrote:
>>>> " If the WG charter is limited to source routing, how will we =
handle the "non source routing" use cases of segment routing ? In =
another working group ? So we will go back to the WG synchronization =
issue that has been raised for this technology ..."
>>>>=20
>>>> That's why I suggested SRV2. We are revisiting source routing with =
new concepts. More generic number/action behavior.
>>>>=20
>>>> Peter
>>>>=20
>>>> -----Original Message-----
>>>> From: [email-masked] [mailto:[email-masked]] On
>>>> Behalf Of [email-masked]
>>>> Sent: Tuesday, September 03, 2013 10:43 AM
>>>> To: AshwoodsmithPeter
>>>> Cc: [email-masked]
>>>> Subject: Re: [Status] Summary of STATUS BOF and the next steps
>>>>=20
>>>>=20
>>>> There was a misunderstanding in my small comment :) so I will =
explain more :
>>>>=20
>>>> In segment routing, you have more than basic source routing : =
segment routing is just associate a segment number to an action and then =
combine segment as you want, yes you can do source routing, but you also =
can do more.
>>>>=20
>>>> In the other hand, I completely agree with your statement that
>>>> source routing is generic and dataplane agnostic, as segment =
routing is ...
>>>> (segment routing is not a new dataplane ...)
>>>>=20
>>>> Now the definition of the WG naming must be inline with the charter
>>>> that will be defined ... (draft today)
>>>>=20
>>>> Based on the already existing consensus (at least for MPLS =
dataplane) brought up during Berlin STATUS BOF meeting, segment routing =
sounds to be a good target candidate.
>>>>=20
>>>> So now, do we want to do more in the WG charter than just make =
progressing segment routing architecture and uses cases document and =
ensure coordination for the standardization of this technology ?
>>>>=20
>>>> Do we want to standardize other technologies in this WG ? I don't =
think so, based on Stewart's conclusion email from the BOF :"A new WG =
focused solely on SR therefore needs to be create"
>>>>=20
>>>> If the WG charter is limited to source routing, how will we handle =
the "non source routing" use cases of segment routing ? In another =
working group ? So we will go back to the WG synchronization issue that =
has been raised for this technology ...
>>>>=20
>>>> If the WG is focused on SR, let's use a name in relation with SR.
>>>>=20
>>>> Feedback ?
>>>>=20
>>>>=20
>>>> Stephane
>>>>=20
>>>>=20
>>>> -----Message d'origine-----
>>>> De : AshwoodsmithPeter [mailto:[email-masked]]
>>>> Envoy=E9 : mardi 3 septembre 2013 15:27 =C0 : LITKOWSKI Stephane
>>>> DTF/DERX Cc : John E Drake; Mark Townsley; Victor Kuarsingh; =
Roberta
>>>> Maglione (robmgl); John G. Scudder; Adrian Farrel; Alvaro Retana
>>>> (aretana); [email-masked]; Stewart Bryant (stbryant) Objet : Re:
>>>> [Status] Summary of STATUS BOF and the next steps
>>>>=20
>>>> The term "source routing" has been around for a very long time and =
is data path agnostic. Its also the term used in the literature etc so =
my preference is to stick with this existing well known and data path =
agnostic term.
>>>>=20
>>>> Peter
>>>>=20
>>>> On Sep 3, 2013, at 9:07 AM, "[email-masked]" =
<[email-masked]> wrote:
>>>>=20
>>>>> Hi,
>>>>>=20
>>>>> "Source routing" is just a subcase of segment routing ... as it is =
for IP routing ...
>>>>>=20
>>>>> Stephane
>>>>>=20
>>>>>=20
>>>>> -----Message d'origine-----
>>>>> De : [email-masked] [mailto:[email-masked]] De =
la
>>>>> part de John E Drake Envoy=E9 : mardi 3 septembre 2013 15:02 =C0 : =
Mark
>>>>> Townsley; Victor Kuarsingh Cc : Roberta Maglione (robmgl); John G.
>>>>> Scudder; Alvaro Retana (aretana); Adrian Farrel; [email-masked];
>>>>> Stewart Bryant (stbryant) Objet : Re: [Status] Summary of STATUS
>>>>> BOF and the next steps
>>>>>=20
>>>>> Hi,
>>>>>=20
>>>>> What is this 'segment routing' silliness?  The correct term is =
'source routing'.
>>>>>=20
>>>>> Yours Irrespectively,
>>>>>=20
>>>>> John
>>>>>=20
>>>>>> -----Original Message-----
>>>>>> From: [email-masked] [mailto:[email-masked]] On
>>>>>> Behalf Of Mark Townsley
>>>>>> Sent: Sunday, September 01, 2013 10:08 AM
>>>>>> To: Victor Kuarsingh
>>>>>> Cc: Roberta Maglione (robmgl); John G. Scudder; Adrian Farrel;
>>>>>> Alvaro Retana (aretana); [email-masked]; Stewart Bryant
>>>>>> (stbryant)
>>>>>> Subject: Re: [Status] Summary of STATUS BOF and the next steps
>>>>>>=20
>>>>>>=20
>>>>>> On Sep 1, 2013, at 5:38 PM, Victor Kuarsingh wrote:
>>>>>>=20
>>>>>>> All,
>>>>>>>=20
>>>>>>> I would also favour "Segment Routing WG" as well.
>>>>>>>=20
>>>>>>> I note this since attempting to come up with an all encompassing
>>>>>>> acronym will be difficult and Segment Routing is generic enough
>>>>>>> to associate to multiple functions.
>>>>>>=20
>>>>>> Then we can just use "segroute" for the short name. WGs do not
>>>>>> have to have acronyms, but they do need to have an 8-char limited
>>>>>> short name for the various automated tools not to break.
>>>>>>=20
>>>>>> - Mark
>>>>>>=20
>>>>>>>=20
>>>>>>> Regards,
>>>>>>>=20
>>>>>>> Victor K
>>>>>>>=20
>>>>>>>=20
>>>>>>>=20
>>>>>>> On 2013-08-31 6:51 PM, "Roberta Maglione (robmgl)"
>>>>>>> <[email-masked]>
>>>>>>> wrote:
>>>>>>>=20
>>>>>>>> +1 for Segment Routing WG
>>>>>>>>=20
>>>>>>>> Roberta
>>>>>>>>=20
>>>>>>>> Sent from my iPad
>>>>>>>>=20
>>>>>>>> On 2013-08-30, at 2:55 PM, "Alvaro Retana (aretana)"
>>>>>>>> <[email-masked]>
>>>>>>>> wrote:
>>>>>>>>=20
>>>>>>>>> Segment Routing WG
>>>>>>>>>=20
>>>>>>>>> Sent from my iPhone
>>>>>>>>>=20
>>>>>>>>> On Aug 30, 2013, at 1:39 PM, "Stewart Bryant (stbryant)"
>>>>>>>>> <[email-masked]> wrote:
>>>>>>>>>=20
>>>>>>>>>> The second task, which hopefully should be relatively easy, =
is
>>>>>>>>>> to find a better working name for the WG, since it has been
>>>>>>>>>> put to me a number of times that STATUS is going to be
>>>>>>>>>> confusing in text and a difficult search term.
>>>>>>>>> _______________________________________________
>>>>>>>>> status mailing list
>>>>>>>>> [email-masked]
>>>>>>>>> https://www.ietf.org/mailman/listinfo/status
>>>>>>>> _______________________________________________
>>>>>>>> status mailing list
>>>>>>>> [email-masked]
>>>>>>>> https://www.ietf.org/mailman/listinfo/status
>>>>>>>=20
>>>>>>>=20
>>>>>>> _______________________________________________
>>>>>>> status mailing list
>>>>>>> [email-masked]
>>>>>>> https://www.ietf.org/mailman/listinfo/status
>>>>>>=20
>>>>>> _______________________________________________
>>>>>> status mailing list
>>>>>> [email-masked]
>>>>>> https://www.ietf.org/mailman/listinfo/status
>>>>>=20
>>>>>=20
>>>>> _______________________________________________
>>>>> status mailing list
>>>>> [email-masked]
>>>>> https://www.ietf.org/mailman/listinfo/status
>>>>>=20
>>>>> =
___________________________________________________________________
>>>>> _ __ ___________________________________________________
>>>>>=20
>>>>> Ce message et ses pieces jointes peuvent contenir des informations
>>>>> confidentielles ou privilegiees et ne doivent donc pas etre
>>>>> diffuses, exploites ou copies sans autorisation. Si vous avez recu
>>>>> ce message par erreur, veuillez le signaler a l'expediteur et le =
detruire ainsi que les pieces jointes. Les messages electroniques etant =
susceptibles d'alteration, Orange decline toute responsabilite si ce =
message a ete altere, deforme ou falsifie. Merci.
>>>>>=20
>>>>> This message and its attachments may contain confidential or
>>>>> privileged information that may be protected by law; they should =
not be distributed, used or copied without authorisation.
>>>>> If you have received this email in error, please notify the sender =
and delete this message and its attachments.
>>>>> As emails may be altered, Orange is not liable for messages that =
have been modified, changed or falsified.
>>>>> Thank you.
>>>>>=20
>>>>> _______________________________________________
>>>>> status mailing list
>>>>> [email-masked]
>>>>> https://www.ietf.org/mailman/listinfo/status
>>>>=20
>>>> =
____________________________________________________________________
>>>> _ ____________________________________________________
>>>>=20
>>>> Ce message et ses pieces jointes peuvent contenir des informations
>>>> confidentielles ou privilegiees et ne doivent donc pas etre
>>>> diffuses, exploites ou copies sans autorisation. Si vous avez recu
>>>> ce message par erreur, veuillez le signaler a l'expediteur et le =
detruire ainsi que les pieces jointes. Les messages electroniques etant =
susceptibles d'alteration, Orange decline toute responsabilite si ce =
message a ete altere, deforme ou falsifie. Merci.
>>>>=20
>>>> This message and its attachments may contain confidential or
>>>> privileged information that may be protected by law; they should =
not be distributed, used or copied without authorisation.
>>>> If you have received this email in error, please notify the sender =
and delete this message and its attachments.
>>>> As emails may be altered, Orange is not liable for messages that =
have been modified, changed or falsified.
>>>> Thank you.
>>>>=20
>>>> _______________________________________________
>>>> status mailing list
>>>> [email-masked]
>>>> https://www.ietf.org/mailman/listinfo/status
>>>> _______________________________________________
>>>> status mailing list
>>>> [email-masked]
>>>> https://www.ietf.org/mailman/listinfo/status
>>>>=20
>>>=20
>>> --
>>>=20
>>>=20
>>> Loa Andersson                        email: [email-masked]
>>> Senior MPLS Expert                          [email-masked]
>>> Huawei Technologies (consultant)     phone: +46 739 81 21 64
>>> _______________________________________________
>>> status mailing list
>>> [email-masked]
>>> https://www.ietf.org/mailman/listinfo/status
>>>=20
>>>=20
>>=20
>>=20
>> _______________________________________________
>> status mailing list
>> [email-masked]
>> https://www.ietf.org/mailman/listinfo/status
>>=20
>> =
______________________________________________________________________
>> ___________________________________________________
>>=20
>> Ce message et ses pieces jointes peuvent contenir des informations
>> confidentielles ou privilegiees et ne doivent donc pas etre diffuses,
>> exploites ou copies sans autorisation. Si vous avez recu ce message
>> par erreur, veuillez le signaler a l'expediteur et le detruire ainsi =
que les pieces jointes. Les messages electroniques etant susceptibles =
d'alteration, Orange decline toute responsabilite si ce message a ete =
altere, deforme ou falsifie. Merci.
>>=20
>> This message and its attachments may contain confidential or
>> privileged information that may be protected by law; they should not =
be distributed, used or copied without authorisation.
>> If you have received this email in error, please notify the sender =
and delete this message and its attachments.
>> As emails may be altered, Orange is not liable for messages that have =
been modified, changed or falsified.
>> Thank you.
>>=20
>>=20
>>=20
>=20
>=20
> _______________________________________________
> status mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/status
>=20
>=20

From: Rob Shakir <[email-masked]>
Date: Mon, 9 Sep 2013 08:24:59 +0000
To: Hannes Gredler <[email-masked]>
Cc: [email-masked], "[email-masked]" <[email-masked]>
Subject: Re: [Status] Summary of STATUS BOF and the next steps

Hannes,

In-line as rjs>.

On 6 Sep 2013, at 16:27, Hannes Gredler <[email-masked]> wrote:

> hi stephane,
>=20
> here is a revised draft charter as per your comments.
>=20
> ---
>=20
> <Name-TBD> domain contains a set of routers with the following
> characteristics:
>=20
> - They form a connected network
> - They can forward traffic through any path within the network using
>  shortest path, or any other (e.g., an explicit) path
> - They share a common trust model. In this model, any router within
>  the domain can specify a path between itself and any other router
>  in the domain. It may then send any packet that passes through it
>  through any path that it has specified and that is conform to the
>  security rules. Downstream routers along the path within the =
<Name-TBD>
>  domain forward the packet as specified by the router at the head-end
>  of the path.
>=20
> The <Name-TBD> working group is chartered for the following ordered
> list of work items:
>=20
> - The first goal of the WG is to identify use-cases.
> - The WG will then define the architecture framework associated with
>  the security considerations. The architecture framework and security
>  considerations must address the relations between domains (inter =
domain).

rjs> It seems a little odd to me that we would identify that there are =
inter-domain issues to solve when there is no suggested use case that =
seemed to relate to this as a requirement. Any extensions of the =
technology developed within the WG to be inter-domain can be for future =
study.

> - Having identified use-cases, architecture and security, the WG will
>  identify gaps between currently available technologies and use-case
>  requirements.
> - The WG will then define requirements for extensions to existing
>  protocols or new protocols that address gaps that are identified.
> - The WG will first focus on the intra-domain forwarding definition.
>=20
> Protocol work may be carried out in this working group or in other
> working groups responsible for the protocols, in coordination with
> this WG, and in agreement with the WG chairs and responsible ADs.
> However, no protocol work will be adopted by a working group to
> address the identified use-cases until the requirements document
> motivating the protocol work has been sent to the IESG for
> publication as an RFC.

rjs> I do not see the need to place this restriction on the WG -- often =
we can shape and re-discuss requirements as we work through the details =
of solutions, based on the practicality of realising particular =
functions, or the complexity of supporting particular capabilities. =
Since we do not have this restriction in other WGs, I'm not clear that =
we need it defined here?

Kind regards,
r.

>=20
> ---
>=20
> /hannes
>=20
> On Sep 4, 2013, at 10:02 AM, <[email-masked]> =
<[email-masked]> wrote:
>=20
>> Hannes,
>>=20
>> In case, we are using only directed forwarding (adjacency segment), =
could we still talk about tunneling ? (it's a very very small tunnel)
>> Moreover talking about "stacking" is really dataplane agnostic (MPLS) =
...
>>=20
>> In the proposed segment routing architectural concepts, segments are =
at the same "level" and pointer moves on the segment list, then the MPLS =
instantiation is performing this using stacking ...
>>=20
>> IMHO, if we use "Stacked Tunnels", we already talk about a chosen =
solution and it's closing the door to something else  ...
>>=20
>> Finally, about the "routing" word, routing is essentially a "forward" =
action which may limit the scope of what we can do by using a segment =
list. Actions associated with a segment could be something else than =
forwarding.
>>=20
>> Do we want in the charter to limit the scope to routing actions ?
>>=20
>> I have no solution today to propose for the naming, but I completely =
agree with Loa, to first focus on working on the charter, and define a =
clear scope of the work and then the name will be easier to find.
>>=20
>> Regarding your charter proposal :
>>=20
>> --------
>>=20
>> - They form a connected network
>>       [SLI] InterAS case must be included, but the WG can go step by =
step and first release intraAS, and then doing interAS (in relation with =
IDR ??).
>>=20
>> - They can forward traffic through the shortest paths or paths other =
than the shortest (the latter called explicitly routed paths, or =
explicit paths)
>>       [SLI] There is something else between SPT and Explicit path, =
you can define other algorithms than SPT to define a path, and it's not =
explicit path. Moreover I come back to my comment, on do we want to =
limit the scope to routing ? I would say no.
>>=20
>> - They share a common trust model. In this model, any router within =
the ERD can specify an explicit path between itself and any other router =
in the ERD. It can then send any packet that passes through it through =
any path that it has specified.
>>       [SLI] Security considerations may have to be addressed in the =
charter , especially for the interAS case (trust yes, but not sure =
access to everything may not be good)
>>=20
>> Downstream routers within the ERD forward the packet as specified by =
the router at the head-end of the path.
>> [SLI] Yes, but any router in the middle may be able to change the end =
to end explicit path.
>>=20
>>=20
>>=20
>> - The first goal of the STER WG is to identify use-cases for ERDs.
>> - Having identified use-cases, the WG will identify gaps between =
currently available technologies and use-case requirements.
>> - The WG will then define requirements for extensions to existing =
protocols or new protocols that address gaps that are identified.
>>=20
>> [SLI] Agree, I would add :
>> - defining the architecture framework
>> - analysing the security considerisations
>>=20
>>=20
>> ---------
>>=20
>>=20
>> Here would be my proposal to extend yours :
>>=20
>> A <named to be defined> domain contains a set of routers with the =
following characteristics:
>>=20
>> - They form a connected network
>> - They can forward traffic through any path within the network using =
shortest path, non shortest path or explicit path
>> - They may provide other types of services than forwarding and they =
can enforce service actions in the path.
>> - They share a common trust model. In this model, any router within =
the domain can specify a path between itself and any other router in the =
domain. It may then send any packet that passes through it through any =
path that it has specified and that is conform to the security rules. =
Downstream routers within the ERD forward the packet as specified by the =
router at the head-end of the path.
>>=20
>> The <name> working group is chartered for the following ordered list =
of work items:
>>=20
>> - The first goal of the WG is to identify use-cases.
>> - The WG will then define the architecture framework associated with =
the security considerations. The architecture framework and security =
considerations must address the relations between domains (interdomain).
>> - Having identified use-cases, architecture and security, the WG will =
identify gaps between currently available technologies and use-case =
requirements.
>> - The WG will then define requirements for extensions to existing =
protocols or new protocols that address gaps that are identified.
>> - The WG will first focus on the intra-domain forwarding definition.
>>=20
>> Protocol work may be carried out in this working group or in other =
working groups responsible for the protocols, in coordination with this =
WG, and in agreement with the WG chairs and responsible ADs. However, no =
protocol work will be adopted by a working group to address the ERD =
use-cases until the requirements document motivating the protocol work =
has been sent to the IESG for publication as an RFC.
>>=20
>> -----Message d'origine-----
>> De : [email-masked] [mailto:[email-masked]] De la =
part de Hannes Gredler
>> Envoy=E9 : mardi 3 septembre 2013 18:31
>> =C0 : Loa Andersson
>> Cc : [email-masked]
>> Objet : Re: [Status] Summary of STATUS BOF and the next steps
>>=20
>> good point - what about this charter proposal ?
>>=20
>> ---
>>=20
>> Stacked Tunnels for Explicit Routing (STER) =
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
>>=20
>> A explicit routing domain (ERD) contains a set of routers with the =
following characteristics:
>>=20
>> - They form a connected network
>> - They can forward traffic through the shortest paths or paths other =
than the shortest (the latter called explicitly routed paths, or =
explicit paths)
>> - They share a common trust model. In this model, any router within =
the ERD can specify an explicit path between itself and any other router =
in the ERD. It can then send any packet that passes through it through =
any path that it has specified. Downstream routers within the ERD =
forward the packet as specified by the router at the head-end of the =
path.
>>=20
>> The STER working group is chartered for the following ordered list of =
work items:
>>=20
>> - The first goal of the STER WG is to identify use-cases for ERDs.
>> - Having identified use-cases, the WG will identify gaps between =
currently available technologies and use-case requirements.
>> - The WG will then define requirements for extensions to existing =
protocols or new protocols that address gaps that are identified.
>>=20
>> Protocol work may be carried out in this working group or in other =
working groups responsible for the protocols, in coordination with this =
WG, and in agreement with the WG chairs and responsible ADs. However, no =
protocol work will be adopted by a working group to address the ERD =
use-cases until the requirements document motivating the protocol work =
has been sent to the IESG for publication as an RFC.
>>=20
>> ---
>>=20
>> <flame suit on>
>>=20
>> /hannes
>>=20
>>=20
>> On Sep 3, 2013, at 5:31 PM, Loa Andersson wrote:
>>=20
>>> Folks,
>>>=20
>>> Excuse me if I'm slightly out of the loop, but so far I have not =
seen
>>> a charter proposal, if there is one please point me to it.
>>>=20
>>> It seems a bit odd to put the cart (what the wg should do) before =
the
>>> horse (wg name). If we drill down the the charter first the wg name
>>> might be easier to figure out.
>>>=20
>>> /Loa
>>>=20
>>> PS
>>> OK I understand that the horse and cart analogy limps a  bit :).
>>>=20
>>>=20
>>>=20
>>> On 2013-09-03 17:22, AshwoodsmithPeter wrote:
>>>> " If the WG charter is limited to source routing, how will we =
handle the "non source routing" use cases of segment routing ? In =
another working group ? So we will go back to the WG synchronization =
issue that has been raised for this technology ..."
>>>>=20
>>>> That's why I suggested SRV2. We are revisiting source routing with =
new concepts. More generic number/action behavior.
>>>>=20
>>>> Peter
>>>>=20
>>>> -----Original Message-----
>>>> From: [email-masked] [mailto:[email-masked]] On
>>>> Behalf Of [email-masked]
>>>> Sent: Tuesday, September 03, 2013 10:43 AM
>>>> To: AshwoodsmithPeter
>>>> Cc: [email-masked]
>>>> Subject: Re: [Status] Summary of STATUS BOF and the next steps
>>>>=20
>>>>=20
>>>> There was a misunderstanding in my small comment :) so I will =
explain more :
>>>>=20
>>>> In segment routing, you have more than basic source routing : =
segment routing is just associate a segment number to an action and then =
combine segment as you want, yes you can do source routing, but you also =
can do more.
>>>>=20
>>>> In the other hand, I completely agree with your statement that =
source
>>>> routing is generic and dataplane agnostic, as segment routing is =
...
>>>> (segment routing is not a new dataplane ...)
>>>>=20
>>>> Now the definition of the WG naming must be inline with the charter
>>>> that will be defined ... (draft today)
>>>>=20
>>>> Based on the already existing consensus (at least for MPLS =
dataplane) brought up during Berlin STATUS BOF meeting, segment routing =
sounds to be a good target candidate.
>>>>=20
>>>> So now, do we want to do more in the WG charter than just make =
progressing segment routing architecture and uses cases document and =
ensure coordination for the standardization of this technology ?
>>>>=20
>>>> Do we want to standardize other technologies in this WG ? I don't =
think so, based on Stewart's conclusion email from the BOF :"A new WG =
focused solely on SR therefore needs to be create"
>>>>=20
>>>> If the WG charter is limited to source routing, how will we handle =
the "non source routing" use cases of segment routing ? In another =
working group ? So we will go back to the WG synchronization issue that =
has been raised for this technology ...
>>>>=20
>>>> If the WG is focused on SR, let's use a name in relation with SR.
>>>>=20
>>>> Feedback ?
>>>>=20
>>>>=20
>>>> Stephane
>>>>=20
>>>>=20
>>>> -----Message d'origine-----
>>>> De : AshwoodsmithPeter [mailto:[email-masked]]
>>>> Envoy=E9 : mardi 3 septembre 2013 15:27 =C0 : LITKOWSKI Stephane =
DTF/DERX
>>>> Cc : John E Drake; Mark Townsley; Victor Kuarsingh; Roberta =
Maglione
>>>> (robmgl); John G. Scudder; Adrian Farrel; Alvaro Retana (aretana);
>>>> [email-masked]; Stewart Bryant (stbryant) Objet : Re: [Status]
>>>> Summary of STATUS BOF and the next steps
>>>>=20
>>>> The term "source routing" has been around for a very long time and =
is data path agnostic. Its also the term used in the literature etc so =
my preference is to stick with this existing well known and data path =
agnostic term.
>>>>=20
>>>> Peter
>>>>=20
>>>> On Sep 3, 2013, at 9:07 AM, "[email-masked]" =
<[email-masked]> wrote:
>>>>=20
>>>>> Hi,
>>>>>=20
>>>>> "Source routing" is just a subcase of segment routing ... as it is =
for IP routing ...
>>>>>=20
>>>>> Stephane
>>>>>=20
>>>>>=20
>>>>> -----Message d'origine-----
>>>>> De : [email-masked] [mailto:[email-masked]] De =
la
>>>>> part de John E Drake Envoy=E9 : mardi 3 septembre 2013 15:02 =C0 : =
Mark
>>>>> Townsley; Victor Kuarsingh Cc : Roberta Maglione (robmgl); John G.
>>>>> Scudder; Alvaro Retana (aretana); Adrian Farrel; [email-masked];
>>>>> Stewart Bryant (stbryant) Objet : Re: [Status] Summary of STATUS =
BOF
>>>>> and the next steps
>>>>>=20
>>>>> Hi,
>>>>>=20
>>>>> What is this 'segment routing' silliness?  The correct term is =
'source routing'.
>>>>>=20
>>>>> Yours Irrespectively,
>>>>>=20
>>>>> John
>>>>>=20
>>>>>> -----Original Message-----
>>>>>> From: [email-masked] [mailto:[email-masked]] On
>>>>>> Behalf Of Mark Townsley
>>>>>> Sent: Sunday, September 01, 2013 10:08 AM
>>>>>> To: Victor Kuarsingh
>>>>>> Cc: Roberta Maglione (robmgl); John G. Scudder; Adrian Farrel;
>>>>>> Alvaro Retana (aretana); [email-masked]; Stewart Bryant =
(stbryant)
>>>>>> Subject: Re: [Status] Summary of STATUS BOF and the next steps
>>>>>>=20
>>>>>>=20
>>>>>> On Sep 1, 2013, at 5:38 PM, Victor Kuarsingh wrote:
>>>>>>=20
>>>>>>> All,
>>>>>>>=20
>>>>>>> I would also favour "Segment Routing WG" as well.
>>>>>>>=20
>>>>>>> I note this since attempting to come up with an all encompassing
>>>>>>> acronym will be difficult and Segment Routing is generic enough =
to
>>>>>>> associate to multiple functions.
>>>>>>=20
>>>>>> Then we can just use "segroute" for the short name. WGs do not =
have
>>>>>> to have acronyms, but they do need to have an 8-char limited =
short
>>>>>> name for the various automated tools not to break.
>>>>>>=20
>>>>>> - Mark
>>>>>>=20
>>>>>>>=20
>>>>>>> Regards,
>>>>>>>=20
>>>>>>> Victor K
>>>>>>>=20
>>>>>>>=20
>>>>>>>=20
>>>>>>> On 2013-08-31 6:51 PM, "Roberta Maglione (robmgl)"
>>>>>>> <[email-masked]>
>>>>>>> wrote:
>>>>>>>=20
>>>>>>>> +1 for Segment Routing WG
>>>>>>>>=20
>>>>>>>> Roberta
>>>>>>>>=20
>>>>>>>> Sent from my iPad
>>>>>>>>=20
>>>>>>>> On 2013-08-30, at 2:55 PM, "Alvaro Retana (aretana)"
>>>>>>>> <[email-masked]>
>>>>>>>> wrote:
>>>>>>>>=20
>>>>>>>>> Segment Routing WG
>>>>>>>>>=20
>>>>>>>>> Sent from my iPhone
>>>>>>>>>=20
>>>>>>>>> On Aug 30, 2013, at 1:39 PM, "Stewart Bryant (stbryant)"
>>>>>>>>> <[email-masked]> wrote:
>>>>>>>>>=20
>>>>>>>>>> The second task, which hopefully should be relatively easy, =
is
>>>>>>>>>> to find a better working name for the WG, since it has been =
put
>>>>>>>>>> to me a number of times that STATUS is going to be confusing =
in
>>>>>>>>>> text and a difficult search term.
>>>>>>>>> _______________________________________________
>>>>>>>>> status mailing list
>>>>>>>>> [email-masked]
>>>>>>>>> https://www.ietf.org/mailman/listinfo/status
>>>>>>>> _______________________________________________
>>>>>>>> status mailing list
>>>>>>>> [email-masked]
>>>>>>>> https://www.ietf.org/mailman/listinfo/status
>>>>>>>=20
>>>>>>>=20
>>>>>>> _______________________________________________
>>>>>>> status mailing list
>>>>>>> [email-masked]
>>>>>>> https://www.ietf.org/mailman/listinfo/status
>>>>>>=20
>>>>>> _______________________________________________
>>>>>> status mailing list
>>>>>> [email-masked]
>>>>>> https://www.ietf.org/mailman/listinfo/status
>>>>>=20
>>>>>=20
>>>>> _______________________________________________
>>>>> status mailing list
>>>>> [email-masked]
>>>>> https://www.ietf.org/mailman/listinfo/status
>>>>>=20
>>>>> =
____________________________________________________________________
>>>>> __ ___________________________________________________
>>>>>=20
>>>>> Ce message et ses pieces jointes peuvent contenir des informations
>>>>> confidentielles ou privilegiees et ne doivent donc pas etre
>>>>> diffuses, exploites ou copies sans autorisation. Si vous avez recu
>>>>> ce message par erreur, veuillez le signaler a l'expediteur et le =
detruire ainsi que les pieces jointes. Les messages electroniques etant =
susceptibles d'alteration, Orange decline toute responsabilite si ce =
message a ete altere, deforme ou falsifie. Merci.
>>>>>=20
>>>>> This message and its attachments may contain confidential or
>>>>> privileged information that may be protected by law; they should =
not be distributed, used or copied without authorisation.
>>>>> If you have received this email in error, please notify the sender =
and delete this message and its attachments.
>>>>> As emails may be altered, Orange is not liable for messages that =
have been modified, changed or falsified.
>>>>> Thank you.
>>>>>=20
>>>>> _______________________________________________
>>>>> status mailing list
>>>>> [email-masked]
>>>>> https://www.ietf.org/mailman/listinfo/status
>>>>=20
>>>> =
_____________________________________________________________________
>>>> ____________________________________________________
>>>>=20
>>>> Ce message et ses pieces jointes peuvent contenir des informations
>>>> confidentielles ou privilegiees et ne doivent donc pas etre =
diffuses,
>>>> exploites ou copies sans autorisation. Si vous avez recu ce message
>>>> par erreur, veuillez le signaler a l'expediteur et le detruire =
ainsi que les pieces jointes. Les messages electroniques etant =
susceptibles d'alteration, Orange decline toute responsabilite si ce =
message a ete altere, deforme ou falsifie. Merci.
>>>>=20
>>>> This message and its attachments may contain confidential or
>>>> privileged information that may be protected by law; they should =
not be distributed, used or copied without authorisation.
>>>> If you have received this email in error, please notify the sender =
and delete this message and its attachments.
>>>> As emails may be altered, Orange is not liable for messages that =
have been modified, changed or falsified.
>>>> Thank you.
>>>>=20
>>>> _______________________________________________
>>>> status mailing list
>>>> [email-masked]
>>>> https://www.ietf.org/mailman/listinfo/status
>>>> _______________________________________________
>>>> status mailing list
>>>> [email-masked]
>>>> https://www.ietf.org/mailman/listinfo/status
>>>>=20
>>>=20
>>> --
>>>=20
>>>=20
>>> Loa Andersson                        email: [email-masked]
>>> Senior MPLS Expert                          [email-masked]
>>> Huawei Technologies (consultant)     phone: +46 739 81 21 64
>>> _______________________________________________
>>> status mailing list
>>> [email-masked]
>>> https://www.ietf.org/mailman/listinfo/status
>>>=20
>>>=20
>>=20
>>=20
>> _______________________________________________
>> status mailing list
>> [email-masked]
>> https://www.ietf.org/mailman/listinfo/status
>>=20
>> =
__________________________________________________________________________=
_______________________________________________
>>=20
>> Ce message et ses pieces jointes peuvent contenir des informations =
confidentielles ou privilegiees et ne doivent donc
>> pas etre diffuses, exploites ou copies sans autorisation. Si vous =
avez recu ce message par erreur, veuillez le signaler
>> a l'expediteur et le detruire ainsi que les pieces jointes. Les =
messages electroniques etant susceptibles d'alteration,
>> Orange decline toute responsabilite si ce message a ete altere, =
deforme ou falsifie. Merci.
>>=20
>> This message and its attachments may contain confidential or =
privileged information that may be protected by law;
>> they should not be distributed, used or copied without authorisation.
>> If you have received this email in error, please notify the sender =
and delete this message and its attachments.
>> As emails may be altered, Orange is not liable for messages that have =
been modified, changed or falsified.
>> Thank you.
>>=20
>>=20
>>=20
>=20
>=20
> _______________________________________________
> status mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/status

From: <[email-masked]>
To: <[email-masked]>
Date: Mon, 9 Sep 2013 09:08:42 +0200
Accept-Language: en-US, de-DE
acceptlanguage: en-US, de-DE
Cc: [email-masked]
Subject: Re: [Status] Summary of STATUS BOF and the next steps

Hannes,

I'm worried about the proposal below, which seem to miss the most important=
 points of SR (I call it that):

- SR allows to reduce complexity by getting rid of RSVP TE and LDP. Apart f=
rom OAM I
  don't think SR is supposed to fill gaps.
- I don't fully understand why the SR work must address inter domain relati=
ons, if
  it is supposed to be primarily chartered with intra domain control plane =
issues.
- My take is, that intra-domain MPLS forwarding will remain as is initially=
 with SR.
  Your last bullet point means todays MPLS is out of scope, as no forwardin=
g
  definitions need to be changed?
- We agreed not work on protocols within the SR WG. Why has that been chang=
ed?

Regards,

Ruediger

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

The <Name-TBD> working group is chartered for the following ordered list of=
 work items:

- The first goal of the WG is to identify use-cases.
- The WG will then define the architecture framework associated with
  the security considerations. The architecture framework and security
  considerations must address the relations between domains (interdomain).
- Having identified use-cases, architecture and security, the WG will
  identify gaps between currently available technologies and use-case
  requirements.
- The WG will then define requirements for extensions to existing
  protocols or new protocols that address gaps that are identified.
- The WG will first focus on the intra-domain forwarding definition.

Protocol work may be carried out in this working group or in other working =
groups responsible for the protocols, in coordination with this WG, and in =
agreement with the WG chairs and responsible ADs.
However, no protocol work will be adopted by a working group to address the=
 identified use-cases until the requirements document motivating the protoc=
ol work has been sent to the IESG for publication as an RFC.

---

/hannes

On Sep 4, 2013, at 10:02 AM, <[email-masked]> <stephane.litk=
[email-masked]> wrote:

> Hannes,
>
> In case, we are using only directed forwarding (adjacency segment),
> could we still talk about tunneling ? (it's a very very small tunnel) Mor=
eover talking about "stacking" is really dataplane agnostic (MPLS) ...
>
> In the proposed segment routing architectural concepts, segments are at t=
he same "level" and pointer moves on the segment list, then the MPLS instan=
tiation is performing this using stacking ...
>
> IMHO, if we use "Stacked Tunnels", we already talk about a chosen solutio=
n and it's closing the door to something else  ...
>
> Finally, about the "routing" word, routing is essentially a "forward" act=
ion which may limit the scope of what we can do by using a segment list. Ac=
tions associated with a segment could be something else than forwarding.
>
> Do we want in the charter to limit the scope to routing actions ?
>
> I have no solution today to propose for the naming, but I completely agre=
e with Loa, to first focus on working on the charter, and define a clear sc=
ope of the work and then the name will be easier to find.
>
> Regarding your charter proposal :
>
> --------
>
> - They form a connected network
>        [SLI] InterAS case must be included, but the WG can go step by ste=
p and first release intraAS, and then doing interAS (in relation with IDR ?=
?).
>
> - They can forward traffic through the shortest paths or paths other than=
 the shortest (the latter called explicitly routed paths, or explicit paths=
)
>        [SLI] There is something else between SPT and Explicit path, you c=
an define other algorithms than SPT to define a path, and it's not explicit=
 path. Moreover I come back to my comment, on do we want to limit the scope=
 to routing ? I would say no.
>
> - They share a common trust model. In this model, any router within the E=
RD can specify an explicit path between itself and any other router in the =
ERD. It can then send any packet that passes through it through any path th=
at it has specified.
>        [SLI] Security considerations may have to be addressed in the
> charter , especially for the interAS case (trust yes, but not sure
> access to everything may not be good)
>
> Downstream routers within the ERD forward the packet as specified by the =
router at the head-end of the path.
> [SLI] Yes, but any router in the middle may be able to change the end to =
end explicit path.
>
>
>
> - The first goal of the STER WG is to identify use-cases for ERDs.
> - Having identified use-cases, the WG will identify gaps between currentl=
y available technologies and use-case requirements.
> - The WG will then define requirements for extensions to existing protoco=
ls or new protocols that address gaps that are identified.
>
> [SLI] Agree, I would add :
> - defining the architecture framework
> - analysing the security considerisations
>
>
> ---------
>
>
> Here would be my proposal to extend yours :
>
> A <named to be defined> domain contains a set of routers with the followi=
ng characteristics:
>
> - They form a connected network
> - They can forward traffic through any path within the network using
> shortest path, non shortest path or explicit path
> - They may provide other types of services than forwarding and they can e=
nforce service actions in the path.
> - They share a common trust model. In this model, any router within the d=
omain can specify a path between itself and any other router in the domain.=
 It may then send any packet that passes through it through any path that i=
t has specified and that is conform to the security rules. Downstream route=
rs within the ERD forward the packet as specified by the router at the head=
-end of the path.
>
> The <name> working group is chartered for the following ordered list of w=
ork items:
>
> - The first goal of the WG is to identify use-cases.
> - The WG will then define the architecture framework associated with the =
security considerations. The architecture framework and security considerat=
ions must address the relations between domains (interdomain).
> - Having identified use-cases, architecture and security, the WG will ide=
ntify gaps between currently available technologies and use-case requiremen=
ts.
> - The WG will then define requirements for extensions to existing protoco=
ls or new protocols that address gaps that are identified.
> - The WG will first focus on the intra-domain forwarding definition.
>
> Protocol work may be carried out in this working group or in other workin=
g groups responsible for the protocols, in coordination with this WG, and i=
n agreement with the WG chairs and responsible ADs. However, no protocol wo=
rk will be adopted by a working group to address the ERD use-cases until th=
e requirements document motivating the protocol work has been sent to the I=
ESG for publication as an RFC.
>
> -----Message d'origine-----
> De : [email-masked] [mailto:[email-masked]] De la
> part de Hannes Gredler Envoy=E9 : mardi 3 septembre 2013 18:31 =C0 : Loa
> Andersson Cc : [email-masked] Objet : Re: [Status] Summary of STATUS
> BOF and the next steps
>
> good point - what about this charter proposal ?
>
> ---
>
> Stacked Tunnels for Explicit Routing (STER)
> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
>
> A explicit routing domain (ERD) contains a set of routers with the follow=
ing characteristics:
>
> - They form a connected network
> - They can forward traffic through the shortest paths or paths other
> than the shortest (the latter called explicitly routed paths, or
> explicit paths)
> - They share a common trust model. In this model, any router within the E=
RD can specify an explicit path between itself and any other router in the =
ERD. It can then send any packet that passes through it through any path th=
at it has specified. Downstream routers within the ERD forward the packet a=
s specified by the router at the head-end of the path.
>
> The STER working group is chartered for the following ordered list of wor=
k items:
>
> - The first goal of the STER WG is to identify use-cases for ERDs.
> - Having identified use-cases, the WG will identify gaps between currentl=
y available technologies and use-case requirements.
> - The WG will then define requirements for extensions to existing protoco=
ls or new protocols that address gaps that are identified.
>
> Protocol work may be carried out in this working group or in other workin=
g groups responsible for the protocols, in coordination with this WG, and i=
n agreement with the WG chairs and responsible ADs. However, no protocol wo=
rk will be adopted by a working group to address the ERD use-cases until th=
e requirements document motivating the protocol work has been sent to the I=
ESG for publication as an RFC.
>
> ---
>
> <flame suit on>
>
> /hannes
>
>
> On Sep 3, 2013, at 5:31 PM, Loa Andersson wrote:
>
>> Folks,
>>
>> Excuse me if I'm slightly out of the loop, but so far I have not seen
>> a charter proposal, if there is one please point me to it.
>>
>> It seems a bit odd to put the cart (what the wg should do) before the
>> horse (wg name). If we drill down the the charter first the wg name
>> might be easier to figure out.
>>
>> /Loa
>>
>> PS
>> OK I understand that the horse and cart analogy limps a  bit :).
>>
>>
>>
>> On 2013-09-03 17:22, AshwoodsmithPeter wrote:
>>> " If the WG charter is limited to source routing, how will we handle th=
e "non source routing" use cases of segment routing ? In another working gr=
oup ? So we will go back to the WG synchronization issue that has been rais=
ed for this technology ..."
>>>
>>> That's why I suggested SRV2. We are revisiting source routing with new =
concepts. More generic number/action behavior.
>>>
>>> Peter
>>>
>>> -----Original Message-----
>>> From: [email-masked] [mailto:[email-masked]] On
>>> Behalf Of [email-masked]
>>> Sent: Tuesday, September 03, 2013 10:43 AM
>>> To: AshwoodsmithPeter
>>> Cc: [email-masked]
>>> Subject: Re: [Status] Summary of STATUS BOF and the next steps
>>>
>>>
>>> There was a misunderstanding in my small comment :) so I will explain m=
ore :
>>>
>>> In segment routing, you have more than basic source routing : segment r=
outing is just associate a segment number to an action and then combine seg=
ment as you want, yes you can do source routing, but you also can do more.
>>>
>>> In the other hand, I completely agree with your statement that
>>> source routing is generic and dataplane agnostic, as segment routing is=
 ...
>>> (segment routing is not a new dataplane ...)
>>>
>>> Now the definition of the WG naming must be inline with the charter
>>> that will be defined ... (draft today)
>>>
>>> Based on the already existing consensus (at least for MPLS dataplane) b=
rought up during Berlin STATUS BOF meeting, segment routing sounds to be a =
good target candidate.
>>>
>>> So now, do we want to do more in the WG charter than just make progress=
ing segment routing architecture and uses cases document and ensure coordin=
ation for the standardization of this technology ?
>>>
>>> Do we want to standardize other technologies in this WG ? I don't think=
 so, based on Stewart's conclusion email from the BOF :"A new WG focused so=
lely on SR therefore needs to be create"
>>>
>>> If the WG charter is limited to source routing, how will we handle the =
"non source routing" use cases of segment routing ? In another working grou=
p ? So we will go back to the WG synchronization issue that has been raised=
 for this technology ...
>>>
>>> If the WG is focused on SR, let's use a name in relation with SR.
>>>
>>> Feedback ?
>>>
>>>
>>> Stephane
>>>
>>>
>>> -----Message d'origine-----
>>> De : AshwoodsmithPeter [mailto:[email-masked]]
>>> Envoy=E9 : mardi 3 septembre 2013 15:27 =C0 : LITKOWSKI Stephane
>>> DTF/DERX Cc : John E Drake; Mark Townsley; Victor Kuarsingh; Roberta
>>> Maglione (robmgl); John G. Scudder; Adrian Farrel; Alvaro Retana
>>> (aretana); [email-masked]; Stewart Bryant (stbryant) Objet : Re:
>>> [Status] Summary of STATUS BOF and the next steps
>>>
>>> The term "source routing" has been around for a very long time and is d=
ata path agnostic. Its also the term used in the literature etc so my prefe=
rence is to stick with this existing well known and data path agnostic term=
.
>>>
>>> Peter
>>>
>>> On Sep 3, 2013, at 9:07 AM, "[email-masked]" <stephane.l=
[email-masked]> wrote:
>>>
>>>> Hi,
>>>>
>>>> "Source routing" is just a subcase of segment routing ... as it is for=
 IP routing ...
>>>>
>>>> Stephane
>>>>
>>>>
>>>> -----Message d'origine-----
>>>> De : [email-masked] [mailto:[email-masked]] De la
>>>> part de John E Drake Envoy=E9 : mardi 3 septembre 2013 15:02 =C0 : Mar=
k
>>>> Townsley; Victor Kuarsingh Cc : Roberta Maglione (robmgl); John G.
>>>> Scudder; Alvaro Retana (aretana); Adrian Farrel; [email-masked];
>>>> Stewart Bryant (stbryant) Objet : Re: [Status] Summary of STATUS
>>>> BOF and the next steps
>>>>
>>>> Hi,
>>>>
>>>> What is this 'segment routing' silliness?  The correct term is 'source=
 routing'.
>>>>
>>>> Yours Irrespectively,
>>>>
>>>> John
>>>>
>>>>> -----Original Message-----
>>>>> From: [email-masked] [mailto:[email-masked]] On
>>>>> Behalf Of Mark Townsley
>>>>> Sent: Sunday, September 01, 2013 10:08 AM
>>>>> To: Victor Kuarsingh
>>>>> Cc: Roberta Maglione (robmgl); John G. Scudder; Adrian Farrel;
>>>>> Alvaro Retana (aretana); [email-masked]; Stewart Bryant
>>>>> (stbryant)
>>>>> Subject: Re: [Status] Summary of STATUS BOF and the next steps
>>>>>
>>>>>
>>>>> On Sep 1, 2013, at 5:38 PM, Victor Kuarsingh wrote:
>>>>>
>>>>>> All,
>>>>>>
>>>>>> I would also favour "Segment Routing WG" as well.
>>>>>>
>>>>>> I note this since attempting to come up with an all encompassing
>>>>>> acronym will be difficult and Segment Routing is generic enough
>>>>>> to associate to multiple functions.
>>>>>
>>>>> Then we can just use "segroute" for the short name. WGs do not
>>>>> have to have acronyms, but they do need to have an 8-char limited
>>>>> short name for the various automated tools not to break.
>>>>>
>>>>> - Mark
>>>>>
>>>>>>
>>>>>> Regards,
>>>>>>
>>>>>> Victor K
>>>>>>
>>>>>>
>>>>>>
>>>>>> On 2013-08-31 6:51 PM, "Roberta Maglione (robmgl)"
>>>>>> <[email-masked]>
>>>>>> wrote:
>>>>>>
>>>>>>> +1 for Segment Routing WG
>>>>>>>
>>>>>>> Roberta
>>>>>>>
>>>>>>> Sent from my iPad
>>>>>>>
>>>>>>> On 2013-08-30, at 2:55 PM, "Alvaro Retana (aretana)"
>>>>>>> <[email-masked]>
>>>>>>> wrote:
>>>>>>>
>>>>>>>> Segment Routing WG
>>>>>>>>
>>>>>>>> Sent from my iPhone
>>>>>>>>
>>>>>>>> On Aug 30, 2013, at 1:39 PM, "Stewart Bryant (stbryant)"
>>>>>>>> <[email-masked]> wrote:
>>>>>>>>
>>>>>>>>> The second task, which hopefully should be relatively easy, is
>>>>>>>>> to find a better working name for the WG, since it has been
>>>>>>>>> put to me a number of times that STATUS is going to be
>>>>>>>>> confusing in text and a difficult search term.
>>>>>>>> _______________________________________________
>>>>>>>> status mailing list
>>>>>>>> [email-masked]
>>>>>>>> https://www.ietf.org/mailman/listinfo/status
>>>>>>> _______________________________________________
>>>>>>> status mailing list
>>>>>>> [email-masked]
>>>>>>> https://www.ietf.org/mailman/listinfo/status
>>>>>>
>>>>>>
>>>>>> _______________________________________________
>>>>>> status mailing list
>>>>>> [email-masked]
>>>>>> https://www.ietf.org/mailman/listinfo/status
>>>>>
>>>>> _______________________________________________
>>>>> status mailing list
>>>>> [email-masked]
>>>>> https://www.ietf.org/mailman/listinfo/status
>>>>
>>>>
>>>> _______________________________________________
>>>> status mailing list
>>>> [email-masked]
>>>> https://www.ietf.org/mailman/listinfo/status
>>>>
>>>> ___________________________________________________________________
>>>> _ __ ___________________________________________________
>>>>
>>>> Ce message et ses pieces jointes peuvent contenir des informations
>>>> confidentielles ou privilegiees et ne doivent donc pas etre
>>>> diffuses, exploites ou copies sans autorisation. Si vous avez recu
>>>> ce message par erreur, veuillez le signaler a l'expediteur et le detru=
ire ainsi que les pieces jointes. Les messages electroniques etant suscepti=
bles d'alteration, Orange decline toute responsabilite si ce message a ete =
altere, deforme ou falsifie. Merci.
>>>>
>>>> This message and its attachments may contain confidential or
>>>> privileged information that may be protected by law; they should not b=
e distributed, used or copied without authorisation.
>>>> If you have received this email in error, please notify the sender and=
 delete this message and its attachments.
>>>> As emails may be altered, Orange is not liable for messages that have =
been modified, changed or falsified.
>>>> Thank you.
>>>>
>>>> _______________________________________________
>>>> status mailing list
>>>> [email-masked]
>>>> https://www.ietf.org/mailman/listinfo/status
>>>
>>> ____________________________________________________________________
>>> _ ____________________________________________________
>>>
>>> Ce message et ses pieces jointes peuvent contenir des informations
>>> confidentielles ou privilegiees et ne doivent donc pas etre
>>> diffuses, exploites ou copies sans autorisation. Si vous avez recu
>>> ce message par erreur, veuillez le signaler a l'expediteur et le detrui=
re ainsi que les pieces jointes. Les messages electroniques etant susceptib=
les d'alteration, Orange decline toute responsabilite si ce message a ete a=
ltere, deforme ou falsifie. Merci.
>>>
>>> This message and its attachments may contain confidential or
>>> privileged information that may be protected by law; they should not be=
 distributed, used or copied without authorisation.
>>> If you have received this email in error, please notify the sender and =
delete this message and its attachments.
>>> As emails may be altered, Orange is not liable for messages that have b=
een modified, changed or falsified.
>>> Thank you.
>>>
>>> _______________________________________________
>>> status mailing list
>>> [email-masked]
>>> https://www.ietf.org/mailman/listinfo/status
>>> _______________________________________________
>>> status mailing list
>>> [email-masked]
>>> https://www.ietf.org/mailman/listinfo/status
>>>
>>
>> --
>>
>>
>> Loa Andersson                        email: [email-masked]
>> Senior MPLS Expert                          [email-masked]
>> Huawei Technologies (consultant)     phone: +46 739 81 21 64
>> _______________________________________________
>> status mailing list
>> [email-masked]
>> https://www.ietf.org/mailman/listinfo/status
>>
>>
>
>
> _______________________________________________
> status mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/status
>
> ______________________________________________________________________
> ___________________________________________________
>
> Ce message et ses pieces jointes peuvent contenir des informations
> confidentielles ou privilegiees et ne doivent donc pas etre diffuses,
> exploites ou copies sans autorisation. Si vous avez recu ce message
> par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que =
les pieces jointes. Les messages electroniques etant susceptibles d'alterat=
ion, Orange decline toute responsabilite si ce message a ete altere, deform=
e ou falsifie. Merci.
>
> This message and its attachments may contain confidential or
> privileged information that may be protected by law; they should not be d=
istributed, used or copied without authorisation.
> If you have received this email in error, please notify the sender and de=
lete this message and its attachments.
> As emails may be altered, Orange is not liable for messages that have bee=
n modified, changed or falsified.
> Thank you.
>
>
>

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

From: Jeff Tantsura <[email-masked]>
To: "[email-masked]" <[email-masked]>
Date: Mon, 9 Sep 2013 06:56:32 +0000
Accept-Language: en-US
Cc: "[email-masked]" <[email-masked]>
Subject: Re: [Status] Proposed Charter

Hi,

Support, looks rather reasonable.

Cheers,
Jeff

>-----Urspr=FCngliche Nachricht-----
>Von: [email-masked] [mailto:[email-masked]] Im Auftrag
>von Stefano Previdi (sprevidi)
>Gesendet: Freitag, 6. September 2013 08:48
>An: [email-masked]
>Cc: Clarence Filsfils (cfilsfil)
>Betreff: [Status] Proposed Charter
>
>All,
>
>here follows a proposal for the charter.
>
>Thanks.
>s.
>
>
>-------------------------------------------------------------------
>Name: SEGROUTE (or SR, or whatever else)
>Charter:
>
>Introduction
>------------
>The following use cases:
>. Path computation based on awareness of utilization or performance
>  data, within both centralized and distributed environments, .
>Multi-topology (dual planes, disjoint trees), . Simplification and
>reduction of signaling components (scaling), . Combined application and
>network layer path specification, . Full coverage LFA-FRR, . Topology
>Aware OAM, . etc.
>
>have triggered work on the definition of new architecture and protocol
>extensions allowing to combine well known shortest path based routing
>paradigms with source/explicit routing methods. Some of these extensions
>have been implemented already.
>
>Objective
>---------
>Define an architecture where a node can steer a packet through a
>controlled set of instructions, called segments while maintaining
>per-explicit path state only at the ingress node.
>
>The instruction associated to a segment can be derived based on arbitrary
>mechanisms which may include:
>
>. Shortest path routing or explicit/source routing paradigms . Intra and
>inter domain path computation . Network or application layer . Network
>virtualization . Centralized or distributed path computation . Unicast or
>Multicast schemes . Others.
>
>The SEGROUTE architecture will support:
>
>. Tunnel and non-tunnel based paradigms
>. Multiple data-planes: MPLS and IPv6. The SEGROUTE control plane
>  should be independent (agnostic) to the data-planes.
>
>The WG will work on the definition of the architecture and protocol
>extensions. No new protocol specification is expected within this WG.
>No MPLS data-plane changes are expected either.
>
>Instead the standardization work should consist in extensions in well
>established protocols (ISIS, OSPF, BGP, PCEP, ...).
>
>It is expected that the SEGROUTE WG will help in the orchestration of
>protocol extensions specification with the existing IETF Working Groups
>(ISIS, OSPF, IDR, PCE, 6MAN, MPLS, ...).
>
>Documents
>---------
>The WG will produce the following documents:
>. Problem Statement
>. Requirements
>. Use Cases
>. Architecture
>. Interoperability Report
>
>The protocol extensions and data-plane instantiations will be handled in
>their respective WGs.
>_______________________________________________
>status mailing list
>[email-masked]
>https://www.ietf.org/mailman/listinfo/status

From: <[email-masked]>
To: <[email-masked]>
Date: Mon, 9 Sep 2013 08:53:00 +0200
Accept-Language: en-US, de-DE
acceptlanguage: en-US, de-DE
Cc: [email-masked]
Subject: Re: [Status] Proposed Charter

Stefano,

I support the draft agenda as suggested below.

Regards,

Ruediger

-----Urspr=FCngliche Nachricht-----
Von: [email-masked] [mailto:[email-masked]] Im Auftrag vo=
n Stefano Previdi (sprevidi)
Gesendet: Freitag, 6. September 2013 08:48
An: [email-masked]
Cc: Clarence Filsfils (cfilsfil)
Betreff: [Status] Proposed Charter

All,

here follows a proposal for the charter.

Thanks.
s.

-------------------------------------------------------------------
Name: SEGROUTE (or SR, or whatever else)
Charter:

Introduction
------------
The following use cases:
. Path computation based on awareness of utilization or performance
  data, within both centralized and distributed environments, . Multi-topol=
ogy (dual planes, disjoint trees), . Simplification and reduction of signal=
ing components (scaling), . Combined application and network layer path spe=
cification, . Full coverage LFA-FRR, . Topology Aware OAM, . etc.

have triggered work on the definition of new architecture and protocol exte=
nsions allowing to combine well known shortest path based routing paradigms=
 with source/explicit routing methods. Some of these extensions have been i=
mplemented already.

Objective
---------
Define an architecture where a node can steer a packet through a controlled=
 set of instructions, called segments while maintaining per-explicit path s=
tate only at the ingress node.

The instruction associated to a segment can be derived based on arbitrary m=
echanisms which may include:

. Shortest path routing or explicit/source routing paradigms . Intra and in=
ter domain path computation . Network or application layer . Network virtua=
lization . Centralized or distributed path computation . Unicast or Multica=
st schemes . Others.

The SEGROUTE architecture will support:

. Tunnel and non-tunnel based paradigms
. Multiple data-planes: MPLS and IPv6. The SEGROUTE control plane
  should be independent (agnostic) to the data-planes.

The WG will work on the definition of the architecture and protocol extensi=
ons. No new protocol specification is expected within this WG.
No MPLS data-plane changes are expected either.

Instead the standardization work should consist in extensions in well estab=
lished protocols (ISIS, OSPF, BGP, PCEP, ...).

It is expected that the SEGROUTE WG will help in the orchestration of proto=
col extensions specification with the existing IETF Working Groups (ISIS, O=
SPF, IDR, PCE, 6MAN, MPLS, ...).

Documents
---------
The WG will produce the following documents:
. Problem Statement
. Requirements
. Use Cases
. Architecture
. Interoperability Report

The protocol extensions and data-plane instantiations will be handled in th=
eir respective WGs.
_______________________________________________
status mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/status

Sender: [email-masked]
Date: Fri, 6 Sep 2013 18:52:39 +0200
From: Robert Raszuk <[email-masked]>
To: Hannes Gredler <[email-masked]>
Cc: [email-masked], "[email-masked]" <[email-masked]>
Subject: Re: [Status] Summary of STATUS BOF and the next steps

Hi,

> - Having identified use-cases, architecture and security, the WG will
>   identify gaps between currently available technologies and use-case
>  requirements.
>
> - The WG will then define requirements for extensions to existing
>   protocols or new protocols that address gaps that are identified.

So this effectively says that if there is a way in today's protocols
to accomplish use-cases - no matter how operationally and deployment
difficult this turns out to be in practice - there would be no gaps -
hence no hope for the operators to see any new protocol extensions
work to proceed.

I find those two sentences quoted above not acceptable.

Of course let's also observe that there is going to be clearly
difficulty - which we have already seen at the "BOF" - to evaluate
proposed use-cases and consider them as valid or not valid. Who will
be the judge and the jury - chairs ? ADs ? IESG ? Rough consensus ?

For the record .. I support charter sent to the list by Stefano Previdi.

Best,
R.

From: Hannes Gredler <[email-masked]>
Date: Fri, 6 Sep 2013 18:27:29 +0200
To: <[email-masked]>
Cc: "[email-masked]" <[email-masked]>
Subject: Re: [Status] Summary of STATUS BOF and the next steps

hi stephane,

here is a revised draft charter as per your comments.

---

<Name-TBD> domain contains a set of routers with the following
characteristics:

- They form a connected network
- They can forward traffic through any path within the network using
  shortest path, or any other (e.g., an explicit) path
- They share a common trust model. In this model, any router within
  the domain can specify a path between itself and any other router
  in the domain. It may then send any packet that passes through it
  through any path that it has specified and that is conform to the
  security rules. Downstream routers along the path within the =
<Name-TBD>
  domain forward the packet as specified by the router at the head-end
  of the path.

The <Name-TBD> working group is chartered for the following ordered
list of work items:

- The first goal of the WG is to identify use-cases.
- The WG will then define the architecture framework associated with
  the security considerations. The architecture framework and security
  considerations must address the relations between domains =
(interdomain).
- Having identified use-cases, architecture and security, the WG will
  identify gaps between currently available technologies and use-case
  requirements.
- The WG will then define requirements for extensions to existing
  protocols or new protocols that address gaps that are identified.
- The WG will first focus on the intra-domain forwarding definition.

Protocol work may be carried out in this working group or in other
working groups responsible for the protocols, in coordination with
this WG, and in agreement with the WG chairs and responsible ADs.
However, no protocol work will be adopted by a working group to
address the identified use-cases until the requirements document
motivating the protocol work has been sent to the IESG for
publication as an RFC.

---

/hannes

On Sep 4, 2013, at 10:02 AM, <[email-masked]> =
<[email-masked]> wrote:

> Hannes,
>=20
> In case, we are using only directed forwarding (adjacency segment), =
could we still talk about tunneling ? (it's a very very small tunnel)
> Moreover talking about "stacking" is really dataplane agnostic (MPLS) =
...
>=20
> In the proposed segment routing architectural concepts, segments are =
at the same "level" and pointer moves on the segment list, then the MPLS =
instantiation is performing this using stacking ...
>=20
> IMHO, if we use "Stacked Tunnels", we already talk about a chosen =
solution and it's closing the door to something else  ...
>=20
> Finally, about the "routing" word, routing is essentially a "forward" =
action which may limit the scope of what we can do by using a segment =
list. Actions associated with a segment could be something else than =
forwarding.
>=20
> Do we want in the charter to limit the scope to routing actions ?
>=20
> I have no solution today to propose for the naming, but I completely =
agree with Loa, to first focus on working on the charter, and define a =
clear scope of the work and then the name will be easier to find.
>=20
> Regarding your charter proposal :
>=20
> --------
>=20
> - They form a connected network
>        [SLI] InterAS case must be included, but the WG can go step by =
step and first release intraAS, and then doing interAS (in relation with =
IDR ??).
>=20
> - They can forward traffic through the shortest paths or paths other =
than the shortest (the latter called explicitly routed paths, or =
explicit paths)
>        [SLI] There is something else between SPT and Explicit path, =
you can define other algorithms than SPT to define a path, and it's not =
explicit path. Moreover I come back to my comment, on do we want to =
limit the scope to routing ? I would say no.
>=20
> - They share a common trust model. In this model, any router within =
the ERD can specify an explicit path between itself and any other router =
in the ERD. It can then send any packet that passes through it through =
any path that it has specified.
>        [SLI] Security considerations may have to be addressed in the =
charter , especially for the interAS case (trust yes, but not sure =
access to everything may not be good)
>=20
> Downstream routers within the ERD forward the packet as specified by =
the router at the head-end of the path.
> [SLI] Yes, but any router in the middle may be able to change the end =
to end explicit path.
>=20
>=20
>=20
> - The first goal of the STER WG is to identify use-cases for ERDs.
> - Having identified use-cases, the WG will identify gaps between =
currently available technologies and use-case requirements.
> - The WG will then define requirements for extensions to existing =
protocols or new protocols that address gaps that are identified.
>=20
> [SLI] Agree, I would add :
> - defining the architecture framework
> - analysing the security considerisations
>=20
>=20
> ---------
>=20
>=20
> Here would be my proposal to extend yours :
>=20
> A <named to be defined> domain contains a set of routers with the =
following characteristics:
>=20
> - They form a connected network
> - They can forward traffic through any path within the network using =
shortest path, non shortest path or explicit path
> - They may provide other types of services than forwarding and they =
can enforce service actions in the path.
> - They share a common trust model. In this model, any router within =
the domain can specify a path between itself and any other router in the =
domain. It may then send any packet that passes through it through any =
path that it has specified and that is conform to the security rules. =
Downstream routers within the ERD forward the packet as specified by the =
router at the head-end of the path.
>=20
> The <name> working group is chartered for the following ordered list =
of work items:
>=20
> - The first goal of the WG is to identify use-cases.
> - The WG will then define the architecture framework associated with =
the security considerations. The architecture framework and security =
considerations must address the relations between domains (interdomain).
> - Having identified use-cases, architecture and security, the WG will =
identify gaps between currently available technologies and use-case =
requirements.
> - The WG will then define requirements for extensions to existing =
protocols or new protocols that address gaps that are identified.
> - The WG will first focus on the intra-domain forwarding definition.
>=20
> Protocol work may be carried out in this working group or in other =
working groups responsible for the protocols, in coordination with this =
WG, and in agreement with the WG chairs and responsible ADs. However, no =
protocol work will be adopted by a working group to address the ERD =
use-cases until the requirements document motivating the protocol work =
has been sent to the IESG for publication as an RFC.
>=20
> -----Message d'origine-----
> De : [email-masked] [mailto:[email-masked]] De la =
part de Hannes Gredler
> Envoy=E9 : mardi 3 septembre 2013 18:31
> =C0 : Loa Andersson
> Cc : [email-masked]
> Objet : Re: [Status] Summary of STATUS BOF and the next steps
>=20
> good point - what about this charter proposal ?
>=20
> ---
>=20
> Stacked Tunnels for Explicit Routing (STER) =
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
>=20
> A explicit routing domain (ERD) contains a set of routers with the =
following characteristics:
>=20
> - They form a connected network
> - They can forward traffic through the shortest paths or paths other =
than the shortest (the latter called explicitly routed paths, or =
explicit paths)
> - They share a common trust model. In this model, any router within =
the ERD can specify an explicit path between itself and any other router =
in the ERD. It can then send any packet that passes through it through =
any path that it has specified. Downstream routers within the ERD =
forward the packet as specified by the router at the head-end of the =
path.
>=20
> The STER working group is chartered for the following ordered list of =
work items:
>=20
> - The first goal of the STER WG is to identify use-cases for ERDs.
> - Having identified use-cases, the WG will identify gaps between =
currently available technologies and use-case requirements.
> - The WG will then define requirements for extensions to existing =
protocols or new protocols that address gaps that are identified.
>=20
> Protocol work may be carried out in this working group or in other =
working groups responsible for the protocols, in coordination with this =
WG, and in agreement with the WG chairs and responsible ADs. However, no =
protocol work will be adopted by a working group to address the ERD =
use-cases until the requirements document motivating the protocol work =
has been sent to the IESG for publication as an RFC.
>=20
> ---
>=20
> <flame suit on>
>=20
> /hannes
>=20
>=20
> On Sep 3, 2013, at 5:31 PM, Loa Andersson wrote:
>=20
>> Folks,
>>=20
>> Excuse me if I'm slightly out of the loop, but so far I have not seen
>> a charter proposal, if there is one please point me to it.
>>=20
>> It seems a bit odd to put the cart (what the wg should do) before the
>> horse (wg name). If we drill down the the charter first the wg name
>> might be easier to figure out.
>>=20
>> /Loa
>>=20
>> PS
>> OK I understand that the horse and cart analogy limps a  bit :).
>>=20
>>=20
>>=20
>> On 2013-09-03 17:22, AshwoodsmithPeter wrote:
>>> " If the WG charter is limited to source routing, how will we handle =
the "non source routing" use cases of segment routing ? In another =
working group ? So we will go back to the WG synchronization issue that =
has been raised for this technology ..."
>>>=20
>>> That's why I suggested SRV2. We are revisiting source routing with =
new concepts. More generic number/action behavior.
>>>=20
>>> Peter
>>>=20
>>> -----Original Message-----
>>> From: [email-masked] [mailto:[email-masked]] On
>>> Behalf Of [email-masked]
>>> Sent: Tuesday, September 03, 2013 10:43 AM
>>> To: AshwoodsmithPeter
>>> Cc: [email-masked]
>>> Subject: Re: [Status] Summary of STATUS BOF and the next steps
>>>=20
>>>=20
>>> There was a misunderstanding in my small comment :) so I will =
explain more :
>>>=20
>>> In segment routing, you have more than basic source routing : =
segment routing is just associate a segment number to an action and then =
combine segment as you want, yes you can do source routing, but you also =
can do more.
>>>=20
>>> In the other hand, I completely agree with your statement that =
source
>>> routing is generic and dataplane agnostic, as segment routing is ...
>>> (segment routing is not a new dataplane ...)
>>>=20
>>> Now the definition of the WG naming must be inline with the charter
>>> that will be defined ... (draft today)
>>>=20
>>> Based on the already existing consensus (at least for MPLS =
dataplane) brought up during Berlin STATUS BOF meeting, segment routing =
sounds to be a good target candidate.
>>>=20
>>> So now, do we want to do more in the WG charter than just make =
progressing segment routing architecture and uses cases document and =
ensure coordination for the standardization of this technology ?
>>>=20
>>> Do we want to standardize other technologies in this WG ? I don't =
think so, based on Stewart's conclusion email from the BOF :"A new WG =
focused solely on SR therefore needs to be create"
>>>=20
>>> If the WG charter is limited to source routing, how will we handle =
the "non source routing" use cases of segment routing ? In another =
working group ? So we will go back to the WG synchronization issue that =
has been raised for this technology ...
>>>=20
>>> If the WG is focused on SR, let's use a name in relation with SR.
>>>=20
>>> Feedback ?
>>>=20
>>>=20
>>> Stephane
>>>=20
>>>=20
>>> -----Message d'origine-----
>>> De : AshwoodsmithPeter [mailto:[email-masked]]
>>> Envoy=E9 : mardi 3 septembre 2013 15:27 =C0 : LITKOWSKI Stephane =
DTF/DERX
>>> Cc : John E Drake; Mark Townsley; Victor Kuarsingh; Roberta Maglione
>>> (robmgl); John G. Scudder; Adrian Farrel; Alvaro Retana (aretana);
>>> [email-masked]; Stewart Bryant (stbryant) Objet : Re: [Status]
>>> Summary of STATUS BOF and the next steps
>>>=20
>>> The term "source routing" has been around for a very long time and =
is data path agnostic. Its also the term used in the literature etc so =
my preference is to stick with this existing well known and data path =
agnostic term.
>>>=20
>>> Peter
>>>=20
>>> On Sep 3, 2013, at 9:07 AM, "[email-masked]" =
<[email-masked]> wrote:
>>>=20
>>>> Hi,
>>>>=20
>>>> "Source routing" is just a subcase of segment routing ... as it is =
for IP routing ...
>>>>=20
>>>> Stephane
>>>>=20
>>>>=20
>>>> -----Message d'origine-----
>>>> De : [email-masked] [mailto:[email-masked]] De la
>>>> part de John E Drake Envoy=E9 : mardi 3 septembre 2013 15:02 =C0 : =
Mark
>>>> Townsley; Victor Kuarsingh Cc : Roberta Maglione (robmgl); John G.
>>>> Scudder; Alvaro Retana (aretana); Adrian Farrel; [email-masked];
>>>> Stewart Bryant (stbryant) Objet : Re: [Status] Summary of STATUS =
BOF
>>>> and the next steps
>>>>=20
>>>> Hi,
>>>>=20
>>>> What is this 'segment routing' silliness?  The correct term is =
'source routing'.
>>>>=20
>>>> Yours Irrespectively,
>>>>=20
>>>> John
>>>>=20
>>>>> -----Original Message-----
>>>>> From: [email-masked] [mailto:[email-masked]] On
>>>>> Behalf Of Mark Townsley
>>>>> Sent: Sunday, September 01, 2013 10:08 AM
>>>>> To: Victor Kuarsingh
>>>>> Cc: Roberta Maglione (robmgl); John G. Scudder; Adrian Farrel;
>>>>> Alvaro Retana (aretana); [email-masked]; Stewart Bryant =
(stbryant)
>>>>> Subject: Re: [Status] Summary of STATUS BOF and the next steps
>>>>>=20
>>>>>=20
>>>>> On Sep 1, 2013, at 5:38 PM, Victor Kuarsingh wrote:
>>>>>=20
>>>>>> All,
>>>>>>=20
>>>>>> I would also favour "Segment Routing WG" as well.
>>>>>>=20
>>>>>> I note this since attempting to come up with an all encompassing
>>>>>> acronym will be difficult and Segment Routing is generic enough =
to
>>>>>> associate to multiple functions.
>>>>>=20
>>>>> Then we can just use "segroute" for the short name. WGs do not =
have
>>>>> to have acronyms, but they do need to have an 8-char limited short
>>>>> name for the various automated tools not to break.
>>>>>=20
>>>>> - Mark
>>>>>=20
>>>>>>=20
>>>>>> Regards,
>>>>>>=20
>>>>>> Victor K
>>>>>>=20
>>>>>>=20
>>>>>>=20
>>>>>> On 2013-08-31 6:51 PM, "Roberta Maglione (robmgl)"
>>>>>> <[email-masked]>
>>>>>> wrote:
>>>>>>=20
>>>>>>> +1 for Segment Routing WG
>>>>>>>=20
>>>>>>> Roberta
>>>>>>>=20
>>>>>>> Sent from my iPad
>>>>>>>=20
>>>>>>> On 2013-08-30, at 2:55 PM, "Alvaro Retana (aretana)"
>>>>>>> <[email-masked]>
>>>>>>> wrote:
>>>>>>>=20
>>>>>>>> Segment Routing WG
>>>>>>>>=20
>>>>>>>> Sent from my iPhone
>>>>>>>>=20
>>>>>>>> On Aug 30, 2013, at 1:39 PM, "Stewart Bryant (stbryant)"
>>>>>>>> <[email-masked]> wrote:
>>>>>>>>=20
>>>>>>>>> The second task, which hopefully should be relatively easy, is
>>>>>>>>> to find a better working name for the WG, since it has been =
put
>>>>>>>>> to me a number of times that STATUS is going to be confusing =
in
>>>>>>>>> text and a difficult search term.
>>>>>>>> _______________________________________________
>>>>>>>> status mailing list
>>>>>>>> [email-masked]
>>>>>>>> https://www.ietf.org/mailman/listinfo/status
>>>>>>> _______________________________________________
>>>>>>> status mailing list
>>>>>>> [email-masked]
>>>>>>> https://www.ietf.org/mailman/listinfo/status
>>>>>>=20
>>>>>>=20
>>>>>> _______________________________________________
>>>>>> status mailing list
>>>>>> [email-masked]
>>>>>> https://www.ietf.org/mailman/listinfo/status
>>>>>=20
>>>>> _______________________________________________
>>>>> status mailing list
>>>>> [email-masked]
>>>>> https://www.ietf.org/mailman/listinfo/status
>>>>=20
>>>>=20
>>>> _______________________________________________
>>>> status mailing list
>>>> [email-masked]
>>>> https://www.ietf.org/mailman/listinfo/status
>>>>=20
>>>> =
____________________________________________________________________
>>>> __ ___________________________________________________
>>>>=20
>>>> Ce message et ses pieces jointes peuvent contenir des informations
>>>> confidentielles ou privilegiees et ne doivent donc pas etre
>>>> diffuses, exploites ou copies sans autorisation. Si vous avez recu
>>>> ce message par erreur, veuillez le signaler a l'expediteur et le =
detruire ainsi que les pieces jointes. Les messages electroniques etant =
susceptibles d'alteration, Orange decline toute responsabilite si ce =
message a ete altere, deforme ou falsifie. Merci.
>>>>=20
>>>> This message and its attachments may contain confidential or
>>>> privileged information that may be protected by law; they should =
not be distributed, used or copied without authorisation.
>>>> If you have received this email in error, please notify the sender =
and delete this message and its attachments.
>>>> As emails may be altered, Orange is not liable for messages that =
have been modified, changed or falsified.
>>>> Thank you.
>>>>=20
>>>> _______________________________________________
>>>> status mailing list
>>>> [email-masked]
>>>> https://www.ietf.org/mailman/listinfo/status
>>>=20
>>> =
_____________________________________________________________________
>>> ____________________________________________________
>>>=20
>>> Ce message et ses pieces jointes peuvent contenir des informations
>>> confidentielles ou privilegiees et ne doivent donc pas etre =
diffuses,
>>> exploites ou copies sans autorisation. Si vous avez recu ce message
>>> par erreur, veuillez le signaler a l'expediteur et le detruire ainsi =
que les pieces jointes. Les messages electroniques etant susceptibles =
d'alteration, Orange decline toute responsabilite si ce message a ete =
altere, deforme ou falsifie. Merci.
>>>=20
>>> This message and its attachments may contain confidential or
>>> privileged information that may be protected by law; they should not =
be distributed, used or copied without authorisation.
>>> If you have received this email in error, please notify the sender =
and delete this message and its attachments.
>>> As emails may be altered, Orange is not liable for messages that =
have been modified, changed or falsified.
>>> Thank you.
>>>=20
>>> _______________________________________________
>>> status mailing list
>>> [email-masked]
>>> https://www.ietf.org/mailman/listinfo/status
>>> _______________________________________________
>>> status mailing list
>>> [email-masked]
>>> https://www.ietf.org/mailman/listinfo/status
>>>=20
>>=20
>> --
>>=20
>>=20
>> Loa Andersson                        email: [email-masked]
>> Senior MPLS Expert                          [email-masked]
>> Huawei Technologies (consultant)     phone: +46 739 81 21 64
>> _______________________________________________
>> status mailing list
>> [email-masked]
>> https://www.ietf.org/mailman/listinfo/status
>>=20
>>=20
>=20
>=20
> _______________________________________________
> status mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/status
>=20
> =
__________________________________________________________________________=
_______________________________________________
>=20
> Ce message et ses pieces jointes peuvent contenir des informations =
confidentielles ou privilegiees et ne doivent donc
> pas etre diffuses, exploites ou copies sans autorisation. Si vous avez =
recu ce message par erreur, veuillez le signaler
> a l'expediteur et le detruire ainsi que les pieces jointes. Les =
messages electroniques etant susceptibles d'alteration,
> Orange decline toute responsabilite si ce message a ete altere, =
deforme ou falsifie. Merci.
>=20
> This message and its attachments may contain confidential or =
privileged information that may be protected by law;
> they should not be distributed, used or copied without authorisation.
> If you have received this email in error, please notify the sender and =
delete this message and its attachments.
> As emails may be altered, Orange is not liable for messages that have =
been modified, changed or falsified.
> Thank you.
>=20
>=20
>=20

From: <[email-masked]>
To: "Stefano Previdi (sprevidi)" <[email-masked]>, "[email-masked]" <[email-masked]>
Date: Fri, 6 Sep 2013 11:00:26 +0200
Accept-Language: fr-FR
acceptlanguage: fr-FR
Cc: "Clarence Filsfils \(cfilsfil\)" <[email-masked]>
Subject: Re: [Status] Proposed Charter

Agree on this charter proposal, just need to add security aspects.
=20

-----Message d'origine-----
De : [email-masked] [mailto:[email-masked]] De la part de=
 Stefano Previdi (sprevidi)
Envoy=E9 : vendredi 6 septembre 2013 08:48
=C0 : [email-masked]
Cc : Clarence Filsfils (cfilsfil)
Objet : [Status] Proposed Charter

All,

here follows a proposal for the charter.

Thanks.
s.

-------------------------------------------------------------------
Name: SEGROUTE (or SR, or whatever else)
Charter:

Introduction
------------
The following use cases:
. Path computation based on awareness of utilization or performance
  data, within both centralized and distributed environments, . Multi-topol=
ogy (dual planes, disjoint trees), . Simplification and reduction of signal=
ing components (scaling), . Combined application and network layer path spe=
cification, . Full coverage LFA-FRR, . Topology Aware OAM, . etc.=20

have triggered work on the definition of new architecture and protocol exte=
nsions allowing to combine well known shortest path based routing paradigms=
 with source/explicit routing methods. Some of these extensions have been i=
mplemented already.

Objective
---------
Define an architecture where a node can steer a packet through a controlled=
 set of instructions, called segments while maintaining per-explicit path s=
tate only at the ingress node.

The instruction associated to a segment can be derived based on arbitrary m=
echanisms which may include:

. Shortest path routing or explicit/source routing paradigms . Intra and in=
ter domain path computation . Network or application layer . Network virtua=
lization . Centralized or distributed path computation . Unicast or Multica=
st schemes . Others.

The SEGROUTE architecture will support:

. Tunnel and non-tunnel based paradigms
. Multiple data-planes: MPLS and IPv6. The SEGROUTE control plane
  should be independent (agnostic) to the data-planes.

The WG will work on the definition of the architecture and protocol extensi=
ons. No new protocol specification is expected within this WG.=20
No MPLS data-plane changes are expected either.

Instead the standardization work should consist in extensions in well estab=
lished protocols (ISIS, OSPF, BGP, PCEP, ...).

It is expected that the SEGROUTE WG will help in the orchestration of proto=
col extensions specification with the existing IETF Working Groups (ISIS, O=
SPF, IDR, PCE, 6MAN, MPLS, ...).
=20
Documents
---------
The WG will produce the following documents:
. Problem Statement
. Requirements
. Use Cases
. Architecture
. Interoperability Report

The protocol extensions and data-plane instantiations will be handled in th=
eir respective WGs.
_______________________________________________
status mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/status

___________________________________________________________________________=
______________________________________________

Ce message et ses pieces jointes peuvent contenir des informations confiden=
tielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu=
 ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages el=
ectroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou =
falsifie. Merci.

This message and its attachments may contain confidential or privileged inf=
ormation that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and dele=
te this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been =
modified, changed or falsified.
Thank you.

From: <[email-masked]>
To: <[email-masked]>
Date: Fri, 6 Sep 2013 09:09:45 +0200
Accept-Language: en-US, de-DE
acceptlanguage: en-US, de-DE
Cc: [email-masked]
Subject: Re: [Status] Summary of STATUS BOF and the next steps

Stewart,

OAM work will start initially, I hope. As I mentioned, there's a prototype =
applying SR technology (without the extensions required by any of the 7 WGs=
 of course). Still, experience collected there allows work on OAM requireme=
nts and features.

I'm exchanging mails with some interested colleagues already. We'd be happy=
 to continue the OAM discussion on a public list.

Regards,

Ruediger

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of=
 Stewart Bryant (stbryant)
Sent: Thursday, September 05, 2013 11:50 PM
To: Robert Raszuk
Cc: Hannes Gredler; [email-masked]
Subject: Re: [Status] Summary of STATUS BOF and the next steps

Robert, please read my summary email that started this thread.

Given 7 WGs that need to contribute (before we even consider OAM and Manage=
ment, or the inevitable feature creep ) and the work potentially spanning t=
wo IETF areas, there needs to be some group that can see the whole picture,=
 and act a as a focus to ensure a consistent design.

Stewart

Sent from my iPad

On 5 Sep 2013, at 20:01, "Robert Raszuk" <[email-masked]> wrote:

>> actually not. the whole point of forming a new WG is that
>> folks do not sneak-in "*-routing" ideas in the respective
>> protocol groups where people may not be paying attention.
>
> Thx for making the objective of this new WG finally very clear ;)
>
> In fact I would recommend we frame the above and make it as a charter.
>
> That way the new soon to be formed WG will be serving as *routing area
> preview/policy working group* preventing anyone to be able to
> "sneak-in" any protocol extension to respective routing protocols WGs
> without making sure such extensions are politically correct and
> approved by unanimity voting of anyone subscribed to the list.
>
> Cheers,
> R.
>
> PS. It's amazing to see this WG being formed considering a vast
> majority of people attending the quote "non working group forming BOF"
> in Berlin indicated no support for such new working group and segment
> routing architecture to be discussed in current rtwg.
> _______________________________________________
> status mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/status
_______________________________________________
status mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/status

From: <[email-masked]>
To: <[email-masked]>
Date: Fri, 6 Sep 2013 08:51:21 +0200
Accept-Language: en-US, de-DE
acceptlanguage: en-US, de-DE
Cc: [email-masked], [email-masked]
Subject: Re: [Status] Proposed Charter

Hi Stefano,

thanks and ok.

Regards,

Ruediger

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of=
 Stefano Previdi (sprevidi)
Sent: Friday, September 06, 2013 8:48 AM
To: [email-masked]
Cc: Clarence Filsfils (cfilsfil)
Subject: [Status] Proposed Charter

All,

here follows a proposal for the charter.

Thanks.
s.

-------------------------------------------------------------------
Name: SEGROUTE (or SR, or whatever else)
Charter:

Introduction
------------
The following use cases:
. Path computation based on awareness of utilization or performance
  data, within both centralized and distributed environments,
. Multi-topology (dual planes, disjoint trees),
. Simplification and reduction of signaling components (scaling),
. Combined application and network layer path specification,
. Full coverage LFA-FRR,
. Topology Aware OAM,
. etc.

have triggered work on the definition of new architecture and protocol
extensions allowing to combine well known shortest path based routing
paradigms with source/explicit routing methods. Some of these
extensions have been implemented already.

Objective
---------
Define an architecture where a node can steer a packet through a
controlled set of instructions, called segments while maintaining
per-explicit path state only at the ingress node.

The instruction associated to a segment can be derived based on
arbitrary mechanisms which may include:

. Shortest path routing or explicit/source routing paradigms
. Intra and inter domain path computation
. Network or application layer
. Network virtualization
. Centralized or distributed path computation
. Unicast or Multicast schemes
. Others.

The SEGROUTE architecture will support:

. Tunnel and non-tunnel based paradigms
. Multiple data-planes: MPLS and IPv6. The SEGROUTE control plane
  should be independent (agnostic) to the data-planes.

The WG will work on the definition of the architecture and protocol
extensions. No new protocol specification is expected within this WG.
No MPLS data-plane changes are expected either.

Instead the standardization work should consist in extensions in well
established protocols (ISIS, OSPF, BGP, PCEP, ...).

It is expected that the SEGROUTE WG will help in the orchestration
of protocol extensions specification with the existing IETF Working
Groups (ISIS, OSPF, IDR, PCE, 6MAN, MPLS, ...).

Documents
---------
The WG will produce the following documents:
. Problem Statement
. Requirements
. Use Cases
. Architecture
. Interoperability Report

The protocol extensions and data-plane instantiations will be handled
in their respective WGs.
_______________________________________________
status mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/status

From: "Stefano Previdi (sprevidi)" <[email-masked]>
To: "[email-masked]" <[email-masked]>
Date: Fri, 6 Sep 2013 06:48:16 +0000
Accept-Language: en-US
Cc: "Clarence Filsfils \(cfilsfil\)" <[email-masked]>
Subject: [Status] Proposed Charter

All,

here follows a proposal for the charter.

Thanks.
s.

-------------------------------------------------------------------
Name: SEGROUTE (or SR, or whatever else)
Charter:

Introduction
------------
The following use cases:
. Path computation based on awareness of utilization or performance=20
  data, within both centralized and distributed environments,
. Multi-topology (dual planes, disjoint trees),
. Simplification and reduction of signaling components (scaling),
. Combined application and network layer path specification,
. Full coverage LFA-FRR,
. Topology Aware OAM,
. etc.=20

have triggered work on the definition of new architecture and protocol=20
extensions allowing to combine well known shortest path based routing=20
paradigms with source/explicit routing methods. Some of these=20
extensions have been implemented already.

Objective
---------
Define an architecture where a node can steer a packet through a=20
controlled set of instructions, called segments while maintaining=20
per-explicit path state only at the ingress node.

The instruction associated to a segment can be derived based on
arbitrary mechanisms which may include:

. Shortest path routing or explicit/source routing paradigms
. Intra and inter domain path computation
. Network or application layer
. Network virtualization
. Centralized or distributed path computation
. Unicast or Multicast schemes
. Others.

The SEGROUTE architecture will support:

. Tunnel and non-tunnel based paradigms
. Multiple data-planes: MPLS and IPv6. The SEGROUTE control plane=20
  should be independent (agnostic) to the data-planes.

The WG will work on the definition of the architecture and protocol=20
extensions. No new protocol specification is expected within this WG.=20
No MPLS data-plane changes are expected either.

Instead the standardization work should consist in extensions in well=20
established protocols (ISIS, OSPF, BGP, PCEP, ...).

It is expected that the SEGROUTE WG will help in the orchestration=20
of protocol extensions specification with the existing IETF Working=20
Groups (ISIS, OSPF, IDR, PCE, 6MAN, MPLS, ...).
=20
Documents
---------
The WG will produce the following documents:
. Problem Statement
. Requirements
. Use Cases
. Architecture=20
. Interoperability Report

The protocol extensions and data-plane instantiations will be handled=20
in their respective WGs.

From: Xuxiaohu <[email-masked]>
To: Anoop Ghanwani <[email-masked]>
Date: Fri, 6 Sep 2013 03:21:55 +0000
Accept-Language: zh-CN, en-US
Cc: "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>
Subject: Re: [Status] A possible way to make IP fans happy//re: Summary of STATUS BOF and the next steps

--_000_1FEE3F8F5CCDE64C9A8E8F4AD27C19EE08202DBCNKGEML512MBSchi_
Content-Type: text/plain; charset="gb2312"
Content-Transfer-Encoding: base64

--_000_1FEE3F8F5CCDE64C9A8E8F4AD27C19EE08202DBCNKGEML512MBSchi_
Content-Type: text/html; charset="gb2312"
Content-Transfer-Encoding: quoted-printable

<html xmlns:v=3D"urn:schemas-microsoft-com:vml" xmlns:o=3D"urn:schemas-micr=
osoft-com:office:office" xmlns:w=3D"urn:schemas-microsoft-com:office:word" =
xmlns:x=3D"urn:schemas-microsoft-com:office:excel" xmlns:p=3D"urn:schemas-m=
icrosoft-com:office:powerpoint" xmlns:a=3D"urn:schemas-microsoft-com:office=
:access" xmlns:dt=3D"uuid:C2F41010-65B3-11d1-A29F-00AA00C14882" xmlns:s=3D"=
uuid:BDC6E3F0-6DA3-11d1-A2A3-00AA00C14882" xmlns:rs=3D"urn:schemas-microsof=
t-com:rowset" xmlns:z=3D"#RowsetSchema" xmlns:b=3D"urn:schemas-microsoft-co=
m:office:publisher" xmlns:ss=3D"urn:schemas-microsoft-com:office:spreadshee=
t" xmlns:c=3D"urn:schemas-microsoft-com:office:component:spreadsheet" xmlns=
:odc=3D"urn:schemas-microsoft-com:office:odc" xmlns:oa=3D"urn:schemas-micro=
soft-com:office:activation" xmlns:html=3D"http://www.w3.org/TR/REC-html40" =
xmlns:q=3D"http://schemas.xmlsoap.org/soap/envelope/" xmlns:rtc=3D"http://m=
icrosoft.com/officenet/conferencing" xmlns:D=3D"DAV:" xmlns:Repl=3D"http://=
schemas.microsoft.com/repl/" xmlns:mt=3D"http://schemas.microsoft.com/share=
point/soap/meetings/" xmlns:x2=3D"http://schemas.microsoft.com/office/excel=
/2003/xml" xmlns:ppda=3D"http://www.passport.com/NameSpace.xsd" xmlns:ois=
=3D"http://schemas.microsoft.com/sharepoint/soap/ois/" xmlns:dir=3D"http://=
schemas.microsoft.com/sharepoint/soap/directory/" xmlns:ds=3D"http://www.w3=
.org/2000/09/xmldsig#" xmlns:dsp=3D"http://schemas.microsoft.com/sharepoint=
/dsp" xmlns:udc=3D"http://schemas.microsoft.com/data/udc" xmlns:xsd=3D"http=
://www.w3.org/2001/XMLSchema" xmlns:sub=3D"http://schemas.microsoft.com/sha=
repoint/soap/2002/1/alerts/" xmlns:ec=3D"http://www.w3.org/2001/04/xmlenc#"=
 xmlns:sp=3D"http://schemas.microsoft.com/sharepoint/" xmlns:sps=3D"http://=
schemas.microsoft.com/sharepoint/soap/" xmlns:xsi=3D"http://www.w3.org/2001=
/XMLSchema-instance" xmlns:udcs=3D"http://schemas.microsoft.com/data/udc/so=
ap" xmlns:udcxf=3D"http://schemas.microsoft.com/data/udc/xmlfile" xmlns:udc=
p2p=3D"http://schemas.microsoft.com/data/udc/parttopart" xmlns:wf=3D"http:/=
/schemas.microsoft.com/sharepoint/soap/workflow/" xmlns:dsss=3D"http://sche=
mas.microsoft.com/office/2006/digsig-setup" xmlns:dssi=3D"http://schemas.mi=
crosoft.com/office/2006/digsig" xmlns:mdssi=3D"http://schemas.openxmlformat=
s.org/package/2006/digital-signature" xmlns:mver=3D"http://schemas.openxmlf=
ormats.org/markup-compatibility/2006" xmlns:m=3D"http://schemas.microsoft.c=
om/office/2004/12/omml" xmlns:mrels=3D"http://schemas.openxmlformats.org/pa=
ckage/2006/relationships" xmlns:spwp=3D"http://microsoft.com/sharepoint/web=
partpages" xmlns:ex12t=3D"http://schemas.microsoft.com/exchange/services/20=
06/types" xmlns:ex12m=3D"http://schemas.microsoft.com/exchange/services/200=
6/messages" xmlns:pptsl=3D"http://schemas.microsoft.com/sharepoint/soap/Sli=
deLibrary/" xmlns:spsl=3D"http://microsoft.com/webservices/SharePointPortal=
Server/PublishedLinksService" xmlns:Z=3D"urn:schemas-microsoft-com:" xmlns:=
st=3D"&#1;" xmlns=3D"http://www.w3.org/TR/REC-html40">
<head>
<meta http-equiv=3D"Content-Type" content=3D"text/html; charset=3Dgb2312">
<meta name=3D"Generator" content=3D"Microsoft Word 12 (filtered medium)">
<style><!--
/* Font Definitions */
@font-face
	{font-family:=CB=CE=CC=E5;
	panose-1:2 1 6 0 3 1 1 1 1 1;}
@font-face
	{font-family:"Cambria Math";
	panose-1:2 4 5 3 5 4 6 3 2 4;}
@font-face
	{font-family:Calibri;
	panose-1:2 15 5 2 2 2 4 3 2 4;}
@font-face
	{font-family:"\@=CB=CE=CC=E5";
	panose-1:2 1 6 0 3 1 1 1 1 1;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
	{margin:0cm;
	margin-bottom:.0001pt;
	font-size:12.0pt;
	font-family:=CB=CE=CC=E5;}
a:link, span.MsoHyperlink
	{mso-style-priority:99;
	color:blue;
	text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
	{mso-style-priority:99;
	color:purple;
	text-decoration:underline;}
p
	{mso-style-priority:99;
	mso-margin-top-alt:auto;
	margin-right:0cm;
	mso-margin-bottom-alt:auto;
	margin-left:0cm;
	font-size:12.0pt;
	font-family:=CB=CE=CC=E5;}
span.EmailStyle18
	{mso-style-type:personal-reply;
	font-family:"Calibri","sans-serif";
	color:#1F497D;}
.MsoChpDefault
	{mso-style-type:export-only;}
@page WordSection1
	{size:612.0pt 792.0pt;
	margin:72.0pt 90.0pt 72.0pt 90.0pt;}
div.WordSection1
	{page:WordSection1;}
--></style><!--[if gte mso 9]><xml>
<o:shapedefaults v:ext=3D"edit" spidmax=3D"1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
<o:shapelayout v:ext=3D"edit">
<o:idmap v:ext=3D"edit" data=3D"1" />
</o:shapelayout></xml><![endif]-->
</head>
<body lang=3D"ZH-CN" link=3D"blue" vlink=3D"purple">
<div class=3D"WordSection1">
<p class=3D"MsoNormal"><span lang=3D"EN-US" style=3D"font-size:16.0pt;font-=
family:&quot;Calibri&quot;,&quot;sans-serif&quot;;color:#1F497D">Hi Anoop,<=
o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US" style=3D"font-size:16.0pt;font-=
family:&quot;Calibri&quot;,&quot;sans-serif&quot;;color:#1F497D"><o:p>&nbsp=
;</o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US" style=3D"font-size:16.0pt;font-=
family:&quot;Calibri&quot;,&quot;sans-serif&quot;;color:#1F497D">It exactly=
 uses the MPLS-in-GRE or other IP-based encapsulations for MPLS.&nbsp;
<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US" style=3D"font-size:16.0pt;font-=
family:&quot;Calibri&quot;,&quot;sans-serif&quot;;color:#1F497D"><o:p>&nbsp=
;</o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US" style=3D"font-size:16.0pt;font-=
family:&quot;Calibri&quot;,&quot;sans-serif&quot;;color:#1F497D">Anyway, u<=
/span><span lang=3D"EN-US" style=3D"font-size:16.0pt;font-family:&quot;Cali=
bri&quot;,&quot;sans-serif&quot;;color:#1F497D">nless it
</span><span lang=3D"EN-US" style=3D"font-size:16.0pt;font-family:&quot;Cal=
ibri&quot;,&quot;sans-serif&quot;;color:#1F497D">is mandatory to</span><spa=
n lang=3D"EN-US" style=3D"font-size:16.0pt;font-family:&quot;Calibri&quot;,=
&quot;sans-serif&quot;;color:#1F497D"> contain a list of
</span><span lang=3D"EN-US" style=3D"font-size:16.0pt;font-family:&quot;Cal=
ibri&quot;,&quot;sans-serif&quot;;color:#1F497D">IPv6 addresses in the IPv6=
 data packet for indicating the predefined next-hops of a given explicit so=
urce path, it would be better to use a list of SHORTER IDs/labels
 instead of the 128-bit long IPv6 addresses to indicate those predefined ne=
xt-hops. IMHO, the existing MPLS label stack mechanism happens to be an ide=
al candidate for this. People who want to use such mechanism don=A1=AFt nee=
d to know any other applications of MPLS.
 The only thing that they need to know is that short (MPLS) labels, instead=
 of IPv6 addresses are used in the IPv6 data packet to indicate the predefi=
ned next-hops. Therefore, it seems that there is no strong technical motiva=
tion to reinvent the wheel for the
 IPv6 data plane.<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US" style=3D"font-size:16.0pt;font-=
family:&quot;Calibri&quot;,&quot;sans-serif&quot;;color:#1F497D"><o:p>&nbsp=
;</o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US" style=3D"font-size:16.0pt;font-=
family:&quot;Calibri&quot;,&quot;sans-serif&quot;;color:#1F497D">Best regar=
ds,<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US" style=3D"font-size:16.0pt;font-=
family:&quot;Calibri&quot;,&quot;sans-serif&quot;;color:#1F497D">Xiaohu</sp=
an><span lang=3D"EN-US" style=3D"font-size:16.0pt;font-family:&quot;Calibri=
&quot;,&quot;sans-serif&quot;;color:#1F497D"><o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US" style=3D"font-size:16.0pt;font-=
family:&quot;Calibri&quot;,&quot;sans-serif&quot;;color:#1F497D"><o:p>&nbsp=
;</o:p></span></p>
<div style=3D"border:none;border-left:solid blue 1.5pt;padding:0cm 0cm 0cm =
4.0pt">
<div>
<div style=3D"border:none;border-top:solid #B5C4DF 1.0pt;padding:3.0pt 0cm =
0cm 0cm">
<p class=3D"MsoNormal"><b><span style=3D"font-size:10.0pt">=B7=A2=BC=FE=C8=
=CB<span lang=3D"EN-US">:</span></span></b><span lang=3D"EN-US" style=3D"fo=
nt-size:10.0pt"> [email-masked] [mailto:[email-masked]]
</span><b><span style=3D"font-size:10.0pt">=B4=FA=B1=ED </span></b><span la=
ng=3D"EN-US" style=3D"font-size:10.0pt">Anoop Ghanwani<br>
</span><b><span style=3D"font-size:10.0pt">=B7=A2=CB=CD=CA=B1=BC=E4<span la=
ng=3D"EN-US">:</span></span></b><span lang=3D"EN-US" style=3D"font-size:10.=
0pt"> 2013</span><span style=3D"font-size:10.0pt">=C4=EA<span lang=3D"EN-US=
">9</span>=D4=C2<span lang=3D"EN-US">5</span>=C8=D5<span lang=3D"EN-US"> 18=
:42<br>
</span><b>=CA=D5=BC=FE=C8=CB<span lang=3D"EN-US">:</span></b><span lang=3D"=
EN-US"> Xuxiaohu<br>
</span><b>=B3=AD=CB=CD<span lang=3D"EN-US">:</span></b><span lang=3D"EN-US"=
> [email-masked]; [email-masked]<br>
</span><b>=D6=F7=CC=E2<span lang=3D"EN-US">:</span></b><span lang=3D"EN-US"=
> Re: [Status] A possible way to make IP fans happy//re: Summary of STATUS =
BOF and the next steps<o:p></o:p></span></span></p>
</div>
</div>
<p class=3D"MsoNormal"><span lang=3D"EN-US"><o:p>&nbsp;</o:p></span></p>
<div>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Is this any different than MPLS=
 over GRE, where GRE is used to get over non-MPLS-aware parts of a network?=
<o:p></o:p></span></p>
<div>
<p class=3D"MsoNormal"><span lang=3D"EN-US"><o:p>&nbsp;</o:p></span></p>
</div>
<div>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Anoop<o:p></o:p></span></p>
</div>
</div>
<div>
<p class=3D"MsoNormal" style=3D"margin-bottom:12.0pt"><span lang=3D"EN-US">=
<o:p>&nbsp;</o:p></span></p>
<div>
<p class=3D"MsoNormal"><span lang=3D"EN-US">On Thu, Sep 5, 2013 at 3:16 AM,=
 Xuxiaohu &lt;<a href=3D"mailto:[email-masked]" target=3D"_blank">xuxi=
[email-masked]</a>&gt; wrote:<o:p></o:p></span></p>
<div>
<div>
<p class=3D"MsoNormal" style=3D"mso-margin-top-alt:auto;mso-margin-bottom-a=
lt:auto"><span lang=3D"EN-US" style=3D"font-size:16.0pt;font-family:&quot;C=
alibri&quot;,&quot;sans-serif&quot;;color:#1F497D">Hi all,</span><span lang=
=3D"EN-US"><o:p></o:p></span></p>
<p class=3D"MsoNormal" style=3D"mso-margin-top-alt:auto;mso-margin-bottom-a=
lt:auto"><span lang=3D"EN-US" style=3D"font-size:16.0pt;font-family:&quot;C=
alibri&quot;,&quot;sans-serif&quot;;color:#1F497D">&nbsp;</span><span lang=
=3D"EN-US"><o:p></o:p></span></p>
<p class=3D"MsoNormal" style=3D"mso-margin-top-alt:auto;mso-margin-bottom-a=
lt:auto"><span lang=3D"EN-US" style=3D"font-size:16.0pt;font-family:&quot;C=
alibri&quot;,&quot;sans-serif&quot;;color:#1F497D">According to the BoF ses=
sion at IETF87, it seems that there are a certain number of
 people who want to see an IPv6-based, rather than MPLS-based source routin=
g mechanism. However, it seems that many people are hesitate to make any ch=
ange to the existing MPLS and IP data planes.</span><span lang=3D"EN-US"><o=
:p></o:p></span></p>
<p class=3D"MsoNormal" style=3D"mso-margin-top-alt:auto;mso-margin-bottom-a=
lt:auto"><span lang=3D"EN-US" style=3D"font-size:16.0pt;font-family:&quot;C=
alibri&quot;,&quot;sans-serif&quot;;color:#1F497D">&nbsp;</span><span lang=
=3D"EN-US"><o:p></o:p></span></p>
<p class=3D"MsoNormal" style=3D"mso-margin-top-alt:auto;mso-margin-bottom-a=
lt:auto"><span lang=3D"EN-US" style=3D"font-size:16.0pt;font-family:&quot;C=
alibri&quot;,&quot;sans-serif&quot;;color:#1F497D">I wonder whether the fol=
lowing low-cost approach can make those IP fans happy: the predefined
 next-hops that the explicit source path must traverse are still expressed =
by the MPLS label stack in the data packets, but the adjacent next-hops are=
 connected via pure IP networks, rather than MPLS networks. &nbsp;For examp=
le, if LSR A wants to send a MPLS VPN
 packet for LSR Z along an explicit path {B, C, Z}, it would push the node =
segment label for Z and then the node segment label for C into the existing=
 MPLS label stack, and then transport such MPLS packet over an IP tunnel to=
wards B. Upon receiving such MPLS
 packet over the IP tunnel, B would look up the corresponding MPLS forwardi=
ng table entry for the topmost label (i.e., the node segment label for C) a=
nd find the out interface for this packet is an IP tunnel interface with tu=
nnel destination of C, therefore
 it would pop the topmost label (if the out label of that MPLS forwarding e=
ntry is null) and then transport the MPLS packet over an IP tunnel towards =
C. &nbsp;Once C receives such MPLS packet over the IP tunnel, C would look =
up the corresponding MPLS forwarding
 entry for the current topmost label (i.e., the node segment label for Z) ,=
 and then forward this MPLS packet over an IP tunnel towards Z like what B =
has done.</span><span lang=3D"EN-US"><o:p></o:p></span></p>
<p class=3D"MsoNormal" style=3D"mso-margin-top-alt:auto;mso-margin-bottom-a=
lt:auto"><span lang=3D"EN-US" style=3D"font-size:16.0pt;font-family:&quot;C=
alibri&quot;,&quot;sans-serif&quot;;color:#1F497D">&nbsp;</span><span lang=
=3D"EN-US"><o:p></o:p></span></p>
<p class=3D"MsoNormal" style=3D"mso-margin-top-alt:auto;mso-margin-bottom-a=
lt:auto"><span lang=3D"EN-US" style=3D"font-size:16.0pt;font-family:&quot;C=
alibri&quot;,&quot;sans-serif&quot;;color:#1F497D">The above approach has a=
t least the following benefits:</span><span lang=3D"EN-US"><o:p></o:p></spa=
n></p>
<p class=3D"MsoNormal" style=3D"mso-margin-top-alt:auto;mso-margin-bottom-a=
lt:auto"><span lang=3D"EN-US" style=3D"font-size:16.0pt;font-family:&quot;C=
alibri&quot;,&quot;sans-serif&quot;;color:#1F497D">&nbsp;</span><span lang=
=3D"EN-US"><o:p></o:p></span></p>
<p style=3D"margin-left:18.0pt"><span lang=3D"EN-US" style=3D"font-size:16.=
0pt;font-family:&quot;Calibri&quot;,&quot;sans-serif&quot;;color:#1F497D">1=
)</span><span lang=3D"EN-US" style=3D"font-size:7.0pt;font-family:&quot;Tim=
es New Roman&quot;,&quot;serif&quot;;color:#1F497D">&nbsp;&nbsp;&nbsp;
</span><span lang=3D"EN-US" style=3D"font-size:16.0pt;font-family:&quot;Cal=
ibri&quot;,&quot;sans-serif&quot;;color:#1F497D">No change to the existing =
MPLS and IP data plane.</span><span lang=3D"EN-US"><o:p></o:p></span></p>
<p style=3D"margin-left:18.0pt"><span lang=3D"EN-US" style=3D"font-size:16.=
0pt;font-family:&quot;Calibri&quot;,&quot;sans-serif&quot;;color:#1F497D">2=
)</span><span lang=3D"EN-US" style=3D"font-size:7.0pt;font-family:&quot;Tim=
es New Roman&quot;,&quot;serif&quot;;color:#1F497D">&nbsp;&nbsp;&nbsp;
</span><span lang=3D"EN-US" style=3D"font-size:16.0pt;font-family:&quot;Cal=
ibri&quot;,&quot;sans-serif&quot;;color:#1F497D">No requirement for the MPL=
S forwarding capability on all routers=3D&gt; only those explicit hops need=
 the MPLS forwarding capability.</span><span lang=3D"EN-US"><o:p></o:p></sp=
an></p>
<p style=3D"margin-left:18.0pt"><span lang=3D"EN-US" style=3D"font-size:16.=
0pt;font-family:&quot;Calibri&quot;,&quot;sans-serif&quot;;color:#1F497D">3=
)</span><span lang=3D"EN-US" style=3D"font-size:7.0pt;font-family:&quot;Tim=
es New Roman&quot;,&quot;serif&quot;;color:#1F497D">&nbsp;&nbsp;&nbsp;
</span><span lang=3D"EN-US" style=3D"font-size:16.0pt;font-family:&quot;Cal=
ibri&quot;,&quot;sans-serif&quot;;color:#1F497D">No requirement for softwar=
e upgrade on all routers=3D&gt; only those explicit hops need such software=
 upgrade.</span><span lang=3D"EN-US"><o:p></o:p></span></p>
<p style=3D"margin-left:18.0pt"><span lang=3D"EN-US" style=3D"font-size:16.=
0pt;font-family:&quot;Calibri&quot;,&quot;sans-serif&quot;;color:#1F497D">4=
)</span><span lang=3D"EN-US" style=3D"font-size:7.0pt;font-family:&quot;Tim=
es New Roman&quot;,&quot;serif&quot;;color:#1F497D">&nbsp;&nbsp;&nbsp;
</span><span lang=3D"EN-US" style=3D"font-size:16.0pt;font-family:&quot;Cal=
ibri&quot;,&quot;sans-serif&quot;;color:#1F497D">Less MTU collision risk du=
e to the usage of 20-bit long MPLS labels, rather than 128-bit long IPv6 ad=
dresses for indicating the predefined next-hops of a given
 explicit source path.</span><span lang=3D"EN-US"><o:p></o:p></span></p>
<p class=3D"MsoNormal" style=3D"mso-margin-top-alt:auto;mso-margin-bottom-a=
lt:auto"><span lang=3D"EN-US" style=3D"font-size:16.0pt;font-family:&quot;C=
alibri&quot;,&quot;sans-serif&quot;;color:#1F497D">&nbsp;</span><span lang=
=3D"EN-US"><o:p></o:p></span></p>
<p class=3D"MsoNormal" style=3D"mso-margin-top-alt:auto;mso-margin-bottom-a=
lt:auto"><span lang=3D"EN-US" style=3D"font-size:16.0pt;font-family:&quot;C=
alibri&quot;,&quot;sans-serif&quot;;color:#1F497D">Best regards,</span><spa=
n lang=3D"EN-US"><o:p></o:p></span></p>
<p class=3D"MsoNormal" style=3D"mso-margin-top-alt:auto;mso-margin-bottom-a=
lt:auto"><span lang=3D"EN-US" style=3D"font-size:16.0pt;font-family:&quot;C=
alibri&quot;,&quot;sans-serif&quot;;color:#1F497D">Xiaohu</span><span lang=
=3D"EN-US"><o:p></o:p></span></p>
<p class=3D"MsoNormal" style=3D"mso-margin-top-alt:auto;mso-margin-bottom-a=
lt:auto"><span lang=3D"EN-US" style=3D"font-size:16.0pt;font-family:&quot;C=
alibri&quot;,&quot;sans-serif&quot;;color:#1F497D">&nbsp;</span><span lang=
=3D"EN-US"><o:p></o:p></span></p>
<div style=3D"border:none;border-left:solid blue 1.5pt;padding:0cm 0cm 0cm =
4.0pt">
<div>
<div style=3D"border:none;border-top:solid #B5C4DF 1.0pt;padding:3.0pt 0cm =
0cm 0cm">
<p class=3D"MsoNormal" style=3D"mso-margin-top-alt:auto;mso-margin-bottom-a=
lt:auto"><b><span style=3D"font-size:10.0pt">=B7=A2=BC=FE=C8=CB<span lang=
=3D"EN-US">:</span></span></b><span lang=3D"EN-US" style=3D"font-size:10.0p=
t">
<a href=3D"mailto:[email-masked]" target=3D"_blank">status-bounces=
@ietf.org</a> [mailto:<a href=3D"mailto:[email-masked]" target=3D"=
_blank">[email-masked]</a>]
</span><b><span style=3D"font-size:10.0pt">=B4=FA=B1=ED </span></b><span la=
ng=3D"EN-US" style=3D"font-size:10.0pt">Stewart Bryant<br>
</span><b><span style=3D"font-size:10.0pt">=B7=A2=CB=CD=CA=B1=BC=E4<span la=
ng=3D"EN-US">:</span></span></b><span lang=3D"EN-US" style=3D"font-size:10.=
0pt"> 2013</span><span style=3D"font-size:10.0pt">=C4=EA<span lang=3D"EN-US=
">9</span>=D4=C2<span lang=3D"EN-US">4</span>=C8=D5<span lang=3D"EN-US"> 18=
:25<br>
</span><b>=CA=D5=BC=FE=C8=CB<span lang=3D"EN-US">:</span></b><span lang=3D"=
EN-US"> Mach Chen<br>
</span><b>=B3=AD=CB=CD<span lang=3D"EN-US">:</span></b><span lang=3D"EN-US"=
> John E Drake; Mark Townsley; Victor Kuarsingh; Roberta Maglione (robmgl);=
 John G. Scudder; Adrian Farrel; Alvaro Retana (aretana);
<a href=3D"mailto:[email-masked]" target=3D"_blank">[email-masked]</a><br=
>
</span><b>=D6=F7=CC=E2<span lang=3D"EN-US">:</span></b><span lang=3D"EN-US"=
> Re: [Status] Summary of STATUS BOF and the next steps</span></span><span =
lang=3D"EN-US"><o:p></o:p></span></p>
</div>
</div>
<p class=3D"MsoNormal" style=3D"mso-margin-top-alt:auto;mso-margin-bottom-a=
lt:auto"><span lang=3D"EN-US">&nbsp;<o:p></o:p></span></p>
<p class=3D"MsoNormal" style=3D"mso-margin-top-alt:auto;margin-bottom:12.0p=
t"><span lang=3D"EN-US"><br>
May I suggest that we use the name &quot;SR&quot; and worry<br>
about what it binds to later.<br>
<br>
The higher priority item is the charter text. Does<br>
anyone have any comments on the text proposed<br>
so far, or the text in the BOF proposal:<br>
<br>
<br>
The Stacked Tunnels for Source Routing (STATUS) Working Group <br>
is chartered to develop a framework and use cases for source-routed <br>
flows in packet switched networks.<br>
<br>
IP previously had a source-based routing mechanism made <br>
available through an IP Option. This mechanism has, however, <br>
not been widely used and has a number of issues that make its <br>
use inadvisable, and other mechanisms (such as RFC 1940) <br>
do not appear to have been implemented at all.<br>
<br>
The ability of a router to influence or control the forwarding <br>
path of an individual packet or all the packets of a given <br>
Forwarding Equivalence Class (FEC) is a desirable feature <br>
for a number of reasons including Label Switched Path stitching, <br>
egress protection, explicit routing, egress ASBR link selection, <br>
and backup (bypass tunnels, Remote Loop-Free Alternates) <br>
routing. This can be achieved by facilitating source-initiated <br>
selection of routes to complement the route selection <br>
provided by existing routing protocols for both inter- domain <br>
and intra-domain routes.<br>
<br>
Historically, distribution of MPLS label binding information <br>
was done by relying on label distribution protocols <br>
such as LDP and RSVP-TE.<br>
<br>
The use cases documented by the working group will <br>
indicate the network function that is being facilitated <br>
and indicate which packet data plane is to be used.<br>
<br>
The framework developed by the working group will <br>
consider forwarding of IPv4, IPv6, and MPLS using the <br>
existing unicast data planes. Multicast forwarding will <br>
be for future study and the choice of data planes will <br>
be limited to those for which use cases exist. A key <br>
objective of the work will be to ensure that source-<br>
routed packets can be handled seamlessly by existing <br>
deployed equipment. A major objective will be that the <br>
new function does not modify existing data plane behavior <br>
or architectures, and that it can be enabled through only <br>
control and management plane software upgrades at <br>
deployed devices.<br>
<br>
Once the working group has established a framework <br>
and there is demonstrable consensus for use cases, <br>
the working group will move forward to specify protocol <br>
solutions for installing forwarding information through <br>
the use of the IGPs (OSPF and IS-IS), or through the <br>
management plane. In the course of developing protocol <br>
extensions, the working group will work closely with <br>
other IETF working groups responsible for the protocols <br>
being modified (such as OSPF, ISIS, and I2RS).<br>
<br>
&nbsp;&nbsp;&nbsp; The working group is chartered for the following work it=
ems:<br>
<br>
&nbsp;&nbsp;&nbsp; A framework for the use of the existing MPLS data plane =
to <br>
&nbsp;&nbsp;&nbsp; support tunnel-based unicast source routing. <br>
<br>
&nbsp;&nbsp;&nbsp; Develop use cases for tunnel-based unicast source routin=
g <br>
&nbsp;&nbsp;&nbsp; that demonstrate the need and support for solutions. Car=
e <br>
&nbsp;&nbsp;&nbsp; should be taken to avoid clustering use cases that might=
 seem<br>
&nbsp; &nbsp; to imply support for multiple use cases when only some of the=
 <br>
&nbsp;&nbsp;&nbsp; cluster actually have wide-scale support. <br>
<br>
&nbsp;&nbsp;&nbsp; Develop ISIS and OSPF protocol extensions necessary for =
<br>
&nbsp;&nbsp; distribution of MPLS forwarding information. <br>
<br>
&nbsp;&nbsp;&nbsp; The working group will consider management (including&nb=
sp; <br>
&nbsp;&nbsp;&nbsp; configuration, reporting, diagnostics, and OAM) and secu=
rity <br>
&nbsp;&nbsp;&nbsp; implications of its work and document them in separate <=
br>
&nbsp;&nbsp;&nbsp; documents as appropriate. <br>
<br>
&nbsp;&nbsp;&nbsp; The working group is not chartered to make any changes t=
o <br>
&nbsp;&nbsp;&nbsp; the MPLS or IPv6 data planes. Any proposed changes to th=
e <br>
&nbsp;&nbsp;&nbsp; data planes are to be specified in the working groups re=
sponsible <br>
&nbsp;&nbsp;&nbsp; for the data planes (that is, the MPLS and 6MAN working =
groups,&nbsp; <br>
&nbsp;&nbsp;&nbsp; respectively).<br>
<br>
- Stewart<o:p></o:p></span></p>
</div>
</div>
</div>
<p class=3D"MsoNormal" style=3D"margin-bottom:12.0pt"><span lang=3D"EN-US">=
<br>
_______________________________________________<br>
status mailing list<br>
<a href=3D"mailto:[email-masked]">[email-masked]</a><br>
<a href=3D"https://www.ietf.org/mailman/listinfo/status" target=3D"_blank">=
https://www.ietf.org/mailman/listinfo/status</a><o:p></o:p></span></p>
</div>
<p class=3D"MsoNormal"><span lang=3D"EN-US"><o:p>&nbsp;</o:p></span></p>
</div>
</div>
</div>
</body>
</html>

--_000_1FEE3F8F5CCDE64C9A8E8F4AD27C19EE08202DBCNKGEML512MBSchi_--

Date: Thu, 5 Sep 2013 20:04:05 -0400
From: Alia Atlas <[email-masked]>
To: Robert Raszuk <[email-masked]>
Cc: Hannes Gredler <[email-masked]>, "[email-masked]" <[email-masked]>
Subject: Re: [Status] Summary of STATUS BOF and the next steps

--047d7b10cf0de7fa9904e5abc634
Content-Type: text/plain; charset=ISO-8859-1

Robert,

If you look at the charter for RTGWG, it is chartered to work on hop-by-hop
fast-reroute and
"The Routing area receives occasional proposals for the development
and publication
of RFCs dealing with routing topics, but for which the required work does
not yet rise to the level where a new working group is justified, yet the
topic does not fit with an existing working group, and it is either not
ready for a BOF or a single BOF would not provide the time to ensure a
mature proposal. The RTGWG will serve as the forum for developing these
types of proposals."

The size of the work for STATUS would take over a significant part of the
WG and hinder it from serving its current purposes.  I think that the work
doesn't fall in the parameters currently expressed in the charter.  When a
casual glance reveals at least 8+ drafts to be coordinated among many
working groups, it is naive to assume that is the extend of the work
involved.

Obviously, the WG chairs serve at the pleasure of the ADs and work on the
charter specified by the IESG.

RTGWG is not busy with a large number of WG drafts, but we nonetheless keep
occupied.  Feel free to come by sometime and see :-)

Alia

On Thu, Sep 5, 2013 at 5:43 PM, Robert Raszuk <[email-masked]> wrote:

> Hi Hannes,
>
> So you are saying that Alvaro declined to work on this in RTGWG where
> there is only 7 pretty stable active WG documents yet is keen on
> working on it in separate WG ?
>
> As far as I recall if chairs decline to work on what IETF community
> considers to be useful, chairs get replaced rather then new WGs get
> formed.
>
> Moreover I do not see any need for any "architectural work on stacking
> labels" .. as far as I recall stacking labels has been day one
> property of MPLS. Label POP - say without PHP - has also been pretty
> well known MPLS day one feature. Ooops there is no swap - does this
> grant new architecture ?
>
> Is this hypothetical WG also going to get involved in source routing
> work going on in homenet ? If not why not ?
>
> For the topic of movie being replayed I have pretty good history of
> similar past strategies where to block the substantial work various
> artificial requirements are being placed (say multicast, security,
> hold any progress of protocol extensions till architecture becomes
> normative document etc ...).
>
> I can bet that when let's say MPLS based segment routing data plane is
> complete the argument why to do this again in IPv6 will be brought up.
> Will that strategy help all customers ... clearly no.
>
> Cheers,
> R.
>
>
> >On Thu, Sep 5, 2013 at 11:17 PM, Hannes Gredler <[email-masked]>
> wrote:
> > robert,
> >
> > given that current RTGWG chairs have already declined to work on
> > architectural work on stacking labels do you have a suggestion where
> > else this work should get done ? - CCAMP or perhaps MPLS (sic!) ?
> >
> > if not would you then consider for a moment the alternative and the
> implications
> > if architectural work involving more than one target protocol would get
> done
> > at the respective protocol-WGs ? i'd predict a whole lot of hush-hush
> > protocol extensions, some even without requirements, some without
> use-cases
> > leaving a mess of incompatible protocols, leading in turn to
> multi-annual protocol
> > wars where at the end everybody has to support all protocols.
> > have seen this movie several times before and
> > as far as i am concerned i do not want this, nor my customers -
> > - they are interested in shipping, interoperable code.
> >
> > shortcutting the process aka "awww we do not all of this"
> > an inspiring unwarranted fear of "the protocol-policy wants to control
> us"
> > does not help to achieve the above.
> >
> > /hannes
> >
> > On Sep 5, 2013, at 9:00 PM, Robert Raszuk wrote:
> >
> >>> actually not. the whole point of forming a new WG is that
> >>> folks do not sneak-in "*-routing" ideas in the respective
> >>> protocol groups where people may not be paying attention.
> >>
> >> Thx for making the objective of this new WG finally very clear ;)
> >>
> >> In fact I would recommend we frame the above and make it as a charter.
> >>
> >> That way the new soon to be formed WG will be serving as *routing area
> >> preview/policy working group* preventing anyone to be able to
> >> "sneak-in" any protocol extension to respective routing protocols WGs
> >> without making sure such extensions are politically correct and
> >> approved by unanimity voting of anyone subscribed to the list.
> >>
> >> Cheers,
> >> R.
> >>
> >> PS. It's amazing to see this WG being formed considering a vast
> >> majority of people attending the quote "non working group forming BOF"
> >> in Berlin indicated no support for such new working group and segment
> >> routing architecture to be discussed in current rtwg.
> >>
> >>
> >
> >
> _______________________________________________
> status mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/status
>

--047d7b10cf0de7fa9904e5abc634
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">Robert,<div><font face=3D"arial, helvetica, sans-serif"><b=
r></font></div><div><font face=3D"arial, helvetica, sans-serif">If you look=
 at the charter for RTGWG, it is chartered to work on hop-by-hop fast-rerou=
te and</font></div>
<div><font face=3D"arial, helvetica, sans-serif">&quot;<span style=3D"color=
:rgb(0,0,0)">The Routing area receives occasional proposals for the develop=
ment and=A0</span><span style=3D"color:rgb(0,0,0)">publication of RFCs deal=
ing with routing topics, but for which the=A0</span><span style=3D"color:rg=
b(0,0,0)">required work does not yet rise to the level where a new working =
group is=A0</span><span style=3D"color:rgb(0,0,0)">justified, yet the topic=
 does not fit with an existing working group,=A0</span><span style=3D"color=
:rgb(0,0,0)">and it is either not ready for a BOF or a single BOF would not=
</span><span style=3D"color:rgb(0,0,0)">=A0provide the time to ensure a mat=
ure proposal. The RTGWG will serve as=A0</span><span style=3D"color:rgb(0,0=
,0)">the forum for developing these types of proposals.&quot;</span></font>=
</div>
<div><span style=3D"color:rgb(0,0,0);font-family:arial,helvetica,sans-serif=
"><br></span></div><div><span style=3D"color:rgb(0,0,0);font-family:arial,h=
elvetica,sans-serif">The size of the work for STATUS would take over a sign=
ificant part of the WG and hinder it from serving its current purposes. =A0=
I think that the work doesn&#39;t fall in the parameters currently expresse=
d in the charter. =A0When a casual glance reveals at least 8+ drafts to be =
coordinated among many working groups, it is naive to assume that is the ex=
tend of the work involved.</span></div>
<div><font color=3D"#000000" face=3D"arial, helvetica, sans-serif"><br></fo=
nt></div><div><font color=3D"#000000" face=3D"arial, helvetica, sans-serif"=
>Obviously, the WG chairs serve at the pleasure of the ADs and work on the =
charter specified by the IESG.</font></div>
<div><font color=3D"#000000" face=3D"arial, helvetica, sans-serif"><br></fo=
nt></div><div><span style=3D"color:rgb(0,0,0);font-family:arial,helvetica,s=
ans-serif">RTGWG is not busy with a large number of WG drafts, but we nonet=
heless keep occupied. =A0Feel free to come by sometime and see :-)=A0</span=
><font color=3D"#000000" face=3D"arial, helvetica, sans-serif"><br>
</font></div><div><span style=3D"color:rgb(0,0,0);font-family:arial,helveti=
ca,sans-serif"><br></span></div><div><span style=3D"color:rgb(0,0,0);font-f=
amily:arial,helvetica,sans-serif">Alia</span></div></div><div class=3D"gmai=
l_extra">
<br><br><div class=3D"gmail_quote">On Thu, Sep 5, 2013 at 5:43 PM, Robert R=
aszuk <span dir=3D"ltr">&lt;<a href=3D"mailto:[email-masked]" target=3D"=
_blank">[email-masked]</a>&gt;</span> wrote:<br><blockquote class=3D"gma=
il_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-lef=
t:1ex">
Hi Hannes,<br>
<br>
So you are saying that Alvaro declined to work on this in RTGWG where<br>
there is only 7 pretty stable active WG documents yet is keen on<br>
working on it in separate WG ?<br>
<br>
As far as I recall if chairs decline to work on what IETF community<br>
considers to be useful, chairs get replaced rather then new WGs get<br>
formed.<br>
<br>
Moreover I do not see any need for any &quot;architectural work on stacking=
<br>
labels&quot; .. as far as I recall stacking labels has been day one<br>
property of MPLS. Label POP - say without PHP - has also been pretty<br>
well known MPLS day one feature. Ooops there is no swap - does this<br>
grant new architecture ?<br>
<br>
Is this hypothetical WG also going to get involved in source routing<br>
work going on in homenet ? If not why not ?<br>
<br>
For the topic of movie being replayed I have pretty good history of<br>
similar past strategies where to block the substantial work various<br>
artificial requirements are being placed (say multicast, security,<br>
hold any progress of protocol extensions till architecture becomes<br>
normative document etc ...).<br>
<br>
I can bet that when let&#39;s say MPLS based segment routing data plane is<=
br>
complete the argument why to do this again in IPv6 will be brought up.<br>
Will that strategy help all customers ... clearly no.<br>
<br>
Cheers,<br>
R.<br>
<div class=3D"HOEnZb"><div class=3D"h5"><br>
<br>
&gt;On Thu, Sep 5, 2013 at 11:17 PM, Hannes Gredler &lt;<a href=3D"mailto:h=
[email-masked]">[email-masked]</a>&gt; wrote:<br>
&gt; robert,<br>
&gt;<br>
&gt; given that current RTGWG chairs have already declined to work on<br>
&gt; architectural work on stacking labels do you have a suggestion where<b=
r>
&gt; else this work should get done ? - CCAMP or perhaps MPLS (sic!) ?<br>
&gt;<br>
&gt; if not would you then consider for a moment the alternative and the im=
plications<br>
&gt; if architectural work involving more than one target protocol would ge=
t done<br>
&gt; at the respective protocol-WGs ? i&#39;d predict a whole lot of hush-h=
ush<br>
&gt; protocol extensions, some even without requirements, some without use-=
cases<br>
&gt; leaving a mess of incompatible protocols, leading in turn to multi-ann=
ual protocol<br>
&gt; wars where at the end everybody has to support all protocols.<br>
&gt; have seen this movie several times before and<br>
&gt; as far as i am concerned i do not want this, nor my customers -<br>
&gt; - they are interested in shipping, interoperable code.<br>
&gt;<br>
&gt; shortcutting the process aka &quot;awww we do not all of this&quot;<br=
>
&gt; an inspiring unwarranted fear of &quot;the protocol-policy wants to co=
ntrol us&quot;<br>
&gt; does not help to achieve the above.<br>
&gt;<br>
&gt; /hannes<br>
&gt;<br>
&gt; On Sep 5, 2013, at 9:00 PM, Robert Raszuk wrote:<br>
&gt;<br>
&gt;&gt;&gt; actually not. the whole point of forming a new WG is that<br>
&gt;&gt;&gt; folks do not sneak-in &quot;*-routing&quot; ideas in the respe=
ctive<br>
&gt;&gt;&gt; protocol groups where people may not be paying attention.<br>
&gt;&gt;<br>
&gt;&gt; Thx for making the objective of this new WG finally very clear ;)<=
br>
&gt;&gt;<br>
&gt;&gt; In fact I would recommend we frame the above and make it as a char=
ter.<br>
&gt;&gt;<br>
&gt;&gt; That way the new soon to be formed WG will be serving as *routing =
area<br>
&gt;&gt; preview/policy working group* preventing anyone to be able to<br>
&gt;&gt; &quot;sneak-in&quot; any protocol extension to respective routing =
protocols WGs<br>
&gt;&gt; without making sure such extensions are politically correct and<br=
>
&gt;&gt; approved by unanimity voting of anyone subscribed to the list.<br>
&gt;&gt;<br>
&gt;&gt; Cheers,<br>
&gt;&gt; R.<br>
&gt;&gt;<br>
&gt;&gt; PS. It&#39;s amazing to see this WG being formed considering a vas=
t<br>
&gt;&gt; majority of people attending the quote &quot;non working group for=
ming BOF&quot;<br>
&gt;&gt; in Berlin indicated no support for such new working group and segm=
ent<br>
&gt;&gt; routing architecture to be discussed in current rtwg.<br>
&gt;&gt;<br>
&gt;&gt;<br>
&gt;<br>
&gt;<br>
_______________________________________________<br>
status mailing list<br>
<a href=3D"mailto:[email-masked]">[email-masked]</a><br>
<a href=3D"https://www.ietf.org/mailman/listinfo/status" target=3D"_blank">=
https://www.ietf.org/mailman/listinfo/status</a><br>
</div></div></blockquote></div><br></div>

--047d7b10cf0de7fa9904e5abc634--

From: Hannes Gredler <[email-masked]>
Date: Fri, 6 Sep 2013 00:16:07 +0200
To: Robert Raszuk <[email-masked]>
Cc: "[email-masked]" <[email-masked]>
Subject: Re: [Status] Summary of STATUS BOF and the next steps

robert,

On Sep 5, 2013, at 11:43 PM, Robert Raszuk wrote:

> [ =85 ]
> For the topic of movie being replayed I have pretty good history of
> similar past strategies where to block the substantial work various
> artificial requirements are being placed (say multicast, security,
> hold any progress of protocol extensions till architecture becomes
> normative document etc ...).
>=20
> I can bet that when let's say MPLS based segment routing data plane is
> complete the argument why to do this again in IPv6 will be brought up.
> Will that strategy help all customers ... clearly no.

and even if you dislike it - its a valid question -
all i am asking is that we have to document the use-cases for each data =
plane
(especially for new ones) seperatetly prior to change of protocols.
i need really a bit more more substance rather than
"aww this could be interesting for service chaining =85."
before commencing expensive ASIC rework for introducing data plane #4
on the global internet.
i am sorry that the "reqs-before-protocol-work" diligence
and asking questions "if the same thing can get achieved using existing
technology" is being perceived as slow down tactics - its not;
its prudent work, nothing else.

/hannes

>> On Thu, Sep 5, 2013 at 11:17 PM, Hannes Gredler <[email-masked]> =
wrote:
>> robert,
>>=20
>> given that current RTGWG chairs have already declined to work on
>> architectural work on stacking labels do you have a suggestion where
>> else this work should get done ? - CCAMP or perhaps MPLS (sic!) ?
>>=20
>> if not would you then consider for a moment the alternative and the =
implications
>> if architectural work involving more than one target protocol would =
get done
>> at the respective protocol-WGs ? i'd predict a whole lot of hush-hush
>> protocol extensions, some even without requirements, some without =
use-cases
>> leaving a mess of incompatible protocols, leading in turn to =
multi-annual protocol
>> wars where at the end everybody has to support all protocols.
>> have seen this movie several times before and
>> as far as i am concerned i do not want this, nor my customers -
>> - they are interested in shipping, interoperable code.
>>=20
>> shortcutting the process aka "awww we do not all of this"
>> an inspiring unwarranted fear of "the protocol-policy wants to =
control us"
>> does not help to achieve the above.
>>=20
>> /hannes
>>=20
>> On Sep 5, 2013, at 9:00 PM, Robert Raszuk wrote:
>>=20
>>>> actually not. the whole point of forming a new WG is that
>>>> folks do not sneak-in "*-routing" ideas in the respective
>>>> protocol groups where people may not be paying attention.
>>>=20
>>> Thx for making the objective of this new WG finally very clear ;)
>>>=20
>>> In fact I would recommend we frame the above and make it as a =
charter.
>>>=20
>>> That way the new soon to be formed WG will be serving as *routing =
area
>>> preview/policy working group* preventing anyone to be able to
>>> "sneak-in" any protocol extension to respective routing protocols =
WGs
>>> without making sure such extensions are politically correct and
>>> approved by unanimity voting of anyone subscribed to the list.
>>>=20
>>> Cheers,
>>> R.
>>>=20
>>> PS. It's amazing to see this WG being formed considering a vast
>>> majority of people attending the quote "non working group forming =
BOF"
>>> in Berlin indicated no support for such new working group and =
segment
>>> routing architecture to be discussed in current rtwg.
>>>=20
>>>=20
>>=20
>>=20
>=20
>=20

From: "Stewart Bryant (stbryant)" <[email-masked]>
To: Robert Raszuk <[email-masked]>
Date: Thu, 5 Sep 2013 22:09:57 +0000
Accept-Language: en-GB, en-US
Cc: Hannes Gredler <[email-masked]>, "[email-masked]" <[email-masked]>
Subject: Re: [Status] Summary of STATUS BOF and the next steps

Robert,

You should set aside the the name of the WG, and whether it is a new WG or =
and existing one, and consider the charter.

WGs are constrained to only work on items specified in their charter, so wh=
ether we spin up a new WG, or put the work in an existing WG, we need a pre=
cise definition of the work, from dataplane(s), through control planes, OAM=
, management etc, since all of these will be impacted to some degree, small=
 or large, by the need to provide the consistent collection of protocol upd=
ates that will provide the SR functionality.=20

So for the moment, can we focus on the a definition of the objective of the=
 work, and an estimate of the work needed to produce a consistent design, i=
.e. focus on the charter.

Stewart

Sent from my iPad

On 5 Sep 2013, at 22:43, "Robert Raszuk" <[email-masked]> wrote:

> Hi Hannes,
>=20
> So you are saying that Alvaro declined to work on this in RTGWG where
> there is only 7 pretty stable active WG documents yet is keen on
> working on it in separate WG ?
>=20
> As far as I recall if chairs decline to work on what IETF community
> considers to be useful, chairs get replaced rather then new WGs get
> formed.
>=20
> Moreover I do not see any need for any "architectural work on stacking
> labels" .. as far as I recall stacking labels has been day one
> property of MPLS. Label POP - say without PHP - has also been pretty
> well known MPLS day one feature. Ooops there is no swap - does this
> grant new architecture ?
>=20
> Is this hypothetical WG also going to get involved in source routing
> work going on in homenet ? If not why not ?
>=20
> For the topic of movie being replayed I have pretty good history of
> similar past strategies where to block the substantial work various
> artificial requirements are being placed (say multicast, security,
> hold any progress of protocol extensions till architecture becomes
> normative document etc ...).
>=20
> I can bet that when let's say MPLS based segment routing data plane is
> complete the argument why to do this again in IPv6 will be brought up.
> Will that strategy help all customers ... clearly no.
>=20
> Cheers,
> R.
>=20
>=20
>> On Thu, Sep 5, 2013 at 11:17 PM, Hannes Gredler <[email-masked]> wro=
te:
>> robert,
>>=20
>> given that current RTGWG chairs have already declined to work on
>> architectural work on stacking labels do you have a suggestion where
>> else this work should get done ? - CCAMP or perhaps MPLS (sic!) ?
>>=20
>> if not would you then consider for a moment the alternative and the impl=
ications
>> if architectural work involving more than one target protocol would get =
done
>> at the respective protocol-WGs ? i'd predict a whole lot of hush-hush
>> protocol extensions, some even without requirements, some without use-ca=
ses
>> leaving a mess of incompatible protocols, leading in turn to multi-annua=
l protocol
>> wars where at the end everybody has to support all protocols.
>> have seen this movie several times before and
>> as far as i am concerned i do not want this, nor my customers -
>> - they are interested in shipping, interoperable code.
>>=20
>> shortcutting the process aka "awww we do not all of this"
>> an inspiring unwarranted fear of "the protocol-policy wants to control u=
s"
>> does not help to achieve the above.
>>=20
>> /hannes
>>=20
>> On Sep 5, 2013, at 9:00 PM, Robert Raszuk wrote:
>>=20
>>>> actually not. the whole point of forming a new WG is that
>>>> folks do not sneak-in "*-routing" ideas in the respective
>>>> protocol groups where people may not be paying attention.
>>>=20
>>> Thx for making the objective of this new WG finally very clear ;)
>>>=20
>>> In fact I would recommend we frame the above and make it as a charter.
>>>=20
>>> That way the new soon to be formed WG will be serving as *routing area
>>> preview/policy working group* preventing anyone to be able to
>>> "sneak-in" any protocol extension to respective routing protocols WGs
>>> without making sure such extensions are politically correct and
>>> approved by unanimity voting of anyone subscribed to the list.
>>>=20
>>> Cheers,
>>> R.
>>>=20
>>> PS. It's amazing to see this WG being formed considering a vast
>>> majority of people attending the quote "non working group forming BOF"
>>> in Berlin indicated no support for such new working group and segment
>>> routing architecture to be discussed in current rtwg.
> _______________________________________________
> status mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/status

From: "Alvaro Retana (aretana)" <[email-masked]>
To: Hannes Gredler <[email-masked]>
Date: Thu, 5 Sep 2013 21:57:31 +0000
Accept-Language: en-US
Cc: "[email-masked]" <[email-masked]>
Subject: Re: [Status] Summary of STATUS BOF and the next steps

On 9/5/13 4:17 PM, "Hannes Gredler" <[email-masked]> wrote:

Hannes:

>given that current RTGWG chairs have already declined to work on
>architectural work on stacking labels

Just to clarify: the decision was made by the IESG/ADs to hold the BOF and
then the resulting train of events.

The work that is chartered in rtgwg (or any other WG for that matter) is
not a decision made by the chairs, but it is a result of WG consensus and
(if needed) rechartering approved by the IESG/Ads.

Alvaro.

From: "Stewart Bryant (stbryant)" <[email-masked]>
To: Robert Raszuk <[email-masked]>
Date: Thu, 5 Sep 2013 21:50:28 +0000
Accept-Language: en-GB, en-US
Cc: Hannes Gredler <[email-masked]>, "[email-masked]" <[email-masked]>
Subject: Re: [Status] Summary of STATUS BOF and the next steps

Robert, please read my summary email that started this thread.

Given 7 WGs that need to contribute (before we even consider OAM and Manage=
ment, or the inevitable feature creep ) and the work potentially spanning t=
wo IETF areas, there needs to be some group that can see the whole picture,=
 and act a as a focus to ensure a consistent design.

Stewart

Sent from my iPad

On 5 Sep 2013, at 20:01, "Robert Raszuk" <[email-masked]> wrote:

>> actually not. the whole point of forming a new WG is that
>> folks do not sneak-in "*-routing" ideas in the respective
>> protocol groups where people may not be paying attention.
>=20
> Thx for making the objective of this new WG finally very clear ;)
>=20
> In fact I would recommend we frame the above and make it as a charter.
>=20
> That way the new soon to be formed WG will be serving as *routing area
> preview/policy working group* preventing anyone to be able to
> "sneak-in" any protocol extension to respective routing protocols WGs
> without making sure such extensions are politically correct and
> approved by unanimity voting of anyone subscribed to the list.
>=20
> Cheers,
> R.
>=20
> PS. It's amazing to see this WG being formed considering a vast
> majority of people attending the quote "non working group forming BOF"
> in Berlin indicated no support for such new working group and segment
> routing architecture to be discussed in current rtwg.
> _______________________________________________
> status mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/status

Sender: [email-masked]
Date: Thu, 5 Sep 2013 23:43:12 +0200
From: Robert Raszuk <[email-masked]>
To: Hannes Gredler <[email-masked]>
Cc: "[email-masked]" <[email-masked]>
Subject: Re: [Status] Summary of STATUS BOF and the next steps

Hi Hannes,

So you are saying that Alvaro declined to work on this in RTGWG where
there is only 7 pretty stable active WG documents yet is keen on
working on it in separate WG ?

As far as I recall if chairs decline to work on what IETF community
considers to be useful, chairs get replaced rather then new WGs get
formed.

Moreover I do not see any need for any "architectural work on stacking
labels" .. as far as I recall stacking labels has been day one
property of MPLS. Label POP - say without PHP - has also been pretty
well known MPLS day one feature. Ooops there is no swap - does this
grant new architecture ?

Is this hypothetical WG also going to get involved in source routing
work going on in homenet ? If not why not ?

For the topic of movie being replayed I have pretty good history of
similar past strategies where to block the substantial work various
artificial requirements are being placed (say multicast, security,
hold any progress of protocol extensions till architecture becomes
normative document etc ...).

I can bet that when let's say MPLS based segment routing data plane is
complete the argument why to do this again in IPv6 will be brought up.
Will that strategy help all customers ... clearly no.

Cheers,
R.

>On Thu, Sep 5, 2013 at 11:17 PM, Hannes Gredler <[email-masked]> wrote:
> robert,
>
> given that current RTGWG chairs have already declined to work on
> architectural work on stacking labels do you have a suggestion where
> else this work should get done ? - CCAMP or perhaps MPLS (sic!) ?
>
> if not would you then consider for a moment the alternative and the implications
> if architectural work involving more than one target protocol would get done
> at the respective protocol-WGs ? i'd predict a whole lot of hush-hush
> protocol extensions, some even without requirements, some without use-cases
> leaving a mess of incompatible protocols, leading in turn to multi-annual protocol
> wars where at the end everybody has to support all protocols.
> have seen this movie several times before and
> as far as i am concerned i do not want this, nor my customers -
> - they are interested in shipping, interoperable code.
>
> shortcutting the process aka "awww we do not all of this"
> an inspiring unwarranted fear of "the protocol-policy wants to control us"
> does not help to achieve the above.
>
> /hannes
>
> On Sep 5, 2013, at 9:00 PM, Robert Raszuk wrote:
>
>>> actually not. the whole point of forming a new WG is that
>>> folks do not sneak-in "*-routing" ideas in the respective
>>> protocol groups where people may not be paying attention.
>>
>> Thx for making the objective of this new WG finally very clear ;)
>>
>> In fact I would recommend we frame the above and make it as a charter.
>>
>> That way the new soon to be formed WG will be serving as *routing area
>> preview/policy working group* preventing anyone to be able to
>> "sneak-in" any protocol extension to respective routing protocols WGs
>> without making sure such extensions are politically correct and
>> approved by unanimity voting of anyone subscribed to the list.
>>
>> Cheers,
>> R.
>>
>> PS. It's amazing to see this WG being formed considering a vast
>> majority of people attending the quote "non working group forming BOF"
>> in Berlin indicated no support for such new working group and segment
>> routing architecture to be discussed in current rtwg.
>>
>>
>
>

From: Hannes Gredler <[email-masked]>
Date: Thu, 5 Sep 2013 23:17:15 +0200
To: Robert Raszuk <[email-masked]>
Cc: "[email-masked]" <[email-masked]>
Subject: Re: [Status] Summary of STATUS BOF and the next steps

robert,

given that current RTGWG chairs have already declined to work on
architectural work on stacking labels do you have a suggestion where
else this work should get done ? - CCAMP or perhaps MPLS (sic!) ?

if not would you then consider for a moment the alternative and the =
implications
if architectural work involving more than one target protocol would get =
done
at the respective protocol-WGs ? i'd predict a whole lot of hush-hush
protocol extensions, some even without requirements, some without =
use-cases
leaving a mess of incompatible protocols, leading in turn to =
multi-annual protocol
wars where at the end everybody has to support all protocols.
have seen this movie several times before and
as far as i am concerned i do not want this, nor my customers -
- they are interested in shipping, interoperable code.

shortcutting the process aka "awww we do not all of this"
an inspiring unwarranted fear of "the protocol-policy wants to control =
us"
does not help to achieve the above.

/hannes

On Sep 5, 2013, at 9:00 PM, Robert Raszuk wrote:

>> actually not. the whole point of forming a new WG is that
>> folks do not sneak-in "*-routing" ideas in the respective
>> protocol groups where people may not be paying attention.
>=20
> Thx for making the objective of this new WG finally very clear ;)
>=20
> In fact I would recommend we frame the above and make it as a charter.
>=20
> That way the new soon to be formed WG will be serving as *routing area
> preview/policy working group* preventing anyone to be able to
> "sneak-in" any protocol extension to respective routing protocols WGs
> without making sure such extensions are politically correct and
> approved by unanimity voting of anyone subscribed to the list.
>=20
> Cheers,
> R.
>=20
> PS. It's amazing to see this WG being formed considering a vast
> majority of people attending the quote "non working group forming BOF"
> in Berlin indicated no support for such new working group and segment
> routing architecture to be discussed in current rtwg.
>=20
>=20

Sender: [email-masked]
Date: Thu, 5 Sep 2013 21:49:03 +0200
From: Robert Raszuk <[email-masked]>
To: "Alvaro Retana (aretana)" <[email-masked]>
Cc: "[email-masked]" <[email-masked]>
Subject: Re: [Status] Summary of STATUS BOF and the next steps

Why not whole routing area if:

"the whole point of forming a new WG is that
folks do not sneak-in "*-routing" ideas in the respective
protocol groups where people may not be paying attention."

Let's set it up once and be done.

Cheers,
R.

On Thu, Sep 5, 2013 at 9:31 PM, Alvaro Retana (aretana)
<[email-masked]> wrote:
> On 9/5/13 2:00 PM, "Robert Raszuk" <[email-masked]> wrote:
>
>>>actually not. the whole point of forming a new WG is that
>>>folks do not sneak-in "*-routing" ideas in the respective
>>>protocol groups where people may not be paying attention.
>>
>>Thx for making the objective of this new WG finally very clear ;)
>>
>>In fact I would recommend we frame the above and make it as a charter.
>>
>>That way the new soon to be formed WG will be serving as *routing area
>>preview/policy working group* preventing anyone to be able to
>>"sneak-in" any protocol extension to respective routing protocols WGs
>>without making sure such extensions are politically correct and
>>approved by unanimity voting of anyone subscribed to the list.
>
> Robert:
>
> Hi!
>
> I assume you mean "preview/policy WG" for the technology in the charter
> (segment routing, or however you want to call it), and not for the whole
> routing area, right? ;-)
>
> Thanks!
>
> Alvaro.
>

From: "Alvaro Retana (aretana)" <[email-masked]>
To: Robert Raszuk <[email-masked]>
Date: Thu, 5 Sep 2013 19:31:02 +0000
Accept-Language: en-US
Cc: "[email-masked]" <[email-masked]>
Subject: Re: [Status] Summary of STATUS BOF and the next steps

On 9/5/13 2:00 PM, "Robert Raszuk" <[email-masked]> wrote:

>>actually not. the whole point of forming a new WG is that
>>folks do not sneak-in "*-routing" ideas in the respective
>>protocol groups where people may not be paying attention.
>
>Thx for making the objective of this new WG finally very clear ;)
>
>In fact I would recommend we frame the above and make it as a charter.
>
>That way the new soon to be formed WG will be serving as *routing area
>preview/policy working group* preventing anyone to be able to
>"sneak-in" any protocol extension to respective routing protocols WGs
>without making sure such extensions are politically correct and
>approved by unanimity voting of anyone subscribed to the list.

Robert:

Hi!

I assume you mean "preview/policy WG" for the technology in the charter
(segment routing, or however you want to call it), and not for the whole
routing area, right? ;-)

Thanks!

Alvaro.

Sender: [email-masked]
Date: Thu, 5 Sep 2013 21:00:54 +0200
From: Robert Raszuk <[email-masked]>
To: Hannes Gredler <[email-masked]>
Cc: "[email-masked]" <[email-masked]>
Subject: Re: [Status] Summary of STATUS BOF and the next steps

> actually not. the whole point of forming a new WG is that
> folks do not sneak-in "*-routing" ideas in the respective
> protocol groups where people may not be paying attention.

Thx for making the objective of this new WG finally very clear ;)

In fact I would recommend we frame the above and make it as a charter.

That way the new soon to be formed WG will be serving as *routing area
preview/policy working group* preventing anyone to be able to
"sneak-in" any protocol extension to respective routing protocols WGs
without making sure such extensions are politically correct and
approved by unanimity voting of anyone subscribed to the list.

Cheers,
R.

PS. It's amazing to see this WG being formed considering a vast
majority of people attending the quote "non working group forming BOF"
in Berlin indicated no support for such new working group and segment
routing architecture to be discussed in current rtwg.

From: John E Drake <[email-masked]>
To: AshwoodsmithPeter <[email-masked]>, "[email-masked]" <[email-masked]>
Date: Thu, 5 Sep 2013 17:55:51 +0000
Accept-Language: en-US
Subject: Re: [Status] Summary of STATUS BOF and the next steps

Peter,

Comments inline.

Yours Irrespectively,

John

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf
> Of AshwoodsmithPeter
> Sent: Thursday, September 05, 2013 6:40 AM
> To: [email-masked]
> Subject: Re: [Status] Summary of STATUS BOF and the next steps
>=20
> [HG] the "moving pointer" is a requirement without an actual use case - d=
o
> you know how this would be used ? - i don't
>=20
> [SLI] Interrest is to keep tracking where the packet is coming from. I'm =
not
> saying that this is a good the solution or not ... working group should d=
ecide
> ... but enforcing "stacking" is the charter may close door to some other
> solutions.
>=20
> There are a number of interesting uses when the history of the packet's
> flight is available.
>=20
>  - tandem fast reroute mechanisms can use previous hops as context to
> spread traffic to different alternate next hops.

[JD]  This information is useless.  Regardless of the paths that packets to=
ok to reach a given transit node, that node is presented with a composite s=
et of traffic flows for each egress node.  It will need to spread the packe=
ts of these flows across its ECMP paths to that egress node by replacing th=
e explicit route in each packet with an explicit route specifying one of th=
ese ECMP paths, subject to the requirement that all packets of a given flow=
 follow the same path.

Also, this is strictly a transient case which stops being of interest once =
the ingress nodes receive the IGP update from the transit node that indicat=
ing the link in question has failed, because at this point the ingress node=
s will compute new explicit routes that don't use the failed link. =20

>  - one can create 1:1 end to end protected paths with reverse path fate
> sharing for the probes, no need to install state at both ends.

[JD]  Without installing state, how will an egress node know which packets =
from a given ingress node are following disjoint paths through the network?=
  I.e., there will be a multiplicity of disjoint path pairs that a given in=
gress node is using to send packets to that egress node.=20

>  - greatly simplified debugging of network.

[JD]  If a packet is misdirected by a transit node, then that transit node =
is obviously not processing the explicit route correctly.  Therefore, what =
is the utility of having the complete explicit route computed by the ingres=
s node in such a misdirected packet, since it is clearly not being followed=
?

I think it would be far more effective to dynamically accumulate a given pa=
cket's path through the network. =20

>  - easier to build network flow information by simply inspecting traffic =
flowing
> through small number of representative network cuts.
=20
[JD]  In a real network with a large number of ECMP paths between ingress/e=
gress node pairs, what leads you to assume that querying a small number of =
transit nodes will give one any idea of how the traffic is flowing through =
one's network?  Why isn't simply querying the ingress nodes both simpler an=
d more effective?
=20
Also, this is obviously useless if a central controller is being used.

>  - reverse path checks can be used for authentication.

[JD]  Reverse path checks are done at the ingress to a network not at the e=
gress. =20

>  - potentially halves the amount of work an central (SDN or Forces) contr=
oller
> must do (assuming symmetry is desired).

[JD]  The phrase 'false economy' springs to mind.=20

>=20
> Admittedly these are longer term uses, but for these reasons and others I
> hope that we do not close the door to keeping track of the history of the
> packet's flight.
>=20
> Cheers,
>=20
> Peter
>=20
> _______________________________________________
> status mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/status
>=20

From: AshwoodsmithPeter <[email-masked]>
To: "[email-masked]" <[email-masked]>
Date: Thu, 5 Sep 2013 13:51:26 +0000
Accept-Language: en-US, zh-CN
Subject: Re: [Status] Summary of STATUS BOF and the next steps

George, the existing architecture document does a pretty good job IMHO. Not=
 perfect of course, but they lay out the properties that are desirable and =
then map them to IP and MPLS. I hope we can keep that approach in the WG.=20

Peter

-----Original Message-----
From: Rob Shakir [mailto:[email-masked]]=20
Sent: Thursday, September 05, 2013 5:23 AM
To: George Swallow (swallow)
Cc: AshwoodsmithPeter; [email-masked]
Subject: Re: [Status] Summary of STATUS BOF and the next steps

On 4 Sep 2013, at 22:38, "George Swallow (swallow)" <[email-masked]> wro=
te:

> I actually don't think it is possible to write a dataplane agnostic archi=
tecture.   We can write an architecture document that is 90% dataplane inde=
pendent and then has some dataplane dependencies.  E.g. having the full SR =
path available at each hop vs the remainder.

You're right, maybe "agnostic" is an overstatement, but it at least needs t=
o be data plane independent as you say (such that the architecture does not=
 link to a specific data plane, but can be re-used across them). The way th=
at we develop the architecture should of course take into account what the =
capabilities are of the data planes that we envisage deploying SR on.

r.

From: AshwoodsmithPeter <[email-masked]>
To: "[email-masked]" <[email-masked]>
Date: Thu, 5 Sep 2013 13:39:54 +0000
Accept-Language: en-US, zh-CN
Subject: Re: [Status] Summary of STATUS BOF and the next steps

[HG] the "moving pointer" is a requirement without an actual use case - do =
you know how this would be used ? - i don't

[SLI] Interrest is to keep tracking where the packet is coming from. I'm no=
t saying that this is a good the solution or not ... working group should d=
ecide ... but enforcing "stacking" is the charter may close door to some ot=
her solutions.

There are a number of interesting uses when the history of the packet's fli=
ght is available.

 - tandem fast reroute mechanisms can use previous hops as context to sprea=
d traffic to different alternate next hops.
 - one can create 1:1 end to end protected paths with reverse path fate sha=
ring for the probes, no need to install state at both ends.
 - greatly simplified debugging of network.
 - easier to build network flow information by simply inspecting traffic fl=
owing through small number of representative network cuts.
 - reverse path checks can be used for authentication.
 - potentially halves the amount of work an central (SDN or Forces) control=
ler must do (assuming symmetry is desired).

Admittedly these are longer term uses, but for these reasons and others I h=
ope that we do not close the door to keeping track of the history of the pa=
cket's flight.=20

Cheers,

Peter

From: "Stefano Previdi (sprevidi)" <[email-masked]>
To: Hannes Gredler <[email-masked]>
Date: Thu, 5 Sep 2013 13:32:35 +0000
Accept-Language: en-US
Cc: Stephane Litkowski <[email-masked]>, "[email-masked]" <[email-masked]>
Subject: Re: [Status] Summary of STATUS BOF and the next steps

On Sep 5, 2013, at 10:50 AM, Hannes Gredler wrote:

> hi stefano,
>=20
> please see comments inline;
>=20
> On Sep 5, 2013, at 10:18 AM, Stefano Previdi (sprevidi) wrote:
>=20
>> Hannes, Stephane,
>>=20
>>=20
>> On Sep 5, 2013, at 10:00 AM, Hannes and Stephane wrote:
>>>=20
>>> Hannes,
>>>=20
>>>=20
>>>> In the proposed segment routing architectural concepts, segments are
>>>> at the same "level" and pointer moves on the segment list, then the
>>>> MPLS instantiation is performing this using stacking ...
>>>=20
>>> [HG] the "moving pointer" is a requirement without an actual use case -=
 do you know how this would be used ? - i don't
>>>=20
>>> [SLI] Interrest is to keep tracking where the packet is coming from. I'=
m not saying that this is a good the solution or not ... working group shou=
ld decide ... but enforcing "stacking" is the charter may close door to som=
e other solutions.
>>=20
>>=20
>> absolutely agree. Data-plane agnostic means there may be differences
>> in the way data-planes instantiate a function.
>>=20
>> If one data-plane stacks, the other may point. Nothing wrong with=20
>> this.
>>=20
>>=20
>>>> Finally, about the "routing" word, routing is essentially a "forward" =
action which may limit the scope of what we can do by using a segment list.=
 Actions associated with a segment could be something else than forwarding.
>>>> Do we want in the charter to limit the scope to routing actions ?
>>>>=20
>>>=20
>>> HG> as per the published use-case drafts all i have seen are use-cases
>>> HG> related to
>>> "forwarding". as far as i am concerned i am good limiting the scope to =
"routing actions".
>>=20
>>=20
>> not me. There are use cases, (still to document but pretty real) that
>> are not routing based. Service Chaining is one.
>=20
> HG> the use cases becomes "real" once they see the light of day (=3Dpubli=
cation)

I'm producing a charter proposal that includes use-cases document=20
publication.

>    in the meantime they'll remain "fictional".
>    for network service chaining it is my understanding that there is a de=
dicated BOF/WG.
>    i fail to see why we would need to do it here. - quite contrary it may=
 be one of those things
>    that http://tools.ietf.org/html/rfc1925 section 2 point (5) warns us a=
bout.
>=20
>>> [SLI] We had to start with something simple, that's why the current use=
 cases are related only to forwarding. But it's not a reason to limit the c=
harter to this ...
>>=20
>>=20
>> absolutely agree.
>=20
> HG> good so lets keep it out for now, and change charter later as require=
ments become more clear;

I don't think we want to keep it out.

s.

>=20
>>=20
>>>> - They form a connected network
>>>>     [SLI] InterAS case must be included, but the WG can go step by ste=
p and first release intraAS, and then doing interAS (in relation with IDR ?=
?).
>>>=20
>>> HG> did i preclude inter-AS in any way ?
>>>=20
>>> [SLI] It was not clear to me what did you put behind "connected network=
"
>>>=20
>>>=20
>>>> - They can forward traffic through the shortest paths or paths other t=
han the shortest (the latter called explicitly routed paths, or explicit pa=
ths)
>>>>     [SLI] There is something else between SPT and Explicit path, you c=
an define other algorithms than SPT to define a path, and it's not explicit=
 path. Moreover I come back to my comment, on do we want to limit the scope=
 to routing ? I would say no.
>>>=20
>>> HG> if you have a case for non-routing, please make it; - IIRC in our
>>> HG> past 6 months of
>>> conversation around IGP label advertisement / SR we haven't discussed a=
ny non-routing use-case.
>>=20
>>=20
>> Service chaining is one of them.
>>=20
>> Thanks.
>>=20
>> s.
>>=20
>>=20
>>=20
>>> [SLI] Non routing use case are more future ...  routing is the basic in=
frastructure on top of which you can add some stuffs.
>>>=20
>>>=20
>>> Stephane
>>>=20
>>>=20
>>>=20
>>>=20
>>> -----Message d'origine-----
>>> De : Hannes Gredler [mailto:[email-masked]]
>>> Envoy=E9 : jeudi 5 septembre 2013 05:54
>>> =C0 : LITKOWSKI Stephane DTF/DERX
>>> Cc : [email-masked]
>>> Objet : Re: [Status] Summary of STATUS BOF and the next steps
>>>=20
>>> hi stephane,
>>>=20
>>> see comments inline prefixed by HG>
>>>=20
>>> On Sep 4, 2013, at 10:02 AM, <[email-masked]> <stephane.=
[email-masked]> wrote:
>>>> case, we are using only directed forwarding (adjacency segment),
>>>> could we still talk about tunneling ? (it's a very very small tunnel)
>>>> Moreover talking about "stacking" is really dataplane agnostic (MPLS)
>>>> ...
>>>=20
>>> HG> one-hop tunnels are ok;
>>>=20
>>>> In the proposed segment routing architectural concepts, segments are
>>>> at the same "level" and pointer moves on the segment list, then the
>>>> MPLS instantiation is performing this using stacking ...
>>>=20
>>> the "moving pointer" is a requirement without an actual use case - do y=
ou know how this would be used ? - i don't
>>>=20
>>>> IMHO, if we use "Stacked Tunnels", we already talk about a chosen
>>>> solution and it's closing the door to something else  ...
>>>=20
>>> HG> closing door to things we have no (known) requirements for is ok;
>>> being anything to anybody is not helpful - the more concise the charter=
 the better;
>>>=20
>>>> Finally, about the "routing" word, routing is essentially a "forward" =
action which may limit the scope of what we can do by using a segment list.=
 Actions associated with a segment could be something else than forwarding.
>>>> Do we want in the charter to limit the scope to routing actions ?
>>>>=20
>>>=20
>>> HG> as per the published use-case drafts all i have seen are use-cases
>>> HG> related to
>>> "forwarding". as far as i am concerned i am good limiting the scope to =
"routing actions".
>>>=20
>>>> I have no solution today to propose for the naming, but I completely a=
gree with Loa, to first focus on working on the charter, and define a clear=
 scope of the work and then the name will be easier to find.
>>>=20
>>> HG> good :-)
>>>=20
>>>> Regarding your charter proposal :
>>>>=20
>>>> --------
>>>>=20
>>>> - They form a connected network
>>>>     [SLI] InterAS case must be included, but the WG can go step by ste=
p and first release intraAS, and then doing interAS (in relation with IDR ?=
?).
>>>=20
>>> HG> did i preclude inter-AS in any way ?
>>>=20
>>>> - They can forward traffic through the shortest paths or paths other t=
han the shortest (the latter called explicitly routed paths, or explicit pa=
ths)
>>>>     [SLI] There is something else between SPT and Explicit path, you c=
an define other algorithms than SPT to define a path, and it's not explicit=
 path. Moreover I come back to my comment, on do we want to limit the scope=
 to routing ? I would say no.
>>>=20
>>> HG> if you have a case for non-routing, please make it; - IIRC in our
>>> HG> past 6 months of
>>> conversation around IGP label advertisement / SR we haven't discussed a=
ny non-routing use-case.
>>>=20
>>>> - They share a common trust model. In this model, any router within th=
e ERD can specify an explicit path between itself and any other router in t=
he ERD. It can then send any packet that passes through it through any path=
 that it has specified.
>>>>     [SLI] Security considerations may have to be addressed in the
>>>> charter , especially for the interAS case (trust yes, but not sure
>>>> access to everything may not be good)
>>>=20
>>> HG> ok.
>>>=20
>>>> Downstream routers within the ERD forward the packet as specified by t=
he router at the head-end of the path.
>>>> [SLI] Yes, but any router in the middle may be able to change the end =
to end explicit path.
>>>=20
>>> HG> is there any application outside FRR for changing an explicit path =
?
>>>=20
>>>> - The first goal of the STER WG is to identify use-cases for ERDs.
>>>> - Having identified use-cases, the WG will identify gaps between curre=
ntly available technologies and use-case requirements.
>>>> - The WG will then define requirements for extensions to existing prot=
ocols or new protocols that address gaps that are identified.
>>>>=20
>>>> [SLI] Agree, I would add :
>>>> - defining the architecture framework
>>>> - analysing the security considerations
>>>=20
>>> HG> ok;
>>>=20
>>>>=20
>>>>=20
>>>> Here would be my proposal to extend yours :
>>>>=20
>>>> A <named to be defined> domain contains a set of routers with the foll=
owing characteristics:
>>>>=20
>>>> - They form a connected network
>>>> - They can forward traffic through any path within the network using
>>>> shortest path, non shortest path or explicit path
>>>> - They may provide other types of services than forwarding and they ca=
n enforce service actions in the path.
>>>> - They share a common trust model. In this model, any router within th=
e domain can specify a path between itself and any other router in the doma=
in. It may then send any packet that passes through it through any path tha=
t it has specified and that is conform to the security rules. Downstream ro=
uters within the ERD forward the packet as specified by the router at the h=
ead-end of the path.
>>>>=20
>>>> The <name> working group is chartered for the following ordered list o=
f work items:
>>>>=20
>>>> - The first goal of the WG is to identify use-cases.
>>>> - The WG will then define the architecture framework associated with t=
he security considerations. The architecture framework and security conside=
rations must address the relations between domains (interdomain).
>>>> - Having identified use-cases, architecture and security, the WG will =
identify gaps between currently available technologies and use-case require=
ments.
>>>> - The WG will then define requirements for extensions to existing prot=
ocols or new protocols that address gaps that are identified.
>>>> - The WG will first focus on the intra-domain forwarding definition.
>>>>=20
>>>> Protocol work may be carried out in this working group or in other wor=
king groups responsible for the protocols, in coordination with this WG, an=
d in agreement with the WG chairs and responsible ADs. However, no protocol=
 work will be adopted by a working group to address the ERD use-cases until=
 the requirements document motivating the protocol work has been sent to th=
e IESG for publication as an RFC.
>>>>=20
>>>> -----Message d'origine-----
>>>> De : [email-masked] [mailto:[email-masked]] De la
>>>> part de Hannes Gredler Envoy=E9 : mardi 3 septembre 2013 18:31 =C0 : L=
oa
>>>> Andersson Cc : [email-masked] Objet : Re: [Status] Summary of STATUS
>>>> BOF and the next steps
>>>>=20
>>>> good point - what about this charter proposal ?
>>>>=20
>>>> ---
>>>>=20
>>>> Stacked Tunnels for Explicit Routing (STER)
>>>> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
>>>>=20
>>>> A explicit routing domain (ERD) contains a set of routers with the fol=
lowing characteristics:
>>>>=20
>>>> - They form a connected network
>>>> - They can forward traffic through the shortest paths or paths other
>>>> than the shortest (the latter called explicitly routed paths, or
>>>> explicit paths)
>>>> - They share a common trust model. In this model, any router within th=
e ERD can specify an explicit path between itself and any other router in t=
he ERD. It can then send any packet that passes through it through any path=
 that it has specified. Downstream routers within the ERD forward the packe=
t as specified by the router at the head-end of the path.
>>>>=20
>>>> The STER working group is chartered for the following ordered list of =
work items:
>>>>=20
>>>> - The first goal of the STER WG is to identify use-cases for ERDs.
>>>> - Having identified use-cases, the WG will identify gaps between curre=
ntly available technologies and use-case requirements.
>>>> - The WG will then define requirements for extensions to existing prot=
ocols or new protocols that address gaps that are identified.
>>>>=20
>>>> Protocol work may be carried out in this working group or in other wor=
king groups responsible for the protocols, in coordination with this WG, an=
d in agreement with the WG chairs and responsible ADs. However, no protocol=
 work will be adopted by a working group to address the ERD use-cases until=
 the requirements document motivating the protocol work has been sent to th=
e IESG for publication as an RFC.
>>>>=20
>>>> ---
>>>>=20
>>>> <flame suit on>
>>>>=20
>>>> /hannes
>>>>=20
>>>>=20
>>>> On Sep 3, 2013, at 5:31 PM, Loa Andersson wrote:
>>>>=20
>>>>> Folks,
>>>>>=20
>>>>> Excuse me if I'm slightly out of the loop, but so far I have not seen
>>>>> a charter proposal, if there is one please point me to it.
>>>>>=20
>>>>> It seems a bit odd to put the cart (what the wg should do) before the
>>>>> horse (wg name). If we drill down the the charter first the wg name
>>>>> might be easier to figure out.
>>>>>=20
>>>>> /Loa
>>>>>=20
>>>>> PS
>>>>> OK I understand that the horse and cart analogy limps a  bit :).
>>>>>=20
>>>>>=20
>>>>>=20
>>>>> On 2013-09-03 17:22, AshwoodsmithPeter wrote:
>>>>>> " If the WG charter is limited to source routing, how will we handle=
 the "non source routing" use cases of segment routing ? In another working=
 group ? So we will go back to the WG synchronization issue that has been r=
aised for this technology ..."
>>>>>>=20
>>>>>> That's why I suggested SRV2. We are revisiting source routing with n=
ew concepts. More generic number/action behavior.
>>>>>>=20
>>>>>> Peter
>>>>>>=20
>>>>>> -----Original Message-----
>>>>>> From: [email-masked] [mailto:[email-masked]] On
>>>>>> Behalf Of [email-masked]
>>>>>> Sent: Tuesday, September 03, 2013 10:43 AM
>>>>>> To: AshwoodsmithPeter
>>>>>> Cc: [email-masked]
>>>>>> Subject: Re: [Status] Summary of STATUS BOF and the next steps
>>>>>>=20
>>>>>>=20
>>>>>> There was a misunderstanding in my small comment :) so I will explai=
n more :
>>>>>>=20
>>>>>> In segment routing, you have more than basic source routing : segmen=
t routing is just associate a segment number to an action and then combine =
segment as you want, yes you can do source routing, but you also can do mor=
e.
>>>>>>=20
>>>>>> In the other hand, I completely agree with your statement that
>>>>>> source routing is generic and dataplane agnostic, as segment routing=
 is ...
>>>>>> (segment routing is not a new dataplane ...)
>>>>>>=20
>>>>>> Now the definition of the WG naming must be inline with the charter
>>>>>> that will be defined ... (draft today)
>>>>>>=20
>>>>>> Based on the already existing consensus (at least for MPLS dataplane=
) brought up during Berlin STATUS BOF meeting, segment routing sounds to be=
 a good target candidate.
>>>>>>=20
>>>>>> So now, do we want to do more in the WG charter than just make progr=
essing segment routing architecture and uses cases document and ensure coor=
dination for the standardization of this technology ?
>>>>>>=20
>>>>>> Do we want to standardize other technologies in this WG ? I don't th=
ink so, based on Stewart's conclusion email from the BOF :"A new WG focused=
 solely on SR therefore needs to be create"
>>>>>>=20
>>>>>> If the WG charter is limited to source routing, how will we handle t=
he "non source routing" use cases of segment routing ? In another working g=
roup ? So we will go back to the WG synchronization issue that has been rai=
sed for this technology ...
>>>>>>=20
>>>>>> If the WG is focused on SR, let's use a name in relation with SR.
>>>>>>=20
>>>>>> Feedback ?
>>>>>>=20
>>>>>>=20
>>>>>> Stephane
>>>>>>=20
>>>>>>=20
>>>>>> -----Message d'origine-----
>>>>>> De : AshwoodsmithPeter [mailto:[email-masked]]
>>>>>> Envoy=E9 : mardi 3 septembre 2013 15:27 =C0 : LITKOWSKI Stephane
>>>>>> DTF/DERX Cc : John E Drake; Mark Townsley; Victor Kuarsingh; Roberta
>>>>>> Maglione (robmgl); John G. Scudder; Adrian Farrel; Alvaro Retana
>>>>>> (aretana); [email-masked]; Stewart Bryant (stbryant) Objet : Re:
>>>>>> [Status] Summary of STATUS BOF and the next steps
>>>>>>=20
>>>>>> The term "source routing" has been around for a very long time and i=
s data path agnostic. Its also the term used in the literature etc so my pr=
eference is to stick with this existing well known and data path agnostic t=
erm.
>>>>>>=20
>>>>>> Peter
>>>>>>=20
>>>>>> On Sep 3, 2013, at 9:07 AM, "[email-masked]" <stephan=
[email-masked]> wrote:
>>>>>>=20
>>>>>>> Hi,
>>>>>>>=20
>>>>>>> "Source routing" is just a subcase of segment routing ... as it is =
for IP routing ...
>>>>>>>=20
>>>>>>> Stephane
>>>>>>>=20
>>>>>>>=20
>>>>>>> -----Message d'origine-----
>>>>>>> De : [email-masked] [mailto:[email-masked]] De la
>>>>>>> part de John E Drake Envoy=E9 : mardi 3 septembre 2013 15:02 =C0 : =
Mark
>>>>>>> Townsley; Victor Kuarsingh Cc : Roberta Maglione (robmgl); John G.
>>>>>>> Scudder; Alvaro Retana (aretana); Adrian Farrel; [email-masked];
>>>>>>> Stewart Bryant (stbryant) Objet : Re: [Status] Summary of STATUS
>>>>>>> BOF and the next steps
>>>>>>>=20
>>>>>>> Hi,
>>>>>>>=20
>>>>>>> What is this 'segment routing' silliness?  The correct term is 'sou=
rce routing'.
>>>>>>>=20
>>>>>>> Yours Irrespectively,
>>>>>>>=20
>>>>>>> John
>>>>>>>=20
>>>>>>>> -----Original Message-----
>>>>>>>> From: [email-masked] [mailto:[email-masked]] On
>>>>>>>> Behalf Of Mark Townsley
>>>>>>>> Sent: Sunday, September 01, 2013 10:08 AM
>>>>>>>> To: Victor Kuarsingh
>>>>>>>> Cc: Roberta Maglione (robmgl); John G. Scudder; Adrian Farrel;
>>>>>>>> Alvaro Retana (aretana); [email-masked]; Stewart Bryant
>>>>>>>> (stbryant)
>>>>>>>> Subject: Re: [Status] Summary of STATUS BOF and the next steps
>>>>>>>>=20
>>>>>>>>=20
>>>>>>>> On Sep 1, 2013, at 5:38 PM, Victor Kuarsingh wrote:
>>>>>>>>=20
>>>>>>>>> All,
>>>>>>>>>=20
>>>>>>>>> I would also favour "Segment Routing WG" as well.
>>>>>>>>>=20
>>>>>>>>> I note this since attempting to come up with an all encompassing
>>>>>>>>> acronym will be difficult and Segment Routing is generic enough
>>>>>>>>> to associate to multiple functions.
>>>>>>>>=20
>>>>>>>> Then we can just use "segroute" for the short name. WGs do not
>>>>>>>> have to have acronyms, but they do need to have an 8-char limited
>>>>>>>> short name for the various automated tools not to break.
>>>>>>>>=20
>>>>>>>> - Mark
>>>>>>>>=20
>>>>>>>>>=20
>>>>>>>>> Regards,
>>>>>>>>>=20
>>>>>>>>> Victor K
>>>>>>>>>=20
>>>>>>>>>=20
>>>>>>>>>=20
>>>>>>>>> On 2013-08-31 6:51 PM, "Roberta Maglione (robmgl)"
>>>>>>>>> <[email-masked]>
>>>>>>>>> wrote:
>>>>>>>>>=20
>>>>>>>>>> +1 for Segment Routing WG
>>>>>>>>>>=20
>>>>>>>>>> Roberta
>>>>>>>>>>=20
>>>>>>>>>> Sent from my iPad
>>>>>>>>>>=20
>>>>>>>>>> On 2013-08-30, at 2:55 PM, "Alvaro Retana (aretana)"
>>>>>>>>>> <[email-masked]>
>>>>>>>>>> wrote:
>>>>>>>>>>=20
>>>>>>>>>>> Segment Routing WG
>>>>>>>>>>>=20
>>>>>>>>>>> Sent from my iPhone
>>>>>>>>>>>=20
>>>>>>>>>>> On Aug 30, 2013, at 1:39 PM, "Stewart Bryant (stbryant)"
>>>>>>>>>>> <[email-masked]> wrote:
>>>>>>>>>>>=20
>>>>>>>>>>>> The second task, which hopefully should be relatively easy, is
>>>>>>>>>>>> to find a better working name for the WG, since it has been
>>>>>>>>>>>> put to me a number of times that STATUS is going to be
>>>>>>>>>>>> confusing in text and a difficult search term.
>>>>>>>>>>> _______________________________________________
>>>>>>>>>>> status mailing list
>>>>>>>>>>> [email-masked]
>>>>>>>>>>> https://www.ietf.org/mailman/listinfo/status
>>>>>>>>>> _______________________________________________
>>>>>>>>>> status mailing list
>>>>>>>>>> [email-masked]
>>>>>>>>>> https://www.ietf.org/mailman/listinfo/status
>>>>>>>>>=20
>>>>>>>>>=20
>>>>>>>>> _______________________________________________
>>>>>>>>> status mailing list
>>>>>>>>> [email-masked]
>>>>>>>>> https://www.ietf.org/mailman/listinfo/status
>>>>>>>>=20
>>>>>>>> _______________________________________________
>>>>>>>> status mailing list
>>>>>>>> [email-masked]
>>>>>>>> https://www.ietf.org/mailman/listinfo/status
>>>>>>>=20
>>>>>>>=20
>>>>>>> _______________________________________________
>>>>>>> status mailing list
>>>>>>> [email-masked]
>>>>>>> https://www.ietf.org/mailman/listinfo/status
>>>>>>>=20
>>>>>>> ___________________________________________________________________
>>>>>>> _ __ ___________________________________________________
>>>>>>>=20
>>>>>>> Ce message et ses pieces jointes peuvent contenir des informations
>>>>>>> confidentielles ou privilegiees et ne doivent donc pas etre
>>>>>>> diffuses, exploites ou copies sans autorisation. Si vous avez recu
>>>>>>> ce message par erreur, veuillez le signaler a l'expediteur et le de=
truire ainsi que les pieces jointes. Les messages electroniques etant susce=
ptibles d'alteration, Orange decline toute responsabilite si ce message a e=
te altere, deforme ou falsifie. Merci.
>>>>>>>=20
>>>>>>> This message and its attachments may contain confidential or
>>>>>>> privileged information that may be protected by law; they should no=
t be distributed, used or copied without authorisation.
>>>>>>> If you have received this email in error, please notify the sender =
and delete this message and its attachments.
>>>>>>> As emails may be altered, Orange is not liable for messages that ha=
ve been modified, changed or falsified.
>>>>>>> Thank you.
>>>>>>>=20
>>>>>>> _______________________________________________
>>>>>>> status mailing list
>>>>>>> [email-masked]
>>>>>>> https://www.ietf.org/mailman/listinfo/status
>>>>>>=20
>>>>>> ____________________________________________________________________
>>>>>> _ ____________________________________________________
>>>>>>=20
>>>>>> Ce message et ses pieces jointes peuvent contenir des informations
>>>>>> confidentielles ou privilegiees et ne doivent donc pas etre
>>>>>> diffuses, exploites ou copies sans autorisation. Si vous avez recu
>>>>>> ce message par erreur, veuillez le signaler a l'expediteur et le det=
ruire ainsi que les pieces jointes. Les messages electroniques etant suscep=
tibles d'alteration, Orange decline toute responsabilite si ce message a et=
e altere, deforme ou falsifie. Merci.
>>>>>>=20
>>>>>> This message and its attachments may contain confidential or
>>>>>> privileged information that may be protected by law; they should not=
 be distributed, used or copied without authorisation.
>>>>>> If you have received this email in error, please notify the sender a=
nd delete this message and its attachments.
>>>>>> As emails may be altered, Orange is not liable for messages that hav=
e been modified, changed or falsified.
>>>>>> Thank you.
>>>>>>=20
>>>>>> _______________________________________________
>>>>>> status mailing list
>>>>>> [email-masked]
>>>>>> https://www.ietf.org/mailman/listinfo/status
>>>>>> _______________________________________________
>>>>>> status mailing list
>>>>>> [email-masked]
>>>>>> https://www.ietf.org/mailman/listinfo/status
>>>>>>=20
>>>>>=20
>>>>> --
>>>>>=20
>>>>>=20
>>>>> Loa Andersson                        email: [email-masked]
>>>>> Senior MPLS Expert                          [email-masked]
>>>>> Huawei Technologies (consultant)     phone: +46 739 81 21 64
>>>>> _______________________________________________
>>>>> status mailing list
>>>>> [email-masked]
>>>>> https://www.ietf.org/mailman/listinfo/status
>>>>>=20
>>>>>=20
>>>>=20
>>>>=20
>>>> _______________________________________________
>>>> status mailing list
>>>> [email-masked]
>>>> https://www.ietf.org/mailman/listinfo/status
>>>>=20
>>>> ______________________________________________________________________
>>>> ___________________________________________________
>>>>=20
>>>> Ce message et ses pieces jointes peuvent contenir des informations
>>>> confidentielles ou privilegiees et ne doivent donc pas etre diffuses,
>>>> exploites ou copies sans autorisation. Si vous avez recu ce message
>>>> par erreur, veuillez le signaler a l'expediteur et le detruire ainsi q=
ue les pieces jointes. Les messages electroniques etant susceptibles d'alte=
ration, Orange decline toute responsabilite si ce message a ete altere, def=
orme ou falsifie. Merci.
>>>>=20
>>>> This message and its attachments may contain confidential or
>>>> privileged information that may be protected by law; they should not b=
e distributed, used or copied without authorisation.
>>>> If you have received this email in error, please notify the sender and=
 delete this message and its attachments.
>>>> As emails may be altered, Orange is not liable for messages that have =
been modified, changed or falsified.
>>>> Thank you.
>>>>=20
>>>>=20
>>>>=20
>>>=20
>>>=20
>>>=20
>>> _______________________________________________________________________=
__________________________________________________
>>>=20
>>> Ce message et ses pieces jointes peuvent contenir des informations conf=
identielles ou privilegiees et ne doivent donc
>>> pas etre diffuses, exploites ou copies sans autorisation. Si vous avez =
recu ce message par erreur, veuillez le signaler
>>> a l'expediteur et le detruire ainsi que les pieces jointes. Les message=
s electroniques etant susceptibles d'alteration,
>>> Orange decline toute responsabilite si ce message a ete altere, deforme=
 ou falsifie. Merci.
>>>=20
>>> This message and its attachments may contain confidential or privileged=
 information that may be protected by law;
>>> they should not be distributed, used or copied without authorisation.
>>> If you have received this email in error, please notify the sender and =
delete this message and its attachments.
>>> As emails may be altered, Orange is not liable for messages that have b=
een modified, changed or falsified.
>>> Thank you.
>>>=20
>>> _______________________________________________
>>> status mailing list
>>> [email-masked]
>>> https://www.ietf.org/mailman/listinfo/status
>>=20
>>=20
>>=20
>=20
>=20

Sender: [email-masked]
Date: Thu, 5 Sep 2013 03:42:23 -0700
From: Anoop Ghanwani <[email-masked]>
To: Xuxiaohu <[email-masked]>
Cc: "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>
Subject: Re: [Status] A possible way to make IP fans happy//re: Summary of STATUS BOF and the next steps

--089e012299c8ca9ac304e5a0938a
Content-Type: text/plain; charset=GB2312
Content-Transfer-Encoding: quoted-printable

Is this any different than MPLS over GRE, where GRE is used to get over
non-MPLS-aware parts of a network?

Anoop

On Thu, Sep 5, 2013 at 3:16 AM, Xuxiaohu <[email-masked]> wrote:

>  Hi all,****
>
> ** **
>
> According to the BoF session at IETF87, it seems that there are a certain
> number of people who want to see an IPv6-based, rather than MPLS-based
> source routing mechanism. However, it seems that many people are hesitate
> to make any change to the existing MPLS and IP data planes.****
>
> ** **
>
> I wonder whether the following low-cost approach can make those IP fans
> happy: the predefined next-hops that the explicit source path must traver=
se
> are still expressed by the MPLS label stack in the data packets, but the
> adjacent next-hops are connected via pure IP networks, rather than MPLS
> networks.  For example, if LSR A wants to send a MPLS VPN packet for LSR =
Z
> along an explicit path {B, C, Z}, it would push the node segment label fo=
r
> Z and then the node segment label for C into the existing MPLS label stac=
k,
> and then transport such MPLS packet over an IP tunnel towards B. Upon
> receiving such MPLS packet over the IP tunnel, B would look up the
> corresponding MPLS forwarding table entry for the topmost label (i.e., th=
e
> node segment label for C) and find the out interface for this packet is a=
n
> IP tunnel interface with tunnel destination of C, therefore it would pop
> the topmost label (if the out label of that MPLS forwarding entry is null=
)
> and then transport the MPLS packet over an IP tunnel towards C.  Once C
> receives such MPLS packet over the IP tunnel, C would look up the
> corresponding MPLS forwarding entry for the current topmost label (i.e.,
> the node segment label for Z) , and then forward this MPLS packet over an
> IP tunnel towards Z like what B has done.****
>
> ** **
>
> The above approach has at least the following benefits:****
>
> ** **
>
> **1)    **No change to the existing MPLS and IP data plane.****
>
> **2)    **No requirement for the MPLS forwarding capability on all
> routers=3D> only those explicit hops need the MPLS forwarding capability.=
***
> *
>
> **3)    **No requirement for software upgrade on all routers=3D> only tho=
se
> explicit hops need such software upgrade.****
>
> **4)    **Less MTU collision risk due to the usage of 20-bit long MPLS
> labels, rather than 128-bit long IPv6 addresses for indicating the
> predefined next-hops of a given explicit source path.****
>
> ** **
>
> Best regards,****
>
> Xiaohu****
>
> ** **
>
> *=B7=A2=BC=FE=C8=CB:* [email-masked] [mailto:status-bounces@ietf=
.org] *=B4=FA=B1=ED *Stewart
> Bryant
> *=B7=A2=CB=CD=CA=B1=BC=E4:* 2013=C4=EA9=D4=C24=C8=D5 18:25
> *=CA=D5=BC=FE=C8=CB:* Mach Chen
> *=B3=AD=CB=CD:* John E Drake; Mark Townsley; Victor Kuarsingh; Roberta Ma=
glione
> (robmgl); John G. Scudder; Adrian Farrel; Alvaro Retana (aretana);
> [email-masked]
> *=D6=F7=CC=E2:* Re: [Status] Summary of STATUS BOF and the next steps****
>
> ** **
>
>
> May I suggest that we use the name "SR" and worry
> about what it binds to later.
>
> The higher priority item is the charter text. Does
> anyone have any comments on the text proposed
> so far, or the text in the BOF proposal:
>
>
> The Stacked Tunnels for Source Routing (STATUS) Working Group
> is chartered to develop a framework and use cases for source-routed
> flows in packet switched networks.
>
> IP previously had a source-based routing mechanism made
> available through an IP Option. This mechanism has, however,
> not been widely used and has a number of issues that make its
> use inadvisable, and other mechanisms (such as RFC 1940)
> do not appear to have been implemented at all.
>
> The ability of a router to influence or control the forwarding
> path of an individual packet or all the packets of a given
> Forwarding Equivalence Class (FEC) is a desirable feature
> for a number of reasons including Label Switched Path stitching,
> egress protection, explicit routing, egress ASBR link selection,
> and backup (bypass tunnels, Remote Loop-Free Alternates)
> routing. This can be achieved by facilitating source-initiated
> selection of routes to complement the route selection
> provided by existing routing protocols for both inter- domain
> and intra-domain routes.
>
> Historically, distribution of MPLS label binding information
> was done by relying on label distribution protocols
> such as LDP and RSVP-TE.
>
> The use cases documented by the working group will
> indicate the network function that is being facilitated
> and indicate which packet data plane is to be used.
>
> The framework developed by the working group will
> consider forwarding of IPv4, IPv6, and MPLS using the
> existing unicast data planes. Multicast forwarding will
> be for future study and the choice of data planes will
> be limited to those for which use cases exist. A key
> objective of the work will be to ensure that source-
> routed packets can be handled seamlessly by existing
> deployed equipment. A major objective will be that the
> new function does not modify existing data plane behavior
> or architectures, and that it can be enabled through only
> control and management plane software upgrades at
> deployed devices.
>
> Once the working group has established a framework
> and there is demonstrable consensus for use cases,
> the working group will move forward to specify protocol
> solutions for installing forwarding information through
> the use of the IGPs (OSPF and IS-IS), or through the
> management plane. In the course of developing protocol
> extensions, the working group will work closely with
> other IETF working groups responsible for the protocols
> being modified (such as OSPF, ISIS, and I2RS).
>
>     The working group is chartered for the following work items:
>
>     A framework for the use of the existing MPLS data plane to
>     support tunnel-based unicast source routing.
>
>     Develop use cases for tunnel-based unicast source routing
>     that demonstrate the need and support for solutions. Care
>     should be taken to avoid clustering use cases that might seem
>     to imply support for multiple use cases when only some of the
>     cluster actually have wide-scale support.
>
>     Develop ISIS and OSPF protocol extensions necessary for
>    distribution of MPLS forwarding information.
>
>     The working group will consider management (including
>     configuration, reporting, diagnostics, and OAM) and security
>     implications of its work and document them in separate
>     documents as appropriate.
>
>     The working group is not chartered to make any changes to
>     the MPLS or IPv6 data planes. Any proposed changes to the
>     data planes are to be specified in the working groups responsible
>     for the data planes (that is, the MPLS and 6MAN working groups,
>     respectively).
>
> - Stewart****
>
> _______________________________________________
> status mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/status
>
>

--089e012299c8ca9ac304e5a0938a
Content-Type: text/html; charset=GB2312
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">Is this any different than MPLS over GRE, where GRE is use=
d to get over non-MPLS-aware parts of a network?<div><br></div><div>Anoop</=
div></div><div class=3D"gmail_extra"><br><br><div class=3D"gmail_quote">On =
Thu, Sep 5, 2013 at 3:16 AM, Xuxiaohu <span dir=3D"ltr">&lt;<a href=3D"mail=
to:[email-masked]" target=3D"_blank">[email-masked]</a>&gt;</span=
> wrote:<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex">

<div bgcolor=3D"white" lang=3D"ZH-CN" link=3D"blue" vlink=3D"purple">
<div>
<p class=3D"MsoNormal"><span lang=3D"EN-US" style=3D"font-size:16.0pt;font-=
family:&quot;Calibri&quot;,&quot;sans-serif&quot;;color:#1f497d">Hi all,<u>=
</u><u></u></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US" style=3D"font-size:16.0pt;font-=
family:&quot;Calibri&quot;,&quot;sans-serif&quot;;color:#1f497d"><u></u>&nb=
sp;<u></u></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US" style=3D"font-size:16.0pt;font-=
family:&quot;Calibri&quot;,&quot;sans-serif&quot;;color:#1f497d">According =
to the BoF session at IETF87, it seems that there are a certain number of p=
eople who want to see an IPv6-based, rather than MPLS-based
 source routing mechanism. However, it seems that many people are hesitate =
to make any change to the existing MPLS and IP data planes.<u></u><u></u></=
span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US" style=3D"font-size:16.0pt;font-=
family:&quot;Calibri&quot;,&quot;sans-serif&quot;;color:#1f497d"><u></u>&nb=
sp;<u></u></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US" style=3D"font-size:16.0pt;font-=
family:&quot;Calibri&quot;,&quot;sans-serif&quot;;color:#1f497d">I wonder w=
hether the following low-cost approach can make those IP fans happy: the pr=
edefined next-hops that the explicit source path must traverse
 are still expressed by the MPLS label stack in the data packets, but the a=
djacent next-hops are connected via pure IP networks, rather than MPLS netw=
orks. &nbsp;For example, if LSR A wants to send a MPLS VPN packet for LSR Z=
 along an explicit path {B, C, Z}, it
 would push the node segment label for Z and then the node segment label fo=
r C into the existing MPLS label stack, and then transport such MPLS packet=
 over an IP tunnel towards B. Upon receiving such MPLS packet over the IP t=
unnel, B would look up the corresponding
 MPLS forwarding table entry for the topmost label (i.e., the node segment =
label for C) and find the out interface for this packet is an IP tunnel int=
erface with tunnel destination of C, therefore it would pop the topmost lab=
el (if the out label of that MPLS
 forwarding entry is null) and then transport the MPLS packet over an IP tu=
nnel towards C. &nbsp;Once C receives such MPLS packet over the IP tunnel, =
C would look up the corresponding MPLS forwarding entry for the current top=
most label (i.e., the node segment label
 for Z) , and then forward this MPLS packet over an IP tunnel towards Z lik=
e what B has done.<u></u><u></u></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US" style=3D"font-size:16.0pt;font-=
family:&quot;Calibri&quot;,&quot;sans-serif&quot;;color:#1f497d"><u></u>&nb=
sp;<u></u></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US" style=3D"font-size:16.0pt;font-=
family:&quot;Calibri&quot;,&quot;sans-serif&quot;;color:#1f497d">The above =
approach has at least the following benefits:<u></u><u></u></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US" style=3D"font-size:16.0pt;font-=
family:&quot;Calibri&quot;,&quot;sans-serif&quot;;color:#1f497d"><u></u>&nb=
sp;<u></u></span></p>
<p style=3D"margin-left:18.0pt">
<u></u><span lang=3D"EN-US" style=3D"font-size:16.0pt;font-family:&quot;Cal=
ibri&quot;,&quot;sans-serif&quot;;color:#1f497d"><span>1)<span style=3D"fon=
t:7.0pt &quot;Times New Roman&quot;">&nbsp;&nbsp;&nbsp;
</span></span></span><u></u><span lang=3D"EN-US" style=3D"font-size:16.0pt;=
font-family:&quot;Calibri&quot;,&quot;sans-serif&quot;;color:#1f497d">No ch=
ange to the existing MPLS and IP data plane.<u></u><u></u></span></p>
<p style=3D"margin-left:18.0pt">
<u></u><span lang=3D"EN-US" style=3D"font-size:16.0pt;font-family:&quot;Cal=
ibri&quot;,&quot;sans-serif&quot;;color:#1f497d"><span>2)<span style=3D"fon=
t:7.0pt &quot;Times New Roman&quot;">&nbsp;&nbsp;&nbsp;
</span></span></span><u></u><span lang=3D"EN-US" style=3D"font-size:16.0pt;=
font-family:&quot;Calibri&quot;,&quot;sans-serif&quot;;color:#1f497d">No re=
quirement for the MPLS forwarding capability on all routers=3D&gt; only tho=
se explicit hops need the MPLS forwarding capability.<u></u><u></u></span><=
/p>

<p style=3D"margin-left:18.0pt">
<u></u><span lang=3D"EN-US" style=3D"font-size:16.0pt;font-family:&quot;Cal=
ibri&quot;,&quot;sans-serif&quot;;color:#1f497d"><span>3)<span style=3D"fon=
t:7.0pt &quot;Times New Roman&quot;">&nbsp;&nbsp;&nbsp;
</span></span></span><u></u><span lang=3D"EN-US" style=3D"font-size:16.0pt;=
font-family:&quot;Calibri&quot;,&quot;sans-serif&quot;;color:#1f497d">No re=
quirement for software upgrade on all routers=3D&gt; only those explicit ho=
ps need such software upgrade.<u></u><u></u></span></p>

<p style=3D"margin-left:18.0pt">
<u></u><span lang=3D"EN-US" style=3D"font-size:16.0pt;font-family:&quot;Cal=
ibri&quot;,&quot;sans-serif&quot;;color:#1f497d"><span>4)<span style=3D"fon=
t:7.0pt &quot;Times New Roman&quot;">&nbsp;&nbsp;&nbsp;
</span></span></span><u></u><span lang=3D"EN-US" style=3D"font-size:16.0pt;=
font-family:&quot;Calibri&quot;,&quot;sans-serif&quot;;color:#1f497d">Less =
MTU collision risk due to the usage of 20-bit long MPLS labels, rather than=
 128-bit long IPv6 addresses for indicating the predefined
 next-hops of a given explicit source path.<u></u><u></u></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US" style=3D"font-size:16.0pt;font-=
family:&quot;Calibri&quot;,&quot;sans-serif&quot;;color:#1f497d"><u></u>&nb=
sp;<u></u></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US" style=3D"font-size:16.0pt;font-=
family:&quot;Calibri&quot;,&quot;sans-serif&quot;;color:#1f497d">Best regar=
ds,<u></u><u></u></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US" style=3D"font-size:16.0pt;font-=
family:&quot;Calibri&quot;,&quot;sans-serif&quot;;color:#1f497d">Xiaohu<u><=
/u><u></u></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US" style=3D"font-size:16.0pt;font-=
family:&quot;Calibri&quot;,&quot;sans-serif&quot;;color:#1f497d"><u></u>&nb=
sp;<u></u></span></p>
<div style=3D"border:none;border-left:solid blue 1.5pt;padding:0cm 0cm 0cm =
4.0pt">
<div>
<div style=3D"border:none;border-top:solid #b5c4df 1.0pt;padding:3.0pt 0cm =
0cm 0cm">
<p class=3D"MsoNormal"><b><span style=3D"font-size:10.0pt;font-family:=CB=
=CE=CC=E5;color:windowtext">=B7=A2=BC=FE=C8=CB<span lang=3D"EN-US">:</span>=
</span></b><span lang=3D"EN-US" style=3D"font-size:10.0pt;font-family:=CB=
=CE=CC=E5;color:windowtext"> <a href=3D"mailto:[email-masked]" tar=
get=3D"_blank">[email-masked]</a> [mailto:<a href=3D"mailto:status=
[email-masked]" target=3D"_blank">[email-masked]</a>]
</span><b><span style=3D"font-size:10.0pt;font-family:=CB=CE=CC=E5;color:wi=
ndowtext">=B4=FA=B1=ED </span>
</b><span lang=3D"EN-US" style=3D"font-size:10.0pt;font-family:=CB=CE=CC=E5=
;color:windowtext">Stewart Bryant<br>
</span><b><span style=3D"font-size:10.0pt;font-family:=CB=CE=CC=E5;color:wi=
ndowtext">=B7=A2=CB=CD=CA=B1=BC=E4<span lang=3D"EN-US">:</span></span></b><=
span lang=3D"EN-US" style=3D"font-size:10.0pt;font-family:=CB=CE=CC=E5;colo=
r:windowtext"> 2013</span><span style=3D"font-size:10.0pt;font-family:=CB=
=CE=CC=E5;color:windowtext">=C4=EA<span lang=3D"EN-US">9</span>=D4=C2<span =
lang=3D"EN-US">4</span>=C8=D5<span lang=3D"EN-US">
 18:25<br>
</span><b>=CA=D5=BC=FE=C8=CB<span lang=3D"EN-US">:</span></b><span lang=3D"=
EN-US"> Mach Chen<br>
</span><b>=B3=AD=CB=CD<span lang=3D"EN-US">:</span></b><span lang=3D"EN-US"=
> John E Drake; Mark Townsley; Victor Kuarsingh; Roberta Maglione (robmgl);=
 John G. Scudder; Adrian Farrel; Alvaro Retana (aretana); <a href=3D"mailto=
:[email-masked]" target=3D"_blank">[email-masked]</a><br>

</span><b>=D6=F7=CC=E2<span lang=3D"EN-US">:</span></b><span lang=3D"EN-US"=
> Re: [Status] Summary of STATUS BOF and the next steps<u></u><u></u></span=
></span></p>
</div>
</div>
<p class=3D"MsoNormal"><span lang=3D"EN-US"><u></u>&nbsp;<u></u></span></p>
<p class=3D"MsoNormal" style=3D"margin-bottom:12.0pt"><span lang=3D"EN-US">=
<br>
May I suggest that we use the name &quot;SR&quot; and worry<br>
about what it binds to later.<br>
<br>
The higher priority item is the charter text. Does<br>
anyone have any comments on the text proposed<br>
so far, or the text in the BOF proposal:<br>
<br>
<br>
The Stacked Tunnels for Source Routing (STATUS) Working Group <br>
is chartered to develop a framework and use cases for source-routed <br>
flows in packet switched networks.<br>
<br>
IP previously had a source-based routing mechanism made <br>
available through an IP Option. This mechanism has, however, <br>
not been widely used and has a number of issues that make its <br>
use inadvisable, and other mechanisms (such as RFC 1940) <br>
do not appear to have been implemented at all.<br>
<br>
The ability of a router to influence or control the forwarding <br>
path of an individual packet or all the packets of a given <br>
Forwarding Equivalence Class (FEC) is a desirable feature <br>
for a number of reasons including Label Switched Path stitching, <br>
egress protection, explicit routing, egress ASBR link selection, <br>
and backup (bypass tunnels, Remote Loop-Free Alternates) <br>
routing. This can be achieved by facilitating source-initiated <br>
selection of routes to complement the route selection <br>
provided by existing routing protocols for both inter- domain <br>
and intra-domain routes.<br>
<br>
Historically, distribution of MPLS label binding information <br>
was done by relying on label distribution protocols <br>
such as LDP and RSVP-TE.<br>
<br>
The use cases documented by the working group will <br>
indicate the network function that is being facilitated <br>
and indicate which packet data plane is to be used.<br>
<br>
The framework developed by the working group will <br>
consider forwarding of IPv4, IPv6, and MPLS using the <br>
existing unicast data planes. Multicast forwarding will <br>
be for future study and the choice of data planes will <br>
be limited to those for which use cases exist. A key <br>
objective of the work will be to ensure that source-<br>
routed packets can be handled seamlessly by existing <br>
deployed equipment. A major objective will be that the <br>
new function does not modify existing data plane behavior <br>
or architectures, and that it can be enabled through only <br>
control and management plane software upgrades at <br>
deployed devices.<br>
<br>
Once the working group has established a framework <br>
and there is demonstrable consensus for use cases, <br>
the working group will move forward to specify protocol <br>
solutions for installing forwarding information through <br>
the use of the IGPs (OSPF and IS-IS), or through the <br>
management plane. In the course of developing protocol <br>
extensions, the working group will work closely with <br>
other IETF working groups responsible for the protocols <br>
being modified (such as OSPF, ISIS, and I2RS).<br>
<br>
&nbsp;&nbsp;&nbsp; The working group is chartered for the following work it=
ems:<br>
<br>
&nbsp;&nbsp;&nbsp; A framework for the use of the existing MPLS data plane =
to <br>
&nbsp;&nbsp;&nbsp; support tunnel-based unicast source routing. <br>
<br>
&nbsp;&nbsp;&nbsp; Develop use cases for tunnel-based unicast source routin=
g <br>
&nbsp;&nbsp;&nbsp; that demonstrate the need and support for solutions. Car=
e <br>
&nbsp;&nbsp;&nbsp; should be taken to avoid clustering use cases that might=
 seem<br>
&nbsp; &nbsp; to imply support for multiple use cases when only some of the=
 <br>
&nbsp;&nbsp;&nbsp; cluster actually have wide-scale support. <br>
<br>
&nbsp;&nbsp;&nbsp; Develop ISIS and OSPF protocol extensions necessary for =
<br>
&nbsp;&nbsp; distribution of MPLS forwarding information. <br>
<br>
&nbsp;&nbsp;&nbsp; The working group will consider management (including&nb=
sp; <br>
&nbsp;&nbsp;&nbsp; configuration, reporting, diagnostics, and OAM) and secu=
rity <br>
&nbsp;&nbsp;&nbsp; implications of its work and document them in separate <=
br>
&nbsp;&nbsp;&nbsp; documents as appropriate. <br>
<br>
&nbsp;&nbsp;&nbsp; The working group is not chartered to make any changes t=
o <br>
&nbsp;&nbsp;&nbsp; the MPLS or IPv6 data planes. Any proposed changes to th=
e <br>
&nbsp;&nbsp;&nbsp; data planes are to be specified in the working groups re=
sponsible <br>
&nbsp;&nbsp;&nbsp; for the data planes (that is, the MPLS and 6MAN working =
groups,&nbsp; <br>
&nbsp;&nbsp;&nbsp; respectively).<br>
<br>
- Stewart<u></u><u></u></span></p>
</div>
</div>
</div>

<br>_______________________________________________<br>
status mailing list<br>
<a href=3D"mailto:[email-masked]">[email-masked]</a><br>
<a href=3D"https://www.ietf.org/mailman/listinfo/status" target=3D"_blank">=
https://www.ietf.org/mailman/listinfo/status</a><br>
<br></blockquote></div><br></div>

--089e012299c8ca9ac304e5a0938a--

From: Xuxiaohu <[email-masked]>
To: "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>
Date: Thu, 5 Sep 2013 10:16:29 +0000
Accept-Language: zh-CN, en-US
Subject: [Status] A possible way to make IP fans happy//re: Summary of STATUS BOF and the next steps

--_000_1FEE3F8F5CCDE64C9A8E8F4AD27C19EE08202966NKGEML512MBSchi_
Content-Type: text/plain; charset="gb2312"
Content-Transfer-Encoding: base64

--_000_1FEE3F8F5CCDE64C9A8E8F4AD27C19EE08202966NKGEML512MBSchi_
Content-Type: text/html; charset="gb2312"
Content-Transfer-Encoding: quoted-printable

<html xmlns:v=3D"urn:schemas-microsoft-com:vml" xmlns:o=3D"urn:schemas-micr=
osoft-com:office:office" xmlns:w=3D"urn:schemas-microsoft-com:office:word" =
xmlns:x=3D"urn:schemas-microsoft-com:office:excel" xmlns:p=3D"urn:schemas-m=
icrosoft-com:office:powerpoint" xmlns:a=3D"urn:schemas-microsoft-com:office=
:access" xmlns:dt=3D"uuid:C2F41010-65B3-11d1-A29F-00AA00C14882" xmlns:s=3D"=
uuid:BDC6E3F0-6DA3-11d1-A2A3-00AA00C14882" xmlns:rs=3D"urn:schemas-microsof=
t-com:rowset" xmlns:z=3D"#RowsetSchema" xmlns:b=3D"urn:schemas-microsoft-co=
m:office:publisher" xmlns:ss=3D"urn:schemas-microsoft-com:office:spreadshee=
t" xmlns:c=3D"urn:schemas-microsoft-com:office:component:spreadsheet" xmlns=
:odc=3D"urn:schemas-microsoft-com:office:odc" xmlns:oa=3D"urn:schemas-micro=
soft-com:office:activation" xmlns:html=3D"http://www.w3.org/TR/REC-html40" =
xmlns:q=3D"http://schemas.xmlsoap.org/soap/envelope/" xmlns:rtc=3D"http://m=
icrosoft.com/officenet/conferencing" xmlns:D=3D"DAV:" xmlns:Repl=3D"http://=
schemas.microsoft.com/repl/" xmlns:mt=3D"http://schemas.microsoft.com/share=
point/soap/meetings/" xmlns:x2=3D"http://schemas.microsoft.com/office/excel=
/2003/xml" xmlns:ppda=3D"http://www.passport.com/NameSpace.xsd" xmlns:ois=
=3D"http://schemas.microsoft.com/sharepoint/soap/ois/" xmlns:dir=3D"http://=
schemas.microsoft.com/sharepoint/soap/directory/" xmlns:ds=3D"http://www.w3=
.org/2000/09/xmldsig#" xmlns:dsp=3D"http://schemas.microsoft.com/sharepoint=
/dsp" xmlns:udc=3D"http://schemas.microsoft.com/data/udc" xmlns:xsd=3D"http=
://www.w3.org/2001/XMLSchema" xmlns:sub=3D"http://schemas.microsoft.com/sha=
repoint/soap/2002/1/alerts/" xmlns:ec=3D"http://www.w3.org/2001/04/xmlenc#"=
 xmlns:sp=3D"http://schemas.microsoft.com/sharepoint/" xmlns:sps=3D"http://=
schemas.microsoft.com/sharepoint/soap/" xmlns:xsi=3D"http://www.w3.org/2001=
/XMLSchema-instance" xmlns:udcs=3D"http://schemas.microsoft.com/data/udc/so=
ap" xmlns:udcxf=3D"http://schemas.microsoft.com/data/udc/xmlfile" xmlns:udc=
p2p=3D"http://schemas.microsoft.com/data/udc/parttopart" xmlns:wf=3D"http:/=
/schemas.microsoft.com/sharepoint/soap/workflow/" xmlns:dsss=3D"http://sche=
mas.microsoft.com/office/2006/digsig-setup" xmlns:dssi=3D"http://schemas.mi=
crosoft.com/office/2006/digsig" xmlns:mdssi=3D"http://schemas.openxmlformat=
s.org/package/2006/digital-signature" xmlns:mver=3D"http://schemas.openxmlf=
ormats.org/markup-compatibility/2006" xmlns:m=3D"http://schemas.microsoft.c=
om/office/2004/12/omml" xmlns:mrels=3D"http://schemas.openxmlformats.org/pa=
ckage/2006/relationships" xmlns:spwp=3D"http://microsoft.com/sharepoint/web=
partpages" xmlns:ex12t=3D"http://schemas.microsoft.com/exchange/services/20=
06/types" xmlns:ex12m=3D"http://schemas.microsoft.com/exchange/services/200=
6/messages" xmlns:pptsl=3D"http://schemas.microsoft.com/sharepoint/soap/Sli=
deLibrary/" xmlns:spsl=3D"http://microsoft.com/webservices/SharePointPortal=
Server/PublishedLinksService" xmlns:Z=3D"urn:schemas-microsoft-com:" xmlns:=
st=3D"&#1;" xmlns=3D"http://www.w3.org/TR/REC-html40">
<head>
<meta http-equiv=3D"Content-Type" content=3D"text/html; charset=3Dgb2312">
<meta name=3D"Generator" content=3D"Microsoft Word 12 (filtered medium)">
<style><!--
/* Font Definitions */
@font-face
	{font-family:=CB=CE=CC=E5;
	panose-1:2 1 6 0 3 1 1 1 1 1;}
@font-face
	{font-family:"Cambria Math";
	panose-1:2 4 5 3 5 4 6 3 2 4;}
@font-face
	{font-family:Calibri;
	panose-1:2 15 5 2 2 2 4 3 2 4;}
@font-face
	{font-family:"\@=CB=CE=CC=E5";
	panose-1:2 1 6 0 3 1 1 1 1 1;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
	{margin:0cm;
	margin-bottom:.0001pt;
	font-size:12.0pt;
	font-family:"Times New Roman","serif";
	color:black;}
a:link, span.MsoHyperlink
	{mso-style-priority:99;
	color:blue;
	text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
	{mso-style-priority:99;
	color:purple;
	text-decoration:underline;}
p.MsoListParagraph, li.MsoListParagraph, div.MsoListParagraph
	{mso-style-priority:34;
	margin:0cm;
	margin-bottom:.0001pt;
	text-indent:21.0pt;
	font-size:12.0pt;
	font-family:"Times New Roman","serif";
	color:black;}
span.EmailStyle17
	{mso-style-type:personal-reply;
	font-family:"Calibri","sans-serif";
	color:#1F497D;}
.MsoChpDefault
	{mso-style-type:export-only;
	font-size:10.0pt;}
@page WordSection1
	{size:612.0pt 792.0pt;
	margin:72.0pt 90.0pt 72.0pt 90.0pt;}
div.WordSection1
	{page:WordSection1;}
/* List Definitions */
@list l0
	{mso-list-id:587423172;
	mso-list-type:hybrid;
	mso-list-template-ids:-1851857708 654196214 67698713 67698715 67698703 676=
98713 67698715 67698703 67698713 67698715;}
@list l0:level1
	{mso-level-text:"%1\)";
	mso-level-tab-stop:none;
	mso-level-number-position:left;
	margin-left:18.0pt;
	text-indent:-18.0pt;}
ol
	{margin-bottom:0cm;}
ul
	{margin-bottom:0cm;}
--></style><!--[if gte mso 9]><xml>
<o:shapedefaults v:ext=3D"edit" spidmax=3D"1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
<o:shapelayout v:ext=3D"edit">
<o:idmap v:ext=3D"edit" data=3D"1" />
</o:shapelayout></xml><![endif]-->
</head>
<body bgcolor=3D"white" lang=3D"ZH-CN" link=3D"blue" vlink=3D"purple">
<div class=3D"WordSection1">
<p class=3D"MsoNormal"><span lang=3D"EN-US" style=3D"font-size:16.0pt;font-=
family:&quot;Calibri&quot;,&quot;sans-serif&quot;;color:#1F497D">Hi all,<o:=
p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US" style=3D"font-size:16.0pt;font-=
family:&quot;Calibri&quot;,&quot;sans-serif&quot;;color:#1F497D"><o:p>&nbsp=
;</o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US" style=3D"font-size:16.0pt;font-=
family:&quot;Calibri&quot;,&quot;sans-serif&quot;;color:#1F497D">According =
to the BoF session at IETF87, it seems that there are a certain number of p=
eople who want to see an IPv6-based, rather than MPLS-based
 source routing mechanism. However, it seems that many people are hesitate =
to make any change to the existing MPLS and IP data planes.<o:p></o:p></spa=
n></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US" style=3D"font-size:16.0pt;font-=
family:&quot;Calibri&quot;,&quot;sans-serif&quot;;color:#1F497D"><o:p>&nbsp=
;</o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US" style=3D"font-size:16.0pt;font-=
family:&quot;Calibri&quot;,&quot;sans-serif&quot;;color:#1F497D">I wonder w=
hether the following low-cost approach can make those IP fans happy: the pr=
edefined next-hops that the explicit source path must traverse
 are still expressed by the MPLS label stack in the data packets, but the a=
djacent next-hops are connected via pure IP networks, rather than MPLS netw=
orks. &nbsp;For example, if LSR A wants to send a MPLS VPN packet for LSR Z=
 along an explicit path {B, C, Z}, it
 would push the node segment label for Z and then the node segment label fo=
r C into the existing MPLS label stack, and then transport such MPLS packet=
 over an IP tunnel towards B. Upon receiving such MPLS packet over the IP t=
unnel, B would look up the corresponding
 MPLS forwarding table entry for the topmost label (i.e., the node segment =
label for C) and find the out interface for this packet is an IP tunnel int=
erface with tunnel destination of C, therefore it would pop the topmost lab=
el (if the out label of that MPLS
 forwarding entry is null) and then transport the MPLS packet over an IP tu=
nnel towards C. &nbsp;Once C receives such MPLS packet over the IP tunnel, =
C would look up the corresponding MPLS forwarding entry for the current top=
most label (i.e., the node segment label
 for Z) , and then forward this MPLS packet over an IP tunnel towards Z lik=
e what B has done.<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US" style=3D"font-size:16.0pt;font-=
family:&quot;Calibri&quot;,&quot;sans-serif&quot;;color:#1F497D"><o:p>&nbsp=
;</o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US" style=3D"font-size:16.0pt;font-=
family:&quot;Calibri&quot;,&quot;sans-serif&quot;;color:#1F497D">The above =
approach has at least the following benefits:<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US" style=3D"font-size:16.0pt;font-=
family:&quot;Calibri&quot;,&quot;sans-serif&quot;;color:#1F497D"><o:p>&nbsp=
;</o:p></span></p>
<p class=3D"MsoListParagraph" style=3D"margin-left:18.0pt;text-indent:-18.0=
pt;mso-list:l0 level1 lfo1">
<![if !supportLists]><span lang=3D"EN-US" style=3D"font-size:16.0pt;font-fa=
mily:&quot;Calibri&quot;,&quot;sans-serif&quot;;color:#1F497D"><span style=
=3D"mso-list:Ignore">1)<span style=3D"font:7.0pt &quot;Times New Roman&quot=
;">&nbsp;&nbsp;&nbsp;
</span></span></span><![endif]><span lang=3D"EN-US" style=3D"font-size:16.0=
pt;font-family:&quot;Calibri&quot;,&quot;sans-serif&quot;;color:#1F497D">No=
 change to the existing MPLS and IP data plane.<o:p></o:p></span></p>
<p class=3D"MsoListParagraph" style=3D"margin-left:18.0pt;text-indent:-18.0=
pt;mso-list:l0 level1 lfo1">
<![if !supportLists]><span lang=3D"EN-US" style=3D"font-size:16.0pt;font-fa=
mily:&quot;Calibri&quot;,&quot;sans-serif&quot;;color:#1F497D"><span style=
=3D"mso-list:Ignore">2)<span style=3D"font:7.0pt &quot;Times New Roman&quot=
;">&nbsp;&nbsp;&nbsp;
</span></span></span><![endif]><span lang=3D"EN-US" style=3D"font-size:16.0=
pt;font-family:&quot;Calibri&quot;,&quot;sans-serif&quot;;color:#1F497D">No=
 requirement for the MPLS forwarding capability on all routers=3D&gt; only =
those explicit hops need the MPLS forwarding capability.<o:p></o:p></span><=
/p>
<p class=3D"MsoListParagraph" style=3D"margin-left:18.0pt;text-indent:-18.0=
pt;mso-list:l0 level1 lfo1">
<![if !supportLists]><span lang=3D"EN-US" style=3D"font-size:16.0pt;font-fa=
mily:&quot;Calibri&quot;,&quot;sans-serif&quot;;color:#1F497D"><span style=
=3D"mso-list:Ignore">3)<span style=3D"font:7.0pt &quot;Times New Roman&quot=
;">&nbsp;&nbsp;&nbsp;
</span></span></span><![endif]><span lang=3D"EN-US" style=3D"font-size:16.0=
pt;font-family:&quot;Calibri&quot;,&quot;sans-serif&quot;;color:#1F497D">No=
 requirement for software upgrade on all routers=3D&gt; only those explicit=
 hops need such software upgrade.<o:p></o:p></span></p>
<p class=3D"MsoListParagraph" style=3D"margin-left:18.0pt;text-indent:-18.0=
pt;mso-list:l0 level1 lfo1">
<![if !supportLists]><span lang=3D"EN-US" style=3D"font-size:16.0pt;font-fa=
mily:&quot;Calibri&quot;,&quot;sans-serif&quot;;color:#1F497D"><span style=
=3D"mso-list:Ignore">4)<span style=3D"font:7.0pt &quot;Times New Roman&quot=
;">&nbsp;&nbsp;&nbsp;
</span></span></span><![endif]><span lang=3D"EN-US" style=3D"font-size:16.0=
pt;font-family:&quot;Calibri&quot;,&quot;sans-serif&quot;;color:#1F497D">Le=
ss MTU collision risk due to the usage of 20-bit long MPLS labels, rather t=
han 128-bit long IPv6 addresses for indicating the predefined
 next-hops of a given explicit source path.<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US" style=3D"font-size:16.0pt;font-=
family:&quot;Calibri&quot;,&quot;sans-serif&quot;;color:#1F497D"><o:p>&nbsp=
;</o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US" style=3D"font-size:16.0pt;font-=
family:&quot;Calibri&quot;,&quot;sans-serif&quot;;color:#1F497D">Best regar=
ds,<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US" style=3D"font-size:16.0pt;font-=
family:&quot;Calibri&quot;,&quot;sans-serif&quot;;color:#1F497D">Xiaohu<o:p=
></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US" style=3D"font-size:16.0pt;font-=
family:&quot;Calibri&quot;,&quot;sans-serif&quot;;color:#1F497D"><o:p>&nbsp=
;</o:p></span></p>
<div style=3D"border:none;border-left:solid blue 1.5pt;padding:0cm 0cm 0cm =
4.0pt">
<div>
<div style=3D"border:none;border-top:solid #B5C4DF 1.0pt;padding:3.0pt 0cm =
0cm 0cm">
<p class=3D"MsoNormal"><b><span style=3D"font-size:10.0pt;font-family:=CB=
=CE=CC=E5;color:windowtext">=B7=A2=BC=FE=C8=CB<span lang=3D"EN-US">:</span>=
</span></b><span lang=3D"EN-US" style=3D"font-size:10.0pt;font-family:=CB=
=CE=CC=E5;color:windowtext"> [email-masked] [mailto:status-bounces=
@ietf.org]
</span><b><span style=3D"font-size:10.0pt;font-family:=CB=CE=CC=E5;color:wi=
ndowtext">=B4=FA=B1=ED </span>
</b><span lang=3D"EN-US" style=3D"font-size:10.0pt;font-family:=CB=CE=CC=E5=
;color:windowtext">Stewart Bryant<br>
</span><b><span style=3D"font-size:10.0pt;font-family:=CB=CE=CC=E5;color:wi=
ndowtext">=B7=A2=CB=CD=CA=B1=BC=E4<span lang=3D"EN-US">:</span></span></b><=
span lang=3D"EN-US" style=3D"font-size:10.0pt;font-family:=CB=CE=CC=E5;colo=
r:windowtext"> 2013</span><span style=3D"font-size:10.0pt;font-family:=CB=
=CE=CC=E5;color:windowtext">=C4=EA<span lang=3D"EN-US">9</span>=D4=C2<span =
lang=3D"EN-US">4</span>=C8=D5<span lang=3D"EN-US">
 18:25<br>
</span><b>=CA=D5=BC=FE=C8=CB<span lang=3D"EN-US">:</span></b><span lang=3D"=
EN-US"> Mach Chen<br>
</span><b>=B3=AD=CB=CD<span lang=3D"EN-US">:</span></b><span lang=3D"EN-US"=
> John E Drake; Mark Townsley; Victor Kuarsingh; Roberta Maglione (robmgl);=
 John G. Scudder; Adrian Farrel; Alvaro Retana (aretana); [email-masked]<b=
r>
</span><b>=D6=F7=CC=E2<span lang=3D"EN-US">:</span></b><span lang=3D"EN-US"=
> Re: [Status] Summary of STATUS BOF and the next steps<o:p></o:p></span></=
span></p>
</div>
</div>
<p class=3D"MsoNormal"><span lang=3D"EN-US"><o:p>&nbsp;</o:p></span></p>
<p class=3D"MsoNormal" style=3D"margin-bottom:12.0pt"><span lang=3D"EN-US">=
<br>
May I suggest that we use the name &quot;SR&quot; and worry<br>
about what it binds to later.<br>
<br>
The higher priority item is the charter text. Does<br>
anyone have any comments on the text proposed<br>
so far, or the text in the BOF proposal:<br>
<br>
<br>
The Stacked Tunnels for Source Routing (STATUS) Working Group <br>
is chartered to develop a framework and use cases for source-routed <br>
flows in packet switched networks.<br>
<br>
IP previously had a source-based routing mechanism made <br>
available through an IP Option. This mechanism has, however, <br>
not been widely used and has a number of issues that make its <br>
use inadvisable, and other mechanisms (such as RFC 1940) <br>
do not appear to have been implemented at all.<br>
<br>
The ability of a router to influence or control the forwarding <br>
path of an individual packet or all the packets of a given <br>
Forwarding Equivalence Class (FEC) is a desirable feature <br>
for a number of reasons including Label Switched Path stitching, <br>
egress protection, explicit routing, egress ASBR link selection, <br>
and backup (bypass tunnels, Remote Loop-Free Alternates) <br>
routing. This can be achieved by facilitating source-initiated <br>
selection of routes to complement the route selection <br>
provided by existing routing protocols for both inter- domain <br>
and intra-domain routes.<br>
<br>
Historically, distribution of MPLS label binding information <br>
was done by relying on label distribution protocols <br>
such as LDP and RSVP-TE.<br>
<br>
The use cases documented by the working group will <br>
indicate the network function that is being facilitated <br>
and indicate which packet data plane is to be used.<br>
<br>
The framework developed by the working group will <br>
consider forwarding of IPv4, IPv6, and MPLS using the <br>
existing unicast data planes. Multicast forwarding will <br>
be for future study and the choice of data planes will <br>
be limited to those for which use cases exist. A key <br>
objective of the work will be to ensure that source-<br>
routed packets can be handled seamlessly by existing <br>
deployed equipment. A major objective will be that the <br>
new function does not modify existing data plane behavior <br>
or architectures, and that it can be enabled through only <br>
control and management plane software upgrades at <br>
deployed devices.<br>
<br>
Once the working group has established a framework <br>
and there is demonstrable consensus for use cases, <br>
the working group will move forward to specify protocol <br>
solutions for installing forwarding information through <br>
the use of the IGPs (OSPF and IS-IS), or through the <br>
management plane. In the course of developing protocol <br>
extensions, the working group will work closely with <br>
other IETF working groups responsible for the protocols <br>
being modified (such as OSPF, ISIS, and I2RS).<br>
<br>
&nbsp;&nbsp;&nbsp; The working group is chartered for the following work it=
ems:<br>
<br>
&nbsp;&nbsp;&nbsp; A framework for the use of the existing MPLS data plane =
to <br>
&nbsp;&nbsp;&nbsp; support tunnel-based unicast source routing. <br>
<br>
&nbsp;&nbsp;&nbsp; Develop use cases for tunnel-based unicast source routin=
g <br>
&nbsp;&nbsp;&nbsp; that demonstrate the need and support for solutions. Car=
e <br>
&nbsp;&nbsp;&nbsp; should be taken to avoid clustering use cases that might=
 seem<br>
&nbsp; &nbsp; to imply support for multiple use cases when only some of the=
 <br>
&nbsp;&nbsp;&nbsp; cluster actually have wide-scale support. <br>
<br>
&nbsp;&nbsp;&nbsp; Develop ISIS and OSPF protocol extensions necessary for =
<br>
&nbsp;&nbsp; distribution of MPLS forwarding information. <br>
<br>
&nbsp;&nbsp;&nbsp; The working group will consider management (including&nb=
sp; <br>
&nbsp;&nbsp;&nbsp; configuration, reporting, diagnostics, and OAM) and secu=
rity <br>
&nbsp;&nbsp;&nbsp; implications of its work and document them in separate <=
br>
&nbsp;&nbsp;&nbsp; documents as appropriate. <br>
<br>
&nbsp;&nbsp;&nbsp; The working group is not chartered to make any changes t=
o <br>
&nbsp;&nbsp;&nbsp; the MPLS or IPv6 data planes. Any proposed changes to th=
e <br>
&nbsp;&nbsp;&nbsp; data planes are to be specified in the working groups re=
sponsible <br>
&nbsp;&nbsp;&nbsp; for the data planes (that is, the MPLS and 6MAN working =
groups,&nbsp; <br>
&nbsp;&nbsp;&nbsp; respectively).<br>
<br>
- Stewart<o:p></o:p></span></p>
</div>
</div>
</body>
</html>

--_000_1FEE3F8F5CCDE64C9A8E8F4AD27C19EE08202966NKGEML512MBSchi_--

From: Rob Shakir <[email-masked]>
Date: Thu, 5 Sep 2013 10:23:11 +0100
To: "George Swallow (swallow)" <[email-masked]>
Cc: "[email-masked]" <[email-masked]>, AshwoodsmithPeter <[email-masked]>
Subject: Re: [Status] Summary of STATUS BOF and the next steps

On 4 Sep 2013, at 22:38, "George Swallow (swallow)" <[email-masked]> =
wrote:

> I actually don't think it is possible to write a dataplane agnostic =
architecture.   We can write an architecture document that is 90% =
dataplane independent and then has some dataplane dependencies.  E.g. =
having the full SR path available at each hop vs the remainder.

You're right, maybe "agnostic" is an overstatement, but it at least =
needs to be data plane independent as you say (such that the =
architecture does not link to a specific data plane, but can be re-used =
across them). The way that we develop the architecture should of course =
take into account what the capabilities are of the data planes that we =
envisage deploying SR on.

r.=

From: Hannes Gredler <[email-masked]>
Date: Thu, 5 Sep 2013 10:50:49 +0200
To: "Stefano Previdi (sprevidi)" <[email-masked]>
Cc: Stephane Litkowski <[email-masked]>, "[email-masked]" <[email-masked]>
Subject: Re: [Status] Summary of STATUS BOF and the next steps

hi stefano,

please see comments inline;

On Sep 5, 2013, at 10:18 AM, Stefano Previdi (sprevidi) wrote:

> Hannes, Stephane,
>=20
>=20
> On Sep 5, 2013, at 10:00 AM, Hannes and Stephane wrote:
>>=20
>> Hannes,
>>=20
>>=20
>>> In the proposed segment routing architectural concepts, segments are
>>> at the same "level" and pointer moves on the segment list, then the
>>> MPLS instantiation is performing this using stacking ...
>>=20
>> [HG] the "moving pointer" is a requirement without an actual use case =
- do you know how this would be used ? - i don't
>>=20
>> [SLI] Interrest is to keep tracking where the packet is coming from. =
I'm not saying that this is a good the solution or not ... working group =
should decide ... but enforcing "stacking" is the charter may close door =
to some other solutions.
>=20
>=20
> absolutely agree. Data-plane agnostic means there may be differences
> in the way data-planes instantiate a function.
>=20
> If one data-plane stacks, the other may point. Nothing wrong with=20
> this.
>=20
>=20
>>> Finally, about the "routing" word, routing is essentially a =
"forward" action which may limit the scope of what we can do by using a =
segment list. Actions associated with a segment could be something else =
than forwarding.
>>> Do we want in the charter to limit the scope to routing actions ?
>>>=20
>>=20
>> HG> as per the published use-case drafts all i have seen are =
use-cases
>> HG> related to
>> "forwarding". as far as i am concerned i am good limiting the scope =
to "routing actions".
>=20
>=20
> not me. There are use cases, (still to document but pretty real) that
> are not routing based. Service Chaining is one.

HG> the use cases becomes "real" once they see the light of day =
(=3Dpublication)
    in the meantime they'll remain "fictional".
    for network service chaining it is my understanding that there is a =
dedicated BOF/WG.
    i fail to see why we would need to do it here. - quite contrary it =
may be one of those things
    that http://tools.ietf.org/html/rfc1925 section 2 point (5) warns us =
about.

>> [SLI] We had to start with something simple, that's why the current =
use cases are related only to forwarding. But it's not a reason to limit =
the charter to this ...
>=20
>=20
> absolutely agree.

HG> good so lets keep it out for now, and change charter later as =
requirements become more clear;

>=20
>>> - They form a connected network
>>>      [SLI] InterAS case must be included, but the WG can go step by =
step and first release intraAS, and then doing interAS (in relation with =
IDR ??).
>>=20
>> HG> did i preclude inter-AS in any way ?
>>=20
>> [SLI] It was not clear to me what did you put behind "connected =
network"
>>=20
>>=20
>>> - They can forward traffic through the shortest paths or paths other =
than the shortest (the latter called explicitly routed paths, or =
explicit paths)
>>>      [SLI] There is something else between SPT and Explicit path, =
you can define other algorithms than SPT to define a path, and it's not =
explicit path. Moreover I come back to my comment, on do we want to =
limit the scope to routing ? I would say no.
>>=20
>> HG> if you have a case for non-routing, please make it; - IIRC in our
>> HG> past 6 months of
>> conversation around IGP label advertisement / SR we haven't discussed =
any non-routing use-case.
>=20
>=20
> Service chaining is one of them.
>=20
> Thanks.
>=20
> s.
>=20
>=20
>=20
>> [SLI] Non routing use case are more future ...  routing is the basic =
infrastructure on top of which you can add some stuffs.
>>=20
>>=20
>> Stephane
>>=20
>>=20
>>=20
>>=20
>> -----Message d'origine-----
>> De : Hannes Gredler [mailto:[email-masked]]
>> Envoy=E9 : jeudi 5 septembre 2013 05:54
>> =C0 : LITKOWSKI Stephane DTF/DERX
>> Cc : [email-masked]
>> Objet : Re: [Status] Summary of STATUS BOF and the next steps
>>=20
>> hi stephane,
>>=20
>> see comments inline prefixed by HG>
>>=20
>> On Sep 4, 2013, at 10:02 AM, <[email-masked]> =
<[email-masked]> wrote:
>>> case, we are using only directed forwarding (adjacency segment),
>>> could we still talk about tunneling ? (it's a very very small =
tunnel)
>>> Moreover talking about "stacking" is really dataplane agnostic =
(MPLS)
>>> ...
>>=20
>> HG> one-hop tunnels are ok;
>>=20
>>> In the proposed segment routing architectural concepts, segments are
>>> at the same "level" and pointer moves on the segment list, then the
>>> MPLS instantiation is performing this using stacking ...
>>=20
>> the "moving pointer" is a requirement without an actual use case - do =
you know how this would be used ? - i don't
>>=20
>>> IMHO, if we use "Stacked Tunnels", we already talk about a chosen
>>> solution and it's closing the door to something else  ...
>>=20
>> HG> closing door to things we have no (known) requirements for is ok;
>> being anything to anybody is not helpful - the more concise the =
charter the better;
>>=20
>>> Finally, about the "routing" word, routing is essentially a =
"forward" action which may limit the scope of what we can do by using a =
segment list. Actions associated with a segment could be something else =
than forwarding.
>>> Do we want in the charter to limit the scope to routing actions ?
>>>=20
>>=20
>> HG> as per the published use-case drafts all i have seen are =
use-cases
>> HG> related to
>> "forwarding". as far as i am concerned i am good limiting the scope =
to "routing actions".
>>=20
>>> I have no solution today to propose for the naming, but I completely =
agree with Loa, to first focus on working on the charter, and define a =
clear scope of the work and then the name will be easier to find.
>>=20
>> HG> good :-)
>>=20
>>> Regarding your charter proposal :
>>>=20
>>> --------
>>>=20
>>> - They form a connected network
>>>      [SLI] InterAS case must be included, but the WG can go step by =
step and first release intraAS, and then doing interAS (in relation with =
IDR ??).
>>=20
>> HG> did i preclude inter-AS in any way ?
>>=20
>>> - They can forward traffic through the shortest paths or paths other =
than the shortest (the latter called explicitly routed paths, or =
explicit paths)
>>>      [SLI] There is something else between SPT and Explicit path, =
you can define other algorithms than SPT to define a path, and it's not =
explicit path. Moreover I come back to my comment, on do we want to =
limit the scope to routing ? I would say no.
>>=20
>> HG> if you have a case for non-routing, please make it; - IIRC in our
>> HG> past 6 months of
>> conversation around IGP label advertisement / SR we haven't discussed =
any non-routing use-case.
>>=20
>>> - They share a common trust model. In this model, any router within =
the ERD can specify an explicit path between itself and any other router =
in the ERD. It can then send any packet that passes through it through =
any path that it has specified.
>>>      [SLI] Security considerations may have to be addressed in the
>>> charter , especially for the interAS case (trust yes, but not sure
>>> access to everything may not be good)
>>=20
>> HG> ok.
>>=20
>>> Downstream routers within the ERD forward the packet as specified by =
the router at the head-end of the path.
>>> [SLI] Yes, but any router in the middle may be able to change the =
end to end explicit path.
>>=20
>> HG> is there any application outside FRR for changing an explicit =
path ?
>>=20
>>> - The first goal of the STER WG is to identify use-cases for ERDs.
>>> - Having identified use-cases, the WG will identify gaps between =
currently available technologies and use-case requirements.
>>> - The WG will then define requirements for extensions to existing =
protocols or new protocols that address gaps that are identified.
>>>=20
>>> [SLI] Agree, I would add :
>>> - defining the architecture framework
>>> - analysing the security considerations
>>=20
>> HG> ok;
>>=20
>>>=20
>>>=20
>>> Here would be my proposal to extend yours :
>>>=20
>>> A <named to be defined> domain contains a set of routers with the =
following characteristics:
>>>=20
>>> - They form a connected network
>>> - They can forward traffic through any path within the network using
>>> shortest path, non shortest path or explicit path
>>> - They may provide other types of services than forwarding and they =
can enforce service actions in the path.
>>> - They share a common trust model. In this model, any router within =
the domain can specify a path between itself and any other router in the =
domain. It may then send any packet that passes through it through any =
path that it has specified and that is conform to the security rules. =
Downstream routers within the ERD forward the packet as specified by the =
router at the head-end of the path.
>>>=20
>>> The <name> working group is chartered for the following ordered list =
of work items:
>>>=20
>>> - The first goal of the WG is to identify use-cases.
>>> - The WG will then define the architecture framework associated with =
the security considerations. The architecture framework and security =
considerations must address the relations between domains (interdomain).
>>> - Having identified use-cases, architecture and security, the WG =
will identify gaps between currently available technologies and use-case =
requirements.
>>> - The WG will then define requirements for extensions to existing =
protocols or new protocols that address gaps that are identified.
>>> - The WG will first focus on the intra-domain forwarding definition.
>>>=20
>>> Protocol work may be carried out in this working group or in other =
working groups responsible for the protocols, in coordination with this =
WG, and in agreement with the WG chairs and responsible ADs. However, no =
protocol work will be adopted by a working group to address the ERD =
use-cases until the requirements document motivating the protocol work =
has been sent to the IESG for publication as an RFC.
>>>=20
>>> -----Message d'origine-----
>>> De : [email-masked] [mailto:[email-masked]] De la
>>> part de Hannes Gredler Envoy=E9 : mardi 3 septembre 2013 18:31 =C0 : =
Loa
>>> Andersson Cc : [email-masked] Objet : Re: [Status] Summary of =
STATUS
>>> BOF and the next steps
>>>=20
>>> good point - what about this charter proposal ?
>>>=20
>>> ---
>>>=20
>>> Stacked Tunnels for Explicit Routing (STER)
>>> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
>>>=20
>>> A explicit routing domain (ERD) contains a set of routers with the =
following characteristics:
>>>=20
>>> - They form a connected network
>>> - They can forward traffic through the shortest paths or paths other
>>> than the shortest (the latter called explicitly routed paths, or
>>> explicit paths)
>>> - They share a common trust model. In this model, any router within =
the ERD can specify an explicit path between itself and any other router =
in the ERD. It can then send any packet that passes through it through =
any path that it has specified. Downstream routers within the ERD =
forward the packet as specified by the router at the head-end of the =
path.
>>>=20
>>> The STER working group is chartered for the following ordered list =
of work items:
>>>=20
>>> - The first goal of the STER WG is to identify use-cases for ERDs.
>>> - Having identified use-cases, the WG will identify gaps between =
currently available technologies and use-case requirements.
>>> - The WG will then define requirements for extensions to existing =
protocols or new protocols that address gaps that are identified.
>>>=20
>>> Protocol work may be carried out in this working group or in other =
working groups responsible for the protocols, in coordination with this =
WG, and in agreement with the WG chairs and responsible ADs. However, no =
protocol work will be adopted by a working group to address the ERD =
use-cases until the requirements document motivating the protocol work =
has been sent to the IESG for publication as an RFC.
>>>=20
>>> ---
>>>=20
>>> <flame suit on>
>>>=20
>>> /hannes
>>>=20
>>>=20
>>> On Sep 3, 2013, at 5:31 PM, Loa Andersson wrote:
>>>=20
>>>> Folks,
>>>>=20
>>>> Excuse me if I'm slightly out of the loop, but so far I have not =
seen
>>>> a charter proposal, if there is one please point me to it.
>>>>=20
>>>> It seems a bit odd to put the cart (what the wg should do) before =
the
>>>> horse (wg name). If we drill down the the charter first the wg name
>>>> might be easier to figure out.
>>>>=20
>>>> /Loa
>>>>=20
>>>> PS
>>>> OK I understand that the horse and cart analogy limps a  bit :).
>>>>=20
>>>>=20
>>>>=20
>>>> On 2013-09-03 17:22, AshwoodsmithPeter wrote:
>>>>> " If the WG charter is limited to source routing, how will we =
handle the "non source routing" use cases of segment routing ? In =
another working group ? So we will go back to the WG synchronization =
issue that has been raised for this technology ..."
>>>>>=20
>>>>> That's why I suggested SRV2. We are revisiting source routing with =
new concepts. More generic number/action behavior.
>>>>>=20
>>>>> Peter
>>>>>=20
>>>>> -----Original Message-----
>>>>> From: [email-masked] [mailto:[email-masked]] On
>>>>> Behalf Of [email-masked]
>>>>> Sent: Tuesday, September 03, 2013 10:43 AM
>>>>> To: AshwoodsmithPeter
>>>>> Cc: [email-masked]
>>>>> Subject: Re: [Status] Summary of STATUS BOF and the next steps
>>>>>=20
>>>>>=20
>>>>> There was a misunderstanding in my small comment :) so I will =
explain more :
>>>>>=20
>>>>> In segment routing, you have more than basic source routing : =
segment routing is just associate a segment number to an action and then =
combine segment as you want, yes you can do source routing, but you also =
can do more.
>>>>>=20
>>>>> In the other hand, I completely agree with your statement that
>>>>> source routing is generic and dataplane agnostic, as segment =
routing is ...
>>>>> (segment routing is not a new dataplane ...)
>>>>>=20
>>>>> Now the definition of the WG naming must be inline with the =
charter
>>>>> that will be defined ... (draft today)
>>>>>=20
>>>>> Based on the already existing consensus (at least for MPLS =
dataplane) brought up during Berlin STATUS BOF meeting, segment routing =
sounds to be a good target candidate.
>>>>>=20
>>>>> So now, do we want to do more in the WG charter than just make =
progressing segment routing architecture and uses cases document and =
ensure coordination for the standardization of this technology ?
>>>>>=20
>>>>> Do we want to standardize other technologies in this WG ? I don't =
think so, based on Stewart's conclusion email from the BOF :"A new WG =
focused solely on SR therefore needs to be create"
>>>>>=20
>>>>> If the WG charter is limited to source routing, how will we handle =
the "non source routing" use cases of segment routing ? In another =
working group ? So we will go back to the WG synchronization issue that =
has been raised for this technology ...
>>>>>=20
>>>>> If the WG is focused on SR, let's use a name in relation with SR.
>>>>>=20
>>>>> Feedback ?
>>>>>=20
>>>>>=20
>>>>> Stephane
>>>>>=20
>>>>>=20
>>>>> -----Message d'origine-----
>>>>> De : AshwoodsmithPeter [mailto:[email-masked]]
>>>>> Envoy=E9 : mardi 3 septembre 2013 15:27 =C0 : LITKOWSKI Stephane
>>>>> DTF/DERX Cc : John E Drake; Mark Townsley; Victor Kuarsingh; =
Roberta
>>>>> Maglione (robmgl); John G. Scudder; Adrian Farrel; Alvaro Retana
>>>>> (aretana); [email-masked]; Stewart Bryant (stbryant) Objet : Re:
>>>>> [Status] Summary of STATUS BOF and the next steps
>>>>>=20
>>>>> The term "source routing" has been around for a very long time and =
is data path agnostic. Its also the term used in the literature etc so =
my preference is to stick with this existing well known and data path =
agnostic term.
>>>>>=20
>>>>> Peter
>>>>>=20
>>>>> On Sep 3, 2013, at 9:07 AM, "[email-masked]" =
<[email-masked]> wrote:
>>>>>=20
>>>>>> Hi,
>>>>>>=20
>>>>>> "Source routing" is just a subcase of segment routing ... as it =
is for IP routing ...
>>>>>>=20
>>>>>> Stephane
>>>>>>=20
>>>>>>=20
>>>>>> -----Message d'origine-----
>>>>>> De : [email-masked] [mailto:[email-masked]] De =
la
>>>>>> part de John E Drake Envoy=E9 : mardi 3 septembre 2013 15:02 =C0 =
: Mark
>>>>>> Townsley; Victor Kuarsingh Cc : Roberta Maglione (robmgl); John =
G.
>>>>>> Scudder; Alvaro Retana (aretana); Adrian Farrel; [email-masked];
>>>>>> Stewart Bryant (stbryant) Objet : Re: [Status] Summary of STATUS
>>>>>> BOF and the next steps
>>>>>>=20
>>>>>> Hi,
>>>>>>=20
>>>>>> What is this 'segment routing' silliness?  The correct term is =
'source routing'.
>>>>>>=20
>>>>>> Yours Irrespectively,
>>>>>>=20
>>>>>> John
>>>>>>=20
>>>>>>> -----Original Message-----
>>>>>>> From: [email-masked] [mailto:[email-masked]] =
On
>>>>>>> Behalf Of Mark Townsley
>>>>>>> Sent: Sunday, September 01, 2013 10:08 AM
>>>>>>> To: Victor Kuarsingh
>>>>>>> Cc: Roberta Maglione (robmgl); John G. Scudder; Adrian Farrel;
>>>>>>> Alvaro Retana (aretana); [email-masked]; Stewart Bryant
>>>>>>> (stbryant)
>>>>>>> Subject: Re: [Status] Summary of STATUS BOF and the next steps
>>>>>>>=20
>>>>>>>=20
>>>>>>> On Sep 1, 2013, at 5:38 PM, Victor Kuarsingh wrote:
>>>>>>>=20
>>>>>>>> All,
>>>>>>>>=20
>>>>>>>> I would also favour "Segment Routing WG" as well.
>>>>>>>>=20
>>>>>>>> I note this since attempting to come up with an all =
encompassing
>>>>>>>> acronym will be difficult and Segment Routing is generic enough
>>>>>>>> to associate to multiple functions.
>>>>>>>=20
>>>>>>> Then we can just use "segroute" for the short name. WGs do not
>>>>>>> have to have acronyms, but they do need to have an 8-char =
limited
>>>>>>> short name for the various automated tools not to break.
>>>>>>>=20
>>>>>>> - Mark
>>>>>>>=20
>>>>>>>>=20
>>>>>>>> Regards,
>>>>>>>>=20
>>>>>>>> Victor K
>>>>>>>>=20
>>>>>>>>=20
>>>>>>>>=20
>>>>>>>> On 2013-08-31 6:51 PM, "Roberta Maglione (robmgl)"
>>>>>>>> <[email-masked]>
>>>>>>>> wrote:
>>>>>>>>=20
>>>>>>>>> +1 for Segment Routing WG
>>>>>>>>>=20
>>>>>>>>> Roberta
>>>>>>>>>=20
>>>>>>>>> Sent from my iPad
>>>>>>>>>=20
>>>>>>>>> On 2013-08-30, at 2:55 PM, "Alvaro Retana (aretana)"
>>>>>>>>> <[email-masked]>
>>>>>>>>> wrote:
>>>>>>>>>=20
>>>>>>>>>> Segment Routing WG
>>>>>>>>>>=20
>>>>>>>>>> Sent from my iPhone
>>>>>>>>>>=20
>>>>>>>>>> On Aug 30, 2013, at 1:39 PM, "Stewart Bryant (stbryant)"
>>>>>>>>>> <[email-masked]> wrote:
>>>>>>>>>>=20
>>>>>>>>>>> The second task, which hopefully should be relatively easy, =
is
>>>>>>>>>>> to find a better working name for the WG, since it has been
>>>>>>>>>>> put to me a number of times that STATUS is going to be
>>>>>>>>>>> confusing in text and a difficult search term.
>>>>>>>>>> _______________________________________________
>>>>>>>>>> status mailing list
>>>>>>>>>> [email-masked]
>>>>>>>>>> https://www.ietf.org/mailman/listinfo/status
>>>>>>>>> _______________________________________________
>>>>>>>>> status mailing list
>>>>>>>>> [email-masked]
>>>>>>>>> https://www.ietf.org/mailman/listinfo/status
>>>>>>>>=20
>>>>>>>>=20
>>>>>>>> _______________________________________________
>>>>>>>> status mailing list
>>>>>>>> [email-masked]
>>>>>>>> https://www.ietf.org/mailman/listinfo/status
>>>>>>>=20
>>>>>>> _______________________________________________
>>>>>>> status mailing list
>>>>>>> [email-masked]
>>>>>>> https://www.ietf.org/mailman/listinfo/status
>>>>>>=20
>>>>>>=20
>>>>>> _______________________________________________
>>>>>> status mailing list
>>>>>> [email-masked]
>>>>>> https://www.ietf.org/mailman/listinfo/status
>>>>>>=20
>>>>>> =
___________________________________________________________________
>>>>>> _ __ ___________________________________________________
>>>>>>=20
>>>>>> Ce message et ses pieces jointes peuvent contenir des =
informations
>>>>>> confidentielles ou privilegiees et ne doivent donc pas etre
>>>>>> diffuses, exploites ou copies sans autorisation. Si vous avez =
recu
>>>>>> ce message par erreur, veuillez le signaler a l'expediteur et le =
detruire ainsi que les pieces jointes. Les messages electroniques etant =
susceptibles d'alteration, Orange decline toute responsabilite si ce =
message a ete altere, deforme ou falsifie. Merci.
>>>>>>=20
>>>>>> This message and its attachments may contain confidential or
>>>>>> privileged information that may be protected by law; they should =
not be distributed, used or copied without authorisation.
>>>>>> If you have received this email in error, please notify the =
sender and delete this message and its attachments.
>>>>>> As emails may be altered, Orange is not liable for messages that =
have been modified, changed or falsified.
>>>>>> Thank you.
>>>>>>=20
>>>>>> _______________________________________________
>>>>>> status mailing list
>>>>>> [email-masked]
>>>>>> https://www.ietf.org/mailman/listinfo/status
>>>>>=20
>>>>> =
____________________________________________________________________
>>>>> _ ____________________________________________________
>>>>>=20
>>>>> Ce message et ses pieces jointes peuvent contenir des informations
>>>>> confidentielles ou privilegiees et ne doivent donc pas etre
>>>>> diffuses, exploites ou copies sans autorisation. Si vous avez recu
>>>>> ce message par erreur, veuillez le signaler a l'expediteur et le =
detruire ainsi que les pieces jointes. Les messages electroniques etant =
susceptibles d'alteration, Orange decline toute responsabilite si ce =
message a ete altere, deforme ou falsifie. Merci.
>>>>>=20
>>>>> This message and its attachments may contain confidential or
>>>>> privileged information that may be protected by law; they should =
not be distributed, used or copied without authorisation.
>>>>> If you have received this email in error, please notify the sender =
and delete this message and its attachments.
>>>>> As emails may be altered, Orange is not liable for messages that =
have been modified, changed or falsified.
>>>>> Thank you.
>>>>>=20
>>>>> _______________________________________________
>>>>> status mailing list
>>>>> [email-masked]
>>>>> https://www.ietf.org/mailman/listinfo/status
>>>>> _______________________________________________
>>>>> status mailing list
>>>>> [email-masked]
>>>>> https://www.ietf.org/mailman/listinfo/status
>>>>>=20
>>>>=20
>>>> --
>>>>=20
>>>>=20
>>>> Loa Andersson                        email: [email-masked]
>>>> Senior MPLS Expert                          [email-masked]
>>>> Huawei Technologies (consultant)     phone: +46 739 81 21 64
>>>> _______________________________________________
>>>> status mailing list
>>>> [email-masked]
>>>> https://www.ietf.org/mailman/listinfo/status
>>>>=20
>>>>=20
>>>=20
>>>=20
>>> _______________________________________________
>>> status mailing list
>>> [email-masked]
>>> https://www.ietf.org/mailman/listinfo/status
>>>=20
>>> =
______________________________________________________________________
>>> ___________________________________________________
>>>=20
>>> Ce message et ses pieces jointes peuvent contenir des informations
>>> confidentielles ou privilegiees et ne doivent donc pas etre =
diffuses,
>>> exploites ou copies sans autorisation. Si vous avez recu ce message
>>> par erreur, veuillez le signaler a l'expediteur et le detruire ainsi =
que les pieces jointes. Les messages electroniques etant susceptibles =
d'alteration, Orange decline toute responsabilite si ce message a ete =
altere, deforme ou falsifie. Merci.
>>>=20
>>> This message and its attachments may contain confidential or
>>> privileged information that may be protected by law; they should not =
be distributed, used or copied without authorisation.
>>> If you have received this email in error, please notify the sender =
and delete this message and its attachments.
>>> As emails may be altered, Orange is not liable for messages that =
have been modified, changed or falsified.
>>> Thank you.
>>>=20
>>>=20
>>>=20
>>=20
>>=20
>>=20
>> =
__________________________________________________________________________=
_______________________________________________
>>=20
>> Ce message et ses pieces jointes peuvent contenir des informations =
confidentielles ou privilegiees et ne doivent donc
>> pas etre diffuses, exploites ou copies sans autorisation. Si vous =
avez recu ce message par erreur, veuillez le signaler
>> a l'expediteur et le detruire ainsi que les pieces jointes. Les =
messages electroniques etant susceptibles d'alteration,
>> Orange decline toute responsabilite si ce message a ete altere, =
deforme ou falsifie. Merci.
>>=20
>> This message and its attachments may contain confidential or =
privileged information that may be protected by law;
>> they should not be distributed, used or copied without authorisation.
>> If you have received this email in error, please notify the sender =
and delete this message and its attachments.
>> As emails may be altered, Orange is not liable for messages that have =
been modified, changed or falsified.
>> Thank you.
>>=20
>> _______________________________________________
>> status mailing list
>> [email-masked]
>> https://www.ietf.org/mailman/listinfo/status
>=20
>=20
>=20

From: "Stefano Previdi (sprevidi)" <[email-masked]>
To: Hannes Gredler <[email-masked]>, Stephane Litkowski <[email-masked]>, "[email-masked]" <[email-masked]>
Date: Thu, 5 Sep 2013 08:18:46 +0000
Accept-Language: en-US
Subject: Re: [Status] Summary of STATUS BOF and the next steps

Hannes, Stephane,

On Sep 5, 2013, at 10:00 AM, Hannes and Stephane wrote:
>=20
> Hannes,
>=20
>=20
>> In the proposed segment routing architectural concepts, segments are
>> at the same "level" and pointer moves on the segment list, then the
>> MPLS instantiation is performing this using stacking ...
>=20
> [HG] the "moving pointer" is a requirement without an actual use case - d=
o you know how this would be used ? - i don't
>=20
> [SLI] Interrest is to keep tracking where the packet is coming from. I'm =
not saying that this is a good the solution or not ... working group should=
 decide ... but enforcing "stacking" is the charter may close door to some =
other solutions.

absolutely agree. Data-plane agnostic means there may be differences
in the way data-planes instantiate a function.

If one data-plane stacks, the other may point. Nothing wrong with=20
this.

>> Finally, about the "routing" word, routing is essentially a "forward" ac=
tion which may limit the scope of what we can do by using a segment list. A=
ctions associated with a segment could be something else than forwarding.
>> Do we want in the charter to limit the scope to routing actions ?
>>=20
>=20
> HG> as per the published use-case drafts all i have seen are use-cases
> HG> related to
> "forwarding". as far as i am concerned i am good limiting the scope to "r=
outing actions".

not me. There are use cases, (still to document but pretty real) that
are not routing based. Service Chaining is one.

> [SLI] We had to start with something simple, that's why the current use c=
ases are related only to forwarding. But it's not a reason to limit the cha=
rter to this ...

absolutely agree.

>> - They form a connected network
>>       [SLI] InterAS case must be included, but the WG can go step by ste=
p and first release intraAS, and then doing interAS (in relation with IDR ?=
?).
>=20
> HG> did i preclude inter-AS in any way ?
>=20
> [SLI] It was not clear to me what did you put behind "connected network"
>=20
>=20
>> - They can forward traffic through the shortest paths or paths other tha=
n the shortest (the latter called explicitly routed paths, or explicit path=
s)
>>       [SLI] There is something else between SPT and Explicit path, you c=
an define other algorithms than SPT to define a path, and it's not explicit=
 path. Moreover I come back to my comment, on do we want to limit the scope=
 to routing ? I would say no.
>=20
> HG> if you have a case for non-routing, please make it; - IIRC in our
> HG> past 6 months of
> conversation around IGP label advertisement / SR we haven't discussed any=
 non-routing use-case.

Service chaining is one of them.

Thanks.

s.

> [SLI] Non routing use case are more future ...  routing is the basic infr=
astructure on top of which you can add some stuffs.
>=20
>=20
> Stephane
>=20
>=20
>=20
>=20
> -----Message d'origine-----
> De : Hannes Gredler [mailto:[email-masked]]
> Envoy=E9 : jeudi 5 septembre 2013 05:54
> =C0 : LITKOWSKI Stephane DTF/DERX
> Cc : [email-masked]
> Objet : Re: [Status] Summary of STATUS BOF and the next steps
>=20
> hi stephane,
>=20
> see comments inline prefixed by HG>
>=20
> On Sep 4, 2013, at 10:02 AM, <[email-masked]> <stephane.li=
[email-masked]> wrote:
>> case, we are using only directed forwarding (adjacency segment),
>> could we still talk about tunneling ? (it's a very very small tunnel)
>> Moreover talking about "stacking" is really dataplane agnostic (MPLS)
>> ...
>=20
> HG> one-hop tunnels are ok;
>=20
>> In the proposed segment routing architectural concepts, segments are
>> at the same "level" and pointer moves on the segment list, then the
>> MPLS instantiation is performing this using stacking ...
>=20
> the "moving pointer" is a requirement without an actual use case - do you=
 know how this would be used ? - i don't
>=20
>> IMHO, if we use "Stacked Tunnels", we already talk about a chosen
>> solution and it's closing the door to something else  ...
>=20
> HG> closing door to things we have no (known) requirements for is ok;
> being anything to anybody is not helpful - the more concise the charter t=
he better;
>=20
>> Finally, about the "routing" word, routing is essentially a "forward" ac=
tion which may limit the scope of what we can do by using a segment list. A=
ctions associated with a segment could be something else than forwarding.
>> Do we want in the charter to limit the scope to routing actions ?
>>=20
>=20
> HG> as per the published use-case drafts all i have seen are use-cases
> HG> related to
> "forwarding". as far as i am concerned i am good limiting the scope to "r=
outing actions".
>=20
>> I have no solution today to propose for the naming, but I completely agr=
ee with Loa, to first focus on working on the charter, and define a clear s=
cope of the work and then the name will be easier to find.
>=20
> HG> good :-)
>=20
>> Regarding your charter proposal :
>>=20
>> --------
>>=20
>> - They form a connected network
>>       [SLI] InterAS case must be included, but the WG can go step by ste=
p and first release intraAS, and then doing interAS (in relation with IDR ?=
?).
>=20
> HG> did i preclude inter-AS in any way ?
>=20
>> - They can forward traffic through the shortest paths or paths other tha=
n the shortest (the latter called explicitly routed paths, or explicit path=
s)
>>       [SLI] There is something else between SPT and Explicit path, you c=
an define other algorithms than SPT to define a path, and it's not explicit=
 path. Moreover I come back to my comment, on do we want to limit the scope=
 to routing ? I would say no.
>=20
> HG> if you have a case for non-routing, please make it; - IIRC in our
> HG> past 6 months of
> conversation around IGP label advertisement / SR we haven't discussed any=
 non-routing use-case.
>=20
>> - They share a common trust model. In this model, any router within the =
ERD can specify an explicit path between itself and any other router in the=
 ERD. It can then send any packet that passes through it through any path t=
hat it has specified.
>>       [SLI] Security considerations may have to be addressed in the
>> charter , especially for the interAS case (trust yes, but not sure
>> access to everything may not be good)
>=20
> HG> ok.
>=20
>> Downstream routers within the ERD forward the packet as specified by the=
 router at the head-end of the path.
>> [SLI] Yes, but any router in the middle may be able to change the end to=
 end explicit path.
>=20
> HG> is there any application outside FRR for changing an explicit path ?
>=20
>> - The first goal of the STER WG is to identify use-cases for ERDs.
>> - Having identified use-cases, the WG will identify gaps between current=
ly available technologies and use-case requirements.
>> - The WG will then define requirements for extensions to existing protoc=
ols or new protocols that address gaps that are identified.
>>=20
>> [SLI] Agree, I would add :
>> - defining the architecture framework
>> - analysing the security considerations
>=20
> HG> ok;
>=20
>>=20
>>=20
>> Here would be my proposal to extend yours :
>>=20
>> A <named to be defined> domain contains a set of routers with the follow=
ing characteristics:
>>=20
>> - They form a connected network
>> - They can forward traffic through any path within the network using
>> shortest path, non shortest path or explicit path
>> - They may provide other types of services than forwarding and they can =
enforce service actions in the path.
>> - They share a common trust model. In this model, any router within the =
domain can specify a path between itself and any other router in the domain=
. It may then send any packet that passes through it through any path that =
it has specified and that is conform to the security rules. Downstream rout=
ers within the ERD forward the packet as specified by the router at the hea=
d-end of the path.
>>=20
>> The <name> working group is chartered for the following ordered list of =
work items:
>>=20
>> - The first goal of the WG is to identify use-cases.
>> - The WG will then define the architecture framework associated with the=
 security considerations. The architecture framework and security considera=
tions must address the relations between domains (interdomain).
>> - Having identified use-cases, architecture and security, the WG will id=
entify gaps between currently available technologies and use-case requireme=
nts.
>> - The WG will then define requirements for extensions to existing protoc=
ols or new protocols that address gaps that are identified.
>> - The WG will first focus on the intra-domain forwarding definition.
>>=20
>> Protocol work may be carried out in this working group or in other worki=
ng groups responsible for the protocols, in coordination with this WG, and =
in agreement with the WG chairs and responsible ADs. However, no protocol w=
ork will be adopted by a working group to address the ERD use-cases until t=
he requirements document motivating the protocol work has been sent to the =
IESG for publication as an RFC.
>>=20
>> -----Message d'origine-----
>> De : [email-masked] [mailto:[email-masked]] De la
>> part de Hannes Gredler Envoy=E9 : mardi 3 septembre 2013 18:31 =C0 : Loa
>> Andersson Cc : [email-masked] Objet : Re: [Status] Summary of STATUS
>> BOF and the next steps
>>=20
>> good point - what about this charter proposal ?
>>=20
>> ---
>>=20
>> Stacked Tunnels for Explicit Routing (STER)
>> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
>>=20
>> A explicit routing domain (ERD) contains a set of routers with the follo=
wing characteristics:
>>=20
>> - They form a connected network
>> - They can forward traffic through the shortest paths or paths other
>> than the shortest (the latter called explicitly routed paths, or
>> explicit paths)
>> - They share a common trust model. In this model, any router within the =
ERD can specify an explicit path between itself and any other router in the=
 ERD. It can then send any packet that passes through it through any path t=
hat it has specified. Downstream routers within the ERD forward the packet =
as specified by the router at the head-end of the path.
>>=20
>> The STER working group is chartered for the following ordered list of wo=
rk items:
>>=20
>> - The first goal of the STER WG is to identify use-cases for ERDs.
>> - Having identified use-cases, the WG will identify gaps between current=
ly available technologies and use-case requirements.
>> - The WG will then define requirements for extensions to existing protoc=
ols or new protocols that address gaps that are identified.
>>=20
>> Protocol work may be carried out in this working group or in other worki=
ng groups responsible for the protocols, in coordination with this WG, and =
in agreement with the WG chairs and responsible ADs. However, no protocol w=
ork will be adopted by a working group to address the ERD use-cases until t=
he requirements document motivating the protocol work has been sent to the =
IESG for publication as an RFC.
>>=20
>> ---
>>=20
>> <flame suit on>
>>=20
>> /hannes
>>=20
>>=20
>> On Sep 3, 2013, at 5:31 PM, Loa Andersson wrote:
>>=20
>>> Folks,
>>>=20
>>> Excuse me if I'm slightly out of the loop, but so far I have not seen
>>> a charter proposal, if there is one please point me to it.
>>>=20
>>> It seems a bit odd to put the cart (what the wg should do) before the
>>> horse (wg name). If we drill down the the charter first the wg name
>>> might be easier to figure out.
>>>=20
>>> /Loa
>>>=20
>>> PS
>>> OK I understand that the horse and cart analogy limps a  bit :).
>>>=20
>>>=20
>>>=20
>>> On 2013-09-03 17:22, AshwoodsmithPeter wrote:
>>>> " If the WG charter is limited to source routing, how will we handle t=
he "non source routing" use cases of segment routing ? In another working g=
roup ? So we will go back to the WG synchronization issue that has been rai=
sed for this technology ..."
>>>>=20
>>>> That's why I suggested SRV2. We are revisiting source routing with new=
 concepts. More generic number/action behavior.
>>>>=20
>>>> Peter
>>>>=20
>>>> -----Original Message-----
>>>> From: [email-masked] [mailto:[email-masked]] On
>>>> Behalf Of [email-masked]
>>>> Sent: Tuesday, September 03, 2013 10:43 AM
>>>> To: AshwoodsmithPeter
>>>> Cc: [email-masked]
>>>> Subject: Re: [Status] Summary of STATUS BOF and the next steps
>>>>=20
>>>>=20
>>>> There was a misunderstanding in my small comment :) so I will explain =
more :
>>>>=20
>>>> In segment routing, you have more than basic source routing : segment =
routing is just associate a segment number to an action and then combine se=
gment as you want, yes you can do source routing, but you also can do more.
>>>>=20
>>>> In the other hand, I completely agree with your statement that
>>>> source routing is generic and dataplane agnostic, as segment routing i=
s ...
>>>> (segment routing is not a new dataplane ...)
>>>>=20
>>>> Now the definition of the WG naming must be inline with the charter
>>>> that will be defined ... (draft today)
>>>>=20
>>>> Based on the already existing consensus (at least for MPLS dataplane) =
brought up during Berlin STATUS BOF meeting, segment routing sounds to be a=
 good target candidate.
>>>>=20
>>>> So now, do we want to do more in the WG charter than just make progres=
sing segment routing architecture and uses cases document and ensure coordi=
nation for the standardization of this technology ?
>>>>=20
>>>> Do we want to standardize other technologies in this WG ? I don't thin=
k so, based on Stewart's conclusion email from the BOF :"A new WG focused s=
olely on SR therefore needs to be create"
>>>>=20
>>>> If the WG charter is limited to source routing, how will we handle the=
 "non source routing" use cases of segment routing ? In another working gro=
up ? So we will go back to the WG synchronization issue that has been raise=
d for this technology ...
>>>>=20
>>>> If the WG is focused on SR, let's use a name in relation with SR.
>>>>=20
>>>> Feedback ?
>>>>=20
>>>>=20
>>>> Stephane
>>>>=20
>>>>=20
>>>> -----Message d'origine-----
>>>> De : AshwoodsmithPeter [mailto:[email-masked]]
>>>> Envoy=E9 : mardi 3 septembre 2013 15:27 =C0 : LITKOWSKI Stephane
>>>> DTF/DERX Cc : John E Drake; Mark Townsley; Victor Kuarsingh; Roberta
>>>> Maglione (robmgl); John G. Scudder; Adrian Farrel; Alvaro Retana
>>>> (aretana); [email-masked]; Stewart Bryant (stbryant) Objet : Re:
>>>> [Status] Summary of STATUS BOF and the next steps
>>>>=20
>>>> The term "source routing" has been around for a very long time and is =
data path agnostic. Its also the term used in the literature etc so my pref=
erence is to stick with this existing well known and data path agnostic ter=
m.
>>>>=20
>>>> Peter
>>>>=20
>>>> On Sep 3, 2013, at 9:07 AM, "[email-masked]" <stephane.=
[email-masked]> wrote:
>>>>=20
>>>>> Hi,
>>>>>=20
>>>>> "Source routing" is just a subcase of segment routing ... as it is fo=
r IP routing ...
>>>>>=20
>>>>> Stephane
>>>>>=20
>>>>>=20
>>>>> -----Message d'origine-----
>>>>> De : [email-masked] [mailto:[email-masked]] De la
>>>>> part de John E Drake Envoy=E9 : mardi 3 septembre 2013 15:02 =C0 : Ma=
rk
>>>>> Townsley; Victor Kuarsingh Cc : Roberta Maglione (robmgl); John G.
>>>>> Scudder; Alvaro Retana (aretana); Adrian Farrel; [email-masked];
>>>>> Stewart Bryant (stbryant) Objet : Re: [Status] Summary of STATUS
>>>>> BOF and the next steps
>>>>>=20
>>>>> Hi,
>>>>>=20
>>>>> What is this 'segment routing' silliness?  The correct term is 'sourc=
e routing'.
>>>>>=20
>>>>> Yours Irrespectively,
>>>>>=20
>>>>> John
>>>>>=20
>>>>>> -----Original Message-----
>>>>>> From: [email-masked] [mailto:[email-masked]] On
>>>>>> Behalf Of Mark Townsley
>>>>>> Sent: Sunday, September 01, 2013 10:08 AM
>>>>>> To: Victor Kuarsingh
>>>>>> Cc: Roberta Maglione (robmgl); John G. Scudder; Adrian Farrel;
>>>>>> Alvaro Retana (aretana); [email-masked]; Stewart Bryant
>>>>>> (stbryant)
>>>>>> Subject: Re: [Status] Summary of STATUS BOF and the next steps
>>>>>>=20
>>>>>>=20
>>>>>> On Sep 1, 2013, at 5:38 PM, Victor Kuarsingh wrote:
>>>>>>=20
>>>>>>> All,
>>>>>>>=20
>>>>>>> I would also favour "Segment Routing WG" as well.
>>>>>>>=20
>>>>>>> I note this since attempting to come up with an all encompassing
>>>>>>> acronym will be difficult and Segment Routing is generic enough
>>>>>>> to associate to multiple functions.
>>>>>>=20
>>>>>> Then we can just use "segroute" for the short name. WGs do not
>>>>>> have to have acronyms, but they do need to have an 8-char limited
>>>>>> short name for the various automated tools not to break.
>>>>>>=20
>>>>>> - Mark
>>>>>>=20
>>>>>>>=20
>>>>>>> Regards,
>>>>>>>=20
>>>>>>> Victor K
>>>>>>>=20
>>>>>>>=20
>>>>>>>=20
>>>>>>> On 2013-08-31 6:51 PM, "Roberta Maglione (robmgl)"
>>>>>>> <[email-masked]>
>>>>>>> wrote:
>>>>>>>=20
>>>>>>>> +1 for Segment Routing WG
>>>>>>>>=20
>>>>>>>> Roberta
>>>>>>>>=20
>>>>>>>> Sent from my iPad
>>>>>>>>=20
>>>>>>>> On 2013-08-30, at 2:55 PM, "Alvaro Retana (aretana)"
>>>>>>>> <[email-masked]>
>>>>>>>> wrote:
>>>>>>>>=20
>>>>>>>>> Segment Routing WG
>>>>>>>>>=20
>>>>>>>>> Sent from my iPhone
>>>>>>>>>=20
>>>>>>>>> On Aug 30, 2013, at 1:39 PM, "Stewart Bryant (stbryant)"
>>>>>>>>> <[email-masked]> wrote:
>>>>>>>>>=20
>>>>>>>>>> The second task, which hopefully should be relatively easy, is
>>>>>>>>>> to find a better working name for the WG, since it has been
>>>>>>>>>> put to me a number of times that STATUS is going to be
>>>>>>>>>> confusing in text and a difficult search term.
>>>>>>>>> _______________________________________________
>>>>>>>>> status mailing list
>>>>>>>>> [email-masked]
>>>>>>>>> https://www.ietf.org/mailman/listinfo/status
>>>>>>>> _______________________________________________
>>>>>>>> status mailing list
>>>>>>>> [email-masked]
>>>>>>>> https://www.ietf.org/mailman/listinfo/status
>>>>>>>=20
>>>>>>>=20
>>>>>>> _______________________________________________
>>>>>>> status mailing list
>>>>>>> [email-masked]
>>>>>>> https://www.ietf.org/mailman/listinfo/status
>>>>>>=20
>>>>>> _______________________________________________
>>>>>> status mailing list
>>>>>> [email-masked]
>>>>>> https://www.ietf.org/mailman/listinfo/status
>>>>>=20
>>>>>=20
>>>>> _______________________________________________
>>>>> status mailing list
>>>>> [email-masked]
>>>>> https://www.ietf.org/mailman/listinfo/status
>>>>>=20
>>>>> ___________________________________________________________________
>>>>> _ __ ___________________________________________________
>>>>>=20
>>>>> Ce message et ses pieces jointes peuvent contenir des informations
>>>>> confidentielles ou privilegiees et ne doivent donc pas etre
>>>>> diffuses, exploites ou copies sans autorisation. Si vous avez recu
>>>>> ce message par erreur, veuillez le signaler a l'expediteur et le detr=
uire ainsi que les pieces jointes. Les messages electroniques etant suscept=
ibles d'alteration, Orange decline toute responsabilite si ce message a ete=
 altere, deforme ou falsifie. Merci.
>>>>>=20
>>>>> This message and its attachments may contain confidential or
>>>>> privileged information that may be protected by law; they should not =
be distributed, used or copied without authorisation.
>>>>> If you have received this email in error, please notify the sender an=
d delete this message and its attachments.
>>>>> As emails may be altered, Orange is not liable for messages that have=
 been modified, changed or falsified.
>>>>> Thank you.
>>>>>=20
>>>>> _______________________________________________
>>>>> status mailing list
>>>>> [email-masked]
>>>>> https://www.ietf.org/mailman/listinfo/status
>>>>=20
>>>> ____________________________________________________________________
>>>> _ ____________________________________________________
>>>>=20
>>>> Ce message et ses pieces jointes peuvent contenir des informations
>>>> confidentielles ou privilegiees et ne doivent donc pas etre
>>>> diffuses, exploites ou copies sans autorisation. Si vous avez recu
>>>> ce message par erreur, veuillez le signaler a l'expediteur et le detru=
ire ainsi que les pieces jointes. Les messages electroniques etant suscepti=
bles d'alteration, Orange decline toute responsabilite si ce message a ete =
altere, deforme ou falsifie. Merci.
>>>>=20
>>>> This message and its attachments may contain confidential or
>>>> privileged information that may be protected by law; they should not b=
e distributed, used or copied without authorisation.
>>>> If you have received this email in error, please notify the sender and=
 delete this message and its attachments.
>>>> As emails may be altered, Orange is not liable for messages that have =
been modified, changed or falsified.
>>>> Thank you.
>>>>=20
>>>> _______________________________________________
>>>> status mailing list
>>>> [email-masked]
>>>> https://www.ietf.org/mailman/listinfo/status
>>>> _______________________________________________
>>>> status mailing list
>>>> [email-masked]
>>>> https://www.ietf.org/mailman/listinfo/status
>>>>=20
>>>=20
>>> --
>>>=20
>>>=20
>>> Loa Andersson                        email: [email-masked]
>>> Senior MPLS Expert                          [email-masked]
>>> Huawei Technologies (consultant)     phone: +46 739 81 21 64
>>> _______________________________________________
>>> status mailing list
>>> [email-masked]
>>> https://www.ietf.org/mailman/listinfo/status
>>>=20
>>>=20
>>=20
>>=20
>> _______________________________________________
>> status mailing list
>> [email-masked]
>> https://www.ietf.org/mailman/listinfo/status
>>=20
>> ______________________________________________________________________
>> ___________________________________________________
>>=20
>> Ce message et ses pieces jointes peuvent contenir des informations
>> confidentielles ou privilegiees et ne doivent donc pas etre diffuses,
>> exploites ou copies sans autorisation. Si vous avez recu ce message
>> par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que=
 les pieces jointes. Les messages electroniques etant susceptibles d'altera=
tion, Orange decline toute responsabilite si ce message a ete altere, defor=
me ou falsifie. Merci.
>>=20
>> This message and its attachments may contain confidential or
>> privileged information that may be protected by law; they should not be =
distributed, used or copied without authorisation.
>> If you have received this email in error, please notify the sender and d=
elete this message and its attachments.
>> As emails may be altered, Orange is not liable for messages that have be=
en modified, changed or falsified.
>> Thank you.
>>=20
>>=20
>>=20
>=20
>=20
>=20
> _________________________________________________________________________=
________________________________________________
>=20
> Ce message et ses pieces jointes peuvent contenir des informations confid=
entielles ou privilegiees et ne doivent donc
> pas etre diffuses, exploites ou copies sans autorisation. Si vous avez re=
cu ce message par erreur, veuillez le signaler
> a l'expediteur et le detruire ainsi que les pieces jointes. Les messages =
electroniques etant susceptibles d'alteration,
> Orange decline toute responsabilite si ce message a ete altere, deforme o=
u falsifie. Merci.
>=20
> This message and its attachments may contain confidential or privileged i=
nformation that may be protected by law;
> they should not be distributed, used or copied without authorisation.
> If you have received this email in error, please notify the sender and de=
lete this message and its attachments.
> As emails may be altered, Orange is not liable for messages that have bee=
n modified, changed or falsified.
> Thank you.
>=20
> _______________________________________________
> status mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/status

From: <[email-masked]>
To: Hannes Gredler <[email-masked]>
Date: Thu, 5 Sep 2013 10:00:34 +0200
Accept-Language: fr-FR
acceptlanguage: fr-FR
Cc: "[email-masked]" <[email-masked]>
Subject: Re: [Status] Summary of STATUS BOF and the next steps

Hannes,

> In the proposed segment routing architectural concepts, segments are
> at the same "level" and pointer moves on the segment list, then the
> MPLS instantiation is performing this using stacking ...

[HG] the "moving pointer" is a requirement without an actual use case - do =
you know how this would be used ? - i don't

[SLI] Interrest is to keep tracking where the packet is coming from. I'm no=
t saying that this is a good the solution or not ... working group should d=
ecide ... but enforcing "stacking" is the charter may close door to some ot=
her solutions.

> Finally, about the "routing" word, routing is essentially a "forward" act=
ion which may limit the scope of what we can do by using a segment list. Ac=
tions associated with a segment could be something else than forwarding.
> Do we want in the charter to limit the scope to routing actions ?
>

HG> as per the published use-case drafts all i have seen are use-cases
HG> related to
"forwarding". as far as i am concerned i am good limiting the scope to "rou=
ting actions".

[SLI] We had to start with something simple, that's why the current use cas=
es are related only to forwarding. But it's not a reason to limit the chart=
er to this ...

> - They form a connected network
>        [SLI] InterAS case must be included, but the WG can go step by ste=
p and first release intraAS, and then doing interAS (in relation with IDR ?=
?).

HG> did i preclude inter-AS in any way ?

[SLI] It was not clear to me what did you put behind "connected network"

> - They can forward traffic through the shortest paths or paths other than=
 the shortest (the latter called explicitly routed paths, or explicit paths)
>        [SLI] There is something else between SPT and Explicit path, you c=
an define other algorithms than SPT to define a path, and it's not explicit=
 path. Moreover I come back to my comment, on do we want to limit the scope=
 to routing ? I would say no.

HG> if you have a case for non-routing, please make it; - IIRC in our
HG> past 6 months of
 conversation around IGP label advertisement / SR we haven't discussed any =
non-routing use-case.

[SLI] Non routing use case are more future ...  routing is the basic infras=
tructure on top of which you can add some stuffs.

Stephane

-----Message d'origine-----
De : Hannes Gredler [mailto:[email-masked]]
Envoy=E9 : jeudi 5 septembre 2013 05:54
=C0 : LITKOWSKI Stephane DTF/DERX
Cc : [email-masked]
Objet : Re: [Status] Summary of STATUS BOF and the next steps

hi stephane,

see comments inline prefixed by HG>

On Sep 4, 2013, at 10:02 AM, <[email-masked]> <stephane.litk=
[email-masked]> wrote:
>  case, we are using only directed forwarding (adjacency segment),
> could we still talk about tunneling ? (it's a very very small tunnel)
> Moreover talking about "stacking" is really dataplane agnostic (MPLS)
> ...

HG> one-hop tunnels are ok;

> In the proposed segment routing architectural concepts, segments are
> at the same "level" and pointer moves on the segment list, then the
> MPLS instantiation is performing this using stacking ...

the "moving pointer" is a requirement without an actual use case - do you k=
now how this would be used ? - i don't

> IMHO, if we use "Stacked Tunnels", we already talk about a chosen
> solution and it's closing the door to something else  ...

HG> closing door to things we have no (known) requirements for is ok;
being anything to anybody is not helpful - the more concise the charter the=
 better;

> Finally, about the "routing" word, routing is essentially a "forward" act=
ion which may limit the scope of what we can do by using a segment list. Ac=
tions associated with a segment could be something else than forwarding.
> Do we want in the charter to limit the scope to routing actions ?
>

HG> as per the published use-case drafts all i have seen are use-cases
HG> related to
"forwarding". as far as i am concerned i am good limiting the scope to "rou=
ting actions".

> I have no solution today to propose for the naming, but I completely agre=
e with Loa, to first focus on working on the charter, and define a clear sc=
ope of the work and then the name will be easier to find.

HG> good :-)

> Regarding your charter proposal :
>
> --------
>
> - They form a connected network
>        [SLI] InterAS case must be included, but the WG can go step by ste=
p and first release intraAS, and then doing interAS (in relation with IDR ?=
?).

HG> did i preclude inter-AS in any way ?

> - They can forward traffic through the shortest paths or paths other than=
 the shortest (the latter called explicitly routed paths, or explicit paths)
>        [SLI] There is something else between SPT and Explicit path, you c=
an define other algorithms than SPT to define a path, and it's not explicit=
 path. Moreover I come back to my comment, on do we want to limit the scope=
 to routing ? I would say no.

HG> if you have a case for non-routing, please make it; - IIRC in our
HG> past 6 months of
 conversation around IGP label advertisement / SR we haven't discussed any =
non-routing use-case.

> - They share a common trust model. In this model, any router within the E=
RD can specify an explicit path between itself and any other router in the =
ERD. It can then send any packet that passes through it through any path th=
at it has specified.
>        [SLI] Security considerations may have to be addressed in the
> charter , especially for the interAS case (trust yes, but not sure
> access to everything may not be good)

HG> ok.

> Downstream routers within the ERD forward the packet as specified by the =
router at the head-end of the path.
> [SLI] Yes, but any router in the middle may be able to change the end to =
end explicit path.

HG> is there any application outside FRR for changing an explicit path ?

> - The first goal of the STER WG is to identify use-cases for ERDs.
> - Having identified use-cases, the WG will identify gaps between currentl=
y available technologies and use-case requirements.
> - The WG will then define requirements for extensions to existing protoco=
ls or new protocols that address gaps that are identified.
>
> [SLI] Agree, I would add :
> - defining the architecture framework
> - analysing the security considerations

HG> ok;

>
>
> Here would be my proposal to extend yours :
>
> A <named to be defined> domain contains a set of routers with the followi=
ng characteristics:
>
> - They form a connected network
> - They can forward traffic through any path within the network using
> shortest path, non shortest path or explicit path
> - They may provide other types of services than forwarding and they can e=
nforce service actions in the path.
> - They share a common trust model. In this model, any router within the d=
omain can specify a path between itself and any other router in the domain.=
 It may then send any packet that passes through it through any path that i=
t has specified and that is conform to the security rules. Downstream route=
rs within the ERD forward the packet as specified by the router at the head=
-end of the path.
>
> The <name> working group is chartered for the following ordered list of w=
ork items:
>
> - The first goal of the WG is to identify use-cases.
> - The WG will then define the architecture framework associated with the =
security considerations. The architecture framework and security considerat=
ions must address the relations between domains (interdomain).
> - Having identified use-cases, architecture and security, the WG will ide=
ntify gaps between currently available technologies and use-case requiremen=
ts.
> - The WG will then define requirements for extensions to existing protoco=
ls or new protocols that address gaps that are identified.
> - The WG will first focus on the intra-domain forwarding definition.
>
> Protocol work may be carried out in this working group or in other workin=
g groups responsible for the protocols, in coordination with this WG, and i=
n agreement with the WG chairs and responsible ADs. However, no protocol wo=
rk will be adopted by a working group to address the ERD use-cases until th=
e requirements document motivating the protocol work has been sent to the I=
ESG for publication as an RFC.
>
> -----Message d'origine-----
> De : [email-masked] [mailto:[email-masked]] De la
> part de Hannes Gredler Envoy=E9 : mardi 3 septembre 2013 18:31 =C0 : Loa
> Andersson Cc : [email-masked] Objet : Re: [Status] Summary of STATUS
> BOF and the next steps
>
> good point - what about this charter proposal ?
>
> ---
>
> Stacked Tunnels for Explicit Routing (STER)
> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
>
> A explicit routing domain (ERD) contains a set of routers with the follow=
ing characteristics:
>
> - They form a connected network
> - They can forward traffic through the shortest paths or paths other
> than the shortest (the latter called explicitly routed paths, or
> explicit paths)
> - They share a common trust model. In this model, any router within the E=
RD can specify an explicit path between itself and any other router in the =
ERD. It can then send any packet that passes through it through any path th=
at it has specified. Downstream routers within the ERD forward the packet a=
s specified by the router at the head-end of the path.
>
> The STER working group is chartered for the following ordered list of wor=
k items:
>
> - The first goal of the STER WG is to identify use-cases for ERDs.
> - Having identified use-cases, the WG will identify gaps between currentl=
y available technologies and use-case requirements.
> - The WG will then define requirements for extensions to existing protoco=
ls or new protocols that address gaps that are identified.
>
> Protocol work may be carried out in this working group or in other workin=
g groups responsible for the protocols, in coordination with this WG, and i=
n agreement with the WG chairs and responsible ADs. However, no protocol wo=
rk will be adopted by a working group to address the ERD use-cases until th=
e requirements document motivating the protocol work has been sent to the I=
ESG for publication as an RFC.
>
> ---
>
> <flame suit on>
>
> /hannes
>
>
> On Sep 3, 2013, at 5:31 PM, Loa Andersson wrote:
>
>> Folks,
>>
>> Excuse me if I'm slightly out of the loop, but so far I have not seen
>> a charter proposal, if there is one please point me to it.
>>
>> It seems a bit odd to put the cart (what the wg should do) before the
>> horse (wg name). If we drill down the the charter first the wg name
>> might be easier to figure out.
>>
>> /Loa
>>
>> PS
>> OK I understand that the horse and cart analogy limps a  bit :).
>>
>>
>>
>> On 2013-09-03 17:22, AshwoodsmithPeter wrote:
>>> " If the WG charter is limited to source routing, how will we handle th=
e "non source routing" use cases of segment routing ? In another working gr=
oup ? So we will go back to the WG synchronization issue that has been rais=
ed for this technology ..."
>>>
>>> That's why I suggested SRV2. We are revisiting source routing with new =
concepts. More generic number/action behavior.
>>>
>>> Peter
>>>
>>> -----Original Message-----
>>> From: [email-masked] [mailto:[email-masked]] On
>>> Behalf Of [email-masked]
>>> Sent: Tuesday, September 03, 2013 10:43 AM
>>> To: AshwoodsmithPeter
>>> Cc: [email-masked]
>>> Subject: Re: [Status] Summary of STATUS BOF and the next steps
>>>
>>>
>>> There was a misunderstanding in my small comment :) so I will explain m=
ore :
>>>
>>> In segment routing, you have more than basic source routing : segment r=
outing is just associate a segment number to an action and then combine seg=
ment as you want, yes you can do source routing, but you also can do more.
>>>
>>> In the other hand, I completely agree with your statement that
>>> source routing is generic and dataplane agnostic, as segment routing is=
 ...
>>> (segment routing is not a new dataplane ...)
>>>
>>> Now the definition of the WG naming must be inline with the charter
>>> that will be defined ... (draft today)
>>>
>>> Based on the already existing consensus (at least for MPLS dataplane) b=
rought up during Berlin STATUS BOF meeting, segment routing sounds to be a =
good target candidate.
>>>
>>> So now, do we want to do more in the WG charter than just make progress=
ing segment routing architecture and uses cases document and ensure coordin=
ation for the standardization of this technology ?
>>>
>>> Do we want to standardize other technologies in this WG ? I don't think=
 so, based on Stewart's conclusion email from the BOF :"A new WG focused so=
lely on SR therefore needs to be create"
>>>
>>> If the WG charter is limited to source routing, how will we handle the =
"non source routing" use cases of segment routing ? In another working grou=
p ? So we will go back to the WG synchronization issue that has been raised=
 for this technology ...
>>>
>>> If the WG is focused on SR, let's use a name in relation with SR.
>>>
>>> Feedback ?
>>>
>>>
>>> Stephane
>>>
>>>
>>> -----Message d'origine-----
>>> De : AshwoodsmithPeter [mailto:[email-masked]]
>>> Envoy=E9 : mardi 3 septembre 2013 15:27 =C0 : LITKOWSKI Stephane
>>> DTF/DERX Cc : John E Drake; Mark Townsley; Victor Kuarsingh; Roberta
>>> Maglione (robmgl); John G. Scudder; Adrian Farrel; Alvaro Retana
>>> (aretana); [email-masked]; Stewart Bryant (stbryant) Objet : Re:
>>> [Status] Summary of STATUS BOF and the next steps
>>>
>>> The term "source routing" has been around for a very long time and is d=
ata path agnostic. Its also the term used in the literature etc so my prefe=
rence is to stick with this existing well known and data path agnostic term.
>>>
>>> Peter
>>>
>>> On Sep 3, 2013, at 9:07 AM, "[email-masked]" <stephane.l=
[email-masked]> wrote:
>>>
>>>> Hi,
>>>>
>>>> "Source routing" is just a subcase of segment routing ... as it is for=
 IP routing ...
>>>>
>>>> Stephane
>>>>
>>>>
>>>> -----Message d'origine-----
>>>> De : [email-masked] [mailto:[email-masked]] De la
>>>> part de John E Drake Envoy=E9 : mardi 3 septembre 2013 15:02 =C0 : Mark
>>>> Townsley; Victor Kuarsingh Cc : Roberta Maglione (robmgl); John G.
>>>> Scudder; Alvaro Retana (aretana); Adrian Farrel; [email-masked];
>>>> Stewart Bryant (stbryant) Objet : Re: [Status] Summary of STATUS
>>>> BOF and the next steps
>>>>
>>>> Hi,
>>>>
>>>> What is this 'segment routing' silliness?  The correct term is 'source=
 routing'.
>>>>
>>>> Yours Irrespectively,
>>>>
>>>> John
>>>>
>>>>> -----Original Message-----
>>>>> From: [email-masked] [mailto:[email-masked]] On
>>>>> Behalf Of Mark Townsley
>>>>> Sent: Sunday, September 01, 2013 10:08 AM
>>>>> To: Victor Kuarsingh
>>>>> Cc: Roberta Maglione (robmgl); John G. Scudder; Adrian Farrel;
>>>>> Alvaro Retana (aretana); [email-masked]; Stewart Bryant
>>>>> (stbryant)
>>>>> Subject: Re: [Status] Summary of STATUS BOF and the next steps
>>>>>
>>>>>
>>>>> On Sep 1, 2013, at 5:38 PM, Victor Kuarsingh wrote:
>>>>>
>>>>>> All,
>>>>>>
>>>>>> I would also favour "Segment Routing WG" as well.
>>>>>>
>>>>>> I note this since attempting to come up with an all encompassing
>>>>>> acronym will be difficult and Segment Routing is generic enough
>>>>>> to associate to multiple functions.
>>>>>
>>>>> Then we can just use "segroute" for the short name. WGs do not
>>>>> have to have acronyms, but they do need to have an 8-char limited
>>>>> short name for the various automated tools not to break.
>>>>>
>>>>> - Mark
>>>>>
>>>>>>
>>>>>> Regards,
>>>>>>
>>>>>> Victor K
>>>>>>
>>>>>>
>>>>>>
>>>>>> On 2013-08-31 6:51 PM, "Roberta Maglione (robmgl)"
>>>>>> <[email-masked]>
>>>>>> wrote:
>>>>>>
>>>>>>> +1 for Segment Routing WG
>>>>>>>
>>>>>>> Roberta
>>>>>>>
>>>>>>> Sent from my iPad
>>>>>>>
>>>>>>> On 2013-08-30, at 2:55 PM, "Alvaro Retana (aretana)"
>>>>>>> <[email-masked]>
>>>>>>> wrote:
>>>>>>>
>>>>>>>> Segment Routing WG
>>>>>>>>
>>>>>>>> Sent from my iPhone
>>>>>>>>
>>>>>>>> On Aug 30, 2013, at 1:39 PM, "Stewart Bryant (stbryant)"
>>>>>>>> <[email-masked]> wrote:
>>>>>>>>
>>>>>>>>> The second task, which hopefully should be relatively easy, is
>>>>>>>>> to find a better working name for the WG, since it has been
>>>>>>>>> put to me a number of times that STATUS is going to be
>>>>>>>>> confusing in text and a difficult search term.
>>>>>>>> _______________________________________________
>>>>>>>> status mailing list
>>>>>>>> [email-masked]
>>>>>>>> https://www.ietf.org/mailman/listinfo/status
>>>>>>> _______________________________________________
>>>>>>> status mailing list
>>>>>>> [email-masked]
>>>>>>> https://www.ietf.org/mailman/listinfo/status
>>>>>>
>>>>>>
>>>>>> _______________________________________________
>>>>>> status mailing list
>>>>>> [email-masked]
>>>>>> https://www.ietf.org/mailman/listinfo/status
>>>>>
>>>>> _______________________________________________
>>>>> status mailing list
>>>>> [email-masked]
>>>>> https://www.ietf.org/mailman/listinfo/status
>>>>
>>>>
>>>> _______________________________________________
>>>> status mailing list
>>>> [email-masked]
>>>> https://www.ietf.org/mailman/listinfo/status
>>>>
>>>> ___________________________________________________________________
>>>> _ __ ___________________________________________________
>>>>
>>>> Ce message et ses pieces jointes peuvent contenir des informations
>>>> confidentielles ou privilegiees et ne doivent donc pas etre
>>>> diffuses, exploites ou copies sans autorisation. Si vous avez recu
>>>> ce message par erreur, veuillez le signaler a l'expediteur et le detru=
ire ainsi que les pieces jointes. Les messages electroniques etant suscepti=
bles d'alteration, Orange decline toute responsabilite si ce message a ete =
altere, deforme ou falsifie. Merci.
>>>>
>>>> This message and its attachments may contain confidential or
>>>> privileged information that may be protected by law; they should not b=
e distributed, used or copied without authorisation.
>>>> If you have received this email in error, please notify the sender and=
 delete this message and its attachments.
>>>> As emails may be altered, Orange is not liable for messages that have =
been modified, changed or falsified.
>>>> Thank you.
>>>>
>>>> _______________________________________________
>>>> status mailing list
>>>> [email-masked]
>>>> https://www.ietf.org/mailman/listinfo/status
>>>
>>> ____________________________________________________________________
>>> _ ____________________________________________________
>>>
>>> Ce message et ses pieces jointes peuvent contenir des informations
>>> confidentielles ou privilegiees et ne doivent donc pas etre
>>> diffuses, exploites ou copies sans autorisation. Si vous avez recu
>>> ce message par erreur, veuillez le signaler a l'expediteur et le detrui=
re ainsi que les pieces jointes. Les messages electroniques etant susceptib=
les d'alteration, Orange decline toute responsabilite si ce message a ete a=
ltere, deforme ou falsifie. Merci.
>>>
>>> This message and its attachments may contain confidential or
>>> privileged information that may be protected by law; they should not be=
 distributed, used or copied without authorisation.
>>> If you have received this email in error, please notify the sender and =
delete this message and its attachments.
>>> As emails may be altered, Orange is not liable for messages that have b=
een modified, changed or falsified.
>>> Thank you.
>>>
>>> _______________________________________________
>>> status mailing list
>>> [email-masked]
>>> https://www.ietf.org/mailman/listinfo/status
>>> _______________________________________________
>>> status mailing list
>>> [email-masked]
>>> https://www.ietf.org/mailman/listinfo/status
>>>
>>
>> --
>>
>>
>> Loa Andersson                        email: [email-masked]
>> Senior MPLS Expert                          [email-masked]
>> Huawei Technologies (consultant)     phone: +46 739 81 21 64
>> _______________________________________________
>> status mailing list
>> [email-masked]
>> https://www.ietf.org/mailman/listinfo/status
>>
>>
>
>
> _______________________________________________
> status mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/status
>
> ______________________________________________________________________
> ___________________________________________________
>
> Ce message et ses pieces jointes peuvent contenir des informations
> confidentielles ou privilegiees et ne doivent donc pas etre diffuses,
> exploites ou copies sans autorisation. Si vous avez recu ce message
> par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que =
les pieces jointes. Les messages electroniques etant susceptibles d'alterat=
ion, Orange decline toute responsabilite si ce message a ete altere, deform=
e ou falsifie. Merci.
>
> This message and its attachments may contain confidential or
> privileged information that may be protected by law; they should not be d=
istributed, used or copied without authorisation.
> If you have received this email in error, please notify the sender and de=
lete this message and its attachments.
> As emails may be altered, Orange is not liable for messages that have bee=
n modified, changed or falsified.
> Thank you.
>
>
>

___________________________________________________________________________=
______________________________________________

Ce message et ses pieces jointes peuvent contenir des informations confiden=
tielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu=
 ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages el=
ectroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou =
falsifie. Merci.

This message and its attachments may contain confidential or privileged inf=
ormation that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and dele=
te this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been =
modified, changed or falsified.
Thank you.

Date: Thu, 5 Sep 2013 07:52:37 +0300
From: Saku Ytti <[email-masked]>
To: [email-masked]
Subject: Re: [Status] Summary of STATUS BOF and the next steps

On (2013-09-04 21:38 +0000), George Swallow (swallow) wrote:

> I actually don't think it is possible to write a dataplane agnostic architecture.   We can write an architecture document that is 90% dataplane independent and then has some dataplane dependencies.  E.g. having the full SR path available at each hop vs the remainder.

Architecture can provide command 'next segment', without explicitly
mandating previous segments to be deleted or kept.

Compatible implementation/wire-format then has some freedom in its
implementation.

-- 
  ++ytti

From: Jeff Tantsura <[email-masked]>
To: Hannes Gredler <[email-masked]>
Date: Thu, 5 Sep 2013 04:26:09 +0000
Accept-Language: en-US
Cc: Anoop Ghanwani <[email-masked]>, Mark Townsley <[email-masked]>, "[email-masked]" <[email-masked]>
Subject: Re: [Status] Summary of STATUS BOF and the next steps

Agree with Hannes, BGP is a valid protocol to work on?

Regards,
Jeff

On Sep 4, 2013, at 21:06, "Hannes Gredler" <[email-masked]> wrote:

>=20
> On Sep 4, 2013, at 4:18 PM, Mark Townsley wrote:
>=20
>>=20
>> On Sep 4, 2013, at 3:26 PM, Anoop Ghanwani wrote:
>>=20
>>> Some folks use BGP to perform the function of an IGP.  It looks like th=
e proposed charter would exclude them from taking advantage of this technol=
ogy.  It might be worthwhile adding BGP to that list of protocols to be enh=
anced for this.
>>=20
>> I agree that the statement "Develop ISIS and OSPF protocol extensions ne=
cessary for distribution of MPLS forwarding information." needs work, for t=
wo reasons. First, the extensions may not be strictly MPLS if the goal is t=
o make this work for MPLS and IPv6. Second, I think it would be better for =
the ISIS and OSPF WGs to advance their own protocol extensions, rather than=
 including that within the charter of SR as a deliverable. BGP, or any othe=
r routing protocol, could then adopt SR based on its own level of interest =
in that WG to do so. Would that suffice?
>=20
> actually not. the whole point of forming a new WG is that
> folks do not sneak-in "*-routing" ideas in the respective
> protocol groups where people may not be paying attention.
>=20
> back to the original argument: since what we are extending
> are link-state protocols and there is an incarnation of BGP
> to carry link-state graphs its perfectly legitimate to
> add BGP to the list of to be worked on protocols.
>=20
>>> With respect to the text about working with existing data paths -- I wo=
nder if there is some way to capture that it might not work with all existi=
ng implementations.  For example, the number of labels required to be pushe=
d at the ingress device may prevent some existing implementations from taki=
ng advantage of this technology, depending on the size of the topology.
>>>=20
>>> Anoop
>>>=20
>>>=20
>>> On Wed, Sep 4, 2013 at 3:24 AM, Stewart Bryant <[email-masked]> wro=
te:
>>>=20
>>> May I suggest that we use the name "SR" and worry
>>> about what it binds to later.
>>>=20
>>> The higher priority item is the charter text. Does
>>> anyone have any comments on the text proposed
>>> so far, or the text in the BOF proposal:
>>>=20
>>>=20
>>> The Stacked Tunnels for Source Routing (STATUS) Working Group=20
>>> is chartered to develop a framework and use cases for source-routed=20
>>> flows in packet switched networks.
>>>=20
>>> IP previously had a source-based routing mechanism made=20
>>> available through an IP Option. This mechanism has, however,=20
>>> not been widely used and has a number of issues that make its=20
>>> use inadvisable, and other mechanisms (such as RFC 1940)=20
>>> do not appear to have been implemented at all.
>>>=20
>>> The ability of a router to influence or control the forwarding=20
>>> path of an individual packet or all the packets of a given=20
>>> Forwarding Equivalence Class (FEC) is a desirable feature=20
>>> for a number of reasons including Label Switched Path stitching,=20
>>> egress protection, explicit routing, egress ASBR link selection,=20
>>> and backup (bypass tunnels, Remote Loop-Free Alternates)=20
>>> routing. This can be achieved by facilitating source-initiated=20
>>> selection of routes to complement the route selection=20
>>> provided by existing routing protocols for both inter- domain=20
>>> and intra-domain routes.
>>>=20
>>> Historically, distribution of MPLS label binding information=20
>>> was done by relying on label distribution protocols=20
>>> such as LDP and RSVP-TE.
>>>=20
>>> The use cases documented by the working group will=20
>>> indicate the network function that is being facilitated=20
>>> and indicate which packet data plane is to be used.
>>>=20
>>> The framework developed by the working group will=20
>>> consider forwarding of IPv4, IPv6, and MPLS using the=20
>>> existing unicast data planes. Multicast forwarding will=20
>>> be for future study and the choice of data planes will=20
>>> be limited to those for which use cases exist. A key=20
>>> objective of the work will be to ensure that source-
>>> routed packets can be handled seamlessly by existing=20
>>> deployed equipment. A major objective will be that the=20
>>> new function does not modify existing data plane behavior=20
>>> or architectures, and that it can be enabled through only=20
>>> control and management plane software upgrades at=20
>>> deployed devices.
>>>=20
>>> Once the working group has established a framework=20
>>> and there is demonstrable consensus for use cases,=20
>>> the working group will move forward to specify protocol=20
>>> solutions for installing forwarding information through=20
>>> the use of the IGPs (OSPF and IS-IS), or through the=20
>>> management plane. In the course of developing protocol=20
>>> extensions, the working group will work closely with=20
>>> other IETF working groups responsible for the protocols=20
>>> being modified (such as OSPF, ISIS, and I2RS).
>>>=20
>>>    The working group is chartered for the following work items:
>>>=20
>>>    A framework for the use of the existing MPLS data plane to=20
>>>    support tunnel-based unicast source routing.=20
>>>=20
>>>    Develop use cases for tunnel-based unicast source routing=20
>>>    that demonstrate the need and support for solutions. Care=20
>>>    should be taken to avoid clustering use cases that might seem
>>>    to imply support for multiple use cases when only some of the=20
>>>    cluster actually have wide-scale support.=20
>>>=20
>>>    Develop ISIS and OSPF protocol extensions necessary for=20
>>>   distribution of MPLS forwarding information.=20
>>>=20
>>>    The working group will consider management (including =20
>>>    configuration, reporting, diagnostics, and OAM) and security=20
>>>    implications of its work and document them in separate=20
>>>    documents as appropriate.=20
>>>=20
>>>    The working group is not chartered to make any changes to=20
>>>    the MPLS or IPv6 data planes. Any proposed changes to the=20
>>>    data planes are to be specified in the working groups responsible=20
>>>    for the data planes (that is, the MPLS and 6MAN working groups, =20
>>>    respectively).
>>>=20
>>> - Stewart
>>>=20
>>>=20
>>> _______________________________________________
>>> status mailing list
>>> [email-masked]
>>> https://www.ietf.org/mailman/listinfo/status
>>>=20
>>>=20
>>>=20
>>> _______________________________________________
>>> status mailing list
>>> [email-masked]
>>> https://www.ietf.org/mailman/listinfo/status
>>=20
>> _______________________________________________
>> status mailing list
>> [email-masked]
>> https://www.ietf.org/mailman/listinfo/status
>=20
>=20
> _______________________________________________
> status mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/status

From: Hannes Gredler <[email-masked]>
Date: Thu, 5 Sep 2013 06:05:49 +0200
To: Mark Townsley <[email-masked]>
Cc: Anoop Ghanwani <[email-masked]>, [email-masked]
Subject: Re: [Status] Summary of STATUS BOF and the next steps

On Sep 4, 2013, at 4:18 PM, Mark Townsley wrote:

>=20
> On Sep 4, 2013, at 3:26 PM, Anoop Ghanwani wrote:
>=20
>> Some folks use BGP to perform the function of an IGP.  It looks like =
the proposed charter would exclude them from taking advantage of this =
technology.  It might be worthwhile adding BGP to that list of protocols =
to be enhanced for this.
>=20
> I agree that the statement "Develop ISIS and OSPF protocol extensions =
necessary for distribution of MPLS forwarding information." needs work, =
for two reasons. First, the extensions may not be strictly MPLS if the =
goal is to make this work for MPLS and IPv6. Second, I think it would be =
better for the ISIS and OSPF WGs to advance their own protocol =
extensions, rather than including that within the charter of SR as a =
deliverable. BGP, or any other routing protocol, could then adopt SR =
based on its own level of interest in that WG to do so. Would that =
suffice?

actually not. the whole point of forming a new WG is that
folks do not sneak-in "*-routing" ideas in the respective
protocol groups where people may not be paying attention.

back to the original argument: since what we are extending
are link-state protocols and there is an incarnation of BGP
to carry link-state graphs its perfectly legitimate to
add BGP to the list of to be worked on protocols.

>> With respect to the text about working with existing data paths -- I =
wonder if there is some way to capture that it might not work with all =
existing implementations.  For example, the number of labels required to =
be pushed at the ingress device may prevent some existing =
implementations from taking advantage of this technology, depending on =
the size of the topology.
>>=20
>> Anoop
>>=20
>>=20
>> On Wed, Sep 4, 2013 at 3:24 AM, Stewart Bryant <[email-masked]> =
wrote:
>>=20
>> May I suggest that we use the name "SR" and worry
>> about what it binds to later.
>>=20
>> The higher priority item is the charter text. Does
>> anyone have any comments on the text proposed
>> so far, or the text in the BOF proposal:
>>=20
>>=20
>> The Stacked Tunnels for Source Routing (STATUS) Working Group=20
>> is chartered to develop a framework and use cases for source-routed=20=

>> flows in packet switched networks.
>>=20
>> IP previously had a source-based routing mechanism made=20
>> available through an IP Option. This mechanism has, however,=20
>> not been widely used and has a number of issues that make its=20
>> use inadvisable, and other mechanisms (such as RFC 1940)=20
>> do not appear to have been implemented at all.
>>=20
>> The ability of a router to influence or control the forwarding=20
>> path of an individual packet or all the packets of a given=20
>> Forwarding Equivalence Class (FEC) is a desirable feature=20
>> for a number of reasons including Label Switched Path stitching,=20
>> egress protection, explicit routing, egress ASBR link selection,=20
>> and backup (bypass tunnels, Remote Loop-Free Alternates)=20
>> routing. This can be achieved by facilitating source-initiated=20
>> selection of routes to complement the route selection=20
>> provided by existing routing protocols for both inter- domain=20
>> and intra-domain routes.
>>=20
>> Historically, distribution of MPLS label binding information=20
>> was done by relying on label distribution protocols=20
>> such as LDP and RSVP-TE.
>>=20
>> The use cases documented by the working group will=20
>> indicate the network function that is being facilitated=20
>> and indicate which packet data plane is to be used.
>>=20
>> The framework developed by the working group will=20
>> consider forwarding of IPv4, IPv6, and MPLS using the=20
>> existing unicast data planes. Multicast forwarding will=20
>> be for future study and the choice of data planes will=20
>> be limited to those for which use cases exist. A key=20
>> objective of the work will be to ensure that source-
>> routed packets can be handled seamlessly by existing=20
>> deployed equipment. A major objective will be that the=20
>> new function does not modify existing data plane behavior=20
>> or architectures, and that it can be enabled through only=20
>> control and management plane software upgrades at=20
>> deployed devices.
>>=20
>> Once the working group has established a framework=20
>> and there is demonstrable consensus for use cases,=20
>> the working group will move forward to specify protocol=20
>> solutions for installing forwarding information through=20
>> the use of the IGPs (OSPF and IS-IS), or through the=20
>> management plane. In the course of developing protocol=20
>> extensions, the working group will work closely with=20
>> other IETF working groups responsible for the protocols=20
>> being modified (such as OSPF, ISIS, and I2RS).
>>=20
>>     The working group is chartered for the following work items:
>>=20
>>     A framework for the use of the existing MPLS data plane to=20
>>     support tunnel-based unicast source routing.=20
>>=20
>>     Develop use cases for tunnel-based unicast source routing=20
>>     that demonstrate the need and support for solutions. Care=20
>>     should be taken to avoid clustering use cases that might seem
>>     to imply support for multiple use cases when only some of the=20
>>     cluster actually have wide-scale support.=20
>>=20
>>     Develop ISIS and OSPF protocol extensions necessary for=20
>>    distribution of MPLS forwarding information.=20
>>=20
>>     The working group will consider management (including =20
>>     configuration, reporting, diagnostics, and OAM) and security=20
>>     implications of its work and document them in separate=20
>>     documents as appropriate.=20
>>=20
>>     The working group is not chartered to make any changes to=20
>>     the MPLS or IPv6 data planes. Any proposed changes to the=20
>>     data planes are to be specified in the working groups responsible=20=

>>     for the data planes (that is, the MPLS and 6MAN working groups, =20=

>>     respectively).
>>=20
>> - Stewart
>>=20
>>=20
>> _______________________________________________
>> status mailing list
>> [email-masked]
>> https://www.ietf.org/mailman/listinfo/status
>>=20
>>=20
>>=20
>> _______________________________________________
>> status mailing list
>> [email-masked]
>> https://www.ietf.org/mailman/listinfo/status
>=20
> _______________________________________________
> status mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/status

From: Hannes Gredler <[email-masked]>
Date: Thu, 5 Sep 2013 05:54:26 +0200
To: <[email-masked]>
Cc: "[email-masked]" <[email-masked]>
Subject: Re: [Status] Summary of STATUS BOF and the next steps

hi stephane,

see comments inline prefixed by HG>

On Sep 4, 2013, at 10:02 AM, <[email-masked]> =
<[email-masked]> wrote:
>  case, we are using only directed forwarding (adjacency segment), =
could we still talk about tunneling ? (it's a very very small tunnel)
> Moreover talking about "stacking" is really dataplane agnostic (MPLS) =
=85

HG> one-hop tunnels are ok;

> In the proposed segment routing architectural concepts, segments are =
at the same "level" and pointer moves on the segment list, then the MPLS =
instantiation is performing this using stacking =85

the "moving pointer" is a requirement without an actual use case -
do you know how this would be used ? - i don't

> IMHO, if we use "Stacked Tunnels", we already talk about a chosen =
solution and it's closing the door to something else  =85

HG> closing door to things we have no (known) requirements for is ok;
being anything to anybody is not helpful - the more concise the charter
the better;

> Finally, about the "routing" word, routing is essentially a "forward" =
action which may limit the scope of what we can do by using a segment =
list. Actions associated with a segment could be something else than =
forwarding.
> Do we want in the charter to limit the scope to routing actions ?
>=20

HG> as per the published use-case drafts all i have seen are use-cases =
related to
"forwarding". as far as i am concerned i am good limiting the scope to
"routing actions".

> I have no solution today to propose for the naming, but I completely =
agree with Loa, to first focus on working on the charter, and define a =
clear scope of the work and then the name will be easier to find.

HG> good :-)

> Regarding your charter proposal :
>=20
> --------
>=20
> - They form a connected network
>        [SLI] InterAS case must be included, but the WG can go step by =
step and first release intraAS, and then doing interAS (in relation with =
IDR ??).

HG> did i preclude inter-AS in any way ?

> - They can forward traffic through the shortest paths or paths other =
than the shortest (the latter called explicitly routed paths, or =
explicit paths)
>        [SLI] There is something else between SPT and Explicit path, =
you can define other algorithms than SPT to define a path, and it's not =
explicit path. Moreover I come back to my comment, on do we want to =
limit the scope to routing ? I would say no.

HG> if you have a case for non-routing, please make it; - IIRC in our =
past 6 months of
 conversation around IGP label advertisement / SR we haven't discussed =
any non-routing use-case.

> - They share a common trust model. In this model, any router within =
the ERD can specify an explicit path between itself and any other router =
in the ERD. It can then send any packet that passes through it through =
any path that it has specified.
>        [SLI] Security considerations may have to be addressed in the =
charter , especially for the interAS case (trust yes, but not sure =
access to everything may not be good)

HG> ok.

> Downstream routers within the ERD forward the packet as specified by =
the router at the head-end of the path.
> [SLI] Yes, but any router in the middle may be able to change the end =
to end explicit path.

HG> is there any application outside FRR for changing an explicit path ?

> - The first goal of the STER WG is to identify use-cases for ERDs.
> - Having identified use-cases, the WG will identify gaps between =
currently available technologies and use-case requirements.
> - The WG will then define requirements for extensions to existing =
protocols or new protocols that address gaps that are identified.
>=20
> [SLI] Agree, I would add :
> - defining the architecture framework
> - analysing the security considerations

HG> ok;

>=20
>=20
> Here would be my proposal to extend yours :
>=20
> A <named to be defined> domain contains a set of routers with the =
following characteristics:
>=20
> - They form a connected network
> - They can forward traffic through any path within the network using =
shortest path, non shortest path or explicit path
> - They may provide other types of services than forwarding and they =
can enforce service actions in the path.
> - They share a common trust model. In this model, any router within =
the domain can specify a path between itself and any other router in the =
domain. It may then send any packet that passes through it through any =
path that it has specified and that is conform to the security rules. =
Downstream routers within the ERD forward the packet as specified by the =
router at the head-end of the path.
>=20
> The <name> working group is chartered for the following ordered list =
of work items:
>=20
> - The first goal of the WG is to identify use-cases.
> - The WG will then define the architecture framework associated with =
the security considerations. The architecture framework and security =
considerations must address the relations between domains (interdomain).
> - Having identified use-cases, architecture and security, the WG will =
identify gaps between currently available technologies and use-case =
requirements.
> - The WG will then define requirements for extensions to existing =
protocols or new protocols that address gaps that are identified.
> - The WG will first focus on the intra-domain forwarding definition.
>=20
> Protocol work may be carried out in this working group or in other =
working groups responsible for the protocols, in coordination with this =
WG, and in agreement with the WG chairs and responsible ADs. However, no =
protocol work will be adopted by a working group to address the ERD =
use-cases until the requirements document motivating the protocol work =
has been sent to the IESG for publication as an RFC.
>=20
> -----Message d'origine-----
> De : [email-masked] [mailto:[email-masked]] De la =
part de Hannes Gredler
> Envoy=E9 : mardi 3 septembre 2013 18:31
> =C0 : Loa Andersson
> Cc : [email-masked]
> Objet : Re: [Status] Summary of STATUS BOF and the next steps
>=20
> good point - what about this charter proposal ?
>=20
> ---
>=20
> Stacked Tunnels for Explicit Routing (STER) =
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
>=20
> A explicit routing domain (ERD) contains a set of routers with the =
following characteristics:
>=20
> - They form a connected network
> - They can forward traffic through the shortest paths or paths other =
than the shortest (the latter called explicitly routed paths, or =
explicit paths)
> - They share a common trust model. In this model, any router within =
the ERD can specify an explicit path between itself and any other router =
in the ERD. It can then send any packet that passes through it through =
any path that it has specified. Downstream routers within the ERD =
forward the packet as specified by the router at the head-end of the =
path.
>=20
> The STER working group is chartered for the following ordered list of =
work items:
>=20
> - The first goal of the STER WG is to identify use-cases for ERDs.
> - Having identified use-cases, the WG will identify gaps between =
currently available technologies and use-case requirements.
> - The WG will then define requirements for extensions to existing =
protocols or new protocols that address gaps that are identified.
>=20
> Protocol work may be carried out in this working group or in other =
working groups responsible for the protocols, in coordination with this =
WG, and in agreement with the WG chairs and responsible ADs. However, no =
protocol work will be adopted by a working group to address the ERD =
use-cases until the requirements document motivating the protocol work =
has been sent to the IESG for publication as an RFC.
>=20
> ---
>=20
> <flame suit on>
>=20
> /hannes
>=20
>=20
> On Sep 3, 2013, at 5:31 PM, Loa Andersson wrote:
>=20
>> Folks,
>>=20
>> Excuse me if I'm slightly out of the loop, but so far I have not seen
>> a charter proposal, if there is one please point me to it.
>>=20
>> It seems a bit odd to put the cart (what the wg should do) before the
>> horse (wg name). If we drill down the the charter first the wg name
>> might be easier to figure out.
>>=20
>> /Loa
>>=20
>> PS
>> OK I understand that the horse and cart analogy limps a  bit :).
>>=20
>>=20
>>=20
>> On 2013-09-03 17:22, AshwoodsmithPeter wrote:
>>> " If the WG charter is limited to source routing, how will we handle =
the "non source routing" use cases of segment routing ? In another =
working group ? So we will go back to the WG synchronization issue that =
has been raised for this technology ..."
>>>=20
>>> That's why I suggested SRV2. We are revisiting source routing with =
new concepts. More generic number/action behavior.
>>>=20
>>> Peter
>>>=20
>>> -----Original Message-----
>>> From: [email-masked] [mailto:[email-masked]] On
>>> Behalf Of [email-masked]
>>> Sent: Tuesday, September 03, 2013 10:43 AM
>>> To: AshwoodsmithPeter
>>> Cc: [email-masked]
>>> Subject: Re: [Status] Summary of STATUS BOF and the next steps
>>>=20
>>>=20
>>> There was a misunderstanding in my small comment :) so I will =
explain more :
>>>=20
>>> In segment routing, you have more than basic source routing : =
segment routing is just associate a segment number to an action and then =
combine segment as you want, yes you can do source routing, but you also =
can do more.
>>>=20
>>> In the other hand, I completely agree with your statement that =
source
>>> routing is generic and dataplane agnostic, as segment routing is ...
>>> (segment routing is not a new dataplane ...)
>>>=20
>>> Now the definition of the WG naming must be inline with the charter
>>> that will be defined ... (draft today)
>>>=20
>>> Based on the already existing consensus (at least for MPLS =
dataplane) brought up during Berlin STATUS BOF meeting, segment routing =
sounds to be a good target candidate.
>>>=20
>>> So now, do we want to do more in the WG charter than just make =
progressing segment routing architecture and uses cases document and =
ensure coordination for the standardization of this technology ?
>>>=20
>>> Do we want to standardize other technologies in this WG ? I don't =
think so, based on Stewart's conclusion email from the BOF :"A new WG =
focused solely on SR therefore needs to be create"
>>>=20
>>> If the WG charter is limited to source routing, how will we handle =
the "non source routing" use cases of segment routing ? In another =
working group ? So we will go back to the WG synchronization issue that =
has been raised for this technology ...
>>>=20
>>> If the WG is focused on SR, let's use a name in relation with SR.
>>>=20
>>> Feedback ?
>>>=20
>>>=20
>>> Stephane
>>>=20
>>>=20
>>> -----Message d'origine-----
>>> De : AshwoodsmithPeter [mailto:[email-masked]]
>>> Envoy=E9 : mardi 3 septembre 2013 15:27 =C0 : LITKOWSKI Stephane =
DTF/DERX
>>> Cc : John E Drake; Mark Townsley; Victor Kuarsingh; Roberta Maglione
>>> (robmgl); John G. Scudder; Adrian Farrel; Alvaro Retana (aretana);
>>> [email-masked]; Stewart Bryant (stbryant) Objet : Re: [Status]
>>> Summary of STATUS BOF and the next steps
>>>=20
>>> The term "source routing" has been around for a very long time and =
is data path agnostic. Its also the term used in the literature etc so =
my preference is to stick with this existing well known and data path =
agnostic term.
>>>=20
>>> Peter
>>>=20
>>> On Sep 3, 2013, at 9:07 AM, "[email-masked]" =
<[email-masked]> wrote:
>>>=20
>>>> Hi,
>>>>=20
>>>> "Source routing" is just a subcase of segment routing ... as it is =
for IP routing ...
>>>>=20
>>>> Stephane
>>>>=20
>>>>=20
>>>> -----Message d'origine-----
>>>> De : [email-masked] [mailto:[email-masked]] De la
>>>> part de John E Drake Envoy=E9 : mardi 3 septembre 2013 15:02 =C0 : =
Mark
>>>> Townsley; Victor Kuarsingh Cc : Roberta Maglione (robmgl); John G.
>>>> Scudder; Alvaro Retana (aretana); Adrian Farrel; [email-masked];
>>>> Stewart Bryant (stbryant) Objet : Re: [Status] Summary of STATUS =
BOF
>>>> and the next steps
>>>>=20
>>>> Hi,
>>>>=20
>>>> What is this 'segment routing' silliness?  The correct term is =
'source routing'.
>>>>=20
>>>> Yours Irrespectively,
>>>>=20
>>>> John
>>>>=20
>>>>> -----Original Message-----
>>>>> From: [email-masked] [mailto:[email-masked]] On
>>>>> Behalf Of Mark Townsley
>>>>> Sent: Sunday, September 01, 2013 10:08 AM
>>>>> To: Victor Kuarsingh
>>>>> Cc: Roberta Maglione (robmgl); John G. Scudder; Adrian Farrel;
>>>>> Alvaro Retana (aretana); [email-masked]; Stewart Bryant =
(stbryant)
>>>>> Subject: Re: [Status] Summary of STATUS BOF and the next steps
>>>>>=20
>>>>>=20
>>>>> On Sep 1, 2013, at 5:38 PM, Victor Kuarsingh wrote:
>>>>>=20
>>>>>> All,
>>>>>>=20
>>>>>> I would also favour "Segment Routing WG" as well.
>>>>>>=20
>>>>>> I note this since attempting to come up with an all encompassing
>>>>>> acronym will be difficult and Segment Routing is generic enough =
to
>>>>>> associate to multiple functions.
>>>>>=20
>>>>> Then we can just use "segroute" for the short name. WGs do not =
have
>>>>> to have acronyms, but they do need to have an 8-char limited short
>>>>> name for the various automated tools not to break.
>>>>>=20
>>>>> - Mark
>>>>>=20
>>>>>>=20
>>>>>> Regards,
>>>>>>=20
>>>>>> Victor K
>>>>>>=20
>>>>>>=20
>>>>>>=20
>>>>>> On 2013-08-31 6:51 PM, "Roberta Maglione (robmgl)"
>>>>>> <[email-masked]>
>>>>>> wrote:
>>>>>>=20
>>>>>>> +1 for Segment Routing WG
>>>>>>>=20
>>>>>>> Roberta
>>>>>>>=20
>>>>>>> Sent from my iPad
>>>>>>>=20
>>>>>>> On 2013-08-30, at 2:55 PM, "Alvaro Retana (aretana)"
>>>>>>> <[email-masked]>
>>>>>>> wrote:
>>>>>>>=20
>>>>>>>> Segment Routing WG
>>>>>>>>=20
>>>>>>>> Sent from my iPhone
>>>>>>>>=20
>>>>>>>> On Aug 30, 2013, at 1:39 PM, "Stewart Bryant (stbryant)"
>>>>>>>> <[email-masked]> wrote:
>>>>>>>>=20
>>>>>>>>> The second task, which hopefully should be relatively easy, is
>>>>>>>>> to find a better working name for the WG, since it has been =
put
>>>>>>>>> to me a number of times that STATUS is going to be confusing =
in
>>>>>>>>> text and a difficult search term.
>>>>>>>> _______________________________________________
>>>>>>>> status mailing list
>>>>>>>> [email-masked]
>>>>>>>> https://www.ietf.org/mailman/listinfo/status
>>>>>>> _______________________________________________
>>>>>>> status mailing list
>>>>>>> [email-masked]
>>>>>>> https://www.ietf.org/mailman/listinfo/status
>>>>>>=20
>>>>>>=20
>>>>>> _______________________________________________
>>>>>> status mailing list
>>>>>> [email-masked]
>>>>>> https://www.ietf.org/mailman/listinfo/status
>>>>>=20
>>>>> _______________________________________________
>>>>> status mailing list
>>>>> [email-masked]
>>>>> https://www.ietf.org/mailman/listinfo/status
>>>>=20
>>>>=20
>>>> _______________________________________________
>>>> status mailing list
>>>> [email-masked]
>>>> https://www.ietf.org/mailman/listinfo/status
>>>>=20
>>>> =
____________________________________________________________________
>>>> __ ___________________________________________________
>>>>=20
>>>> Ce message et ses pieces jointes peuvent contenir des informations
>>>> confidentielles ou privilegiees et ne doivent donc pas etre
>>>> diffuses, exploites ou copies sans autorisation. Si vous avez recu
>>>> ce message par erreur, veuillez le signaler a l'expediteur et le =
detruire ainsi que les pieces jointes. Les messages electroniques etant =
susceptibles d'alteration, Orange decline toute responsabilite si ce =
message a ete altere, deforme ou falsifie. Merci.
>>>>=20
>>>> This message and its attachments may contain confidential or
>>>> privileged information that may be protected by law; they should =
not be distributed, used or copied without authorisation.
>>>> If you have received this email in error, please notify the sender =
and delete this message and its attachments.
>>>> As emails may be altered, Orange is not liable for messages that =
have been modified, changed or falsified.
>>>> Thank you.
>>>>=20
>>>> _______________________________________________
>>>> status mailing list
>>>> [email-masked]
>>>> https://www.ietf.org/mailman/listinfo/status
>>>=20
>>> =
_____________________________________________________________________
>>> ____________________________________________________
>>>=20
>>> Ce message et ses pieces jointes peuvent contenir des informations
>>> confidentielles ou privilegiees et ne doivent donc pas etre =
diffuses,
>>> exploites ou copies sans autorisation. Si vous avez recu ce message
>>> par erreur, veuillez le signaler a l'expediteur et le detruire ainsi =
que les pieces jointes. Les messages electroniques etant susceptibles =
d'alteration, Orange decline toute responsabilite si ce message a ete =
altere, deforme ou falsifie. Merci.
>>>=20
>>> This message and its attachments may contain confidential or
>>> privileged information that may be protected by law; they should not =
be distributed, used or copied without authorisation.
>>> If you have received this email in error, please notify the sender =
and delete this message and its attachments.
>>> As emails may be altered, Orange is not liable for messages that =
have been modified, changed or falsified.
>>> Thank you.
>>>=20
>>> _______________________________________________
>>> status mailing list
>>> [email-masked]
>>> https://www.ietf.org/mailman/listinfo/status
>>> _______________________________________________
>>> status mailing list
>>> [email-masked]
>>> https://www.ietf.org/mailman/listinfo/status
>>>=20
>>=20
>> --
>>=20
>>=20
>> Loa Andersson                        email: [email-masked]
>> Senior MPLS Expert                          [email-masked]
>> Huawei Technologies (consultant)     phone: +46 739 81 21 64
>> _______________________________________________
>> status mailing list
>> [email-masked]
>> https://www.ietf.org/mailman/listinfo/status
>>=20
>>=20
>=20
>=20
> _______________________________________________
> status mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/status
>=20
> =
__________________________________________________________________________=
_______________________________________________
>=20
> Ce message et ses pieces jointes peuvent contenir des informations =
confidentielles ou privilegiees et ne doivent donc
> pas etre diffuses, exploites ou copies sans autorisation. Si vous avez =
recu ce message par erreur, veuillez le signaler
> a l'expediteur et le detruire ainsi que les pieces jointes. Les =
messages electroniques etant susceptibles d'alteration,
> Orange decline toute responsabilite si ce message a ete altere, =
deforme ou falsifie. Merci.
>=20
> This message and its attachments may contain confidential or =
privileged information that may be protected by law;
> they should not be distributed, used or copied without authorisation.
> If you have received this email in error, please notify the sender and =
delete this message and its attachments.
> As emails may be altered, Orange is not liable for messages that have =
been modified, changed or falsified.
> Thank you.
>=20
>=20
>=20

From: "George Swallow (swallow)" <[email-masked]>
To: AshwoodsmithPeter <[email-masked]>, Rob Shakir <[email-masked]>, "[email-masked]" <[email-masked]>
Date: Wed, 4 Sep 2013 21:38:51 +0000
Accept-Language: en-US
Cc: "George Swallow \(swallow\)" <[email-masked]>
Subject: Re: [Status] Summary of STATUS BOF and the next steps

--_000_2FE467D3673DCE409A84D67EC2F607BB140E703Fxmbrcdx10ciscoc_
Content-Type: text/plain; charset="Windows-1252"
Content-Transfer-Encoding: quoted-printable

I actually don't think it is possible to write a dataplane agnostic archite=
cture.   We can write an architecture document that is 90% dataplane indepe=
ndent and then has some dataplane dependencies.  E.g. having the full SR pa=
th available at each hop vs the remainder.

George

From: AshwoodsmithPeter <[email-masked]<mailto:Peter.Ashwood=
[email-masked]>>
Date: Wednesday, September 4, 2013 3:05 PM
To: Rob Shakir <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:sta=
[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: Re: [Status] Summary of STATUS BOF and the next steps

strongly concur.

Peter

On Sep 4, 2013, at 2:57 PM, "Rob Shakir" <[email-masked]<mailto:[email-masked]>> wr=
ote:

Right. Day 1 we need this to work with things that are deployable in real a=
nd existing networks, but I think this should not stop us defining the char=
ter to write a data plane agnostic architecture, which can then have docume=
nts describing how it is implemented in each data plane we want to use.

This way we can define the features that we need - or at least desirable - =
and then work out how they are realised (some existing data planes may not =
be able to support all desirable features - an example is retaining the ful=
l path at all hops). It also reduces duplication across the data plane inst=
ance specs.

>From my perspective this means the charter must include an architecture del=
iverable plus one defining the MPLS data plane. Based on the assessment of =
the BoF it should also include one for lPv6. This would not preclude future=
 data planes from being added to the charter and reusing all the output of =
the WG sometime down the line.

r.

Sent from my iPhone

On 4 Sep 2013, at 15:26, John E Drake <[email-masked]<mailto:jdrake@jun=
iper.net>> wrote:

Peter,

The group=92s charter can always be amended in the future, but I don=92t th=
ink it=92s good to declare open season on the MPLS data plane initially.

Yours Irrespectively,

John

From:[email-masked]<mailto:[email-masked]> [mailto:status=
[email-masked]] On Behalf Of AshwoodsmithPeter
Sent: Wednesday, September 04, 2013 7:01 AM
To: [email-masked]<mailto:[email-masked]>
Subject: Re: [Status] Summary of STATUS BOF and the next steps

I would like us to have the door open to changes in the data plane in the f=
uture.

The text as written pretty much closes that door.

Naturally it makes sense to focus on what current hardware can do, but we n=
eed to be forward looking and to make recommendations on what changes would=
 be useful in the future.

Peter

From:[email-masked]<mailto:[email-masked]> [mailto:status=
[email-masked]] On Behalf Of Stewart Bryant
Sent: Wednesday, September 04, 2013 6:25 AM
To: Mach Chen
Cc: John E Drake; Mark Townsley; Victor Kuarsingh; Roberta Maglione (robmgl=
); John G. Scudder; Adrian Farrel; Alvaro Retana (aretana); [email-masked]=
<mailto:[email-masked]>
Subject: Re: [Status] Summary of STATUS BOF and the next steps

May I suggest that we use the name "SR" and worry
about what it binds to later.

The higher priority item is the charter text. Does
anyone have any comments on the text proposed
so far, or the text in the BOF proposal:

The Stacked Tunnels for Source Routing (STATUS) Working Group
is chartered to develop a framework and use cases for source-routed
flows in packet switched networks.

IP previously had a source-based routing mechanism made
available through an IP Option. This mechanism has, however,
not been widely used and has a number of issues that make its
use inadvisable, and other mechanisms (such as RFC 1940)
do not appear to have been implemented at all.

The ability of a router to influence or control the forwarding
path of an individual packet or all the packets of a given
Forwarding Equivalence Class (FEC) is a desirable feature
for a number of reasons including Label Switched Path stitching,
egress protection, explicit routing, egress ASBR link selection,
and backup (bypass tunnels, Remote Loop-Free Alternates)
routing. This can be achieved by facilitating source-initiated
selection of routes to complement the route selection
provided by existing routing protocols for both inter- domain
and intra-domain routes.

Historically, distribution of MPLS label binding information
was done by relying on label distribution protocols
such as LDP and RSVP-TE.

The use cases documented by the working group will
indicate the network function that is being facilitated
and indicate which packet data plane is to be used.

The framework developed by the working group will
consider forwarding of IPv4, IPv6, and MPLS using the
existing unicast data planes. Multicast forwarding will
be for future study and the choice of data planes will
be limited to those for which use cases exist. A key
objective of the work will be to ensure that source-
routed packets can be handled seamlessly by existing
deployed equipment. A major objective will be that the
new function does not modify existing data plane behavior
or architectures, and that it can be enabled through only
control and management plane software upgrades at
deployed devices.

Once the working group has established a framework
and there is demonstrable consensus for use cases,
the working group will move forward to specify protocol
solutions for installing forwarding information through
the use of the IGPs (OSPF and IS-IS), or through the
management plane. In the course of developing protocol
extensions, the working group will work closely with
other IETF working groups responsible for the protocols
being modified (such as OSPF, ISIS, and I2RS).

    The working group is chartered for the following work items:

    A framework for the use of the existing MPLS data plane to
    support tunnel-based unicast source routing.

    Develop use cases for tunnel-based unicast source routing
    that demonstrate the need and support for solutions. Care
    should be taken to avoid clustering use cases that might seem
    to imply support for multiple use cases when only some of the
    cluster actually have wide-scale support.

    Develop ISIS and OSPF protocol extensions necessary for
   distribution of MPLS forwarding information.

    The working group will consider management (including
    configuration, reporting, diagnostics, and OAM) and security
    implications of its work and document them in separate
    documents as appropriate.

    The working group is not chartered to make any changes to
    the MPLS or IPv6 data planes. Any proposed changes to the
    data planes are to be specified in the working groups responsible
    for the data planes (that is, the MPLS and 6MAN working groups,
    respectively).

- Stewart
_______________________________________________
status mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/status

--_000_2FE467D3673DCE409A84D67EC2F607BB140E703Fxmbrcdx10ciscoc_
Content-Type: text/html; charset="Windows-1252"
Content-ID: <[email-masked]>
Content-Transfer-Encoding: quoted-printable

<html>
<head>
<meta http-equiv=3D"Content-Type" content=3D"text/html; charset=3DWindows-1=
252">
</head>
<body style=3D"word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-lin=
e-break: after-white-space; color: rgb(0, 0, 0); font-size: 14px; font-fami=
ly: Calibri, sans-serif; ">
<div>I actually don't think it is possible to write a dataplane agnostic ar=
chitecture. &nbsp; We can write an architecture document that is 90% datapl=
ane independent and then has some dataplane dependencies. &nbsp;E.g. having=
 the full SR path available at each hop vs
 the remainder.</div>
<div><br>
</div>
<div>George</div>
<div><br>
</div>
<span id=3D"OLK_SRC_BODY_SECTION">
<div style=3D"font-family:Calibri; font-size:11pt; text-align:left; color:b=
lack; BORDER-BOTTOM: medium none; BORDER-LEFT: medium none; PADDING-BOTTOM:=
 0in; PADDING-LEFT: 0in; PADDING-RIGHT: 0in; BORDER-TOP: #b5c4df 1pt solid;=
 BORDER-RIGHT: medium none; PADDING-TOP: 3pt">
<span style=3D"font-weight:bold">From: </span>AshwoodsmithPeter &lt;<a href=
=3D"mailto:[email-masked]">[email-masked]</a>=
&gt;<br>
<span style=3D"font-weight:bold">Date: </span>Wednesday, September 4, 2013 =
3:05 PM<br>
<span style=3D"font-weight:bold">To: </span>Rob Shakir &lt;<a href=3D"mailt=
o:[email-masked]">[email-masked]</a>&gt;, &quot;<a href=3D"mailto:[email-masked]">=
[email-masked]</a>&quot; &lt;<a href=3D"mailto:[email-masked]">status@iet=
f.org</a>&gt;<br>
<span style=3D"font-weight:bold">Subject: </span>Re: [Status] Summary of ST=
ATUS BOF and the next steps<br>
</div>
<div><br>
</div>
<div>
<div dir=3D"auto">
<div>strongly concur.<br>
<br>
Peter</div>
<div><br>
On Sep 4, 2013, at 2:57 PM, &quot;Rob Shakir&quot; &lt;<a href=3D"mailto:rj=
[email-masked]">[email-masked]</a>&gt; wrote:<br>
<br>
</div>
<blockquote type=3D"cite">
<div>
<div>
<div><span style=3D"-webkit-text-size-adjust: auto; background-color: rgba(=
255, 255, 255, 0);">Right. Day 1 we need this to work with things that are =
deployable in real and existing networks, but I think this should not stop =
us defining the charter to write a
 data plane agnostic architecture, which can then have documents describing=
 how it is implemented in each data plane we want to use.&nbsp;</span></div=
>
<div><span style=3D"-webkit-text-size-adjust: auto; background-color: rgba(=
255, 255, 255, 0);"><br>
</span></div>
<div><span style=3D"-webkit-text-size-adjust: auto; background-color: rgba(=
255, 255, 255, 0);">This way we can define the features that we need - or a=
t least desirable - and then work out how they are realised (some existing =
data planes may not be able to support
 all desirable features - an example is retaining the full path at all hops=
). It also reduces duplication across the data plane instance specs.&nbsp;<=
/span></div>
<div><span style=3D"-webkit-text-size-adjust: auto; background-color: rgba(=
255, 255, 255, 0);"><br>
</span></div>
<div><span style=3D"-webkit-text-size-adjust: auto; background-color: rgba(=
255, 255, 255, 0);">From my perspective this means the charter must include=
 an architecture deliverable plus one defining the MPLS data plane. Based o=
n the assessment of the BoF it should
 also include one for lPv6. This would not preclude future data planes from=
 being added to the charter and reusing all the output of the WG sometime d=
own the line.&nbsp;</span></div>
<div><br>
</div>
<div><span style=3D"-webkit-text-size-adjust: auto;">r.&nbsp;</span></div>
<br>
<span style=3D"-webkit-text-size-adjust: auto;">Sent from my iPhone</span><=
/div>
<div style=3D"-webkit-text-size-adjust: auto; "><br>
On 4 Sep 2013, at 15:26, John E Drake &lt;<a href=3D"mailto:jdrake@juniper.=
net">[email-masked]</a>&gt; wrote:<br>
<br>
</div>
<blockquote type=3D"cite" style=3D"-webkit-text-size-adjust: auto; ">
<div>
<meta name=3D"Generator" content=3D"Microsoft Word 15 (filtered medium)">
<style><!--
/* Font Definitions */
@font-face
	{font-family:"Cambria Math";
	panose-1:2 4 5 3 5 4 6 3 2 4;}
@font-face
	{font-family:Calibri;
	panose-1:2 15 5 2 2 2 4 3 2 4;}
@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","serif";
	color:black;}
a:link, span.MsoHyperlink
	{mso-style-priority:99;
	color:blue;
	text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
	{mso-style-priority:99;
	color:purple;
	text-decoration:underline;}
span.EmailStyle17
	{mso-style-type:personal;
	font-family:"Calibri","sans-serif";
	color:#1F497D;}
span.EmailStyle18
	{mso-style-type:personal-reply;
	font-family:"Calibri","sans-serif";
	color:#1F497D;}
.MsoChpDefault
	{mso-style-type:export-only;
	font-size:10.0pt;}
@page WordSection1
	{size:8.5in 11.0in;
	margin:1.0in 1.0in 1.0in 1.0in;}
div.WordSection1
	{page:WordSection1;}
--></style><!--[if gte mso 9]><xml>
<o:shapedefaults v:ext=3D"edit" spidmax=3D"1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
<o:shapelayout v:ext=3D"edit">
<o:idmap v:ext=3D"edit" data=3D"1" />
</o:shapelayout></xml><![endif]-->
<div class=3D"WordSection1">
<p class=3D"MsoNormal"><span style=3D"font-size: 11pt; font-family: Calibri=
, sans-serif; color: rgb(31, 73, 125); ">Peter,<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span style=3D"font-size: 11pt; font-family: Calibri=
, sans-serif; color: rgb(31, 73, 125); "><o:p>&nbsp;</o:p></span></p>
<p class=3D"MsoNormal"><span style=3D"font-size: 11pt; font-family: Calibri=
, sans-serif; color: rgb(31, 73, 125); ">The group=92s charter can always b=
e amended in the future, but I don=92t think it=92s good to declare open se=
ason on the MPLS data plane initially.
<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span style=3D"font-size: 11pt; font-family: Calibri=
, sans-serif; color: rgb(31, 73, 125); "><o:p>&nbsp;</o:p></span></p>
<div>
<p class=3D"MsoNormal"><span style=3D"font-size: 11pt; font-family: Calibri=
, sans-serif; color: rgb(31, 73, 125); ">Yours Irrespectively,<o:p></o:p></=
span></p>
<p class=3D"MsoNormal"><span style=3D"font-size: 11pt; font-family: Calibri=
, sans-serif; color: rgb(31, 73, 125); "><o:p>&nbsp;</o:p></span></p>
<p class=3D"MsoNormal"><span style=3D"font-size: 11pt; font-family: Calibri=
, sans-serif; color: rgb(31, 73, 125); ">John<o:p></o:p></span></p>
</div>
<p class=3D"MsoNormal"><span style=3D"font-size: 11pt; font-family: Calibri=
, sans-serif; color: rgb(31, 73, 125); "><o:p>&nbsp;</o:p></span></p>
<div style=3D"border:none;border-left:solid blue 1.5pt;padding:0in 0in 0in =
4.0pt">
<div>
<div style=3D"border:none;border-top:solid #E1E1E1 1.0pt;padding:3.0pt 0in =
0in 0in">
<p class=3D"MsoNormal"><b><span style=3D"font-size: 11pt; font-family: Cali=
bri, sans-serif; color: windowtext; ">From:</span></b><span style=3D"font-s=
ize: 11pt; font-family: Calibri, sans-serif; color: windowtext; "><a href=
=3D"mailto:[email-masked]">[email-masked]</a>
 [<a href=3D"mailto:[email-masked]">mailto:[email-masked]=
</a>] <b>
On Behalf Of </b>AshwoodsmithPeter<br>
<b>Sent:</b> Wednesday, September 04, 2013 7:01 AM<br>
<b>To:</b> <a href=3D"mailto:[email-masked]">[email-masked]</a><br>
<b>Subject:</b> Re: [Status] Summary of STATUS BOF and the next steps<o:p><=
/o:p></span></p>
</div>
</div>
<p class=3D"MsoNormal"><o:p>&nbsp;</o:p></p>
<p class=3D"MsoNormal"><span style=3D"font-size: 11pt; font-family: Calibri=
, sans-serif; color: rgb(31, 73, 125); ">I would like us to have the door o=
pen to changes in the data plane
<b>in the future</b>.<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span style=3D"font-size: 11pt; font-family: Calibri=
, sans-serif; color: rgb(31, 73, 125); "><o:p>&nbsp;</o:p></span></p>
<p class=3D"MsoNormal"><span style=3D"font-size: 11pt; font-family: Calibri=
, sans-serif; color: rgb(31, 73, 125); ">The text as written pretty much cl=
oses that door.<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span style=3D"font-size: 11pt; font-family: Calibri=
, sans-serif; color: rgb(31, 73, 125); "><o:p>&nbsp;</o:p></span></p>
<p class=3D"MsoNormal"><span style=3D"font-size: 11pt; font-family: Calibri=
, sans-serif; color: rgb(31, 73, 125); ">Naturally it makes sense to focus =
on what current hardware can do, but we need to be forward looking and to m=
ake recommendations on what changes
 would be useful in the future.<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span style=3D"font-size: 11pt; font-family: Calibri=
, sans-serif; color: rgb(31, 73, 125); "><o:p>&nbsp;</o:p></span></p>
<p class=3D"MsoNormal"><span style=3D"font-size: 11pt; font-family: Calibri=
, sans-serif; color: rgb(31, 73, 125); ">Peter<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span style=3D"font-size: 11pt; font-family: Calibri=
, sans-serif; color: rgb(31, 73, 125); "><o:p>&nbsp;</o:p></span></p>
<div>
<div style=3D"border:none;border-top:solid #B5C4DF 1.0pt;padding:3.0pt 0in =
0in 0in">
<p class=3D"MsoNormal"><b><span style=3D"font-size: 10pt; font-family: Taho=
ma, sans-serif; color: windowtext; ">From:</span></b><span style=3D"font-si=
ze: 10pt; font-family: Tahoma, sans-serif; color: windowtext; "><a href=3D"=
mailto:[email-masked]">[email-masked]</a>
 [<a href=3D"mailto:[email-masked]">mailto:[email-masked]=
</a>] <b>
On Behalf Of </b>Stewart Bryant<br>
<b>Sent:</b> Wednesday, September 04, 2013 6:25 AM<br>
<b>To:</b> Mach Chen<br>
<b>Cc:</b> John E Drake; Mark Townsley; Victor Kuarsingh; Roberta Maglione =
(robmgl); John G. Scudder; Adrian Farrel; Alvaro Retana (aretana);
<a href=3D"mailto:[email-masked]">[email-masked]</a><br>
<b>Subject:</b> Re: [Status] Summary of STATUS BOF and the next steps<o:p><=
/o:p></span></p>
</div>
</div>
<p class=3D"MsoNormal"><o:p>&nbsp;</o:p></p>
<p class=3D"MsoNormal" style=3D"margin-bottom:12.0pt"><br>
May I suggest that we use the name &quot;SR&quot; and worry<br>
about what it binds to later.<br>
<br>
The higher priority item is the charter text. Does<br>
anyone have any comments on the text proposed<br>
so far, or the text in the BOF proposal:<br>
<br>
<br>
The Stacked Tunnels for Source Routing (STATUS) Working Group <br>
is chartered to develop a framework and use cases for source-routed <br>
flows in packet switched networks.<br>
<br>
IP previously had a source-based routing mechanism made <br>
available through an IP Option. This mechanism has, however, <br>
not been widely used and has a number of issues that make its <br>
use inadvisable, and other mechanisms (such as RFC 1940) <br>
do not appear to have been implemented at all.<br>
<br>
The ability of a router to influence or control the forwarding <br>
path of an individual packet or all the packets of a given <br>
Forwarding Equivalence Class (FEC) is a desirable feature <br>
for a number of reasons including Label Switched Path stitching, <br>
egress protection, explicit routing, egress ASBR link selection, <br>
and backup (bypass tunnels, Remote Loop-Free Alternates) <br>
routing. This can be achieved by facilitating source-initiated <br>
selection of routes to complement the route selection <br>
provided by existing routing protocols for both inter- domain <br>
and intra-domain routes.<br>
<br>
Historically, distribution of MPLS label binding information <br>
was done by relying on label distribution protocols <br>
such as LDP and RSVP-TE.<br>
<br>
The use cases documented by the working group will <br>
indicate the network function that is being facilitated <br>
and indicate which packet data plane is to be used.<br>
<br>
The framework developed by the working group will <br>
consider forwarding of IPv4, IPv6, and MPLS using the <br>
existing unicast data planes. Multicast forwarding will <br>
be for future study and the choice of data planes will <br>
be limited to those for which use cases exist. A key <br>
objective of the work will be to ensure that source-<br>
routed packets can be handled seamlessly by existing <br>
deployed equipment. A major objective will be that the <br>
new function does not modify existing data plane behavior <br>
or architectures, and that it can be enabled through only <br>
control and management plane software upgrades at <br>
deployed devices.<br>
<br>
Once the working group has established a framework <br>
and there is demonstrable consensus for use cases, <br>
the working group will move forward to specify protocol <br>
solutions for installing forwarding information through <br>
the use of the IGPs (OSPF and IS-IS), or through the <br>
management plane. In the course of developing protocol <br>
extensions, the working group will work closely with <br>
other IETF working groups responsible for the protocols <br>
being modified (such as OSPF, ISIS, and I2RS).<br>
<br>
&nbsp;&nbsp;&nbsp; The working group is chartered for the following work it=
ems:<br>
<br>
&nbsp;&nbsp;&nbsp; A framework for the use of the existing MPLS data plane =
to <br>
&nbsp;&nbsp;&nbsp; support tunnel-based unicast source routing. <br>
<br>
&nbsp;&nbsp;&nbsp; Develop use cases for tunnel-based unicast source routin=
g <br>
&nbsp;&nbsp;&nbsp; that demonstrate the need and support for solutions. Car=
e <br>
&nbsp;&nbsp;&nbsp; should be taken to avoid clustering use cases that might=
 seem<br>
&nbsp; &nbsp; to imply support for multiple use cases when only some of the=
 <br>
&nbsp;&nbsp;&nbsp; cluster actually have wide-scale support. <br>
<br>
&nbsp;&nbsp;&nbsp; Develop ISIS and OSPF protocol extensions necessary for =
<br>
&nbsp;&nbsp; distribution of MPLS forwarding information. <br>
<br>
&nbsp;&nbsp;&nbsp; The working group will consider management (including&nb=
sp; <br>
&nbsp;&nbsp;&nbsp; configuration, reporting, diagnostics, and OAM) and secu=
rity <br>
&nbsp;&nbsp;&nbsp; implications of its work and document them in separate <=
br>
&nbsp;&nbsp;&nbsp; documents as appropriate. <br>
<br>
&nbsp;&nbsp;&nbsp; The working group is not chartered to make any changes t=
o <br>
&nbsp;&nbsp;&nbsp; the MPLS or IPv6 data planes. Any proposed changes to th=
e <br>
&nbsp;&nbsp;&nbsp; data planes are to be specified in the working groups re=
sponsible <br>
&nbsp;&nbsp;&nbsp; for the data planes (that is, the MPLS and 6MAN working =
groups,&nbsp; <br>
&nbsp;&nbsp;&nbsp; respectively).<br>
<br>
- Stewart<o:p></o:p></p>
</div>
</div>
</div>
</blockquote>
<blockquote type=3D"cite" style=3D"-webkit-text-size-adjust: auto; ">
<div><span>_______________________________________________</span><br>
<span>status mailing list</span><br>
<span><a href=3D"mailto:[email-masked]">[email-masked]</a></span><br>
<span><a href=3D"https://www.ietf.org/mailman/listinfo/status">https://www.=
ietf.org/mailman/listinfo/status</a></span><br>
</div>
</blockquote>
</div>
</blockquote>
<blockquote type=3D"cite">
<div></div>
</blockquote>
</div>
</div>
</span>
</body>
</html>

--_000_2FE467D3673DCE409A84D67EC2F607BB140E703Fxmbrcdx10ciscoc_--

From: AshwoodsmithPeter <[email-masked]>
To: Rob Shakir <[email-masked]>, "[email-masked]" <[email-masked]>
Date: Wed, 4 Sep 2013 19:05:53 +0000
Accept-Language: en-US, zh-CN
Subject: Re: [Status] Summary of STATUS BOF and the next steps

--_000_746508F17E894C4B9A119233C6985E3Ehuaweicom_
Content-Type: text/plain; charset="Windows-1252"
Content-Transfer-Encoding: quoted-printable

strongly concur.

Peter

On Sep 4, 2013, at 2:57 PM, "Rob Shakir" <[email-masked]<mailto:[email-masked]>> wr=
ote:

Right. Day 1 we need this to work with things that are deployable in real a=
nd existing networks, but I think this should not stop us defining the char=
ter to write a data plane agnostic architecture, which can then have docume=
nts describing how it is implemented in each data plane we want to use.

This way we can define the features that we need - or at least desirable - =
and then work out how they are realised (some existing data planes may not =
be able to support all desirable features - an example is retaining the ful=
l path at all hops). It also reduces duplication across the data plane inst=
ance specs.

>From my perspective this means the charter must include an architecture del=
iverable plus one defining the MPLS data plane. Based on the assessment of =
the BoF it should also include one for lPv6. This would not preclude future=
 data planes from being added to the charter and reusing all the output of =
the WG sometime down the line.

r.

Sent from my iPhone

On 4 Sep 2013, at 15:26, John E Drake <[email-masked]<mailto:jdrake@jun=
iper.net>> wrote:

Peter,

The group=92s charter can always be amended in the future, but I don=92t th=
ink it=92s good to declare open season on the MPLS data plane initially.

Yours Irrespectively,

John

From: [email-masked]<mailto:[email-masked]> [mailto:statu=
[email-masked]] On Behalf Of AshwoodsmithPeter
Sent: Wednesday, September 04, 2013 7:01 AM
To: [email-masked]<mailto:[email-masked]>
Subject: Re: [Status] Summary of STATUS BOF and the next steps

I would like us to have the door open to changes in the data plane in the f=
uture.

The text as written pretty much closes that door.

Naturally it makes sense to focus on what current hardware can do, but we n=
eed to be forward looking and to make recommendations on what changes would=
 be useful in the future.

Peter

From: [email-masked]<mailto:[email-masked]> [mailto:statu=
[email-masked]] On Behalf Of Stewart Bryant
Sent: Wednesday, September 04, 2013 6:25 AM
To: Mach Chen
Cc: John E Drake; Mark Townsley; Victor Kuarsingh; Roberta Maglione (robmgl=
); John G. Scudder; Adrian Farrel; Alvaro Retana (aretana); [email-masked]=
<mailto:[email-masked]>
Subject: Re: [Status] Summary of STATUS BOF and the next steps

May I suggest that we use the name "SR" and worry
about what it binds to later.

The higher priority item is the charter text. Does
anyone have any comments on the text proposed
so far, or the text in the BOF proposal:

The Stacked Tunnels for Source Routing (STATUS) Working Group
is chartered to develop a framework and use cases for source-routed
flows in packet switched networks.

IP previously had a source-based routing mechanism made
available through an IP Option. This mechanism has, however,
not been widely used and has a number of issues that make its
use inadvisable, and other mechanisms (such as RFC 1940)
do not appear to have been implemented at all.

The ability of a router to influence or control the forwarding
path of an individual packet or all the packets of a given
Forwarding Equivalence Class (FEC) is a desirable feature
for a number of reasons including Label Switched Path stitching,
egress protection, explicit routing, egress ASBR link selection,
and backup (bypass tunnels, Remote Loop-Free Alternates)
routing. This can be achieved by facilitating source-initiated
selection of routes to complement the route selection
provided by existing routing protocols for both inter- domain
and intra-domain routes.

Historically, distribution of MPLS label binding information
was done by relying on label distribution protocols
such as LDP and RSVP-TE.

The use cases documented by the working group will
indicate the network function that is being facilitated
and indicate which packet data plane is to be used.

The framework developed by the working group will
consider forwarding of IPv4, IPv6, and MPLS using the
existing unicast data planes. Multicast forwarding will
be for future study and the choice of data planes will
be limited to those for which use cases exist. A key
objective of the work will be to ensure that source-
routed packets can be handled seamlessly by existing
deployed equipment. A major objective will be that the
new function does not modify existing data plane behavior
or architectures, and that it can be enabled through only
control and management plane software upgrades at
deployed devices.

Once the working group has established a framework
and there is demonstrable consensus for use cases,
the working group will move forward to specify protocol
solutions for installing forwarding information through
the use of the IGPs (OSPF and IS-IS), or through the
management plane. In the course of developing protocol
extensions, the working group will work closely with
other IETF working groups responsible for the protocols
being modified (such as OSPF, ISIS, and I2RS).

    The working group is chartered for the following work items:

    A framework for the use of the existing MPLS data plane to
    support tunnel-based unicast source routing.

    Develop use cases for tunnel-based unicast source routing
    that demonstrate the need and support for solutions. Care
    should be taken to avoid clustering use cases that might seem
    to imply support for multiple use cases when only some of the
    cluster actually have wide-scale support.

    Develop ISIS and OSPF protocol extensions necessary for
   distribution of MPLS forwarding information.

    The working group will consider management (including
    configuration, reporting, diagnostics, and OAM) and security
    implications of its work and document them in separate
    documents as appropriate.

    The working group is not chartered to make any changes to
    the MPLS or IPv6 data planes. Any proposed changes to the
    data planes are to be specified in the working groups responsible
    for the data planes (that is, the MPLS and 6MAN working groups,
    respectively).

- Stewart
_______________________________________________
status mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/status

--_000_746508F17E894C4B9A119233C6985E3Ehuaweicom_
Content-Type: text/html; charset="Windows-1252"
Content-Transfer-Encoding: quoted-printable

<html>
<head>
<meta http-equiv=3D"Content-Type" content=3D"text/html; charset=3DWindows-1=
252">
</head>
<body dir=3D"auto">
<div>strongly concur.<br>
<br>
Peter</div>
<div><br>
On Sep 4, 2013, at 2:57 PM, &quot;Rob Shakir&quot; &lt;<a href=3D"mailto:rj=
[email-masked]">[email-masked]</a>&gt; wrote:<br>
<br>
</div>
<blockquote type=3D"cite">
<div>
<div>
<div><span style=3D"-webkit-text-size-adjust: auto; background-color: rgba(=
255, 255, 255, 0);">Right. Day 1 we need this to work with things that are =
deployable in real and existing networks, but I think this should not stop =
us defining the charter to write a
 data plane agnostic architecture, which can then have documents describing=
 how it is implemented in each data plane we want to use.&nbsp;</span></div=
>
<div><span style=3D"-webkit-text-size-adjust: auto; background-color: rgba(=
255, 255, 255, 0);"><br>
</span></div>
<div><span style=3D"-webkit-text-size-adjust: auto; background-color: rgba(=
255, 255, 255, 0);">This way we can define the features that we need - or a=
t least desirable - and then work out how they are realised (some existing =
data planes may not be able to support
 all desirable features - an example is retaining the full path at all hops=
). It also reduces duplication across the data plane instance specs.&nbsp;<=
/span></div>
<div><span style=3D"-webkit-text-size-adjust: auto; background-color: rgba(=
255, 255, 255, 0);"><br>
</span></div>
<div><span style=3D"-webkit-text-size-adjust: auto; background-color: rgba(=
255, 255, 255, 0);">From my perspective this means the charter must include=
 an architecture deliverable plus one defining the MPLS data plane. Based o=
n the assessment of the BoF it should
 also include one for lPv6. This would not preclude future data planes from=
 being added to the charter and reusing all the output of the WG sometime d=
own the line.&nbsp;</span></div>
<div><br>
</div>
<div><span style=3D"-webkit-text-size-adjust: auto;">r.&nbsp;</span></div>
<br>
<span style=3D"-webkit-text-size-adjust: auto;">Sent from my iPhone</span><=
/div>
<div style=3D"-webkit-text-size-adjust: auto; "><br>
On 4 Sep 2013, at 15:26, John E Drake &lt;<a href=3D"mailto:jdrake@juniper.=
net">[email-masked]</a>&gt; wrote:<br>
<br>
</div>
<blockquote type=3D"cite" style=3D"-webkit-text-size-adjust: auto; ">
<div>
<meta name=3D"Generator" content=3D"Microsoft Word 15 (filtered medium)">
<style><!--
/* Font Definitions */
@font-face
	{font-family:"Cambria Math";
	panose-1:2 4 5 3 5 4 6 3 2 4;}
@font-face
	{font-family:Calibri;
	panose-1:2 15 5 2 2 2 4 3 2 4;}
@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","serif";
	color:black;}
a:link, span.MsoHyperlink
	{mso-style-priority:99;
	color:blue;
	text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
	{mso-style-priority:99;
	color:purple;
	text-decoration:underline;}
span.EmailStyle17
	{mso-style-type:personal;
	font-family:"Calibri","sans-serif";
	color:#1F497D;}
span.EmailStyle18
	{mso-style-type:personal-reply;
	font-family:"Calibri","sans-serif";
	color:#1F497D;}
.MsoChpDefault
	{mso-style-type:export-only;
	font-size:10.0pt;}
@page WordSection1
	{size:8.5in 11.0in;
	margin:1.0in 1.0in 1.0in 1.0in;}
div.WordSection1
	{page:WordSection1;}
--></style><!--[if gte mso 9]><xml>
<o:shapedefaults v:ext=3D"edit" spidmax=3D"1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
<o:shapelayout v:ext=3D"edit">
<o:idmap v:ext=3D"edit" data=3D"1" />
</o:shapelayout></xml><![endif]-->
<div class=3D"WordSection1">
<p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=
libri&quot;,&quot;sans-serif&quot;;color:#1F497D">Peter,<o:p></o:p></span><=
/p>
<p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=
libri&quot;,&quot;sans-serif&quot;;color:#1F497D"><o:p>&nbsp;</o:p></span><=
/p>
<p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=
libri&quot;,&quot;sans-serif&quot;;color:#1F497D">The group=92s charter can=
 always be amended in the future, but I don=92t think it=92s good to declar=
e open season on the MPLS data plane initially.
<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=
libri&quot;,&quot;sans-serif&quot;;color:#1F497D"><o:p>&nbsp;</o:p></span><=
/p>
<div>
<p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=
libri&quot;,&quot;sans-serif&quot;;color:#1F497D">Yours Irrespectively,<o:p=
></o:p></span></p>
<p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=
libri&quot;,&quot;sans-serif&quot;;color:#1F497D"><o:p>&nbsp;</o:p></span><=
/p>
<p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=
libri&quot;,&quot;sans-serif&quot;;color:#1F497D">John<o:p></o:p></span></p=
>
</div>
<p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=
libri&quot;,&quot;sans-serif&quot;;color:#1F497D"><o:p>&nbsp;</o:p></span><=
/p>
<div style=3D"border:none;border-left:solid blue 1.5pt;padding:0in 0in 0in =
4.0pt">
<div>
<div style=3D"border:none;border-top:solid #E1E1E1 1.0pt;padding:3.0pt 0in =
0in 0in">
<p class=3D"MsoNormal"><b><span style=3D"font-size:11.0pt;font-family:&quot=
;Calibri&quot;,&quot;sans-serif&quot;;color:windowtext">From:</span></b><sp=
an style=3D"font-size:11.0pt;font-family:&quot;Calibri&quot;,&quot;sans-ser=
if&quot;;color:windowtext">
<a href=3D"mailto:[email-masked]">[email-masked]</a> [<a =
href=3D"mailto:[email-masked]">mailto:[email-masked]</a>]
<b>On Behalf Of </b>AshwoodsmithPeter<br>
<b>Sent:</b> Wednesday, September 04, 2013 7:01 AM<br>
<b>To:</b> <a href=3D"mailto:[email-masked]">[email-masked]</a><br>
<b>Subject:</b> Re: [Status] Summary of STATUS BOF and the next steps<o:p><=
/o:p></span></p>
</div>
</div>
<p class=3D"MsoNormal"><o:p>&nbsp;</o:p></p>
<p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=
libri&quot;,&quot;sans-serif&quot;;color:#1F497D">I would like us to have t=
he door open to changes in the data plane
<b>in the future</b>.<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=
libri&quot;,&quot;sans-serif&quot;;color:#1F497D"><o:p>&nbsp;</o:p></span><=
/p>
<p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=
libri&quot;,&quot;sans-serif&quot;;color:#1F497D">The text as written prett=
y much closes that door.<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=
libri&quot;,&quot;sans-serif&quot;;color:#1F497D"><o:p>&nbsp;</o:p></span><=
/p>
<p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=
libri&quot;,&quot;sans-serif&quot;;color:#1F497D">Naturally it makes sense =
to focus on what current hardware can do, but we need to be forward looking=
 and to make recommendations on what changes would be useful
 in the future.<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=
libri&quot;,&quot;sans-serif&quot;;color:#1F497D"><o:p>&nbsp;</o:p></span><=
/p>
<p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=
libri&quot;,&quot;sans-serif&quot;;color:#1F497D">Peter<o:p></o:p></span></=
p>
<p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=
libri&quot;,&quot;sans-serif&quot;;color:#1F497D"><o:p>&nbsp;</o:p></span><=
/p>
<div>
<div style=3D"border:none;border-top:solid #B5C4DF 1.0pt;padding:3.0pt 0in =
0in 0in">
<p class=3D"MsoNormal"><b><span style=3D"font-size:10.0pt;font-family:&quot=
;Tahoma&quot;,&quot;sans-serif&quot;;color:windowtext">From:</span></b><spa=
n style=3D"font-size:10.0pt;font-family:&quot;Tahoma&quot;,&quot;sans-serif=
&quot;;color:windowtext">
<a href=3D"mailto:[email-masked]">[email-masked]</a> [<a =
href=3D"mailto:[email-masked]">mailto:[email-masked]</a>]
<b>On Behalf Of </b>Stewart Bryant<br>
<b>Sent:</b> Wednesday, September 04, 2013 6:25 AM<br>
<b>To:</b> Mach Chen<br>
<b>Cc:</b> John E Drake; Mark Townsley; Victor Kuarsingh; Roberta Maglione =
(robmgl); John G. Scudder; Adrian Farrel; Alvaro Retana (aretana);
<a href=3D"mailto:[email-masked]">[email-masked]</a><br>
<b>Subject:</b> Re: [Status] Summary of STATUS BOF and the next steps<o:p><=
/o:p></span></p>
</div>
</div>
<p class=3D"MsoNormal"><o:p>&nbsp;</o:p></p>
<p class=3D"MsoNormal" style=3D"margin-bottom:12.0pt"><br>
May I suggest that we use the name &quot;SR&quot; and worry<br>
about what it binds to later.<br>
<br>
The higher priority item is the charter text. Does<br>
anyone have any comments on the text proposed<br>
so far, or the text in the BOF proposal:<br>
<br>
<br>
The Stacked Tunnels for Source Routing (STATUS) Working Group <br>
is chartered to develop a framework and use cases for source-routed <br>
flows in packet switched networks.<br>
<br>
IP previously had a source-based routing mechanism made <br>
available through an IP Option. This mechanism has, however, <br>
not been widely used and has a number of issues that make its <br>
use inadvisable, and other mechanisms (such as RFC 1940) <br>
do not appear to have been implemented at all.<br>
<br>
The ability of a router to influence or control the forwarding <br>
path of an individual packet or all the packets of a given <br>
Forwarding Equivalence Class (FEC) is a desirable feature <br>
for a number of reasons including Label Switched Path stitching, <br>
egress protection, explicit routing, egress ASBR link selection, <br>
and backup (bypass tunnels, Remote Loop-Free Alternates) <br>
routing. This can be achieved by facilitating source-initiated <br>
selection of routes to complement the route selection <br>
provided by existing routing protocols for both inter- domain <br>
and intra-domain routes.<br>
<br>
Historically, distribution of MPLS label binding information <br>
was done by relying on label distribution protocols <br>
such as LDP and RSVP-TE.<br>
<br>
The use cases documented by the working group will <br>
indicate the network function that is being facilitated <br>
and indicate which packet data plane is to be used.<br>
<br>
The framework developed by the working group will <br>
consider forwarding of IPv4, IPv6, and MPLS using the <br>
existing unicast data planes. Multicast forwarding will <br>
be for future study and the choice of data planes will <br>
be limited to those for which use cases exist. A key <br>
objective of the work will be to ensure that source-<br>
routed packets can be handled seamlessly by existing <br>
deployed equipment. A major objective will be that the <br>
new function does not modify existing data plane behavior <br>
or architectures, and that it can be enabled through only <br>
control and management plane software upgrades at <br>
deployed devices.<br>
<br>
Once the working group has established a framework <br>
and there is demonstrable consensus for use cases, <br>
the working group will move forward to specify protocol <br>
solutions for installing forwarding information through <br>
the use of the IGPs (OSPF and IS-IS), or through the <br>
management plane. In the course of developing protocol <br>
extensions, the working group will work closely with <br>
other IETF working groups responsible for the protocols <br>
being modified (such as OSPF, ISIS, and I2RS).<br>
<br>
&nbsp;&nbsp;&nbsp; The working group is chartered for the following work it=
ems:<br>
<br>
&nbsp;&nbsp;&nbsp; A framework for the use of the existing MPLS data plane =
to <br>
&nbsp;&nbsp;&nbsp; support tunnel-based unicast source routing. <br>
<br>
&nbsp;&nbsp;&nbsp; Develop use cases for tunnel-based unicast source routin=
g <br>
&nbsp;&nbsp;&nbsp; that demonstrate the need and support for solutions. Car=
e <br>
&nbsp;&nbsp;&nbsp; should be taken to avoid clustering use cases that might=
 seem<br>
&nbsp; &nbsp; to imply support for multiple use cases when only some of the=
 <br>
&nbsp;&nbsp;&nbsp; cluster actually have wide-scale support. <br>
<br>
&nbsp;&nbsp;&nbsp; Develop ISIS and OSPF protocol extensions necessary for =
<br>
&nbsp;&nbsp; distribution of MPLS forwarding information. <br>
<br>
&nbsp;&nbsp;&nbsp; The working group will consider management (including&nb=
sp; <br>
&nbsp;&nbsp;&nbsp; configuration, reporting, diagnostics, and OAM) and secu=
rity <br>
&nbsp;&nbsp;&nbsp; implications of its work and document them in separate <=
br>
&nbsp;&nbsp;&nbsp; documents as appropriate. <br>
<br>
&nbsp;&nbsp;&nbsp; The working group is not chartered to make any changes t=
o <br>
&nbsp;&nbsp;&nbsp; the MPLS or IPv6 data planes. Any proposed changes to th=
e <br>
&nbsp;&nbsp;&nbsp; data planes are to be specified in the working groups re=
sponsible <br>
&nbsp;&nbsp;&nbsp; for the data planes (that is, the MPLS and 6MAN working =
groups,&nbsp; <br>
&nbsp;&nbsp;&nbsp; respectively).<br>
<br>
- Stewart<o:p></o:p></p>
</div>
</div>
</div>
</blockquote>
<blockquote type=3D"cite" style=3D"-webkit-text-size-adjust: auto; ">
<div><span>_______________________________________________</span><br>
<span>status mailing list</span><br>
<span><a href=3D"mailto:[email-masked]">[email-masked]</a></span><br>
<span><a href=3D"https://www.ietf.org/mailman/listinfo/status">https://www.=
ietf.org/mailman/listinfo/status</a></span><br>
</div>
</blockquote>
</div>
</blockquote>
<blockquote type=3D"cite">
<div></div>
</blockquote>
</body>
</html>

--_000_746508F17E894C4B9A119233C6985E3Ehuaweicom_--

From: Rob Shakir <[email-masked]>
Date: Wed, 4 Sep 2013 19:56:37 +0100
To: John E Drake <[email-masked]>
Cc: "[email-masked]" <[email-masked]>, AshwoodsmithPeter <[email-masked]>
Subject: Re: [Status] Summary of STATUS BOF and the next steps

--Apple-Mail-166B02E9-174A-413E-A62C-7A0E832E66CD
Content-Type: text/plain;
	charset=utf-8
Content-Transfer-Encoding: quoted-printable

Right. Day 1 we need this to work with things that are deployable in real an=
d existing networks, but I think this should not stop us defining the charte=
r to write a data plane agnostic architecture, which can then have documents=
 describing how it is implemented in each data plane we want to use.=20

This way we can define the features that we need - or at least desirable - a=
nd then work out how they are realised (some existing data planes may not be=
 able to support all desirable features - an example is retaining the full p=
ath at all hops). It also reduces duplication across the data plane instance=
 specs.=20

=46rom my perspective this means the charter must include an architecture de=
liverable plus one defining the MPLS data plane. Based on the assessment of t=
he BoF it should also include one for lPv6. This would not preclude future d=
ata planes from being added to the charter and reusing all the output of the=
 WG sometime down the line.=20

r.=20

Sent from my iPhone

On 4 Sep 2013, at 15:26, John E Drake <[email-masked]> wrote:

> Peter,
> =20
> The group=E2=80=99s charter can always be amended in the future, but I don=
=E2=80=99t think it=E2=80=99s good to declare open season on the MPLS data p=
lane initially.
> =20
> Yours Irrespectively,
> =20
> John
> =20
> From: [email-masked] [mailto:[email-masked]] On Behalf O=
f AshwoodsmithPeter
> Sent: Wednesday, September 04, 2013 7:01 AM
> To: [email-masked]
> Subject: Re: [Status] Summary of STATUS BOF and the next steps
> =20
> I would like us to have the door open to changes in the data plane in the f=
uture.
> =20
> The text as written pretty much closes that door.
> =20
> Naturally it makes sense to focus on what current hardware can do, but we n=
eed to be forward looking and to make recommendations on what changes would b=
e useful in the future.
> =20
> Peter
> =20
> From: [email-masked] [mailto:[email-masked]] On Behalf O=
f Stewart Bryant
> Sent: Wednesday, September 04, 2013 6:25 AM
> To: Mach Chen
> Cc: John E Drake; Mark Townsley; Victor Kuarsingh; Roberta Maglione (robmg=
l); John G. Scudder; Adrian Farrel; Alvaro Retana (aretana); [email-masked]=

> Subject: Re: [Status] Summary of STATUS BOF and the next steps
> =20
>=20
> May I suggest that we use the name "SR" and worry
> about what it binds to later.
>=20
> The higher priority item is the charter text. Does
> anyone have any comments on the text proposed
> so far, or the text in the BOF proposal:
>=20
>=20
> The Stacked Tunnels for Source Routing (STATUS) Working Group=20
> is chartered to develop a framework and use cases for source-routed=20
> flows in packet switched networks.
>=20
> IP previously had a source-based routing mechanism made=20
> available through an IP Option. This mechanism has, however,=20
> not been widely used and has a number of issues that make its=20
> use inadvisable, and other mechanisms (such as RFC 1940)=20
> do not appear to have been implemented at all.
>=20
> The ability of a router to influence or control the forwarding=20
> path of an individual packet or all the packets of a given=20
> Forwarding Equivalence Class (FEC) is a desirable feature=20
> for a number of reasons including Label Switched Path stitching,=20
> egress protection, explicit routing, egress ASBR link selection,=20
> and backup (bypass tunnels, Remote Loop-Free Alternates)=20
> routing. This can be achieved by facilitating source-initiated=20
> selection of routes to complement the route selection=20
> provided by existing routing protocols for both inter- domain=20
> and intra-domain routes.
>=20
> Historically, distribution of MPLS label binding information=20
> was done by relying on label distribution protocols=20
> such as LDP and RSVP-TE.
>=20
> The use cases documented by the working group will=20
> indicate the network function that is being facilitated=20
> and indicate which packet data plane is to be used.
>=20
> The framework developed by the working group will=20
> consider forwarding of IPv4, IPv6, and MPLS using the=20
> existing unicast data planes. Multicast forwarding will=20
> be for future study and the choice of data planes will=20
> be limited to those for which use cases exist. A key=20
> objective of the work will be to ensure that source-
> routed packets can be handled seamlessly by existing=20
> deployed equipment. A major objective will be that the=20
> new function does not modify existing data plane behavior=20
> or architectures, and that it can be enabled through only=20
> control and management plane software upgrades at=20
> deployed devices.
>=20
> Once the working group has established a framework=20
> and there is demonstrable consensus for use cases,=20
> the working group will move forward to specify protocol=20
> solutions for installing forwarding information through=20
> the use of the IGPs (OSPF and IS-IS), or through the=20
> management plane. In the course of developing protocol=20
> extensions, the working group will work closely with=20
> other IETF working groups responsible for the protocols=20
> being modified (such as OSPF, ISIS, and I2RS).
>=20
>     The working group is chartered for the following work items:
>=20
>     A framework for the use of the existing MPLS data plane to=20
>     support tunnel-based unicast source routing.=20
>=20
>     Develop use cases for tunnel-based unicast source routing=20
>     that demonstrate the need and support for solutions. Care=20
>     should be taken to avoid clustering use cases that might seem
>     to imply support for multiple use cases when only some of the=20
>     cluster actually have wide-scale support.=20
>=20
>     Develop ISIS and OSPF protocol extensions necessary for=20
>    distribution of MPLS forwarding information.=20
>=20
>     The working group will consider management (including =20
>     configuration, reporting, diagnostics, and OAM) and security=20
>     implications of its work and document them in separate=20
>     documents as appropriate.=20
>=20
>     The working group is not chartered to make any changes to=20
>     the MPLS or IPv6 data planes. Any proposed changes to the=20
>     data planes are to be specified in the working groups responsible=20
>     for the data planes (that is, the MPLS and 6MAN working groups, =20
>     respectively).
>=20
> - Stewart
>=20
> _______________________________________________
> status mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/status

--Apple-Mail-166B02E9-174A-413E-A62C-7A0E832E66CD
Content-Type: text/html;
	charset=utf-8
Content-Transfer-Encoding: quoted-printable

<html><head><meta http-equiv=3D"content-type" content=3D"text/html; charset=3D=
utf-8"></head><body dir=3D"auto"><div><div><span style=3D"-webkit-text-size-=
adjust: auto; background-color: rgba(255, 255, 255, 0);">Right. Day 1 we nee=
d this to work with things that are deployable in real and existing networks=
, but I think this should not stop us defining the charter to write a data p=
lane agnostic architecture, which can then have documents describing how it i=
s implemented in each data plane we want to use.&nbsp;</span></div><div><spa=
n style=3D"-webkit-text-size-adjust: auto; background-color: rgba(255, 255, 2=
55, 0);"><br></span></div><div><span style=3D"-webkit-text-size-adjust: auto=
; background-color: rgba(255, 255, 255, 0);">This way we can define the feat=
ures that we need - or at least desirable - and then work out how they are r=
ealised (some existing data planes may not be able to support all desirable f=
eatures - an example is retaining the full path at all hops). It also reduce=
s duplication across the data plane instance specs.&nbsp;</span></div><div><=
span style=3D"-webkit-text-size-adjust: auto; background-color: rgba(255, 25=
5, 255, 0);"><br></span></div><div><span style=3D"-webkit-text-size-adjust: a=
uto; background-color: rgba(255, 255, 255, 0);">=46rom my perspective this m=
eans the charter must include an architecture deliverable plus one defining t=
he MPLS data plane. Based on the assessment of the BoF it should also includ=
e one for lPv6. This would not preclude future data planes from being added t=
o the charter and reusing all the output of the WG sometime down the line.&n=
bsp;</span></div><div><br></div><div><span style=3D"-webkit-text-size-adjust=
: auto;">r.&nbsp;</span></div><br><span style=3D"-webkit-text-size-adjust: a=
uto;">Sent from my iPhone</span></div><div style=3D"-webkit-text-size-adjust=
: auto; "><br>On 4 Sep 2013, at 15:26, John E Drake &lt;<a href=3D"mailto:jd=
[email-masked]">[email-masked]</a>&gt; wrote:<br><br></div><blockquote=
 type=3D"cite" style=3D"-webkit-text-size-adjust: auto; "><div>

<meta http-equiv=3D"Content-Type" content=3D"text/html; charset=3Dus-ascii">=

<meta name=3D"Generator" content=3D"Microsoft Word 15 (filtered medium)">
<style><!--
/* Font Definitions */
@font-face
	{font-family:"Cambria Math";
	panose-1:2 4 5 3 5 4 6 3 2 4;}
@font-face
	{font-family:Calibri;
	panose-1:2 15 5 2 2 2 4 3 2 4;}
@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","serif";
	color:black;}
a:link, span.MsoHyperlink
	{mso-style-priority:99;
	color:blue;
	text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
	{mso-style-priority:99;
	color:purple;
	text-decoration:underline;}
span.EmailStyle17
	{mso-style-type:personal;
	font-family:"Calibri","sans-serif";
	color:#1F497D;}
span.EmailStyle18
	{mso-style-type:personal-reply;
	font-family:"Calibri","sans-serif";
	color:#1F497D;}
.MsoChpDefault
	{mso-style-type:export-only;
	font-size:10.0pt;}
@page WordSection1
	{size:8.5in 11.0in;
	margin:1.0in 1.0in 1.0in 1.0in;}
div.WordSection1
	{page:WordSection1;}
--></style><!--[if gte mso 9]><xml>
<o:shapedefaults v:ext=3D"edit" spidmax=3D"1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
<o:shapelayout v:ext=3D"edit">
<o:idmap v:ext=3D"edit" data=3D"1" />
</o:shapelayout></xml><![endif]-->

<div class=3D"WordSection1">
<p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Cal=
ibri&quot;,&quot;sans-serif&quot;;color:#1F497D">Peter,<o:p></o:p></span></p=
>
<p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Cal=
ibri&quot;,&quot;sans-serif&quot;;color:#1F497D"><o:p>&nbsp;</o:p></span></p=
>
<p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Cal=
ibri&quot;,&quot;sans-serif&quot;;color:#1F497D">The group=E2=80=99s charter=
 can always be amended in the future, but I don=E2=80=99t think it=E2=80=99s=
 good to declare open season on the MPLS data plane initially.
<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Cal=
ibri&quot;,&quot;sans-serif&quot;;color:#1F497D"><o:p>&nbsp;</o:p></span></p=
>
<div>
<p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Cal=
ibri&quot;,&quot;sans-serif&quot;;color:#1F497D">Yours Irrespectively,<o:p><=
/o:p></span></p>
<p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Cal=
ibri&quot;,&quot;sans-serif&quot;;color:#1F497D"><o:p>&nbsp;</o:p></span></p=
>
<p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Cal=
ibri&quot;,&quot;sans-serif&quot;;color:#1F497D">John<o:p></o:p></span></p>
</div>
<p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Cal=
ibri&quot;,&quot;sans-serif&quot;;color:#1F497D"><o:p>&nbsp;</o:p></span></p=
>
<div style=3D"border:none;border-left:solid blue 1.5pt;padding:0in 0in 0in 4=
.0pt">
<div>
<div style=3D"border:none;border-top:solid #E1E1E1 1.0pt;padding:3.0pt 0in 0=
in 0in">
<p class=3D"MsoNormal"><b><span style=3D"font-size:11.0pt;font-family:&quot;=
Calibri&quot;,&quot;sans-serif&quot;;color:windowtext">From:</span></b><span=
 style=3D"font-size:11.0pt;font-family:&quot;Calibri&quot;,&quot;sans-serif&=
quot;;color:windowtext"> <a href=3D"mailto:[email-masked]">status-b=
[email-masked]</a> [<a href=3D"mailto:[email-masked]">mailto:statu=
[email-masked]</a>]
<b>On Behalf Of </b>AshwoodsmithPeter<br>
<b>Sent:</b> Wednesday, September 04, 2013 7:01 AM<br>
<b>To:</b> <a href=3D"mailto:[email-masked]">[email-masked]</a><br>
<b>Subject:</b> Re: [Status] Summary of STATUS BOF and the next steps<o:p></=
o:p></span></p>
</div>
</div>
<p class=3D"MsoNormal"><o:p>&nbsp;</o:p></p>
<p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Cal=
ibri&quot;,&quot;sans-serif&quot;;color:#1F497D">I would like us to have the=
 door open to changes in the data plane
<b>in the future</b>.<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Cal=
ibri&quot;,&quot;sans-serif&quot;;color:#1F497D"><o:p>&nbsp;</o:p></span></p=
>
<p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Cal=
ibri&quot;,&quot;sans-serif&quot;;color:#1F497D">The text as written pretty m=
uch closes that door.<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Cal=
ibri&quot;,&quot;sans-serif&quot;;color:#1F497D"><o:p>&nbsp;</o:p></span></p=
>
<p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Cal=
ibri&quot;,&quot;sans-serif&quot;;color:#1F497D">Naturally it makes sense to=
 focus on what current hardware can do, but we need to be forward looking an=
d to make recommendations on what changes would be useful
 in the future.<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Cal=
ibri&quot;,&quot;sans-serif&quot;;color:#1F497D"><o:p>&nbsp;</o:p></span></p=
>
<p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Cal=
ibri&quot;,&quot;sans-serif&quot;;color:#1F497D">Peter<o:p></o:p></span></p>=

<p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Cal=
ibri&quot;,&quot;sans-serif&quot;;color:#1F497D"><o:p>&nbsp;</o:p></span></p=
>
<div>
<div style=3D"border:none;border-top:solid #B5C4DF 1.0pt;padding:3.0pt 0in 0=
in 0in">
<p class=3D"MsoNormal"><b><span style=3D"font-size:10.0pt;font-family:&quot;=
Tahoma&quot;,&quot;sans-serif&quot;;color:windowtext">From:</span></b><span s=
tyle=3D"font-size:10.0pt;font-family:&quot;Tahoma&quot;,&quot;sans-serif&quo=
t;;color:windowtext">
<a href=3D"mailto:[email-masked]">[email-masked]</a> [<a h=
ref=3D"mailto:[email-masked]">mailto:[email-masked]</a>]
<b>On Behalf Of </b>Stewart Bryant<br>
<b>Sent:</b> Wednesday, September 04, 2013 6:25 AM<br>
<b>To:</b> Mach Chen<br>
<b>Cc:</b> John E Drake; Mark Townsley; Victor Kuarsingh; Roberta Maglione (=
robmgl); John G. Scudder; Adrian Farrel; Alvaro Retana (aretana);
<a href=3D"mailto:[email-masked]">[email-masked]</a><br>
<b>Subject:</b> Re: [Status] Summary of STATUS BOF and the next steps<o:p></=
o:p></span></p>
</div>
</div>
<p class=3D"MsoNormal"><o:p>&nbsp;</o:p></p>
<p class=3D"MsoNormal" style=3D"margin-bottom:12.0pt"><br>
May I suggest that we use the name "SR" and worry<br>
about what it binds to later.<br>
<br>
The higher priority item is the charter text. Does<br>
anyone have any comments on the text proposed<br>
so far, or the text in the BOF proposal:<br>
<br>
<br>
The Stacked Tunnels for Source Routing (STATUS) Working Group <br>
is chartered to develop a framework and use cases for source-routed <br>
flows in packet switched networks.<br>
<br>
IP previously had a source-based routing mechanism made <br>
available through an IP Option. This mechanism has, however, <br>
not been widely used and has a number of issues that make its <br>
use inadvisable, and other mechanisms (such as RFC 1940) <br>
do not appear to have been implemented at all.<br>
<br>
The ability of a router to influence or control the forwarding <br>
path of an individual packet or all the packets of a given <br>
Forwarding Equivalence Class (FEC) is a desirable feature <br>
for a number of reasons including Label Switched Path stitching, <br>
egress protection, explicit routing, egress ASBR link selection, <br>
and backup (bypass tunnels, Remote Loop-Free Alternates) <br>
routing. This can be achieved by facilitating source-initiated <br>
selection of routes to complement the route selection <br>
provided by existing routing protocols for both inter- domain <br>
and intra-domain routes.<br>
<br>
Historically, distribution of MPLS label binding information <br>
was done by relying on label distribution protocols <br>
such as LDP and RSVP-TE.<br>
<br>
The use cases documented by the working group will <br>
indicate the network function that is being facilitated <br>
and indicate which packet data plane is to be used.<br>
<br>
The framework developed by the working group will <br>
consider forwarding of IPv4, IPv6, and MPLS using the <br>
existing unicast data planes. Multicast forwarding will <br>
be for future study and the choice of data planes will <br>
be limited to those for which use cases exist. A key <br>
objective of the work will be to ensure that source-<br>
routed packets can be handled seamlessly by existing <br>
deployed equipment. A major objective will be that the <br>
new function does not modify existing data plane behavior <br>
or architectures, and that it can be enabled through only <br>
control and management plane software upgrades at <br>
deployed devices.<br>
<br>
Once the working group has established a framework <br>
and there is demonstrable consensus for use cases, <br>
the working group will move forward to specify protocol <br>
solutions for installing forwarding information through <br>
the use of the IGPs (OSPF and IS-IS), or through the <br>
management plane. In the course of developing protocol <br>
extensions, the working group will work closely with <br>
other IETF working groups responsible for the protocols <br>
being modified (such as OSPF, ISIS, and I2RS).<br>
<br>
&nbsp;&nbsp;&nbsp; The working group is chartered for the following work ite=
ms:<br>
<br>
&nbsp;&nbsp;&nbsp; A framework for the use of the existing MPLS data plane t=
o <br>
&nbsp;&nbsp;&nbsp; support tunnel-based unicast source routing. <br>
<br>
&nbsp;&nbsp;&nbsp; Develop use cases for tunnel-based unicast source routing=
 <br>
&nbsp;&nbsp;&nbsp; that demonstrate the need and support for solutions. Care=
 <br>
&nbsp;&nbsp;&nbsp; should be taken to avoid clustering use cases that might s=
eem<br>
&nbsp; &nbsp; to imply support for multiple use cases when only some of the <=
br>
&nbsp;&nbsp;&nbsp; cluster actually have wide-scale support. <br>
<br>
&nbsp;&nbsp;&nbsp; Develop ISIS and OSPF protocol extensions necessary for <=
br>
&nbsp;&nbsp; distribution of MPLS forwarding information. <br>
<br>
&nbsp;&nbsp;&nbsp; The working group will consider management (including&nbs=
p; <br>
&nbsp;&nbsp;&nbsp; configuration, reporting, diagnostics, and OAM) and secur=
ity <br>
&nbsp;&nbsp;&nbsp; implications of its work and document them in separate <b=
r>
&nbsp;&nbsp;&nbsp; documents as appropriate. <br>
<br>
&nbsp;&nbsp;&nbsp; The working group is not chartered to make any changes to=
 <br>
&nbsp;&nbsp;&nbsp; the MPLS or IPv6 data planes. Any proposed changes to the=
 <br>
&nbsp;&nbsp;&nbsp; data planes are to be specified in the working groups res=
ponsible <br>
&nbsp;&nbsp;&nbsp; for the data planes (that is, the MPLS and 6MAN working g=
roups,&nbsp; <br>
&nbsp;&nbsp;&nbsp; respectively).<br>
<br>
- Stewart<o:p></o:p></p>
</div>
</div>

</div></blockquote><blockquote type=3D"cite" style=3D"-webkit-text-size-adju=
st: auto; "><div><span>_______________________________________________</span=
><br><span>status mailing list</span><br><span><a href=3D"mailto:status@ietf=
.org">[email-masked]</a></span><br><span><a href=3D"https://www.ietf.org/ma=
ilman/listinfo/status">https://www.ietf.org/mailman/listinfo/status</a></spa=
n><br></div></blockquote></body></html>=

--Apple-Mail-166B02E9-174A-413E-A62C-7A0E832E66CD--

Sender: [email-masked]
Date: Wed, 4 Sep 2013 07:40:40 -0700
From: Anoop Ghanwani <[email-masked]>
To: Mark Townsley <[email-masked]>
Cc: "[email-masked]" <[email-masked]>
Subject: Re: [Status] Summary of STATUS BOF and the next steps

--001a11c227ee21a7a204e58fca05
Content-Type: text/plain; charset=ISO-8859-1

On Wed, Sep 4, 2013 at 7:18 AM, Mark Townsley <[email-masked]> wrote:

>
> On Sep 4, 2013, at 3:26 PM, Anoop Ghanwani wrote:
>
> Some folks use BGP to perform the function of an IGP.  It looks like the
> proposed charter would exclude them from taking advantage of this
> technology.  It might be worthwhile adding BGP to that list of protocols to
> be enhanced for this.
>
>
> I agree that the statement "Develop ISIS and OSPF protocol extensions
> necessary for distribution of MPLS forwarding information." needs work, for
> two reasons. First, the extensions may not be strictly MPLS if the goal is
> to make this work for MPLS and IPv6. Second, I think it would be better for
> the ISIS and OSPF WGs to advance their own protocol extensions, rather than
> including that within the charter of SR as a deliverable. BGP, or any other
> routing protocol, could then adopt SR based on its own level of interest in
> that WG to do so. Would that suffice?
>

Yes, I think that would be reasonable.

Anoop

--001a11c227ee21a7a204e58fca05
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><br><div class=3D"gmail_extra"><br><br><div class=3D"gmail=
_quote">On Wed, Sep 4, 2013 at 7:18 AM, Mark Townsley <span dir=3D"ltr">&lt=
;<a href=3D"mailto:[email-masked]" target=3D"_blank">[email-masked]</=
a>&gt;</span> wrote:<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex"><div style=3D"word-wrap:break-word"><br><div=
><div class=3D"im"><div>On Sep 4, 2013, at 3:26 PM, Anoop Ghanwani wrote:</=
div>
<br><blockquote type=3D"cite"><div dir=3D"ltr">Some folks use BGP to perfor=
m the function of an IGP. =A0It looks like the proposed charter would exclu=
de them from taking advantage of this technology. =A0It might be worthwhile=
 adding BGP to that list of protocols to be enhanced for this.<br>
</div></blockquote><div><br></div></div><div>I agree that the statement &qu=
ot;Develop ISIS and OSPF protocol extensions necessary for distribution of =
MPLS forwarding information.&quot; needs work, for two reasons. First, the =
extensions may not be strictly MPLS if the goal is to make this work for MP=
LS and IPv6. Second, I think it would=A0be better for the ISIS and OSPF WGs=
 to advance their own protocol extensions, rather than including that withi=
n the charter of SR as a deliverable. BGP, or any other routing protocol, c=
ould then adopt SR based on its own level of interest in that WG to do so. =
Would that suffice?</div>
</div></div></blockquote><div><br></div><div>Yes, I think that would be rea=
sonable.</div><div><br></div><div>Anoop=A0</div></div></div></div>

--001a11c227ee21a7a204e58fca05--

From: John E Drake <[email-masked]>
To: AshwoodsmithPeter <[email-masked]>, "[email-masked]" <[email-masked]>
Date: Wed, 4 Sep 2013 14:26:28 +0000
Accept-Language: en-US
Subject: Re: [Status] Summary of STATUS BOF and the next steps

--_000_6831c7c2579c42bfb63573e464cf66ccBY2PR05MB142namprd05pro_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

Peter,

The group's charter can always be amended in the future, but I don't think =
it's good to declare open season on the MPLS data plane initially.

Yours Irrespectively,

John

From: [email-masked] [mailto:[email-masked]] On Behalf Of=
 AshwoodsmithPeter
Sent: Wednesday, September 04, 2013 7:01 AM
To: [email-masked]
Subject: Re: [Status] Summary of STATUS BOF and the next steps

I would like us to have the door open to changes in the data plane in the f=
uture.

The text as written pretty much closes that door.

Naturally it makes sense to focus on what current hardware can do, but we n=
eed to be forward looking and to make recommendations on what changes would=
 be useful in the future.

Peter

From: [email-masked]<mailto:[email-masked]> [mailto:statu=
[email-masked]] On Behalf Of Stewart Bryant
Sent: Wednesday, September 04, 2013 6:25 AM
To: Mach Chen
Cc: John E Drake; Mark Townsley; Victor Kuarsingh; Roberta Maglione (robmgl=
); John G. Scudder; Adrian Farrel; Alvaro Retana (aretana); [email-masked]=
<mailto:[email-masked]>
Subject: Re: [Status] Summary of STATUS BOF and the next steps

May I suggest that we use the name "SR" and worry
about what it binds to later.

The higher priority item is the charter text. Does
anyone have any comments on the text proposed
so far, or the text in the BOF proposal:

The Stacked Tunnels for Source Routing (STATUS) Working Group
is chartered to develop a framework and use cases for source-routed
flows in packet switched networks.

IP previously had a source-based routing mechanism made
available through an IP Option. This mechanism has, however,
not been widely used and has a number of issues that make its
use inadvisable, and other mechanisms (such as RFC 1940)
do not appear to have been implemented at all.

The ability of a router to influence or control the forwarding
path of an individual packet or all the packets of a given
Forwarding Equivalence Class (FEC) is a desirable feature
for a number of reasons including Label Switched Path stitching,
egress protection, explicit routing, egress ASBR link selection,
and backup (bypass tunnels, Remote Loop-Free Alternates)
routing. This can be achieved by facilitating source-initiated
selection of routes to complement the route selection
provided by existing routing protocols for both inter- domain
and intra-domain routes.

Historically, distribution of MPLS label binding information
was done by relying on label distribution protocols
such as LDP and RSVP-TE.

The use cases documented by the working group will
indicate the network function that is being facilitated
and indicate which packet data plane is to be used.

The framework developed by the working group will
consider forwarding of IPv4, IPv6, and MPLS using the
existing unicast data planes. Multicast forwarding will
be for future study and the choice of data planes will
be limited to those for which use cases exist. A key
objective of the work will be to ensure that source-
routed packets can be handled seamlessly by existing
deployed equipment. A major objective will be that the
new function does not modify existing data plane behavior
or architectures, and that it can be enabled through only
control and management plane software upgrades at
deployed devices.

Once the working group has established a framework
and there is demonstrable consensus for use cases,
the working group will move forward to specify protocol
solutions for installing forwarding information through
the use of the IGPs (OSPF and IS-IS), or through the
management plane. In the course of developing protocol
extensions, the working group will work closely with
other IETF working groups responsible for the protocols
being modified (such as OSPF, ISIS, and I2RS).

    The working group is chartered for the following work items:

    A framework for the use of the existing MPLS data plane to
    support tunnel-based unicast source routing.

    Develop use cases for tunnel-based unicast source routing
    that demonstrate the need and support for solutions. Care
    should be taken to avoid clustering use cases that might seem
    to imply support for multiple use cases when only some of the
    cluster actually have wide-scale support.

    Develop ISIS and OSPF protocol extensions necessary for
   distribution of MPLS forwarding information.

    The working group will consider management (including
    configuration, reporting, diagnostics, and OAM) and security
    implications of its work and document them in separate
    documents as appropriate.

    The working group is not chartered to make any changes to
    the MPLS or IPv6 data planes. Any proposed changes to the
    data planes are to be specified in the working groups responsible
    for the data planes (that is, the MPLS and 6MAN working groups,
    respectively).

- Stewart

--_000_6831c7c2579c42bfb63573e464cf66ccBY2PR05MB142namprd05pro_
Content-Type: text/html; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

<html xmlns:v=3D"urn:schemas-microsoft-com:vml" xmlns:o=3D"urn:schemas-micr=
osoft-com:office:office" xmlns:w=3D"urn:schemas-microsoft-com:office:word" =
xmlns:m=3D"http://schemas.microsoft.com/office/2004/12/omml" xmlns=3D"http:=
//www.w3.org/TR/REC-html40">
<head>
<meta http-equiv=3D"Content-Type" content=3D"text/html; charset=3Dus-ascii"=
>
<meta name=3D"Generator" content=3D"Microsoft Word 15 (filtered medium)">
<style><!--
/* Font Definitions */
@font-face
	{font-family:"Cambria Math";
	panose-1:2 4 5 3 5 4 6 3 2 4;}
@font-face
	{font-family:Calibri;
	panose-1:2 15 5 2 2 2 4 3 2 4;}
@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","serif";
	color:black;}
a:link, span.MsoHyperlink
	{mso-style-priority:99;
	color:blue;
	text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
	{mso-style-priority:99;
	color:purple;
	text-decoration:underline;}
span.EmailStyle17
	{mso-style-type:personal;
	font-family:"Calibri","sans-serif";
	color:#1F497D;}
span.EmailStyle18
	{mso-style-type:personal-reply;
	font-family:"Calibri","sans-serif";
	color:#1F497D;}
.MsoChpDefault
	{mso-style-type:export-only;
	font-size:10.0pt;}
@page WordSection1
	{size:8.5in 11.0in;
	margin:1.0in 1.0in 1.0in 1.0in;}
div.WordSection1
	{page:WordSection1;}
--></style><!--[if gte mso 9]><xml>
<o:shapedefaults v:ext=3D"edit" spidmax=3D"1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
<o:shapelayout v:ext=3D"edit">
<o:idmap v:ext=3D"edit" data=3D"1" />
</o:shapelayout></xml><![endif]-->
</head>
<body bgcolor=3D"white" lang=3D"EN-US" link=3D"blue" vlink=3D"purple">
<div class=3D"WordSection1">
<p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=
libri&quot;,&quot;sans-serif&quot;;color:#1F497D">Peter,<o:p></o:p></span><=
/p>
<p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=
libri&quot;,&quot;sans-serif&quot;;color:#1F497D"><o:p>&nbsp;</o:p></span><=
/p>
<p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=
libri&quot;,&quot;sans-serif&quot;;color:#1F497D">The group&#8217;s charter=
 can always be amended in the future, but I don&#8217;t think it&#8217;s go=
od to declare open season on the MPLS data plane initially.
<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=
libri&quot;,&quot;sans-serif&quot;;color:#1F497D"><o:p>&nbsp;</o:p></span><=
/p>
<div>
<p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=
libri&quot;,&quot;sans-serif&quot;;color:#1F497D">Yours Irrespectively,<o:p=
></o:p></span></p>
<p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=
libri&quot;,&quot;sans-serif&quot;;color:#1F497D"><o:p>&nbsp;</o:p></span><=
/p>
<p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=
libri&quot;,&quot;sans-serif&quot;;color:#1F497D">John<o:p></o:p></span></p=
>
</div>
<p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=
libri&quot;,&quot;sans-serif&quot;;color:#1F497D"><o:p>&nbsp;</o:p></span><=
/p>
<div style=3D"border:none;border-left:solid blue 1.5pt;padding:0in 0in 0in =
4.0pt">
<div>
<div style=3D"border:none;border-top:solid #E1E1E1 1.0pt;padding:3.0pt 0in =
0in 0in">
<p class=3D"MsoNormal"><b><span style=3D"font-size:11.0pt;font-family:&quot=
;Calibri&quot;,&quot;sans-serif&quot;;color:windowtext">From:</span></b><sp=
an style=3D"font-size:11.0pt;font-family:&quot;Calibri&quot;,&quot;sans-ser=
if&quot;;color:windowtext"> [email-masked] [mailto:status-bounces@=
ietf.org]
<b>On Behalf Of </b>AshwoodsmithPeter<br>
<b>Sent:</b> Wednesday, September 04, 2013 7:01 AM<br>
<b>To:</b> [email-masked]<br>
<b>Subject:</b> Re: [Status] Summary of STATUS BOF and the next steps<o:p><=
/o:p></span></p>
</div>
</div>
<p class=3D"MsoNormal"><o:p>&nbsp;</o:p></p>
<p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=
libri&quot;,&quot;sans-serif&quot;;color:#1F497D">I would like us to have t=
he door open to changes in the data plane
<b>in the future</b>.<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=
libri&quot;,&quot;sans-serif&quot;;color:#1F497D"><o:p>&nbsp;</o:p></span><=
/p>
<p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=
libri&quot;,&quot;sans-serif&quot;;color:#1F497D">The text as written prett=
y much closes that door.<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=
libri&quot;,&quot;sans-serif&quot;;color:#1F497D"><o:p>&nbsp;</o:p></span><=
/p>
<p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=
libri&quot;,&quot;sans-serif&quot;;color:#1F497D">Naturally it makes sense =
to focus on what current hardware can do, but we need to be forward looking=
 and to make recommendations on what changes would be useful
 in the future.<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=
libri&quot;,&quot;sans-serif&quot;;color:#1F497D"><o:p>&nbsp;</o:p></span><=
/p>
<p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=
libri&quot;,&quot;sans-serif&quot;;color:#1F497D">Peter<o:p></o:p></span></=
p>
<p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=
libri&quot;,&quot;sans-serif&quot;;color:#1F497D"><o:p>&nbsp;</o:p></span><=
/p>
<div>
<div style=3D"border:none;border-top:solid #B5C4DF 1.0pt;padding:3.0pt 0in =
0in 0in">
<p class=3D"MsoNormal"><b><span style=3D"font-size:10.0pt;font-family:&quot=
;Tahoma&quot;,&quot;sans-serif&quot;;color:windowtext">From:</span></b><spa=
n style=3D"font-size:10.0pt;font-family:&quot;Tahoma&quot;,&quot;sans-serif=
&quot;;color:windowtext">
<a href=3D"mailto:[email-masked]">[email-masked]</a> [<a =
href=3D"mailto:[email-masked]">mailto:[email-masked]</a>]
<b>On Behalf Of </b>Stewart Bryant<br>
<b>Sent:</b> Wednesday, September 04, 2013 6:25 AM<br>
<b>To:</b> Mach Chen<br>
<b>Cc:</b> John E Drake; Mark Townsley; Victor Kuarsingh; Roberta Maglione =
(robmgl); John G. Scudder; Adrian Farrel; Alvaro Retana (aretana);
<a href=3D"mailto:[email-masked]">[email-masked]</a><br>
<b>Subject:</b> Re: [Status] Summary of STATUS BOF and the next steps<o:p><=
/o:p></span></p>
</div>
</div>
<p class=3D"MsoNormal"><o:p>&nbsp;</o:p></p>
<p class=3D"MsoNormal" style=3D"margin-bottom:12.0pt"><br>
May I suggest that we use the name &quot;SR&quot; and worry<br>
about what it binds to later.<br>
<br>
The higher priority item is the charter text. Does<br>
anyone have any comments on the text proposed<br>
so far, or the text in the BOF proposal:<br>
<br>
<br>
The Stacked Tunnels for Source Routing (STATUS) Working Group <br>
is chartered to develop a framework and use cases for source-routed <br>
flows in packet switched networks.<br>
<br>
IP previously had a source-based routing mechanism made <br>
available through an IP Option. This mechanism has, however, <br>
not been widely used and has a number of issues that make its <br>
use inadvisable, and other mechanisms (such as RFC 1940) <br>
do not appear to have been implemented at all.<br>
<br>
The ability of a router to influence or control the forwarding <br>
path of an individual packet or all the packets of a given <br>
Forwarding Equivalence Class (FEC) is a desirable feature <br>
for a number of reasons including Label Switched Path stitching, <br>
egress protection, explicit routing, egress ASBR link selection, <br>
and backup (bypass tunnels, Remote Loop-Free Alternates) <br>
routing. This can be achieved by facilitating source-initiated <br>
selection of routes to complement the route selection <br>
provided by existing routing protocols for both inter- domain <br>
and intra-domain routes.<br>
<br>
Historically, distribution of MPLS label binding information <br>
was done by relying on label distribution protocols <br>
such as LDP and RSVP-TE.<br>
<br>
The use cases documented by the working group will <br>
indicate the network function that is being facilitated <br>
and indicate which packet data plane is to be used.<br>
<br>
The framework developed by the working group will <br>
consider forwarding of IPv4, IPv6, and MPLS using the <br>
existing unicast data planes. Multicast forwarding will <br>
be for future study and the choice of data planes will <br>
be limited to those for which use cases exist. A key <br>
objective of the work will be to ensure that source-<br>
routed packets can be handled seamlessly by existing <br>
deployed equipment. A major objective will be that the <br>
new function does not modify existing data plane behavior <br>
or architectures, and that it can be enabled through only <br>
control and management plane software upgrades at <br>
deployed devices.<br>
<br>
Once the working group has established a framework <br>
and there is demonstrable consensus for use cases, <br>
the working group will move forward to specify protocol <br>
solutions for installing forwarding information through <br>
the use of the IGPs (OSPF and IS-IS), or through the <br>
management plane. In the course of developing protocol <br>
extensions, the working group will work closely with <br>
other IETF working groups responsible for the protocols <br>
being modified (such as OSPF, ISIS, and I2RS).<br>
<br>
&nbsp;&nbsp;&nbsp; The working group is chartered for the following work it=
ems:<br>
<br>
&nbsp;&nbsp;&nbsp; A framework for the use of the existing MPLS data plane =
to <br>
&nbsp;&nbsp;&nbsp; support tunnel-based unicast source routing. <br>
<br>
&nbsp;&nbsp;&nbsp; Develop use cases for tunnel-based unicast source routin=
g <br>
&nbsp;&nbsp;&nbsp; that demonstrate the need and support for solutions. Car=
e <br>
&nbsp;&nbsp;&nbsp; should be taken to avoid clustering use cases that might=
 seem<br>
&nbsp; &nbsp; to imply support for multiple use cases when only some of the=
 <br>
&nbsp;&nbsp;&nbsp; cluster actually have wide-scale support. <br>
<br>
&nbsp;&nbsp;&nbsp; Develop ISIS and OSPF protocol extensions necessary for =
<br>
&nbsp;&nbsp; distribution of MPLS forwarding information. <br>
<br>
&nbsp;&nbsp;&nbsp; The working group will consider management (including&nb=
sp; <br>
&nbsp;&nbsp;&nbsp; configuration, reporting, diagnostics, and OAM) and secu=
rity <br>
&nbsp;&nbsp;&nbsp; implications of its work and document them in separate <=
br>
&nbsp;&nbsp;&nbsp; documents as appropriate. <br>
<br>
&nbsp;&nbsp;&nbsp; The working group is not chartered to make any changes t=
o <br>
&nbsp;&nbsp;&nbsp; the MPLS or IPv6 data planes. Any proposed changes to th=
e <br>
&nbsp;&nbsp;&nbsp; data planes are to be specified in the working groups re=
sponsible <br>
&nbsp;&nbsp;&nbsp; for the data planes (that is, the MPLS and 6MAN working =
groups,&nbsp; <br>
&nbsp;&nbsp;&nbsp; respectively).<br>
<br>
- Stewart<o:p></o:p></p>
</div>
</div>
</body>
</html>

--_000_6831c7c2579c42bfb63573e464cf66ccBY2PR05MB142namprd05pro_--

From: <[email-masked]>
To: <[email-masked]>
Date: Wed, 4 Sep 2013 16:21:13 +0200
Accept-Language: en-US, de-DE
acceptlanguage: en-US, de-DE
Cc: [email-masked]
Subject: Re: [Status] Summary of STATUS BOF and the next steps

--_000_CA7A7C64CC4ADB458B74477EA99DF6F501F563C27EHE111643EMEA1_
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

Peter,

no objection, if you address phase 2 of SR. So whatever is done in phase 1,=
 it should not exclude future changes to the data plane. SR Phase 1, which =
is chartered now, should exclude changes to the existing data plane. Let's =
stay focused.

Regards,

Ruediger

________________________________
From: [email-masked] [mailto:[email-masked]] On Behalf Of=
 AshwoodsmithPeter
Sent: Wednesday, September 04, 2013 4:01 PM
To: [email-masked]
Subject: Re: [Status] Summary of STATUS BOF and the next steps

I would like us to have the door open to changes in the data plane in the f=
uture.

The text as written pretty much closes that door.

Naturally it makes sense to focus on what current hardware can do, but we n=
eed to be forward looking and to make recommendations on what changes would=
 be useful in the future.

Peter

From: [email-masked] [mailto:[email-masked]] On Behalf Of=
 Stewart Bryant
Sent: Wednesday, September 04, 2013 6:25 AM
To: Mach Chen
Cc: John E Drake; Mark Townsley; Victor Kuarsingh; Roberta Maglione (robmgl=
); John G. Scudder; Adrian Farrel; Alvaro Retana (aretana); [email-masked]
Subject: Re: [Status] Summary of STATUS BOF and the next steps

May I suggest that we use the name "SR" and worry
about what it binds to later.

The higher priority item is the charter text. Does
anyone have any comments on the text proposed
so far, or the text in the BOF proposal:

The Stacked Tunnels for Source Routing (STATUS) Working Group
is chartered to develop a framework and use cases for source-routed
flows in packet switched networks.

IP previously had a source-based routing mechanism made
available through an IP Option. This mechanism has, however,
not been widely used and has a number of issues that make its
use inadvisable, and other mechanisms (such as RFC 1940)
do not appear to have been implemented at all.

The ability of a router to influence or control the forwarding
path of an individual packet or all the packets of a given
Forwarding Equivalence Class (FEC) is a desirable feature
for a number of reasons including Label Switched Path stitching,
egress protection, explicit routing, egress ASBR link selection,
and backup (bypass tunnels, Remote Loop-Free Alternates)
routing. This can be achieved by facilitating source-initiated
selection of routes to complement the route selection
provided by existing routing protocols for both inter- domain
and intra-domain routes.

Historically, distribution of MPLS label binding information
was done by relying on label distribution protocols
such as LDP and RSVP-TE.

The use cases documented by the working group will
indicate the network function that is being facilitated
and indicate which packet data plane is to be used.

The framework developed by the working group will
consider forwarding of IPv4, IPv6, and MPLS using the
existing unicast data planes. Multicast forwarding will
be for future study and the choice of data planes will
be limited to those for which use cases exist. A key
objective of the work will be to ensure that source-
routed packets can be handled seamlessly by existing
deployed equipment. A major objective will be that the
new function does not modify existing data plane behavior
or architectures, and that it can be enabled through only
control and management plane software upgrades at
deployed devices.

Once the working group has established a framework
and there is demonstrable consensus for use cases,
the working group will move forward to specify protocol
solutions for installing forwarding information through
the use of the IGPs (OSPF and IS-IS), or through the
management plane. In the course of developing protocol
extensions, the working group will work closely with
other IETF working groups responsible for the protocols
being modified (such as OSPF, ISIS, and I2RS).

    The working group is chartered for the following work items:

    A framework for the use of the existing MPLS data plane to
    support tunnel-based unicast source routing.

    Develop use cases for tunnel-based unicast source routing
    that demonstrate the need and support for solutions. Care
    should be taken to avoid clustering use cases that might seem
    to imply support for multiple use cases when only some of the
    cluster actually have wide-scale support.

    Develop ISIS and OSPF protocol extensions necessary for
   distribution of MPLS forwarding information.

    The working group will consider management (including
    configuration, reporting, diagnostics, and OAM) and security
    implications of its work and document them in separate
    documents as appropriate.

    The working group is not chartered to make any changes to
    the MPLS or IPv6 data planes. Any proposed changes to the
    data planes are to be specified in the working groups responsible
    for the data planes (that is, the MPLS and 6MAN working groups,
    respectively).

- Stewart

--_000_CA7A7C64CC4ADB458B74477EA99DF6F501F563C27EHE111643EMEA1_
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=3D"http://www.w3.org/TR/REC-html40" xmlns:v =3D=20
"urn:schemas-microsoft-com:vml" xmlns:o =3D=20
"urn:schemas-microsoft-com:office:office" xmlns:w =3D=20
"urn:schemas-microsoft-com:office:word" xmlns:m =3D=20
"http://schemas.microsoft.com/office/2004/12/omml"><HEAD>
<META content=3D"text/html; charset=3Diso-8859-1" http-equiv=3DContent-Type=
>
<META name=3DGENERATOR content=3D"MSHTML 8.00.6001.23507">
<STYLE>@font-face {
	font-family: Cambria Math;
}
@font-face {
	font-family: Calibri;
}
@font-face {
	font-family: Tahoma;
}
@page WordSection1 {size: 8.5in 11.0in; margin: 1.0in 1.0in 1.0in 1.0in; }
P.MsoNormal {
	MARGIN: 0in 0in 0pt; FONT-FAMILY: "Times New Roman","serif"; COLOR: black;=
 FONT-SIZE: 12pt
}
LI.MsoNormal {
	MARGIN: 0in 0in 0pt; FONT-FAMILY: "Times New Roman","serif"; COLOR: black;=
 FONT-SIZE: 12pt
}
DIV.MsoNormal {
	MARGIN: 0in 0in 0pt; FONT-FAMILY: "Times New Roman","serif"; COLOR: black;=
 FONT-SIZE: 12pt
}
A:link {
	COLOR: blue; TEXT-DECORATION: underline; mso-style-priority: 99
}
SPAN.MsoHyperlink {
	COLOR: blue; TEXT-DECORATION: underline; mso-style-priority: 99
}
A:visited {
	COLOR: purple; TEXT-DECORATION: underline; mso-style-priority: 99
}
SPAN.MsoHyperlinkFollowed {
	COLOR: purple; TEXT-DECORATION: underline; mso-style-priority: 99
}
SPAN.EmailStyle17 {
	FONT-FAMILY: "Calibri","sans-serif"; COLOR: #1f497d; mso-style-type: perso=
nal-reply
}
.MsoChpDefault {
	FONT-SIZE: 10pt; mso-style-type: export-only
}
DIV.WordSection1 {
	page: WordSection1
}
</STYLE>
<!--[if gte mso 9]><xml>
<o:shapedefaults v:ext=3D"edit" spidmax=3D"1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
<o:shapelayout v:ext=3D"edit">
<o:idmap v:ext=3D"edit" data=3D"1" />
</o:shapelayout></xml><![endif]--></HEAD>
<BODY lang=3DEN-US link=3Dblue bgColor=3Dwhite vLink=3Dpurple>
<DIV dir=3Dltr align=3Dleft><FONT color=3D#0000ff size=3D2 face=3DArial><SP=
AN=20
class=3D525461714-04092013>Peter,</SPAN></FONT></DIV>
<DIV dir=3Dltr align=3Dleft><FONT color=3D#0000ff size=3D2 face=3DArial><SP=
AN=20
class=3D525461714-04092013></SPAN></FONT>&nbsp;</DIV>
<DIV dir=3Dltr align=3Dleft><FONT color=3D#0000ff size=3D2 face=3DArial><SP=
AN=20
class=3D525461714-04092013>no objection, if you address&nbsp;phase 2 of SR.=
 So=20
whatever is done in phase 1, it should not exclude future changes to the da=
ta=20
plane. SR Phase 1, which is chartered now, should exclude changes to the=20
existing data plane. Let's stay focused.</SPAN></FONT></DIV>
<DIV dir=3Dltr align=3Dleft><FONT color=3D#0000ff size=3D2 face=3DArial><SP=
AN=20
class=3D525461714-04092013></SPAN></FONT>&nbsp;</DIV>
<DIV dir=3Dltr align=3Dleft><FONT color=3D#0000ff size=3D2 face=3DArial><SP=
AN=20
class=3D525461714-04092013>Regards, </SPAN></FONT></DIV>
<DIV dir=3Dltr align=3Dleft><FONT color=3D#0000ff size=3D2 face=3DArial><SP=
AN=20
class=3D525461714-04092013></SPAN></FONT>&nbsp;</DIV>
<DIV dir=3Dltr align=3Dleft><FONT color=3D#0000ff size=3D2 face=3DArial><SP=
AN=20
class=3D525461714-04092013>Ruediger</SPAN></FONT></DIV><BR>
<DIV dir=3Dltr lang=3Dde class=3DOutlookMessageHeader align=3Dleft>
<HR tabIndex=3D-1>
<FONT size=3D2 face=3DTahoma><B>From:</B> [email-masked]=20
[mailto:[email-masked]] <B>On Behalf Of=20
</B>AshwoodsmithPeter<BR><B>Sent:</B> Wednesday, September 04, 2013 4:01=20
PM<BR><B>To:</B> [email-masked]<BR><B>Subject:</B> Re: [Status] Summary of=
=20
STATUS BOF and the next steps<BR></FONT><BR></DIV>
<DIV></DIV>
<DIV class=3DWordSection1>
<P class=3DMsoNormal><SPAN=20
style=3D"FONT-FAMILY: 'Calibri','sans-serif'; COLOR: #1f497d; FONT-SIZE: 11=
pt">I=20
would like us to have the door open to changes in the data plane <B>in the=
=20
future</B>.<o:p></o:p></SPAN></P>
<P class=3DMsoNormal><SPAN=20
style=3D"FONT-FAMILY: 'Calibri','sans-serif'; COLOR: #1f497d; FONT-SIZE: 11=
pt"><o:p>&nbsp;</o:p></SPAN></P>
<P class=3DMsoNormal><SPAN=20
style=3D"FONT-FAMILY: 'Calibri','sans-serif'; COLOR: #1f497d; FONT-SIZE: 11=
pt">The=20
text as written pretty much closes that door.<o:p></o:p></SPAN></P>
<P class=3DMsoNormal><SPAN=20
style=3D"FONT-FAMILY: 'Calibri','sans-serif'; COLOR: #1f497d; FONT-SIZE: 11=
pt"><o:p>&nbsp;</o:p></SPAN></P>
<P class=3DMsoNormal><SPAN=20
style=3D"FONT-FAMILY: 'Calibri','sans-serif'; COLOR: #1f497d; FONT-SIZE: 11=
pt">Naturally=20
it makes sense to focus on what current hardware can do, but we need to be=
=20
forward looking and to make recommendations on what changes would be useful=
 in=20
the future.<o:p></o:p></SPAN></P>
<P class=3DMsoNormal><SPAN=20
style=3D"FONT-FAMILY: 'Calibri','sans-serif'; COLOR: #1f497d; FONT-SIZE: 11=
pt"><o:p>&nbsp;</o:p></SPAN></P>
<P class=3DMsoNormal><SPAN=20
style=3D"FONT-FAMILY: 'Calibri','sans-serif'; COLOR: #1f497d; FONT-SIZE: 11=
pt">Peter<o:p></o:p></SPAN></P>
<P class=3DMsoNormal><SPAN=20
style=3D"FONT-FAMILY: 'Calibri','sans-serif'; COLOR: #1f497d; FONT-SIZE: 11=
pt"><o:p>&nbsp;</o:p></SPAN></P>
<DIV>
<DIV=20
style=3D"BORDER-BOTTOM: medium none; BORDER-LEFT: medium none; PADDING-BOTT=
OM: 0in; PADDING-LEFT: 0in; PADDING-RIGHT: 0in; BORDER-TOP: #b5c4df 1pt sol=
id; BORDER-RIGHT: medium none; PADDING-TOP: 3pt">
<P class=3DMsoNormal><B><SPAN=20
style=3D"FONT-FAMILY: 'Tahoma','sans-serif'; COLOR: windowtext; FONT-SIZE: =
10pt">From:</SPAN></B><SPAN=20
style=3D"FONT-FAMILY: 'Tahoma','sans-serif'; COLOR: windowtext; FONT-SIZE: =
10pt">=20
[email-masked] [mailto:[email-masked]] <B>On Behalf Of=20
</B>Stewart Bryant<BR><B>Sent:</B> Wednesday, September 04, 2013 6:25=20
AM<BR><B>To:</B> Mach Chen<BR><B>Cc:</B> John E Drake; Mark Townsley; Victo=
r=20
Kuarsingh; Roberta Maglione (robmgl); John G. Scudder; Adrian Farrel; Alvar=
o=20
Retana (aretana); [email-masked]<BR><B>Subject:</B> Re: [Status] Summary o=
f=20
STATUS BOF and the next steps<o:p></o:p></SPAN></P></DIV></DIV>
<P class=3DMsoNormal><o:p>&nbsp;</o:p></P>
<P style=3D"MARGIN-BOTTOM: 12pt" class=3DMsoNormal><BR>May I suggest that w=
e use the=20
name "SR" and worry<BR>about what it binds to later.<BR><BR>The higher prio=
rity=20
item is the charter text. Does<BR>anyone have any comments on the text=20
proposed<BR>so far, or the text in the BOF proposal:<BR><BR><BR>The Stacked=
=20
Tunnels for Source Routing (STATUS) Working Group <BR>is chartered to devel=
op a=20
framework and use cases for source-routed <BR>flows in packet switched=20
networks.<BR><BR>IP previously had a source-based routing mechanism made=20
<BR>available through an IP Option. This mechanism has, however, <BR>not be=
en=20
widely used and has a number of issues that make its <BR>use inadvisable, a=
nd=20
other mechanisms (such as RFC 1940) <BR>do not appear to have been implemen=
ted=20
at all.<BR><BR>The ability of a router to influence or control the forwardi=
ng=20
<BR>path of an individual packet or all the packets of a given <BR>Forwardi=
ng=20
Equivalence Class (FEC) is a desirable feature <BR>for a number of reasons=
=20
including Label Switched Path stitching, <BR>egress protection, explicit=20
routing, egress ASBR link selection, <BR>and backup (bypass tunnels, Remote=
=20
Loop-Free Alternates) <BR>routing. This can be achieved by facilitating=20
source-initiated <BR>selection of routes to complement the route selection=
=20
<BR>provided by existing routing protocols for both inter- domain <BR>and=20
intra-domain routes.<BR><BR>Historically, distribution of MPLS label bindin=
g=20
information <BR>was done by relying on label distribution protocols <BR>suc=
h as=20
LDP and RSVP-TE.<BR><BR>The use cases documented by the working group will=
=20
<BR>indicate the network function that is being facilitated <BR>and indicat=
e=20
which packet data plane is to be used.<BR><BR>The framework developed by th=
e=20
working group will <BR>consider forwarding of IPv4, IPv6, and MPLS using th=
e=20
<BR>existing unicast data planes. Multicast forwarding will <BR>be for futu=
re=20
study and the choice of data planes will <BR>be limited to those for which =
use=20
cases exist. A key <BR>objective of the work will be to ensure that=20
source-<BR>routed packets can be handled seamlessly by existing <BR>deploye=
d=20
equipment. A major objective will be that the <BR>new function does not mod=
ify=20
existing data plane behavior <BR>or architectures, and that it can be enabl=
ed=20
through only <BR>control and management plane software upgrades at <BR>depl=
oyed=20
devices.<BR><BR>Once the working group has established a framework <BR>and =
there=20
is demonstrable consensus for use cases, <BR>the working group will move fo=
rward=20
to specify protocol <BR>solutions for installing forwarding information thr=
ough=20
<BR>the use of the IGPs (OSPF and IS-IS), or through the <BR>management pla=
ne.=20
In the course of developing protocol <BR>extensions, the working group will=
 work=20
closely with <BR>other IETF working groups responsible for the protocols=20
<BR>being modified (such as OSPF, ISIS, and I2RS).<BR><BR>&nbsp;&nbsp;&nbsp=
; The=20
working group is chartered for the following work=20
items:<BR><BR>&nbsp;&nbsp;&nbsp; A framework for the use of the existing MP=
LS=20
data plane to <BR>&nbsp;&nbsp;&nbsp; support tunnel-based unicast source=20
routing. <BR><BR>&nbsp;&nbsp;&nbsp; Develop use cases for tunnel-based unic=
ast=20
source routing <BR>&nbsp;&nbsp;&nbsp; that demonstrate the need and support=
 for=20
solutions. Care <BR>&nbsp;&nbsp;&nbsp; should be taken to avoid clustering =
use=20
cases that might seem<BR>&nbsp; &nbsp; to imply support for multiple use ca=
ses=20
when only some of the <BR>&nbsp;&nbsp;&nbsp; cluster actually have wide-sca=
le=20
support. <BR><BR>&nbsp;&nbsp;&nbsp; Develop ISIS and OSPF protocol extensio=
ns=20
necessary for <BR>&nbsp;&nbsp; distribution of MPLS forwarding information.=
=20
<BR><BR>&nbsp;&nbsp;&nbsp; The working group will consider management=20
(including&nbsp; <BR>&nbsp;&nbsp;&nbsp; configuration, reporting, diagnosti=
cs,=20
and OAM) and security <BR>&nbsp;&nbsp;&nbsp; implications of its work and=20
document them in separate <BR>&nbsp;&nbsp;&nbsp; documents as appropriate.=
=20
<BR><BR>&nbsp;&nbsp;&nbsp; The working group is not chartered to make any=20
changes to <BR>&nbsp;&nbsp;&nbsp; the MPLS or IPv6 data planes. Any propose=
d=20
changes to the <BR>&nbsp;&nbsp;&nbsp; data planes are to be specified in th=
e=20
working groups responsible <BR>&nbsp;&nbsp;&nbsp; for the data planes (that=
 is,=20
the MPLS and 6MAN working groups,&nbsp; <BR>&nbsp;&nbsp;&nbsp;=20
respectively).<BR><BR>- Stewart<o:p></o:p></P></DIV></BODY></HTML>

--_000_CA7A7C64CC4ADB458B74477EA99DF6F501F563C27EHE111643EMEA1_--

From: Mark Townsley <[email-masked]>
Date: Wed, 4 Sep 2013 16:18:11 +0200
To: Anoop Ghanwani <[email-masked]>
Cc: "[email-masked]" <[email-masked]>
Subject: Re: [Status] Summary of STATUS BOF and the next steps

--Apple-Mail=_08A703D3-6D68-4939-AB7B-DD66A9A99401
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=iso-8859-1

On Sep 4, 2013, at 3:26 PM, Anoop Ghanwani wrote:

> Some folks use BGP to perform the function of an IGP.  It looks like =
the proposed charter would exclude them from taking advantage of this =
technology.  It might be worthwhile adding BGP to that list of protocols =
to be enhanced for this.

I agree that the statement "Develop ISIS and OSPF protocol extensions =
necessary for distribution of MPLS forwarding information." needs work, =
for two reasons. First, the extensions may not be strictly MPLS if the =
goal is to make this work for MPLS and IPv6. Second, I think it would be =
better for the ISIS and OSPF WGs to advance their own protocol =
extensions, rather than including that within the charter of SR as a =
deliverable. BGP, or any other routing protocol, could then adopt SR =
based on its own level of interest in that WG to do so. Would that =
suffice?

- Mark

> With respect to the text about working with existing data paths -- I =
wonder if there is some way to capture that it might not work with all =
existing implementations.  For example, the number of labels required to =
be pushed at the ingress device may prevent some existing =
implementations from taking advantage of this technology, depending on =
the size of the topology.
>=20
> Anoop
>=20
>=20
> On Wed, Sep 4, 2013 at 3:24 AM, Stewart Bryant <[email-masked]> =
wrote:
>=20
> May I suggest that we use the name "SR" and worry
> about what it binds to later.
>=20
> The higher priority item is the charter text. Does
> anyone have any comments on the text proposed
> so far, or the text in the BOF proposal:
>=20
>=20
> The Stacked Tunnels for Source Routing (STATUS) Working Group=20
> is chartered to develop a framework and use cases for source-routed=20
> flows in packet switched networks.
>=20
> IP previously had a source-based routing mechanism made=20
> available through an IP Option. This mechanism has, however,=20
> not been widely used and has a number of issues that make its=20
> use inadvisable, and other mechanisms (such as RFC 1940)=20
> do not appear to have been implemented at all.
>=20
> The ability of a router to influence or control the forwarding=20
> path of an individual packet or all the packets of a given=20
> Forwarding Equivalence Class (FEC) is a desirable feature=20
> for a number of reasons including Label Switched Path stitching,=20
> egress protection, explicit routing, egress ASBR link selection,=20
> and backup (bypass tunnels, Remote Loop-Free Alternates)=20
> routing. This can be achieved by facilitating source-initiated=20
> selection of routes to complement the route selection=20
> provided by existing routing protocols for both inter- domain=20
> and intra-domain routes.
>=20
> Historically, distribution of MPLS label binding information=20
> was done by relying on label distribution protocols=20
> such as LDP and RSVP-TE.
>=20
> The use cases documented by the working group will=20
> indicate the network function that is being facilitated=20
> and indicate which packet data plane is to be used.
>=20
> The framework developed by the working group will=20
> consider forwarding of IPv4, IPv6, and MPLS using the=20
> existing unicast data planes. Multicast forwarding will=20
> be for future study and the choice of data planes will=20
> be limited to those for which use cases exist. A key=20
> objective of the work will be to ensure that source-
> routed packets can be handled seamlessly by existing=20
> deployed equipment. A major objective will be that the=20
> new function does not modify existing data plane behavior=20
> or architectures, and that it can be enabled through only=20
> control and management plane software upgrades at=20
> deployed devices.
>=20
> Once the working group has established a framework=20
> and there is demonstrable consensus for use cases,=20
> the working group will move forward to specify protocol=20
> solutions for installing forwarding information through=20
> the use of the IGPs (OSPF and IS-IS), or through the=20
> management plane. In the course of developing protocol=20
> extensions, the working group will work closely with=20
> other IETF working groups responsible for the protocols=20
> being modified (such as OSPF, ISIS, and I2RS).
>=20
>     The working group is chartered for the following work items:
>=20
>     A framework for the use of the existing MPLS data plane to=20
>     support tunnel-based unicast source routing.=20
>=20
>     Develop use cases for tunnel-based unicast source routing=20
>     that demonstrate the need and support for solutions. Care=20
>     should be taken to avoid clustering use cases that might seem
>     to imply support for multiple use cases when only some of the=20
>     cluster actually have wide-scale support.=20
>=20
>     Develop ISIS and OSPF protocol extensions necessary for=20
>    distribution of MPLS forwarding information.=20
>=20
>     The working group will consider management (including =20
>     configuration, reporting, diagnostics, and OAM) and security=20
>     implications of its work and document them in separate=20
>     documents as appropriate.=20
>=20
>     The working group is not chartered to make any changes to=20
>     the MPLS or IPv6 data planes. Any proposed changes to the=20
>     data planes are to be specified in the working groups responsible=20=

>     for the data planes (that is, the MPLS and 6MAN working groups, =20=

>     respectively).
>=20
> - Stewart
>=20
>=20
> _______________________________________________
> status mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/status
>=20
>=20
>=20
> _______________________________________________
> status mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/status

--Apple-Mail=_08A703D3-6D68-4939-AB7B-DD66A9A99401
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=iso-8859-1

<html><head></head><body style=3D"word-wrap: break-word; =
-webkit-nbsp-mode: space; -webkit-line-break: after-white-space; =
"><br><div><div>On Sep 4, 2013, at 3:26 PM, Anoop Ghanwani =
wrote:</div><br class=3D"Apple-interchange-newline"><blockquote =
type=3D"cite"><div dir=3D"ltr">Some folks use BGP to perform the =
function of an IGP. &nbsp;It looks like the proposed charter would =
exclude them from taking advantage of this technology. &nbsp;It might be =
worthwhile adding BGP to that list of protocols to be enhanced for =
this.<br></div></blockquote><div><br></div><div>I agree that the =
statement "Develop ISIS and OSPF protocol extensions necessary for =
distribution of MPLS forwarding information." needs work, for two =
reasons. First, the extensions may not be strictly MPLS if the goal is =
to make this work for MPLS and IPv6. Second, I think it would&nbsp;be =
better for the ISIS and OSPF WGs to advance their own protocol =
extensions, rather than including that within the charter of SR as a =
deliverable. BGP, or any other routing protocol, could then adopt SR =
based on its own level of interest in that WG to do so. Would that =
suffice?</div><div><br></div><div>- Mark</div><div><br></div><blockquote =
type=3D"cite"><div dir=3D"ltr">
<div class=3D"gmail_quote"><div dir=3D"ltr"><div>With respect to the =
text about working with existing data paths -- I wonder if there is some =
way to capture that it might not work with all existing implementations. =
&nbsp;For example, the number of labels required to be pushed at the =
ingress device may prevent some existing implementations from taking =
advantage of this technology, depending on the size of the =
topology.</div></div></div></div></blockquote><blockquote =
type=3D"cite"><div dir=3D"ltr"><div class=3D"gmail_quote"><div =
dir=3D"ltr">
<span class=3D"HOEnZb"><font color=3D"#888888">
<div><div><br></div><div>Anoop</div></div></font></span><div =
class=3D"gmail_extra"><br><br><div class=3D"gmail_quote"><div><div =
class=3D"h5">On Wed, Sep 4, 2013 at 3:24 AM, Stewart Bryant <span =
dir=3D"ltr">&lt;<a href=3D"mailto:[email-masked]" =
target=3D"_blank">[email-masked]</a>&gt;</span> wrote:<br>

</div></div><blockquote class=3D"gmail_quote" style=3D"margin-top: 0px; =
margin-right: 0px; margin-bottom: 0px; margin-left: 0.8ex; =
border-left-width: 1px; border-left-color: rgb(204, 204, 204); =
border-left-style: solid; padding-left: 1ex; position: static; z-index: =
auto; "><div><div class=3D"h5">
 =20
   =20
 =20
  <div bgcolor=3D"#FFFFFF" text=3D"#000000">
    <br>
    May I suggest that we use the name "SR" and worry<br>
    about what it binds to later.<br>
    <br>
    The higher priority item is the charter text. Does<br>
    anyone have any comments on the text proposed<br>
    so far, or the text in the BOF proposal:<br>
    <br>
   =20
    <br>
    The Stacked Tunnels for Source Routing (STATUS) Working Group <br>
    is chartered to develop a framework and use cases for source-routed
    <br>
    flows in packet switched networks.<br>
    <br>
    IP previously had a source-based routing mechanism made <br>
    available through an IP Option. This mechanism has, however, <br>
    not been widely used and has a number of issues that make its <br>
    use inadvisable, and other mechanisms (such as RFC 1940) <br>
    do not appear to have been implemented at all.<br>
    <br>
    The ability of a router to influence or control the forwarding <br>
    path of an individual packet or all the packets of a given <br>
    Forwarding Equivalence Class (FEC) is a desirable feature <br>
    for a number of reasons including Label Switched Path stitching, =
<br>
    egress protection, explicit routing, egress ASBR link selection, =
<br>
    and backup (bypass tunnels, Remote Loop-Free Alternates) <br>
    routing. This can be achieved by facilitating source-initiated <br>
    selection of routes to complement the route selection <br>
    provided by existing routing protocols for both inter- domain <br>
    and intra-domain routes.<br>
    <br>
    Historically, distribution of MPLS label binding information <br>
    was done by relying on label distribution protocols <br>
    such as LDP and RSVP-TE.<br>
    <br>
    The use cases documented by the working group will <br>
    indicate the network function that is being facilitated <br>
    and indicate which packet data plane is to be used.<br>
    <br>
    The framework developed by the working group will <br>
    consider forwarding of IPv4, IPv6, and MPLS using the <br>
    existing unicast data planes. Multicast forwarding will <br>
    be for future study and the choice of data planes will <br>
    be limited to those for which use cases exist. A key <br>
    objective of the work will be to ensure that source-<br>
    routed packets can be handled seamlessly by existing <br>
    deployed equipment. A major objective will be that the <br>
    new function does not modify existing data plane behavior <br>
    or architectures, and that it can be enabled through only <br>
    control and management plane software upgrades at <br>
    deployed devices.<br>
    <br>
    Once the working group has established a framework <br>
    and there is demonstrable consensus for use cases, <br>
    the working group will move forward to specify protocol <br>
    solutions for installing forwarding information through <br>
    the use of the IGPs (OSPF and IS-IS), or through the <br>
    management plane. In the course of developing protocol <br>
    extensions, the working group will work closely with <br>
    other IETF working groups responsible for the protocols <br>
    being modified (such as OSPF, ISIS, and I2RS).<br>
    <br>
    &nbsp;&nbsp;&nbsp; The working group is chartered for the following =
work items:<br>
    <br>
    &nbsp;&nbsp;&nbsp; A framework for the use of the existing MPLS data =
plane to <br>
    &nbsp;&nbsp;&nbsp; support tunnel-based unicast source routing. <br>
    <br>
    &nbsp;&nbsp;&nbsp; Develop use cases for tunnel-based unicast source =
routing <br>
    &nbsp;&nbsp;&nbsp; that demonstrate the need and support for =
solutions. Care <br>
    &nbsp;&nbsp;&nbsp; should be taken to avoid clustering use cases =
that might seem<br>
    &nbsp; &nbsp; to imply support for multiple use cases when only some =
of the <br>
    &nbsp;&nbsp;&nbsp; cluster actually have wide-scale support. <br>
    <br>
    &nbsp;&nbsp;&nbsp; Develop ISIS and OSPF protocol extensions =
necessary for <br>
    &nbsp;&nbsp; distribution of MPLS forwarding information. <br>
    <br>
    &nbsp;&nbsp;&nbsp; The working group will consider management =
(including&nbsp; <br>
    &nbsp;&nbsp;&nbsp; configuration, reporting, diagnostics, and OAM) =
and security <br>
    &nbsp;&nbsp;&nbsp; implications of its work and document them in =
separate <br>
    &nbsp;&nbsp;&nbsp; documents as appropriate. <br>
    <br>
    &nbsp;&nbsp;&nbsp; The working group is not chartered to make any =
changes to <br>
    &nbsp;&nbsp;&nbsp; the MPLS or IPv6 data planes. Any proposed =
changes to the <br>
    &nbsp;&nbsp;&nbsp; data planes are to be specified in the working =
groups
    responsible <br>
    &nbsp;&nbsp;&nbsp; for the data planes (that is, the MPLS and 6MAN =
working groups,&nbsp;
    <br>
    &nbsp;&nbsp;&nbsp; respectively).<span><font color=3D"#888888"><br>
    <br>
    - Stewart<br>
    <br>
  </font></span></div>

<br></div></div><div =
class=3D"im">_______________________________________________<br>
status mailing list<br>
<a href=3D"mailto:[email-masked]" =
target=3D"_blank">[email-masked]</a><br>
<a href=3D"https://www.ietf.org/mailman/listinfo/status" =
target=3D"_blank">https://www.ietf.org/mailman/listinfo/status</a><br>
<br></div></blockquote></div><br></div></div>
</div><br></div>
_______________________________________________<br>status mailing =
list<br><a =
href=3D"mailto:[email-masked]">[email-masked]</a><br>https://www.ietf.or=
g/mailman/listinfo/status<br></blockquote></div><br></body></html>=

--Apple-Mail=_08A703D3-6D68-4939-AB7B-DD66A9A99401--

From: AshwoodsmithPeter <[email-masked]>
To: "[email-masked]" <[email-masked]>
Date: Wed, 4 Sep 2013 14:01:03 +0000
Accept-Language: en-US, zh-CN
Subject: Re: [Status] Summary of STATUS BOF and the next steps

--_000_7AE6A4247B044C4ABE0A5B6BF427F8E2098E5327dfweml513mbbchi_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

I would like us to have the door open to changes in the data plane in the f=
uture.

The text as written pretty much closes that door.

Naturally it makes sense to focus on what current hardware can do, but we n=
eed to be forward looking and to make recommendations on what changes would=
 be useful in the future.

Peter

From: [email-masked] [mailto:[email-masked]] On Behalf Of=
 Stewart Bryant
Sent: Wednesday, September 04, 2013 6:25 AM
To: Mach Chen
Cc: John E Drake; Mark Townsley; Victor Kuarsingh; Roberta Maglione (robmgl=
); John G. Scudder; Adrian Farrel; Alvaro Retana (aretana); [email-masked]
Subject: Re: [Status] Summary of STATUS BOF and the next steps

May I suggest that we use the name "SR" and worry
about what it binds to later.

The higher priority item is the charter text. Does
anyone have any comments on the text proposed
so far, or the text in the BOF proposal:

The Stacked Tunnels for Source Routing (STATUS) Working Group
is chartered to develop a framework and use cases for source-routed
flows in packet switched networks.

IP previously had a source-based routing mechanism made
available through an IP Option. This mechanism has, however,
not been widely used and has a number of issues that make its
use inadvisable, and other mechanisms (such as RFC 1940)
do not appear to have been implemented at all.

The ability of a router to influence or control the forwarding
path of an individual packet or all the packets of a given
Forwarding Equivalence Class (FEC) is a desirable feature
for a number of reasons including Label Switched Path stitching,
egress protection, explicit routing, egress ASBR link selection,
and backup (bypass tunnels, Remote Loop-Free Alternates)
routing. This can be achieved by facilitating source-initiated
selection of routes to complement the route selection
provided by existing routing protocols for both inter- domain
and intra-domain routes.

Historically, distribution of MPLS label binding information
was done by relying on label distribution protocols
such as LDP and RSVP-TE.

The use cases documented by the working group will
indicate the network function that is being facilitated
and indicate which packet data plane is to be used.

The framework developed by the working group will
consider forwarding of IPv4, IPv6, and MPLS using the
existing unicast data planes. Multicast forwarding will
be for future study and the choice of data planes will
be limited to those for which use cases exist. A key
objective of the work will be to ensure that source-
routed packets can be handled seamlessly by existing
deployed equipment. A major objective will be that the
new function does not modify existing data plane behavior
or architectures, and that it can be enabled through only
control and management plane software upgrades at
deployed devices.

Once the working group has established a framework
and there is demonstrable consensus for use cases,
the working group will move forward to specify protocol
solutions for installing forwarding information through
the use of the IGPs (OSPF and IS-IS), or through the
management plane. In the course of developing protocol
extensions, the working group will work closely with
other IETF working groups responsible for the protocols
being modified (such as OSPF, ISIS, and I2RS).

    The working group is chartered for the following work items:

    A framework for the use of the existing MPLS data plane to
    support tunnel-based unicast source routing.

    Develop use cases for tunnel-based unicast source routing
    that demonstrate the need and support for solutions. Care
    should be taken to avoid clustering use cases that might seem
    to imply support for multiple use cases when only some of the
    cluster actually have wide-scale support.

    Develop ISIS and OSPF protocol extensions necessary for
   distribution of MPLS forwarding information.

    The working group will consider management (including
    configuration, reporting, diagnostics, and OAM) and security
    implications of its work and document them in separate
    documents as appropriate.

    The working group is not chartered to make any changes to
    the MPLS or IPv6 data planes. Any proposed changes to the
    data planes are to be specified in the working groups responsible
    for the data planes (that is, the MPLS and 6MAN working groups,
    respectively).

- Stewart

--_000_7AE6A4247B044C4ABE0A5B6BF427F8E2098E5327dfweml513mbbchi_
Content-Type: text/html; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

<html xmlns:v=3D"urn:schemas-microsoft-com:vml" xmlns:o=3D"urn:schemas-micr=
osoft-com:office:office" xmlns:w=3D"urn:schemas-microsoft-com:office:word" =
xmlns:m=3D"http://schemas.microsoft.com/office/2004/12/omml" xmlns=3D"http:=
//www.w3.org/TR/REC-html40">
<head>
<meta http-equiv=3D"Content-Type" content=3D"text/html; charset=3Dus-ascii"=
>
<meta name=3D"Generator" content=3D"Microsoft Word 12 (filtered medium)">
<style><!--
/* Font Definitions */
@font-face
	{font-family:"Cambria Math";
	panose-1:2 4 5 3 5 4 6 3 2 4;}
@font-face
	{font-family:Calibri;
	panose-1:2 15 5 2 2 2 4 3 2 4;}
@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","serif";
	color:black;}
a:link, span.MsoHyperlink
	{mso-style-priority:99;
	color:blue;
	text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
	{mso-style-priority:99;
	color:purple;
	text-decoration:underline;}
span.EmailStyle17
	{mso-style-type:personal-reply;
	font-family:"Calibri","sans-serif";
	color:#1F497D;}
.MsoChpDefault
	{mso-style-type:export-only;
	font-size:10.0pt;}
@page WordSection1
	{size:8.5in 11.0in;
	margin:1.0in 1.0in 1.0in 1.0in;}
div.WordSection1
	{page:WordSection1;}
--></style><!--[if gte mso 9]><xml>
<o:shapedefaults v:ext=3D"edit" spidmax=3D"1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
<o:shapelayout v:ext=3D"edit">
<o:idmap v:ext=3D"edit" data=3D"1" />
</o:shapelayout></xml><![endif]-->
</head>
<body bgcolor=3D"white" lang=3D"EN-US" link=3D"blue" vlink=3D"purple">
<div class=3D"WordSection1">
<p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=
libri&quot;,&quot;sans-serif&quot;;color:#1F497D">I would like us to have t=
he door open to changes in the data plane
<b>in the future</b>.<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=
libri&quot;,&quot;sans-serif&quot;;color:#1F497D"><o:p>&nbsp;</o:p></span><=
/p>
<p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=
libri&quot;,&quot;sans-serif&quot;;color:#1F497D">The text as written prett=
y much closes that door.<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=
libri&quot;,&quot;sans-serif&quot;;color:#1F497D"><o:p>&nbsp;</o:p></span><=
/p>
<p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=
libri&quot;,&quot;sans-serif&quot;;color:#1F497D">Naturally it makes sense =
to focus on what current hardware can do, but we need to be forward looking=
 and to make recommendations on what changes would be useful
 in the future.<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=
libri&quot;,&quot;sans-serif&quot;;color:#1F497D"><o:p>&nbsp;</o:p></span><=
/p>
<p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=
libri&quot;,&quot;sans-serif&quot;;color:#1F497D">Peter<o:p></o:p></span></=
p>
<p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=
libri&quot;,&quot;sans-serif&quot;;color:#1F497D"><o:p>&nbsp;</o:p></span><=
/p>
<div>
<div style=3D"border:none;border-top:solid #B5C4DF 1.0pt;padding:3.0pt 0in =
0in 0in">
<p class=3D"MsoNormal"><b><span style=3D"font-size:10.0pt;font-family:&quot=
;Tahoma&quot;,&quot;sans-serif&quot;;color:windowtext">From:</span></b><spa=
n style=3D"font-size:10.0pt;font-family:&quot;Tahoma&quot;,&quot;sans-serif=
&quot;;color:windowtext"> [email-masked] [mailto:status-bounces@ie=
tf.org]
<b>On Behalf Of </b>Stewart Bryant<br>
<b>Sent:</b> Wednesday, September 04, 2013 6:25 AM<br>
<b>To:</b> Mach Chen<br>
<b>Cc:</b> John E Drake; Mark Townsley; Victor Kuarsingh; Roberta Maglione =
(robmgl); John G. Scudder; Adrian Farrel; Alvaro Retana (aretana); status@i=
etf.org<br>
<b>Subject:</b> Re: [Status] Summary of STATUS BOF and the next steps<o:p><=
/o:p></span></p>
</div>
</div>
<p class=3D"MsoNormal"><o:p>&nbsp;</o:p></p>
<p class=3D"MsoNormal" style=3D"margin-bottom:12.0pt"><br>
May I suggest that we use the name &quot;SR&quot; and worry<br>
about what it binds to later.<br>
<br>
The higher priority item is the charter text. Does<br>
anyone have any comments on the text proposed<br>
so far, or the text in the BOF proposal:<br>
<br>
<br>
The Stacked Tunnels for Source Routing (STATUS) Working Group <br>
is chartered to develop a framework and use cases for source-routed <br>
flows in packet switched networks.<br>
<br>
IP previously had a source-based routing mechanism made <br>
available through an IP Option. This mechanism has, however, <br>
not been widely used and has a number of issues that make its <br>
use inadvisable, and other mechanisms (such as RFC 1940) <br>
do not appear to have been implemented at all.<br>
<br>
The ability of a router to influence or control the forwarding <br>
path of an individual packet or all the packets of a given <br>
Forwarding Equivalence Class (FEC) is a desirable feature <br>
for a number of reasons including Label Switched Path stitching, <br>
egress protection, explicit routing, egress ASBR link selection, <br>
and backup (bypass tunnels, Remote Loop-Free Alternates) <br>
routing. This can be achieved by facilitating source-initiated <br>
selection of routes to complement the route selection <br>
provided by existing routing protocols for both inter- domain <br>
and intra-domain routes.<br>
<br>
Historically, distribution of MPLS label binding information <br>
was done by relying on label distribution protocols <br>
such as LDP and RSVP-TE.<br>
<br>
The use cases documented by the working group will <br>
indicate the network function that is being facilitated <br>
and indicate which packet data plane is to be used.<br>
<br>
The framework developed by the working group will <br>
consider forwarding of IPv4, IPv6, and MPLS using the <br>
existing unicast data planes. Multicast forwarding will <br>
be for future study and the choice of data planes will <br>
be limited to those for which use cases exist. A key <br>
objective of the work will be to ensure that source-<br>
routed packets can be handled seamlessly by existing <br>
deployed equipment. A major objective will be that the <br>
new function does not modify existing data plane behavior <br>
or architectures, and that it can be enabled through only <br>
control and management plane software upgrades at <br>
deployed devices.<br>
<br>
Once the working group has established a framework <br>
and there is demonstrable consensus for use cases, <br>
the working group will move forward to specify protocol <br>
solutions for installing forwarding information through <br>
the use of the IGPs (OSPF and IS-IS), or through the <br>
management plane. In the course of developing protocol <br>
extensions, the working group will work closely with <br>
other IETF working groups responsible for the protocols <br>
being modified (such as OSPF, ISIS, and I2RS).<br>
<br>
&nbsp;&nbsp;&nbsp; The working group is chartered for the following work it=
ems:<br>
<br>
&nbsp;&nbsp;&nbsp; A framework for the use of the existing MPLS data plane =
to <br>
&nbsp;&nbsp;&nbsp; support tunnel-based unicast source routing. <br>
<br>
&nbsp;&nbsp;&nbsp; Develop use cases for tunnel-based unicast source routin=
g <br>
&nbsp;&nbsp;&nbsp; that demonstrate the need and support for solutions. Car=
e <br>
&nbsp;&nbsp;&nbsp; should be taken to avoid clustering use cases that might=
 seem<br>
&nbsp; &nbsp; to imply support for multiple use cases when only some of the=
 <br>
&nbsp;&nbsp;&nbsp; cluster actually have wide-scale support. <br>
<br>
&nbsp;&nbsp;&nbsp; Develop ISIS and OSPF protocol extensions necessary for =
<br>
&nbsp;&nbsp; distribution of MPLS forwarding information. <br>
<br>
&nbsp;&nbsp;&nbsp; The working group will consider management (including&nb=
sp; <br>
&nbsp;&nbsp;&nbsp; configuration, reporting, diagnostics, and OAM) and secu=
rity <br>
&nbsp;&nbsp;&nbsp; implications of its work and document them in separate <=
br>
&nbsp;&nbsp;&nbsp; documents as appropriate. <br>
<br>
&nbsp;&nbsp;&nbsp; The working group is not chartered to make any changes t=
o <br>
&nbsp;&nbsp;&nbsp; the MPLS or IPv6 data planes. Any proposed changes to th=
e <br>
&nbsp;&nbsp;&nbsp; data planes are to be specified in the working groups re=
sponsible <br>
&nbsp;&nbsp;&nbsp; for the data planes (that is, the MPLS and 6MAN working =
groups,&nbsp; <br>
&nbsp;&nbsp;&nbsp; respectively).<br>
<br>
- Stewart<o:p></o:p></p>
</div>
</body>
</html>

--_000_7AE6A4247B044C4ABE0A5B6BF427F8E2098E5327dfweml513mbbchi_--

From: <[email-masked]>
To: Anoop Ghanwani <[email-masked]>, "[email-masked]" <[email-masked]>
Date: Wed, 4 Sep 2013 16:00:35 +0200
Accept-Language: fr-FR
acceptlanguage: fr-FR
Subject: Re: [Status] Summary of STATUS BOF and the next steps

--_000_EEE55384044474429A926C625D0FCC810963161D72PUEXCB2Fnante_
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

Some folks use BGP to perform the function of an IGP.  It looks like the pr=
oposed charter would exclude them from taking advantage of this technology.=
  It might be worthwhile adding BGP to that list of protocols to be enhance=
d for this.

[SLI] The charter must not mention any protocol. In the charter, first we m=
ust do an analysis, then see which protocols must be fixed and how. But the=
 charter must not define the solution :)

________________________________
De : [email-masked] [mailto:[email-masked]] De la part de=
 Anoop Ghanwani
Envoy=E9 : mercredi 4 septembre 2013 15:26
=C0 : [email-masked]
Objet : Re: [Status] Summary of STATUS BOF and the next steps

Some folks use BGP to perform the function of an IGP.  It looks like the pr=
oposed charter would exclude them from taking advantage of this technology.=
  It might be worthwhile adding BGP to that list of protocols to be enhance=
d for this.

With respect to the text about working with existing data paths -- I wonder=
 if there is some way to capture that it might not work with all existing i=
mplementations.  For example, the number of labels required to be pushed at=
 the ingress device may prevent some existing implementations from taking a=
dvantage of this technology, depending on the size of the topology.

Anoop

On Wed, Sep 4, 2013 at 3:24 AM, Stewart Bryant <[email-masked]<mailto:s=
[email-masked]>> wrote:

May I suggest that we use the name "SR" and worry
about what it binds to later.

The higher priority item is the charter text. Does
anyone have any comments on the text proposed
so far, or the text in the BOF proposal:

The Stacked Tunnels for Source Routing (STATUS) Working Group
is chartered to develop a framework and use cases for source-routed
flows in packet switched networks.

IP previously had a source-based routing mechanism made
available through an IP Option. This mechanism has, however,
not been widely used and has a number of issues that make its
use inadvisable, and other mechanisms (such as RFC 1940)
do not appear to have been implemented at all.

The ability of a router to influence or control the forwarding
path of an individual packet or all the packets of a given
Forwarding Equivalence Class (FEC) is a desirable feature
for a number of reasons including Label Switched Path stitching,
egress protection, explicit routing, egress ASBR link selection,
and backup (bypass tunnels, Remote Loop-Free Alternates)
routing. This can be achieved by facilitating source-initiated
selection of routes to complement the route selection
provided by existing routing protocols for both inter- domain
and intra-domain routes.

Historically, distribution of MPLS label binding information
was done by relying on label distribution protocols
such as LDP and RSVP-TE.

The use cases documented by the working group will
indicate the network function that is being facilitated
and indicate which packet data plane is to be used.

The framework developed by the working group will
consider forwarding of IPv4, IPv6, and MPLS using the
existing unicast data planes. Multicast forwarding will
be for future study and the choice of data planes will
be limited to those for which use cases exist. A key
objective of the work will be to ensure that source-
routed packets can be handled seamlessly by existing
deployed equipment. A major objective will be that the
new function does not modify existing data plane behavior
or architectures, and that it can be enabled through only
control and management plane software upgrades at
deployed devices.

Once the working group has established a framework
and there is demonstrable consensus for use cases,
the working group will move forward to specify protocol
solutions for installing forwarding information through
the use of the IGPs (OSPF and IS-IS), or through the
management plane. In the course of developing protocol
extensions, the working group will work closely with
other IETF working groups responsible for the protocols
being modified (such as OSPF, ISIS, and I2RS).

    The working group is chartered for the following work items:

    A framework for the use of the existing MPLS data plane to
    support tunnel-based unicast source routing.

    Develop use cases for tunnel-based unicast source routing
    that demonstrate the need and support for solutions. Care
    should be taken to avoid clustering use cases that might seem
    to imply support for multiple use cases when only some of the
    cluster actually have wide-scale support.

    Develop ISIS and OSPF protocol extensions necessary for
   distribution of MPLS forwarding information.

    The working group will consider management (including
    configuration, reporting, diagnostics, and OAM) and security
    implications of its work and document them in separate
    documents as appropriate.

    The working group is not chartered to make any changes to
    the MPLS or IPv6 data planes. Any proposed changes to the
    data planes are to be specified in the working groups responsible
    for the data planes (that is, the MPLS and 6MAN working groups,
    respectively).

- Stewart

_______________________________________________
status mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/status

___________________________________________________________________________=
______________________________________________

Ce message et ses pieces jointes peuvent contenir des informations confiden=
tielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu=
 ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages el=
ectroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou =
falsifie. Merci.

This message and its attachments may contain confidential or privileged inf=
ormation that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and dele=
te this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been =
modified, changed or falsified.
Thank you.

--_000_EEE55384044474429A926C625D0FCC810963161D72PUEXCB2Fnante_
Content-Type: text/html; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META http-equiv=3DContent-Type content=3D"text/html; charset=3Diso-8859-1">
<META content=3D"MSHTML 6.00.6000.21264" name=3DGENERATOR></HEAD>
<BODY>
<DIV dir=3Dltr align=3Dleft>Some folks use BGP to perform the function of a=
n IGP.=20
&nbsp;It looks like the proposed charter would exclude them from taking=20
advantage of this technology. &nbsp;It might be worthwhile adding BGP to th=
at=20
list of protocols to be enhanced for this.</DIV>
<DIV dir=3Dltr align=3Dleft>&nbsp;</DIV>
<DIV dir=3Dltr align=3Dleft><SPAN class=3D004445713-04092013><FONT face=3DA=
rial=20
size=3D2>[SLI] The charter must not mention any protocol. In the charter, f=
irst we=20
must do an analysis, then see which protocols must be fixed and how. But th=
e=20
charter must not define the solution :)</FONT></SPAN></DIV>
<DIV dir=3Dltr align=3Dleft><SPAN class=3D004445713-04092013><FONT face=3DA=
rial=20
size=3D2></FONT></SPAN>&nbsp;</DIV>
<DIV dir=3Dltr align=3Dleft><SPAN class=3D004445713-04092013><FONT face=3DA=
rial=20
size=3D2></FONT></SPAN>&nbsp;</DIV>
<DIV dir=3Dltr align=3Dleft><SPAN class=3D004445713-04092013><FONT face=3DA=
rial=20
size=3D2></FONT></SPAN>&nbsp;</DIV><BR>
<BLOCKQUOTE dir=3Dltr style=3D"MARGIN-RIGHT: 0px">
  <DIV class=3DOutlookMessageHeader lang=3Dfr dir=3Dltr align=3Dleft>
  <HR tabIndex=3D-1>
  <FONT face=3DTahoma size=3D2><B>De&nbsp;:</B> [email-masked]=20
  [mailto:[email-masked]] <B>De la part de</B> Anoop=20
  Ghanwani<BR><B>Envoy=E9&nbsp;:</B> mercredi 4 septembre 2013=20
  15:26<BR><B>=C0&nbsp;:</B> [email-masked]<BR><B>Objet&nbsp;:</B> Re: [St=
atus]=20
  Summary of STATUS BOF and the next steps<BR></FONT><BR></DIV>
  <DIV></DIV>
  <DIV dir=3Dltr>Some folks use BGP to perform the function of an IGP. &nbs=
p;It=20
  looks like the proposed charter would exclude them from taking advantage =
of=20
  this technology. &nbsp;It might be worthwhile adding BGP to that list of=
=20
  protocols to be enhanced for this.<BR>
  <DIV class=3Dgmail_quote>
  <DIV dir=3Dltr>
  <DIV><BR></DIV>
  <DIV>With respect to the text about working with existing data paths -- I=
=20
  wonder if there is some way to capture that it might not work with all=20
  existing implementations. &nbsp;For example, the number of labels require=
d to=20
  be pushed at the ingress device may prevent some existing implementations=
 from=20
  taking advantage of this technology, depending on the size of the=20
  topology.</DIV><SPAN class=3DHOEnZb><FONT color=3D#888888>
  <DIV>
  <DIV><BR></DIV>
  <DIV>Anoop</DIV></DIV></FONT></SPAN>
  <DIV class=3Dgmail_extra><BR><BR>
  <DIV class=3Dgmail_quote>
  <DIV>
  <DIV class=3Dh5>On Wed, Sep 4, 2013 at 3:24 AM, Stewart Bryant <SPAN=20
  dir=3Dltr>&lt;<A href=3D"mailto:[email-masked]"=20
  target=3D_blank>[email-masked]</A>&gt;</SPAN> wrote:<BR></DIV></DIV>
  <BLOCKQUOTE class=3Dgmail_quote=20
  style=3D"PADDING-LEFT: 1ex; MARGIN: 0px 0px 0px 0.8ex; BORDER-LEFT: #ccc =
1px solid">
    <DIV>
    <DIV class=3Dh5>
    <DIV text=3D"#000000" bgcolor=3D"#FFFFFF"><BR>May I suggest that we use=
 the name=20
    "SR" and worry<BR>about what it binds to later.<BR><BR>The higher prior=
ity=20
    item is the charter text. Does<BR>anyone have any comments on the text=
=20
    proposed<BR>so far, or the text in the BOF proposal:<BR><BR><BR>The Sta=
cked=20
    Tunnels for Source Routing (STATUS) Working Group <BR>is chartered to=
=20
    develop a framework and use cases for source-routed <BR>flows in packet=
=20
    switched networks.<BR><BR>IP previously had a source-based routing mech=
anism=20
    made <BR>available through an IP Option. This mechanism has, however,=
=20
    <BR>not been widely used and has a number of issues that make its <BR>u=
se=20
    inadvisable, and other mechanisms (such as RFC 1940) <BR>do not appear =
to=20
    have been implemented at all.<BR><BR>The ability of a router to influen=
ce or=20
    control the forwarding <BR>path of an individual packet or all the pack=
ets=20
    of a given <BR>Forwarding Equivalence Class (FEC) is a desirable featur=
e=20
    <BR>for a number of reasons including Label Switched Path stitching,=20
    <BR>egress protection, explicit routing, egress ASBR link selection, <B=
R>and=20
    backup (bypass tunnels, Remote Loop-Free Alternates) <BR>routing. This =
can=20
    be achieved by facilitating source-initiated <BR>selection of routes to=
=20
    complement the route selection <BR>provided by existing routing protoco=
ls=20
    for both inter- domain <BR>and intra-domain routes.<BR><BR>Historically=
,=20
    distribution of MPLS label binding information <BR>was done by relying =
on=20
    label distribution protocols <BR>such as LDP and RSVP-TE.<BR><BR>The us=
e=20
    cases documented by the working group will <BR>indicate the network fun=
ction=20
    that is being facilitated <BR>and indicate which packet data plane is t=
o be=20
    used.<BR><BR>The framework developed by the working group will <BR>cons=
ider=20
    forwarding of IPv4, IPv6, and MPLS using the <BR>existing unicast data=
=20
    planes. Multicast forwarding will <BR>be for future study and the choic=
e of=20
    data planes will <BR>be limited to those for which use cases exist. A k=
ey=20
    <BR>objective of the work will be to ensure that source-<BR>routed pack=
ets=20
    can be handled seamlessly by existing <BR>deployed equipment. A major=
=20
    objective will be that the <BR>new function does not modify existing da=
ta=20
    plane behavior <BR>or architectures, and that it can be enabled through=
 only=20
    <BR>control and management plane software upgrades at <BR>deployed=20
    devices.<BR><BR>Once the working group has established a framework <BR>=
and=20
    there is demonstrable consensus for use cases, <BR>the working group wi=
ll=20
    move forward to specify protocol <BR>solutions for installing forwardin=
g=20
    information through <BR>the use of the IGPs (OSPF and IS-IS), or throug=
h the=20
    <BR>management plane. In the course of developing protocol <BR>extensio=
ns,=20
    the working group will work closely with <BR>other IETF working groups=
=20
    responsible for the protocols <BR>being modified (such as OSPF, ISIS, a=
nd=20
    I2RS).<BR><BR>&nbsp;&nbsp;&nbsp; The working group is chartered for the=
=20
    following work items:<BR><BR>&nbsp;&nbsp;&nbsp; A framework for the use=
 of=20
    the existing MPLS data plane to <BR>&nbsp;&nbsp;&nbsp; support tunnel-b=
ased=20
    unicast source routing. <BR><BR>&nbsp;&nbsp;&nbsp; Develop use cases fo=
r=20
    tunnel-based unicast source routing <BR>&nbsp;&nbsp;&nbsp; that demonst=
rate=20
    the need and support for solutions. Care <BR>&nbsp;&nbsp;&nbsp; should =
be=20
    taken to avoid clustering use cases that might seem<BR>&nbsp; &nbsp; to=
=20
    imply support for multiple use cases when only some of the=20
    <BR>&nbsp;&nbsp;&nbsp; cluster actually have wide-scale support.=20
    <BR><BR>&nbsp;&nbsp;&nbsp; Develop ISIS and OSPF protocol extensions=20
    necessary for <BR>&nbsp;&nbsp; distribution of MPLS forwarding informat=
ion.=20
    <BR><BR>&nbsp;&nbsp;&nbsp; The working group will consider management=
=20
    (including&nbsp; <BR>&nbsp;&nbsp;&nbsp; configuration, reporting,=20
    diagnostics, and OAM) and security <BR>&nbsp;&nbsp;&nbsp; implications =
of=20
    its work and document them in separate <BR>&nbsp;&nbsp;&nbsp; documents=
 as=20
    appropriate. <BR><BR>&nbsp;&nbsp;&nbsp; The working group is not charte=
red=20
    to make any changes to <BR>&nbsp;&nbsp;&nbsp; the MPLS or IPv6 data pla=
nes.=20
    Any proposed changes to the <BR>&nbsp;&nbsp;&nbsp; data planes are to b=
e=20
    specified in the working groups responsible <BR>&nbsp;&nbsp;&nbsp; for =
the=20
    data planes (that is, the MPLS and 6MAN working groups,&nbsp;=20
    <BR>&nbsp;&nbsp;&nbsp; respectively).<SPAN><FONT color=3D#888888><BR><B=
R>-=20
    Stewart<BR><BR></FONT></SPAN></DIV><BR></DIV></DIV>
    <DIV class=3Dim>_______________________________________________<BR>stat=
us=20
    mailing list<BR><A href=3D"mailto:[email-masked]"=20
    target=3D_blank>[email-masked]</A><BR><A=20
    href=3D"https://www.ietf.org/mailman/listinfo/status"=20
    target=3D_blank>https://www.ietf.org/mailman/listinfo/status</A><BR><BR=
></DIV></BLOCKQUOTE></DIV><BR></DIV></DIV></DIV><BR></DIV></BLOCKQUOTE><PRE=
>__________________________________________________________________________=
_______________________________________________

Ce message et ses pieces jointes peuvent contenir des informations confiden=
tielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu=
 ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages el=
ectroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou =
falsifie. Merci.

This message and its attachments may contain confidential or privileged inf=
ormation that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and dele=
te this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been =
modified, changed or falsified.
Thank you.
</PRE></BODY></HTML>

--_000_EEE55384044474429A926C625D0FCC810963161D72PUEXCB2Fnante_--

Sender: [email-masked]
Date: Wed, 4 Sep 2013 06:26:06 -0700
From: Anoop Ghanwani <[email-masked]>
To: "[email-masked]" <[email-masked]>
Subject: Re: [Status] Summary of STATUS BOF and the next steps

--047d7b66f907737ad104e58ebfa5
Content-Type: text/plain; charset=ISO-8859-1

Some folks use BGP to perform the function of an IGP.  It looks like the
proposed charter would exclude them from taking advantage of this
technology.  It might be worthwhile adding BGP to that list of protocols to
be enhanced for this.

With respect to the text about working with existing data paths -- I wonder
if there is some way to capture that it might not work with all existing
implementations.  For example, the number of labels required to be pushed
at the ingress device may prevent some existing implementations from taking
advantage of this technology, depending on the size of the topology.

Anoop

On Wed, Sep 4, 2013 at 3:24 AM, Stewart Bryant <[email-masked]> wrote:

>
> May I suggest that we use the name "SR" and worry
> about what it binds to later.
>
> The higher priority item is the charter text. Does
> anyone have any comments on the text proposed
> so far, or the text in the BOF proposal:
>
>
> The Stacked Tunnels for Source Routing (STATUS) Working Group
> is chartered to develop a framework and use cases for source-routed
> flows in packet switched networks.
>
> IP previously had a source-based routing mechanism made
> available through an IP Option. This mechanism has, however,
> not been widely used and has a number of issues that make its
> use inadvisable, and other mechanisms (such as RFC 1940)
> do not appear to have been implemented at all.
>
> The ability of a router to influence or control the forwarding
> path of an individual packet or all the packets of a given
> Forwarding Equivalence Class (FEC) is a desirable feature
> for a number of reasons including Label Switched Path stitching,
> egress protection, explicit routing, egress ASBR link selection,
> and backup (bypass tunnels, Remote Loop-Free Alternates)
> routing. This can be achieved by facilitating source-initiated
> selection of routes to complement the route selection
> provided by existing routing protocols for both inter- domain
> and intra-domain routes.
>
> Historically, distribution of MPLS label binding information
> was done by relying on label distribution protocols
> such as LDP and RSVP-TE.
>
> The use cases documented by the working group will
> indicate the network function that is being facilitated
> and indicate which packet data plane is to be used.
>
> The framework developed by the working group will
> consider forwarding of IPv4, IPv6, and MPLS using the
> existing unicast data planes. Multicast forwarding will
> be for future study and the choice of data planes will
> be limited to those for which use cases exist. A key
> objective of the work will be to ensure that source-
> routed packets can be handled seamlessly by existing
> deployed equipment. A major objective will be that the
> new function does not modify existing data plane behavior
> or architectures, and that it can be enabled through only
> control and management plane software upgrades at
> deployed devices.
>
> Once the working group has established a framework
> and there is demonstrable consensus for use cases,
> the working group will move forward to specify protocol
> solutions for installing forwarding information through
> the use of the IGPs (OSPF and IS-IS), or through the
> management plane. In the course of developing protocol
> extensions, the working group will work closely with
> other IETF working groups responsible for the protocols
> being modified (such as OSPF, ISIS, and I2RS).
>
>     The working group is chartered for the following work items:
>
>     A framework for the use of the existing MPLS data plane to
>     support tunnel-based unicast source routing.
>
>     Develop use cases for tunnel-based unicast source routing
>     that demonstrate the need and support for solutions. Care
>     should be taken to avoid clustering use cases that might seem
>     to imply support for multiple use cases when only some of the
>     cluster actually have wide-scale support.
>
>     Develop ISIS and OSPF protocol extensions necessary for
>    distribution of MPLS forwarding information.
>
>     The working group will consider management (including
>     configuration, reporting, diagnostics, and OAM) and security
>     implications of its work and document them in separate
>     documents as appropriate.
>
>     The working group is not chartered to make any changes to
>     the MPLS or IPv6 data planes. Any proposed changes to the
>     data planes are to be specified in the working groups responsible
>     for the data planes (that is, the MPLS and 6MAN working groups,
>     respectively).
>
> - Stewart
>
>
> _______________________________________________
> status mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/status
>
>

--047d7b66f907737ad104e58ebfa5
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">Some folks use BGP to perform the function of an IGP. =A0I=
t looks like the proposed charter would exclude them from taking advantage =
of this technology. =A0It might be worthwhile adding BGP to that list of pr=
otocols to be enhanced for this.<br>
<div class=3D"gmail_quote"><div dir=3D"ltr"><div>
<br></div><div>With respect to the text about working with existing data pa=
ths -- I wonder if there is some way to capture that it might not work with=
 all existing implementations. =A0For example, the number of labels require=
d to be pushed at the ingress device may prevent some existing implementati=
ons from taking advantage of this technology, depending on the size of the =
topology.</div>
<span class=3D"HOEnZb"><font color=3D"#888888">
<div><div><br></div><div>Anoop</div></div></font></span><div class=3D"gmail=
_extra"><br><br><div class=3D"gmail_quote"><div><div class=3D"h5">On Wed, S=
ep 4, 2013 at 3:24 AM, Stewart Bryant <span dir=3D"ltr">&lt;<a href=3D"mail=
to:[email-masked]" target=3D"_blank">[email-masked]</a>&gt;</span> =
wrote:<br>

</div></div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;bo=
rder-left:1px #ccc solid;padding-left:1ex"><div><div class=3D"h5">
 =20
   =20
 =20
  <div bgcolor=3D"#FFFFFF" text=3D"#000000">
    <br>
    May I suggest that we use the name &quot;SR&quot; and worry<br>
    about what it binds to later.<br>
    <br>
    The higher priority item is the charter text. Does<br>
    anyone have any comments on the text proposed<br>
    so far, or the text in the BOF proposal:<br>
    <br>
   =20
    <br>
    The Stacked Tunnels for Source Routing (STATUS) Working Group <br>
    is chartered to develop a framework and use cases for source-routed
    <br>
    flows in packet switched networks.<br>
    <br>
    IP previously had a source-based routing mechanism made <br>
    available through an IP Option. This mechanism has, however, <br>
    not been widely used and has a number of issues that make its <br>
    use inadvisable, and other mechanisms (such as RFC 1940) <br>
    do not appear to have been implemented at all.<br>
    <br>
    The ability of a router to influence or control the forwarding <br>
    path of an individual packet or all the packets of a given <br>
    Forwarding Equivalence Class (FEC) is a desirable feature <br>
    for a number of reasons including Label Switched Path stitching, <br>
    egress protection, explicit routing, egress ASBR link selection, <br>
    and backup (bypass tunnels, Remote Loop-Free Alternates) <br>
    routing. This can be achieved by facilitating source-initiated <br>
    selection of routes to complement the route selection <br>
    provided by existing routing protocols for both inter- domain <br>
    and intra-domain routes.<br>
    <br>
    Historically, distribution of MPLS label binding information <br>
    was done by relying on label distribution protocols <br>
    such as LDP and RSVP-TE.<br>
    <br>
    The use cases documented by the working group will <br>
    indicate the network function that is being facilitated <br>
    and indicate which packet data plane is to be used.<br>
    <br>
    The framework developed by the working group will <br>
    consider forwarding of IPv4, IPv6, and MPLS using the <br>
    existing unicast data planes. Multicast forwarding will <br>
    be for future study and the choice of data planes will <br>
    be limited to those for which use cases exist. A key <br>
    objective of the work will be to ensure that source-<br>
    routed packets can be handled seamlessly by existing <br>
    deployed equipment. A major objective will be that the <br>
    new function does not modify existing data plane behavior <br>
    or architectures, and that it can be enabled through only <br>
    control and management plane software upgrades at <br>
    deployed devices.<br>
    <br>
    Once the working group has established a framework <br>
    and there is demonstrable consensus for use cases, <br>
    the working group will move forward to specify protocol <br>
    solutions for installing forwarding information through <br>
    the use of the IGPs (OSPF and IS-IS), or through the <br>
    management plane. In the course of developing protocol <br>
    extensions, the working group will work closely with <br>
    other IETF working groups responsible for the protocols <br>
    being modified (such as OSPF, ISIS, and I2RS).<br>
    <br>
    =A0=A0=A0 The working group is chartered for the following work items:<=
br>
    <br>
    =A0=A0=A0 A framework for the use of the existing MPLS data plane to <b=
r>
    =A0=A0=A0 support tunnel-based unicast source routing. <br>
    <br>
    =A0=A0=A0 Develop use cases for tunnel-based unicast source routing <br=
>
    =A0=A0=A0 that demonstrate the need and support for solutions. Care <br=
>
    =A0=A0=A0 should be taken to avoid clustering use cases that might seem=
<br>
    =A0 =A0 to imply support for multiple use cases when only some of the <=
br>
    =A0=A0=A0 cluster actually have wide-scale support. <br>
    <br>
    =A0=A0=A0 Develop ISIS and OSPF protocol extensions necessary for <br>
    =A0=A0 distribution of MPLS forwarding information. <br>
    <br>
    =A0=A0=A0 The working group will consider management (including=A0 <br>
    =A0=A0=A0 configuration, reporting, diagnostics, and OAM) and security =
<br>
    =A0=A0=A0 implications of its work and document them in separate <br>
    =A0=A0=A0 documents as appropriate. <br>
    <br>
    =A0=A0=A0 The working group is not chartered to make any changes to <br=
>
    =A0=A0=A0 the MPLS or IPv6 data planes. Any proposed changes to the <br=
>
    =A0=A0=A0 data planes are to be specified in the working groups
    responsible <br>
    =A0=A0=A0 for the data planes (that is, the MPLS and 6MAN working group=
s,=A0
    <br>
    =A0=A0=A0 respectively).<span><font color=3D"#888888"><br>
    <br>
    - Stewart<br>
    <br>
  </font></span></div>

<br></div></div><div class=3D"im">_________________________________________=
______<br>
status mailing list<br>
<a href=3D"mailto:[email-masked]" target=3D"_blank">[email-masked]</a><br=
>
<a href=3D"https://www.ietf.org/mailman/listinfo/status" target=3D"_blank">=
https://www.ietf.org/mailman/listinfo/status</a><br>
<br></div></blockquote></div><br></div></div>
</div><br></div>

--047d7b66f907737ad104e58ebfa5--

Date: Wed, 04 Sep 2013 11:24:52 +0100
From: Stewart Bryant <[email-masked]>
To: Mach Chen <[email-masked]>
Cc: John E Drake <[email-masked]>, Mark Townsley <[email-masked]>, Victor Kuarsingh <[email-masked]>, "Roberta Maglione \(robmgl\)" <[email-masked]>, "John G. Scudder" <[email-masked]>, Adrian Farrel <[email-masked]>, "Alvaro Retana \(aretana\)" <[email-masked]>, "[email-masked]" <[email-masked]>
Subject: Re: [Status] Summary of STATUS BOF and the next steps
Reply-To: [email-masked]

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

May I suggest that we use the name "SR" and worry
about what it binds to later.

The higher priority item is the charter text. Does
anyone have any comments on the text proposed
so far, or the text in the BOF proposal:

The Stacked Tunnels for Source Routing (STATUS) Working Group
is chartered to develop a framework and use cases for source-routed
flows in packet switched networks.

IP previously had a source-based routing mechanism made
available through an IP Option. This mechanism has, however,
not been widely used and has a number of issues that make its
use inadvisable, and other mechanisms (such as RFC 1940)
do not appear to have been implemented at all.

The ability of a router to influence or control the forwarding
path of an individual packet or all the packets of a given
Forwarding Equivalence Class (FEC) is a desirable feature
for a number of reasons including Label Switched Path stitching,
egress protection, explicit routing, egress ASBR link selection,
and backup (bypass tunnels, Remote Loop-Free Alternates)
routing. This can be achieved by facilitating source-initiated
selection of routes to complement the route selection
provided by existing routing protocols for both inter- domain
and intra-domain routes.

Historically, distribution of MPLS label binding information
was done by relying on label distribution protocols
such as LDP and RSVP-TE.

The use cases documented by the working group will
indicate the network function that is being facilitated
and indicate which packet data plane is to be used.

The framework developed by the working group will
consider forwarding of IPv4, IPv6, and MPLS using the
existing unicast data planes. Multicast forwarding will
be for future study and the choice of data planes will
be limited to those for which use cases exist. A key
objective of the work will be to ensure that source-
routed packets can be handled seamlessly by existing
deployed equipment. A major objective will be that the
new function does not modify existing data plane behavior
or architectures, and that it can be enabled through only
control and management plane software upgrades at
deployed devices.

Once the working group has established a framework
and there is demonstrable consensus for use cases,
the working group will move forward to specify protocol
solutions for installing forwarding information through
the use of the IGPs (OSPF and IS-IS), or through the
management plane. In the course of developing protocol
extensions, the working group will work closely with
other IETF working groups responsible for the protocols
being modified (such as OSPF, ISIS, and I2RS).

     The working group is chartered for the following work items:

     A framework for the use of the existing MPLS data plane to
     support tunnel-based unicast source routing.

     Develop use cases for tunnel-based unicast source routing
     that demonstrate the need and support for solutions. Care
     should be taken to avoid clustering use cases that might seem
     to imply support for multiple use cases when only some of the
     cluster actually have wide-scale support.

     Develop ISIS and OSPF protocol extensions necessary for
    distribution of MPLS forwarding information.

     The working group will consider management (including
     configuration, reporting, diagnostics, and OAM) and security
     implications of its work and document them in separate
     documents as appropriate.

     The working group is not chartered to make any changes to
     the MPLS or IPv6 data planes. Any proposed changes to the
     data planes are to be specified in the working groups responsible
     for the data planes (that is, the MPLS and 6MAN working groups,
     respectively).

- Stewart

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

<html>
  <head>
    <meta content="text/html; charset=ISO-8859-1"
      http-equiv="Content-Type">
  </head>
  <body bgcolor="#FFFFFF" text="#000000">
    <br>
    May I suggest that we use the name "SR" and worry<br>
    about what it binds to later.<br>
    <br>
    The higher priority item is the charter text. Does<br>
    anyone have any comments on the text proposed<br>
    so far, or the text in the BOF proposal:<br>
    <br>
    <meta http-equiv="content-type" content="text/html;
      charset=ISO-8859-1">
    <br>
    The Stacked Tunnels for Source Routing (STATUS) Working Group <br>
    is chartered to develop a framework and use cases for source-routed
    <br>
    flows in packet switched networks.<br>
    <br>
    IP previously had a source-based routing mechanism made <br>
    available through an IP Option. This mechanism has, however, <br>
    not been widely used and has a number of issues that make its <br>
    use inadvisable, and other mechanisms (such as RFC 1940) <br>
    do not appear to have been implemented at all.<br>
    <br>
    The ability of a router to influence or control the forwarding <br>
    path of an individual packet or all the packets of a given <br>
    Forwarding Equivalence Class (FEC) is a desirable feature <br>
    for a number of reasons including Label Switched Path stitching, <br>
    egress protection, explicit routing, egress ASBR link selection, <br>
    and backup (bypass tunnels, Remote Loop-Free Alternates) <br>
    routing. This can be achieved by facilitating source-initiated <br>
    selection of routes to complement the route selection <br>
    provided by existing routing protocols for both inter- domain <br>
    and intra-domain routes.<br>
    <br>
    Historically, distribution of MPLS label binding information <br>
    was done by relying on label distribution protocols <br>
    such as LDP and RSVP-TE.<br>
    <br>
    The use cases documented by the working group will <br>
    indicate the network function that is being facilitated <br>
    and indicate which packet data plane is to be used.<br>
    <br>
    The framework developed by the working group will <br>
    consider forwarding of IPv4, IPv6, and MPLS using the <br>
    existing unicast data planes. Multicast forwarding will <br>
    be for future study and the choice of data planes will <br>
    be limited to those for which use cases exist. A key <br>
    objective of the work will be to ensure that source-<br>
    routed packets can be handled seamlessly by existing <br>
    deployed equipment. A major objective will be that the <br>
    new function does not modify existing data plane behavior <br>
    or architectures, and that it can be enabled through only <br>
    control and management plane software upgrades at <br>
    deployed devices.<br>
    <br>
    Once the working group has established a framework <br>
    and there is demonstrable consensus for use cases, <br>
    the working group will move forward to specify protocol <br>
    solutions for installing forwarding information through <br>
    the use of the IGPs (OSPF and IS-IS), or through the <br>
    management plane. In the course of developing protocol <br>
    extensions, the working group will work closely with <br>
    other IETF working groups responsible for the protocols <br>
    being modified (such as OSPF, ISIS, and I2RS).<br>
    <br>
    &nbsp;&nbsp;&nbsp; The working group is chartered for the following work items:<br>
    <br>
    &nbsp;&nbsp;&nbsp; A framework for the use of the existing MPLS data plane to <br>
    &nbsp;&nbsp;&nbsp; support tunnel-based unicast source routing. <br>
    <br>
    &nbsp;&nbsp;&nbsp; Develop use cases for tunnel-based unicast source routing <br>
    &nbsp;&nbsp;&nbsp; that demonstrate the need and support for solutions. Care <br>
    &nbsp;&nbsp;&nbsp; should be taken to avoid clustering use cases that might seem<br>
    &nbsp; &nbsp; to imply support for multiple use cases when only some of the <br>
    &nbsp;&nbsp;&nbsp; cluster actually have wide-scale support. <br>
    <br>
    &nbsp;&nbsp;&nbsp; Develop ISIS and OSPF protocol extensions necessary for <br>
    &nbsp;&nbsp; distribution of MPLS forwarding information. <br>
    <br>
    &nbsp;&nbsp;&nbsp; The working group will consider management (including&nbsp; <br>
    &nbsp;&nbsp;&nbsp; configuration, reporting, diagnostics, and OAM) and security <br>
    &nbsp;&nbsp;&nbsp; implications of its work and document them in separate <br>
    &nbsp;&nbsp;&nbsp; documents as appropriate. <br>
    <br>
    &nbsp;&nbsp;&nbsp; The working group is not chartered to make any changes to <br>
    &nbsp;&nbsp;&nbsp; the MPLS or IPv6 data planes. Any proposed changes to the <br>
    &nbsp;&nbsp;&nbsp; data planes are to be specified in the working groups
    responsible <br>
    &nbsp;&nbsp;&nbsp; for the data planes (that is, the MPLS and 6MAN working groups,&nbsp;
    <br>
    &nbsp;&nbsp;&nbsp; respectively).<br>
    <br>
    - Stewart<br>
    <br>
  </body>
</html>

--------------010802000607090309080402--

From: <[email-masked]>
To: Hannes Gredler <[email-masked]>
Date: Wed, 4 Sep 2013 10:02:45 +0200
Accept-Language: fr-FR
acceptlanguage: fr-FR
Cc: "[email-masked]" <[email-masked]>
Subject: Re: [Status] Summary of STATUS BOF and the next steps

Hannes,

In case, we are using only directed forwarding (adjacency segment), could w=
e still talk about tunneling ? (it's a very very small tunnel)
Moreover talking about "stacking" is really dataplane agnostic (MPLS) ...

In the proposed segment routing architectural concepts, segments are at the=
 same "level" and pointer moves on the segment list, then the MPLS instanti=
ation is performing this using stacking ...

IMHO, if we use "Stacked Tunnels", we already talk about a chosen solution =
and it's closing the door to something else  ...

Finally, about the "routing" word, routing is essentially a "forward" actio=
n which may limit the scope of what we can do by using a segment list. Acti=
ons associated with a segment could be something else than forwarding.

Do we want in the charter to limit the scope to routing actions ?

I have no solution today to propose for the naming, but I completely agree =
with Loa, to first focus on working on the charter, and define a clear scop=
e of the work and then the name will be easier to find.

Regarding your charter proposal :

--------

- They form a connected network
        [SLI] InterAS case must be included, but the WG can go step by step=
 and first release intraAS, and then doing interAS (in relation with IDR ??=
).

- They can forward traffic through the shortest paths or paths other than t=
he shortest (the latter called explicitly routed paths, or explicit paths)
        [SLI] There is something else between SPT and Explicit path, you ca=
n define other algorithms than SPT to define a path, and it's not explicit =
path. Moreover I come back to my comment, on do we want to limit the scope =
to routing ? I would say no.

- They share a common trust model. In this model, any router within the ERD=
 can specify an explicit path between itself and any other router in the ER=
D. It can then send any packet that passes through it through any path that=
 it has specified.
        [SLI] Security considerations may have to be addressed in the chart=
er , especially for the interAS case (trust yes, but not sure access to eve=
rything may not be good)

Downstream routers within the ERD forward the packet as specified by the ro=
uter at the head-end of the path.
[SLI] Yes, but any router in the middle may be able to change the end to en=
d explicit path.

- The first goal of the STER WG is to identify use-cases for ERDs.
- Having identified use-cases, the WG will identify gaps between currently =
available technologies and use-case requirements.
- The WG will then define requirements for extensions to existing protocols=
 or new protocols that address gaps that are identified.

[SLI] Agree, I would add :
- defining the architecture framework
- analysing the security considerisations

---------

Here would be my proposal to extend yours :

A <named to be defined> domain contains a set of routers with the following=
 characteristics:

- They form a connected network
- They can forward traffic through any path within the network using shorte=
st path, non shortest path or explicit path
- They may provide other types of services than forwarding and they can enf=
orce service actions in the path.
- They share a common trust model. In this model, any router within the dom=
ain can specify a path between itself and any other router in the domain. I=
t may then send any packet that passes through it through any path that it =
has specified and that is conform to the security rules. Downstream routers=
 within the ERD forward the packet as specified by the router at the head-e=
nd of the path.

The <name> working group is chartered for the following ordered list of wor=
k items:

- The first goal of the WG is to identify use-cases.
- The WG will then define the architecture framework associated with the se=
curity considerations. The architecture framework and security consideratio=
ns must address the relations between domains (interdomain).
- Having identified use-cases, architecture and security, the WG will ident=
ify gaps between currently available technologies and use-case requirements.
- The WG will then define requirements for extensions to existing protocols=
 or new protocols that address gaps that are identified.
- The WG will first focus on the intra-domain forwarding definition.

Protocol work may be carried out in this working group or in other working =
groups responsible for the protocols, in coordination with this WG, and in =
agreement with the WG chairs and responsible ADs. However, no protocol work=
 will be adopted by a working group to address the ERD use-cases until the =
requirements document motivating the protocol work has been sent to the IES=
G for publication as an RFC.

-----Message d'origine-----
De : [email-masked] [mailto:[email-masked]] De la part de=
 Hannes Gredler
Envoy=E9 : mardi 3 septembre 2013 18:31
=C0 : Loa Andersson
Cc : [email-masked]
Objet : Re: [Status] Summary of STATUS BOF and the next steps

good point - what about this charter proposal ?

---

Stacked Tunnels for Explicit Routing (STER) =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D

A explicit routing domain (ERD) contains a set of routers with the followin=
g characteristics:

- They form a connected network
- They can forward traffic through the shortest paths or paths other than t=
he shortest (the latter called explicitly routed paths, or explicit paths)
- They share a common trust model. In this model, any router within the ERD=
 can specify an explicit path between itself and any other router in the ER=
D. It can then send any packet that passes through it through any path that=
 it has specified. Downstream routers within the ERD forward the packet as =
specified by the router at the head-end of the path.

The STER working group is chartered for the following ordered list of work =
items:

- The first goal of the STER WG is to identify use-cases for ERDs.
- Having identified use-cases, the WG will identify gaps between currently =
available technologies and use-case requirements.
- The WG will then define requirements for extensions to existing protocols=
 or new protocols that address gaps that are identified.

Protocol work may be carried out in this working group or in other working =
groups responsible for the protocols, in coordination with this WG, and in =
agreement with the WG chairs and responsible ADs. However, no protocol work=
 will be adopted by a working group to address the ERD use-cases until the =
requirements document motivating the protocol work has been sent to the IES=
G for publication as an RFC.

---

<flame suit on>

/hannes

On Sep 3, 2013, at 5:31 PM, Loa Andersson wrote:

> Folks,
>
> Excuse me if I'm slightly out of the loop, but so far I have not seen
> a charter proposal, if there is one please point me to it.
>
> It seems a bit odd to put the cart (what the wg should do) before the
> horse (wg name). If we drill down the the charter first the wg name
> might be easier to figure out.
>
> /Loa
>
> PS
> OK I understand that the horse and cart analogy limps a  bit :).
>
>
>
> On 2013-09-03 17:22, AshwoodsmithPeter wrote:
>> " If the WG charter is limited to source routing, how will we handle the=
 "non source routing" use cases of segment routing ? In another working gro=
up ? So we will go back to the WG synchronization issue that has been raise=
d for this technology ..."
>>
>> That's why I suggested SRV2. We are revisiting source routing with new c=
oncepts. More generic number/action behavior.
>>
>> Peter
>>
>> -----Original Message-----
>> From: [email-masked] [mailto:[email-masked]] On
>> Behalf Of [email-masked]
>> Sent: Tuesday, September 03, 2013 10:43 AM
>> To: AshwoodsmithPeter
>> Cc: [email-masked]
>> Subject: Re: [Status] Summary of STATUS BOF and the next steps
>>
>>
>> There was a misunderstanding in my small comment :) so I will explain mo=
re :
>>
>> In segment routing, you have more than basic source routing : segment ro=
uting is just associate a segment number to an action and then combine segm=
ent as you want, yes you can do source routing, but you also can do more.
>>
>> In the other hand, I completely agree with your statement that source
>> routing is generic and dataplane agnostic, as segment routing is ...
>> (segment routing is not a new dataplane ...)
>>
>> Now the definition of the WG naming must be inline with the charter
>> that will be defined ... (draft today)
>>
>> Based on the already existing consensus (at least for MPLS dataplane) br=
ought up during Berlin STATUS BOF meeting, segment routing sounds to be a g=
ood target candidate.
>>
>> So now, do we want to do more in the WG charter than just make progressi=
ng segment routing architecture and uses cases document and ensure coordina=
tion for the standardization of this technology ?
>>
>> Do we want to standardize other technologies in this WG ? I don't think =
so, based on Stewart's conclusion email from the BOF :"A new WG focused sol=
ely on SR therefore needs to be create"
>>
>> If the WG charter is limited to source routing, how will we handle the "=
non source routing" use cases of segment routing ? In another working group=
 ? So we will go back to the WG synchronization issue that has been raised =
for this technology ...
>>
>> If the WG is focused on SR, let's use a name in relation with SR.
>>
>> Feedback ?
>>
>>
>> Stephane
>>
>>
>> -----Message d'origine-----
>> De : AshwoodsmithPeter [mailto:[email-masked]]
>> Envoy=E9 : mardi 3 septembre 2013 15:27 =C0 : LITKOWSKI Stephane DTF/DERX
>> Cc : John E Drake; Mark Townsley; Victor Kuarsingh; Roberta Maglione
>> (robmgl); John G. Scudder; Adrian Farrel; Alvaro Retana (aretana);
>> [email-masked]; Stewart Bryant (stbryant) Objet : Re: [Status]
>> Summary of STATUS BOF and the next steps
>>
>> The term "source routing" has been around for a very long time and is da=
ta path agnostic. Its also the term used in the literature etc so my prefer=
ence is to stick with this existing well known and data path agnostic term.
>>
>> Peter
>>
>> On Sep 3, 2013, at 9:07 AM, "[email-masked]" <stephane.li=
[email-masked]> wrote:
>>
>>> Hi,
>>>
>>> "Source routing" is just a subcase of segment routing ... as it is for =
IP routing ...
>>>
>>> Stephane
>>>
>>>
>>> -----Message d'origine-----
>>> De : [email-masked] [mailto:[email-masked]] De la
>>> part de John E Drake Envoy=E9 : mardi 3 septembre 2013 15:02 =C0 : Mark
>>> Townsley; Victor Kuarsingh Cc : Roberta Maglione (robmgl); John G.
>>> Scudder; Alvaro Retana (aretana); Adrian Farrel; [email-masked];
>>> Stewart Bryant (stbryant) Objet : Re: [Status] Summary of STATUS BOF
>>> and the next steps
>>>
>>> Hi,
>>>
>>> What is this 'segment routing' silliness?  The correct term is 'source =
routing'.
>>>
>>> Yours Irrespectively,
>>>
>>> John
>>>
>>>> -----Original Message-----
>>>> From: [email-masked] [mailto:[email-masked]] On
>>>> Behalf Of Mark Townsley
>>>> Sent: Sunday, September 01, 2013 10:08 AM
>>>> To: Victor Kuarsingh
>>>> Cc: Roberta Maglione (robmgl); John G. Scudder; Adrian Farrel;
>>>> Alvaro Retana (aretana); [email-masked]; Stewart Bryant (stbryant)
>>>> Subject: Re: [Status] Summary of STATUS BOF and the next steps
>>>>
>>>>
>>>> On Sep 1, 2013, at 5:38 PM, Victor Kuarsingh wrote:
>>>>
>>>>> All,
>>>>>
>>>>> I would also favour "Segment Routing WG" as well.
>>>>>
>>>>> I note this since attempting to come up with an all encompassing
>>>>> acronym will be difficult and Segment Routing is generic enough to
>>>>> associate to multiple functions.
>>>>
>>>> Then we can just use "segroute" for the short name. WGs do not have
>>>> to have acronyms, but they do need to have an 8-char limited short
>>>> name for the various automated tools not to break.
>>>>
>>>> - Mark
>>>>
>>>>>
>>>>> Regards,
>>>>>
>>>>> Victor K
>>>>>
>>>>>
>>>>>
>>>>> On 2013-08-31 6:51 PM, "Roberta Maglione (robmgl)"
>>>>> <[email-masked]>
>>>>> wrote:
>>>>>
>>>>>> +1 for Segment Routing WG
>>>>>>
>>>>>> Roberta
>>>>>>
>>>>>> Sent from my iPad
>>>>>>
>>>>>> On 2013-08-30, at 2:55 PM, "Alvaro Retana (aretana)"
>>>>>> <[email-masked]>
>>>>>> wrote:
>>>>>>
>>>>>>> Segment Routing WG
>>>>>>>
>>>>>>> Sent from my iPhone
>>>>>>>
>>>>>>> On Aug 30, 2013, at 1:39 PM, "Stewart Bryant (stbryant)"
>>>>>>> <[email-masked]> wrote:
>>>>>>>
>>>>>>>> The second task, which hopefully should be relatively easy, is
>>>>>>>> to find a better working name for the WG, since it has been put
>>>>>>>> to me a number of times that STATUS is going to be confusing in
>>>>>>>> text and a difficult search term.
>>>>>>> _______________________________________________
>>>>>>> status mailing list
>>>>>>> [email-masked]
>>>>>>> https://www.ietf.org/mailman/listinfo/status
>>>>>> _______________________________________________
>>>>>> status mailing list
>>>>>> [email-masked]
>>>>>> https://www.ietf.org/mailman/listinfo/status
>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> status mailing list
>>>>> [email-masked]
>>>>> https://www.ietf.org/mailman/listinfo/status
>>>>
>>>> _______________________________________________
>>>> status mailing list
>>>> [email-masked]
>>>> https://www.ietf.org/mailman/listinfo/status
>>>
>>>
>>> _______________________________________________
>>> status mailing list
>>> [email-masked]
>>> https://www.ietf.org/mailman/listinfo/status
>>>
>>> ____________________________________________________________________
>>> __ ___________________________________________________
>>>
>>> Ce message et ses pieces jointes peuvent contenir des informations
>>> confidentielles ou privilegiees et ne doivent donc pas etre
>>> diffuses, exploites ou copies sans autorisation. Si vous avez recu
>>> ce message par erreur, veuillez le signaler a l'expediteur et le detrui=
re ainsi que les pieces jointes. Les messages electroniques etant susceptib=
les d'alteration, Orange decline toute responsabilite si ce message a ete a=
ltere, deforme ou falsifie. Merci.
>>>
>>> This message and its attachments may contain confidential or
>>> privileged information that may be protected by law; they should not be=
 distributed, used or copied without authorisation.
>>> If you have received this email in error, please notify the sender and =
delete this message and its attachments.
>>> As emails may be altered, Orange is not liable for messages that have b=
een modified, changed or falsified.
>>> Thank you.
>>>
>>> _______________________________________________
>>> status mailing list
>>> [email-masked]
>>> https://www.ietf.org/mailman/listinfo/status
>>
>> _____________________________________________________________________
>> ____________________________________________________
>>
>> Ce message et ses pieces jointes peuvent contenir des informations
>> confidentielles ou privilegiees et ne doivent donc pas etre diffuses,
>> exploites ou copies sans autorisation. Si vous avez recu ce message
>> par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que=
 les pieces jointes. Les messages electroniques etant susceptibles d'altera=
tion, Orange decline toute responsabilite si ce message a ete altere, defor=
me ou falsifie. Merci.
>>
>> This message and its attachments may contain confidential or
>> privileged information that may be protected by law; they should not be =
distributed, used or copied without authorisation.
>> If you have received this email in error, please notify the sender and d=
elete this message and its attachments.
>> As emails may be altered, Orange is not liable for messages that have be=
en modified, changed or falsified.
>> Thank you.
>>
>> _______________________________________________
>> status mailing list
>> [email-masked]
>> https://www.ietf.org/mailman/listinfo/status
>> _______________________________________________
>> status mailing list
>> [email-masked]
>> https://www.ietf.org/mailman/listinfo/status
>>
>
> --
>
>
> Loa Andersson                        email: [email-masked]
> Senior MPLS Expert                          [email-masked]
> Huawei Technologies (consultant)     phone: +46 739 81 21 64
> _______________________________________________
> status mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/status
>
>

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

___________________________________________________________________________=
______________________________________________

Ce message et ses pieces jointes peuvent contenir des informations confiden=
tielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu=
 ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages el=
ectroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou =
falsifie. Merci.

This message and its attachments may contain confidential or privileged inf=
ormation that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and dele=
te this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been =
modified, changed or falsified.
Thank you.

From: <[email-masked]>
To: AshwoodsmithPeter <[email-masked]>
Date: Wed, 4 Sep 2013 09:21:52 +0200
Accept-Language: fr-FR
acceptlanguage: fr-FR
Cc: "[email-masked]" <[email-masked]>
Subject: Re: [Status] Summary of STATUS BOF and the next steps

 >We are revisiting source routing with new concepts. More generic number/a=
ction behavior.

[SLI] Agree ! So I would be more in favor of a new term to prevent confusio=
n with a very well known concept today.

-----Message d'origine-----
De : AshwoodsmithPeter [mailto:[email-masked]]=20
Envoy=E9 : mardi 3 septembre 2013 17:22
=C0 : LITKOWSKI Stephane DTF/DERX
Cc : [email-masked]
Objet : RE: [Status] Summary of STATUS BOF and the next steps

" If the WG charter is limited to source routing, how will we handle the "n=
on source routing" use cases of segment routing ? In another working group =
? So we will go back to the WG synchronization issue that has been raised f=
or this technology ..."

That's why I suggested SRV2. We are revisiting source routing with new conc=
epts. More generic number/action behavior.=20

Peter

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of=
 [email-masked]
Sent: Tuesday, September 03, 2013 10:43 AM
To: AshwoodsmithPeter
Cc: [email-masked]
Subject: Re: [Status] Summary of STATUS BOF and the next steps

=20
There was a misunderstanding in my small comment :) so I will explain more :

In segment routing, you have more than basic source routing : segment routi=
ng is just associate a segment number to an action and then combine segment=
 as you want, yes you can do source routing, but you also can do more.

In the other hand, I completely agree with your statement that source routi=
ng is generic and dataplane agnostic, as segment routing is ... (segment ro=
uting is not a new dataplane ...)

Now the definition of the WG naming must be inline with the charter that wi=
ll be defined ... (draft today)
=20
Based on the already existing consensus (at least for MPLS dataplane) broug=
ht up during Berlin STATUS BOF meeting, segment routing sounds to be a good=
 target candidate.

So now, do we want to do more in the WG charter than just make progressing =
segment routing architecture and uses cases document and ensure coordinatio=
n for the standardization of this technology ?
=20
Do we want to standardize other technologies in this WG ? I don't think so,=
 based on Stewart's conclusion email from the BOF :"A new WG focused solely=
 on SR therefore needs to be create"

If the WG charter is limited to source routing, how will we handle the "non=
 source routing" use cases of segment routing ? In another working group ? =
So we will go back to the WG synchronization issue that has been raised for=
 this technology ...

If the WG is focused on SR, let's use a name in relation with SR.

Feedback ?

Stephane

-----Message d'origine-----
De : AshwoodsmithPeter [mailto:[email-masked]]
Envoy=E9 : mardi 3 septembre 2013 15:27
=C0 : LITKOWSKI Stephane DTF/DERX
Cc : John E Drake; Mark Townsley; Victor Kuarsingh; Roberta Maglione (robmg=
l); John G. Scudder; Adrian Farrel; Alvaro Retana (aretana); [email-masked]=
g; Stewart Bryant (stbryant) Objet : Re: [Status] Summary of STATUS BOF and=
 the next steps

The term "source routing" has been around for a very long time and is data =
path agnostic. Its also the term used in the literature etc so my preferenc=
e is to stick with this existing well known and data path agnostic term.

Peter

On Sep 3, 2013, at 9:07 AM, "[email-masked]" <stephane.litko=
[email-masked]> wrote:

> Hi,
>=20
> "Source routing" is just a subcase of segment routing ... as it is for IP=
 routing ...
>=20
> Stephane
>=20
>=20
> -----Message d'origine-----
> De : [email-masked] [mailto:[email-masked]] De la=20
> part de John E Drake Envoy=E9 : mardi 3 septembre 2013 15:02 =C0 : Mark=
=20
> Townsley; Victor Kuarsingh Cc : Roberta Maglione (robmgl); John G.
> Scudder; Alvaro Retana (aretana); Adrian Farrel; [email-masked];=20
> Stewart Bryant (stbryant) Objet : Re: [Status] Summary of STATUS BOF=20
> and the next steps
>=20
> Hi,
>=20
> What is this 'segment routing' silliness?  The correct term is 'source ro=
uting'.=20
>=20
> Yours Irrespectively,
>=20
> John
>=20
>> -----Original Message-----
>> From: [email-masked] [mailto:[email-masked]] On=20
>> Behalf Of Mark Townsley
>> Sent: Sunday, September 01, 2013 10:08 AM
>> To: Victor Kuarsingh
>> Cc: Roberta Maglione (robmgl); John G. Scudder; Adrian Farrel; Alvaro=20
>> Retana (aretana); [email-masked]; Stewart Bryant (stbryant)
>> Subject: Re: [Status] Summary of STATUS BOF and the next steps
>>=20
>>=20
>> On Sep 1, 2013, at 5:38 PM, Victor Kuarsingh wrote:
>>=20
>>> All,
>>>=20
>>> I would also favour "Segment Routing WG" as well.
>>>=20
>>> I note this since attempting to come up with an all encompassing=20
>>> acronym will be difficult and Segment Routing is generic enough to=20
>>> associate to multiple functions.
>>=20
>> Then we can just use "segroute" for the short name. WGs do not have=20
>> to have acronyms, but they do need to have an 8-char limited short=20
>> name for the various automated tools not to break.
>>=20
>> - Mark
>>=20
>>>=20
>>> Regards,
>>>=20
>>> Victor K
>>>=20
>>>=20
>>>=20
>>> On 2013-08-31 6:51 PM, "Roberta Maglione (robmgl)"=20
>>> <[email-masked]>
>>> wrote:
>>>=20
>>>> +1 for Segment Routing WG
>>>>=20
>>>> Roberta
>>>>=20
>>>> Sent from my iPad
>>>>=20
>>>> On 2013-08-30, at 2:55 PM, "Alvaro Retana (aretana)"
>>>> <[email-masked]>
>>>> wrote:
>>>>=20
>>>>> Segment Routing WG
>>>>>=20
>>>>> Sent from my iPhone
>>>>>=20
>>>>> On Aug 30, 2013, at 1:39 PM, "Stewart Bryant (stbryant)"
>>>>> <[email-masked]> wrote:
>>>>>=20
>>>>>> The second task, which hopefully should be relatively easy, is to=20
>>>>>> find a better working name for the WG, since it has been put to=20
>>>>>> me a number of times that STATUS is going to be confusing in text=20
>>>>>> and a difficult search term.
>>>>> _______________________________________________
>>>>> status mailing list
>>>>> [email-masked]
>>>>> https://www.ietf.org/mailman/listinfo/status
>>>> _______________________________________________
>>>> status mailing list
>>>> [email-masked]
>>>> https://www.ietf.org/mailman/listinfo/status
>>>=20
>>>=20
>>> _______________________________________________
>>> status mailing list
>>> [email-masked]
>>> https://www.ietf.org/mailman/listinfo/status
>>=20
>> _______________________________________________
>> status mailing list
>> [email-masked]
>> https://www.ietf.org/mailman/listinfo/status
>=20
>=20
> _______________________________________________
> status mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/status
>=20
> ______________________________________________________________________
> ___________________________________________________
>=20
> Ce message et ses pieces jointes peuvent contenir des informations=20
> confidentielles ou privilegiees et ne doivent donc pas etre diffuses,=20
> exploites ou copies sans autorisation. Si vous avez recu ce message=20
> par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que =
les pieces jointes. Les messages electroniques etant susceptibles d'alterat=
ion, Orange decline toute responsabilite si ce message a ete altere, deform=
e ou falsifie. Merci.
>=20
> This message and its attachments may contain confidential or=20
> privileged information that may be protected by law; they should not be d=
istributed, used or copied without authorisation.
> If you have received this email in error, please notify the sender and de=
lete this message and its attachments.
> As emails may be altered, Orange is not liable for messages that have bee=
n modified, changed or falsified.
> Thank you.
>=20
> _______________________________________________
> status mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/status

___________________________________________________________________________=
______________________________________________

Ce message et ses pieces jointes peuvent contenir des informations confiden=
tielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou =
copies sans autorisation. Si vous avez recu ce message par erreur, veuillez=
 le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Le=
s messages electroniques etant susceptibles d'alteration, Orange decline to=
ute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.

This message and its attachments may contain confidential or privileged inf=
ormation that may be protected by law; they should not be distributed, used=
 or copied without authorisation.
If you have received this email in error, please notify the sender and dele=
te this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been =
modified, changed or falsified.
Thank you.

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

___________________________________________________________________________=
______________________________________________

Ce message et ses pieces jointes peuvent contenir des informations confiden=
tielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu=
 ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages el=
ectroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou =
falsifie. Merci.

This message and its attachments may contain confidential or privileged inf=
ormation that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and dele=
te this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been =
modified, changed or falsified.
Thank you.

From: Mach Chen <[email-masked]>
To: John E Drake <[email-masked]>, Mark Townsley <[email-masked]>, Victor Kuarsingh <[email-masked]>
Date: Wed, 4 Sep 2013 01:55:43 +0000
Accept-Language: en-US, zh-CN
Cc: "Roberta Maglione \(robmgl\)" <[email-masked]>, "John G. Scudder" <[email-masked]>, Adrian Farrel <[email-masked]>, "Alvaro Retana \(aretana\)" <[email-masked]>, "[email-masked]" <[email-masked]>, "Stewart Bryant \(stbryant\)" <[email-masked]>
Subject: Re: [Status] Summary of STATUS BOF and the next steps

I also prefer to "source routing", it's well-know and direct.

Best regards,
Mach

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf =
Of
> John E Drake
> Sent: Tuesday, September 03, 2013 9:02 PM
> To: Mark Townsley; Victor Kuarsingh
> Cc: Roberta Maglione (robmgl); John G. Scudder; Alvaro Retana (aretana); =
Adrian
> Farrel; [email-masked]; Stewart Bryant (stbryant)
> Subject: Re: [Status] Summary of STATUS BOF and the next steps
>=20
> Hi,
>=20
> What is this 'segment routing' silliness?  The correct term is 'source ro=
uting'.
>=20
> Yours Irrespectively,
>=20
> John
>=20
> > -----Original Message-----
> > From: [email-masked] [mailto:[email-masked]] On Behal=
f
> > Of Mark Townsley
> > Sent: Sunday, September 01, 2013 10:08 AM
> > To: Victor Kuarsingh
> > Cc: Roberta Maglione (robmgl); John G. Scudder; Adrian Farrel; Alvaro R=
etana
> > (aretana); [email-masked]; Stewart Bryant (stbryant)
> > Subject: Re: [Status] Summary of STATUS BOF and the next steps
> >
> >
> > On Sep 1, 2013, at 5:38 PM, Victor Kuarsingh wrote:
> >
> > > All,
> > >
> > > I would also favour "Segment Routing WG" as well.
> > >
> > > I note this since attempting to come up with an all encompassing
> > > acronym will be difficult and Segment Routing is generic enough to
> > > associate to multiple functions.
> >
> > Then we can just use "segroute" for the short name. WGs do not have to
> > have acronyms, but they do need to have an 8-char limited short name fo=
r
> > the various automated tools not to break.
> >
> > - Mark
> >
> > >
> > > Regards,
> > >
> > > Victor K
> > >
> > >
> > >
> > > On 2013-08-31 6:51 PM, "Roberta Maglione (robmgl)" <[email-masked]>
> > > wrote:
> > >
> > >> +1 for Segment Routing WG
> > >>
> > >> Roberta
> > >>
> > >> Sent from my iPad
> > >>
> > >> On 2013-08-30, at 2:55 PM, "Alvaro Retana (aretana)"
> > >> <[email-masked]>
> > >> wrote:
> > >>
> > >>> Segment Routing WG
> > >>>
> > >>> Sent from my iPhone
> > >>>
> > >>> On Aug 30, 2013, at 1:39 PM, "Stewart Bryant (stbryant)"
> > >>> <[email-masked]> wrote:
> > >>>
> > >>>> The second task, which hopefully should be relatively easy, is to
> > >>>> find a better working name for the WG, since it has been put to me
> > >>>> a number of times that STATUS is going to be confusing in text and
> > >>>> a difficult search term.
> > >>> _______________________________________________
> > >>> status mailing list
> > >>> [email-masked]
> > >>> https://www.ietf.org/mailman/listinfo/status
> > >> _______________________________________________
> > >> status mailing list
> > >> [email-masked]
> > >> https://www.ietf.org/mailman/listinfo/status
> > >
> > >
> > > _______________________________________________
> > > status mailing list
> > > [email-masked]
> > > https://www.ietf.org/mailman/listinfo/status
> >
> > _______________________________________________
> > status mailing list
> > [email-masked]
> > https://www.ietf.org/mailman/listinfo/status
> >
>=20
>=20
> _______________________________________________
> status mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/status

From: John E Drake <[email-masked]>
To: Noel Chiappa <[email-masked]>, "[email-masked]" <[email-masked]>
Date: Wed, 4 Sep 2013 01:29:54 +0000
Accept-Language: en-US
Subject: Re: [Status] Summary of STATUS BOF and the next steps

Noel,

Snipped, comments inline.

Yours Irrespectively,

John

> -----Original Message-----
> From: Noel Chiappa [mailto:[email-masked]]
> Sent: Tuesday, September 03, 2013 6:08 PM
> To: [email-masked]
> Cc: [email-masked]
> Subject: RE: [Status] Summary of STATUS BOF and the next steps
>=20
>     > From: John E Drake <[email-masked]>
>=20
>     > I'm happy with either source routing or explicit routing. If you in=
sist
>     > upon a new term, why not 'directed forwarding|routing'.
>=20
> Now I'm somewhat confused, because you aren't stuck on 'source routing' o=
r
> 'explicit routing', but... 'segment routing' is a no-go - apparently beca=
use you
> find it "to be startlingly non-evocative" - you didn't, AFAICR, put forwa=
rd any
> other reason it's unacceptable?

[JD]  If a term has only passing familiarity with what it is describing, it=
 is effectively useless.

>=20
> Look, I am not at all invested in 'segment routing'. If someone comes up =
with
> a good alternative, that's fine with me.
>=20
>     > You were making incorrect statements about MPLS
>=20
> No. What I said, exactly, was "an MPLS path, for instance (which I don't
> consider a tunnel)". The key phrase there being "I don't consider" - i.e.
> it's my opinion.

[JD]  Right.  I was simply pointing out that your opinion is wrong.

To: [email-masked]
Date: Tue,  3 Sep 2013 21:08:24 -0400 (EDT)
From: [email-masked] (Noel Chiappa)
Cc: [email-masked]
Subject: Re: [Status] Summary of STATUS BOF and the next steps

    > From: John E Drake <[email-masked]>

    > I'm happy with either source routing or explicit routing. If you insist
    > upon a new term, why not 'directed forwarding|routing'.

Now I'm somewhat confused, because you aren't stuck on 'source routing' or
'explicit routing', but... 'segment routing' is a no-go - apparently because
you find it "to be startlingly non-evocative" - you didn't, AFAICR, put
forward any other reason it's unacceptable?

Look, I am not at all invested in 'segment routing'. If someone comes up with
a good alternative, that's fine with me.

    > You were making incorrect statements about MPLS

No. What I said, exactly, was "an MPLS path, for instance (which I don't
consider a tunnel)". The key phrase there being "I don't consider" - i.e.
it's my opinion.

    > From: Yakov Rekhter <[email-masked]>

    > rfc3031 is a product of IETF.
    > ...
    > In the context of IETF work, reading supported by IETF documents (RFCs)
    > takes precedence over reading supported by other non-IETF documents.

The world of computers/networking is larger than the IETF. If an IETF
document re-defined "packet" or "datagram", would that be definitive?
(Heck, RFC-1753/RFC-1992 _did_ re-define 'datagram', but I don't go around
demanding that people always use that definition!)

Anyway, there are other IETF documents that do use the 'layer 2...N wrapped
inside layer N' definition of "tunnel" - see RFC-1241, RFC-1853, etc (and
that's 5 minutes of my life I'll never get back).

    > From: "Adrian Farrel" <[email-masked]>

    > next time you are updating this wikipedia entry

I have _never_ worked on that entry, and have no intention of ever so doing.

And this whole argument about tunnels is almost as stupid as much of the
flaming on the IETF main list. I feel like I've fallen into an episode of
Monty Python. (For people who don't get the reference, see this:

  https://en.wikipedia.org/wiki/The_Argument_Sketch

which will explain it.)

	Noel

From: John E Drake <[email-masked]>
To: Noel Chiappa <[email-masked]>, "[email-masked]" <[email-masked]>
Date: Tue, 3 Sep 2013 21:36:34 +0000
Accept-Language: en-US
Subject: Re: [Status] Summary of STATUS BOF and the next steps

Yours Irrespectively,

John

> -----Original Message-----
> From: Noel Chiappa [mailto:[email-masked]]
> Sent: Tuesday, September 03, 2013 11:40 AM
> To: [email-masked]
> Cc: [email-masked]
> Subject: RE: [Status] Summary of STATUS BOF and the next steps
>=20
>     > From: John E Drake <[email-masked]>
>=20
>     > Inventing a new term to describe an existing phenomenon is not
>     > necessarily a good idea.
>=20
> The only two possible existing terms are "source routing" and "explicit
> routing", and both of them cover a lot more ground then the specific desi=
gn
> here. Did I miss another alternative?

[JD]  I'm happy with either source routing or explicit routing.  If you ins=
ist upon a new term, why not 'directed forwarding|routing'.=20

>=20
>=20
>     > From RFC3031
>=20
> Just because one can find one document which supports a particular readin=
g,
> that doesn't necessarily mean much,

[JD]  You were making incorrect statements about MPLS, so for some odd reas=
on I thought it appropriate to reference the MPLS architecture RFC.=20

> if there are other documents which
> support other readings. E.g.:
>=20
>   Tunneling typically contrasts with a layered protocol model ... The
>   delivery protocol usually ... operates at a higher level in the model t=
han
>   does the payload protocol
>=20
>   http://en.wikipedia.org/wiki/Tunneling_protocol
>=20
> (from the first entry in a quick Google search).

[JD]  Perhaps you would consider re-writing this?=20

>=20
>       Noel
>=20

From: "Adrian Farrel" <[email-masked]>
To: "'Mark Townsley'" <[email-masked]>, <[email-masked]>
Date: Tue, 3 Sep 2013 22:13:36 +0100
Subject: Re: [Status] Summary of STATUS BOF and the next steps
Reply-To: [email-masked]

Hi Mark,

The term "source routing" in the homenet context appears to apply to the concept
of considering the source address at the time of making a routing decision,
rather than the imposition of a route by the source node. Thus, what homenet is
doing is a form of policy-based routing (where the policy applies to the source
address).

It may be the case that the homenet problem space overlaps somewhat with the
STATUS work, but it looks like STATUS is considering a wider set of problems and
networks with larger diameters.

[snip]

> We're working with the ADs on where to advance this, including the possibility
of
> the rtgwg (hence baker's rtgwg document listed above). Whatever ends up
> coming out of homenet, rtgwg, and the WG that is forming here, we should aim
> to be very clear what is what.

I haven't been involved in that discussion (yet), but I note that the homenet
charter says...

 If it turns out that additional 
 options are needed for a routing protocol, they will be developed in 
 the appropriate Routing Area working group, with the HOMENET working 
 group providing the architecture and requirements for such 
 enhancements.

But you're right. We need to be clear on terminology and division of labor.

Thanks for raising this.

Adrian

From: "Adrian Farrel" <[email-masked]>
To: "'Noel Chiappa'" <[email-masked]>, <[email-masked]>
Date: Tue, 3 Sep 2013 21:58:49 +0100
Subject: Re: [Status] Summary of STATUS BOF and the next steps
Reply-To: [email-masked]

Hi Noel,

Far be it from me to criticise the wisdom of wikipedia, but...

>   Tunneling typically contrasts with a layered protocol model ... The
>   delivery protocol usually ... operates at a higher level in the model than
>   does the payload protocol

"operates at  higher level" might be an architectural rather than a
technological definition.

Whatever!

I consider IP-in-IP to be tunneling. Looks like IP is probably at the same level
as IP.
I think that pseudowires are tunneling. Looks like IP/L2TP/MPLS are probably at
a higher layer than Ethernet or TDM.
I think MPLS-in-MPLS is tunneling, and MPLS is at the same level as MPLS.

So, maybe, next time you are updating this wikipedia entry, s/operates at a
higher level/operates at the same or a higher level/

Cheers,
Adrian 

To: Noel Chiappa <[email-masked]>
Date: Tue, 3 Sep 2013 11:46:10 -0700
From: Yakov Rekhter <[email-masked]>
Cc: [email-masked]
Subject: Re: [Status] Summary of STATUS BOF and the next steps

Noel,

>     > From: John E Drake <[email-masked]>
> 
>     > Inventing a new term to describe an existing phenomenon is not
>     > necessarily a good idea.
> 
> The only two possible existing terms are "source routing" and "explicit
> routing", and both of them cover a lot more ground then the specific design
> here. Did I miss another alternative?
> 
> 
>     > From RFC3031
> 
> Just because one can find one document which supports a particular reading,
> that doesn't necessarily mean much, if there are other documents which support
> other readings. E.g.:
> 
>   Tunneling typically contrasts with a layered protocol model ... The
>   delivery protocol usually ... operates at a higher level in the model than
>   does the payload protocol
> 
>   http://en.wikipedia.org/wiki/Tunneling_protocol
> 
> (from the first entry in a quick Google search).

rfc3031 is a product of IETF.

http://en.wikipedia.org/wiki/Tunneling_protocol is not.

In the context of IETF work, reading supported by IETF documents (RFCs) takes
precedence over reading supported by other non-IETF documents.

Yakov.

To: [email-masked]
Date: Tue,  3 Sep 2013 14:39:32 -0400 (EDT)
From: [email-masked] (Noel Chiappa)
Cc: [email-masked]
Subject: Re: [Status] Summary of STATUS BOF and the next steps

    > From: John E Drake <[email-masked]>

    > Inventing a new term to describe an existing phenomenon is not
    > necessarily a good idea.

The only two possible existing terms are "source routing" and "explicit
routing", and both of them cover a lot more ground then the specific design
here. Did I miss another alternative?

    > From RFC3031

Just because one can find one document which supports a particular reading,
that doesn't necessarily mean much, if there are other documents which support
other readings. E.g.:

  Tunneling typically contrasts with a layered protocol model ... The
  delivery protocol usually ... operates at a higher level in the model than
  does the payload protocol

  http://en.wikipedia.org/wiki/Tunneling_protocol

(from the first entry in a quick Google search).

      Noel

From: John E Drake <[email-masked]>
To: Noel Chiappa <[email-masked]>, "[email-masked]" <[email-masked]>
Date: Tue, 3 Sep 2013 18:10:43 +0000
Accept-Language: en-US
Subject: Re: [Status] Summary of STATUS BOF and the next steps

Noel,

Comments inline.

Yours Irrespectively,

John

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf
> Of Noel Chiappa
> Sent: Tuesday, September 03, 2013 9:54 AM
> To: [email-masked]
> Cc: [email-masked]
> Subject: Re: [Status] Summary of STATUS BOF and the next steps
>=20
>     > From: Hannes Gredler <[email-masked]>
>=20
>     > what about this charter proposal ?
>=20
> It looks like a good start to me, but one thing:
>=20
>     > Stacked Tunnels for Explicit Routing (STER)
>=20
> I actually like the name "segment routing". For one, it's a new term, so =
it
> doesn't have any existing (overloaded) meaning.

[JD]  Inventing a new term to describe an existing phenomenon is not necess=
arily a good idea.=20

>=20
> For another, I find the 'ST' part of 'STER' a bit misleading because an E=
RD
> might not be using a tunnel (as I normally think of it, which involves 'I=
PvN in
> IPvN encapsulation' or 'L2 in IPvN encapsulation', or something like that=
) to
> specify a path across itself; it might be using an MPLS path, for instanc=
e
> (which I don't consider a tunnel).

[JD]  From RFC3031:

 3.27. Tunnels and Hierarchy

   Sometimes a router Ru takes explicit action to cause a particular
   packet to be delivered to another router Rd, even though Ru and Rd
   are not consecutive routers on the Hop-by-hop path for that packet,
   and Rd is not the packet's ultimate destination.  For example, this
   may be done by encapsulating the packet inside a network layer packet
   whose destination address is the address of Rd itself.  This creates
   a "tunnel" from Ru to Rd.  We refer to any packet so handled as a
   "Tunneled Packet".

3.27.2. Explicitly Routed Tunnel

   If a Tunneled Packet travels from Ru to Rd over a path other than the
   Hop-by-hop path, we say that it is in an "Explicitly Routed Tunnel"
   whose "transmit endpoint" is Ru and whose "receive endpoint" is Rd.
   For example, we might send a packet through an Explicitly Routed
   Tunnel by encapsulating it in a packet which is source routed.

>=20
> 'Segment routing' seems to me to capture the essence of what's going on; =
at
> certain points along the overall path, an explicit route is picked for th=
e next
> segment of the overall path; hence, my liking for it.

[JD]  It must be a matter of taste as I find 'segment routing' to be startl=
ingly non-evocative.=20

>=20
> I have no objection to using the term 'explicit routing' along with 'segm=
ent',
> so combinations like 'segment routing with explicit path sections', etc, =
would
> all be fine with me too, although I don't have a perfect suggested name t=
o
> suggest.
>=20
> 	Noel
> _______________________________________________
> status mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/status
>=20

From: "Carlos Pignataro (cpignata)" <[email-masked]>
To: Mark Townsley <[email-masked]>
Date: Tue, 3 Sep 2013 17:18:00 +0000
Accept-Language: en-US
Cc: "<[email-masked]>" <[email-masked]>
Subject: Re: [Status] Summary of STATUS BOF and the next steps

--Apple-Mail=_13E9F7E0-CD4F-4BC4-96E6-76F6925B88B6
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=us-ascii

This is another datapoint against using "source routing" -- the term is =
overloaded with multiple meanings and history including "providing =
routing information at the source", use of SRR options, and "making a =
routing decision based on a source address".

"Segment Routing" is simple and captures the essence of the work =
(including non explicit -- meaning IGP selected -- paths).

Thanks,

-- Carlos.

On Sep 3, 2013, at 12:47 PM, Mark Townsley <[email-masked]> wrote:

>=20
> For those who might not be aware, the homenet WG has been actively =
working on "source and destination routing" (SADR) techniques to solve =
the routing problem facing a multi-router, multi-homed, multi-prefix, =
IPv6 home network:
>=20
> A few refs:
>=20
> draft-troan-homenet-sadr
> draft-baker-ipv6-ospf-dst-src-routing
> draft-baker-ipv6-isis-dst-src-routing
> draft-boutier-homenet-source-specific-routing
> draft-baker-rtgwg-src-dst-routing-use-cases
>=20
> We're working with the ADs on where to advance this, including the =
possibility of the rtgwg (hence baker's rtgwg document listed above). =
Whatever ends up coming out of homenet, rtgwg, and the WG that is =
forming here, we should aim to be very clear what is what.=20
>=20
> - Mark
>=20
> P.S. Another ref, just for kicks: =
http://www.youtube.com/watch?v=3D3Omg1lJ6EQI
>=20
>=20
> On Sep 3, 2013, at 5:35 PM, Noel Chiappa wrote:
>=20
>>> From: AshwoodsmithPeter <[email-masked]>
>>=20
>>> We are revisiting source routing with new concepts.=20
>>=20
>> The problem is that "source routing" seems, by the time you do the =
set-or of
>> all the various meanings that people apply to it, to basically mean =
"not
>> hop-by-hop routing".
>>=20
>> The problem, therefore, with calling something "source routing" is =
that it's
>> like me calling myself "Not Peter Ashwood-Smith". The problem is that =
there
>> are a lot of people whose name is "Not Peter Ashwood-Smith", so it's =
really a
>> pretty useless name.
>>=20
>> Similarly, saying that something is "source routing" really tells you =
very
>> little about it - except that it's not hop-by-hop. So let's find a =
different,
>> and actually meaningful, name.
>>=20
>> 	Noel
>> _______________________________________________
>> status mailing list
>> [email-masked]
>> https://www.ietf.org/mailman/listinfo/status
>=20
> _______________________________________________
> status mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/status

--Apple-Mail=_13E9F7E0-CD4F-4BC4-96E6-76F6925B88B6
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment; filename="signature.asc"
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: Message signed with OpenPGP using GPGMail

--Apple-Mail=_13E9F7E0-CD4F-4BC4-96E6-76F6925B88B6--

From: John E Drake <[email-masked]>
To: Hannes Gredler <[email-masked]>, Loa Andersson <[email-masked]>
Date: Tue, 3 Sep 2013 17:02:09 +0000
Accept-Language: en-US
Cc: "[email-masked]" <[email-masked]>
Subject: Re: [Status] Summary of STATUS BOF and the next steps

Hannes,

This is the precisely the terminology that I used in my Berlin presentation=
 and the charter statement seems fine.

Yours Irrespectively,

John

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf
> Of Hannes Gredler
> Sent: Tuesday, September 03, 2013 9:31 AM
> To: Loa Andersson
> Cc: [email-masked]
> Subject: Re: [Status] Summary of STATUS BOF and the next steps
>=20
> good point - what about this charter proposal ?
>=20
> ---
>=20
> Stacked Tunnels for Explicit Routing (STER)
> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
>=20
> A explicit routing domain (ERD) contains a set of routers with the follow=
ing
> characteristics:
>=20
> - They form a connected network
> - They can forward traffic through the shortest paths or paths other than=
 the
> shortest (the latter called explicitly routed paths, or explicit paths)
> - They share a common trust model. In this model, any router within the E=
RD
> can specify an explicit path between itself and any other router in the E=
RD. It
> can then send any packet that passes through it through any path that it =
has
> specified. Downstream routers within the ERD forward the packet as
> specified by the router at the head-end of the path.
>=20
> The STER working group is chartered for the following ordered list of wor=
k
> items:
>=20
> - The first goal of the STER WG is to identify use-cases for ERDs.
> - Having identified use-cases, the WG will identify gaps between currentl=
y
> available technologies and use-case requirements.
> - The WG will then define requirements for extensions to existing protoco=
ls
> or new protocols that address gaps that are identified.
>=20
> Protocol work may be carried out in this working group or in other workin=
g
> groups responsible for the protocols, in coordination with this WG, and i=
n
> agreement with the WG chairs and responsible ADs. However, no protocol
> work will be adopted by a working group to address the ERD use-cases unti=
l
> the requirements document motivating the protocol work has been sent to
> the IESG for publication as an RFC.
>=20
> ---
>=20
> <flame suit on>
>=20
> /hannes
>=20
>=20
> On Sep 3, 2013, at 5:31 PM, Loa Andersson wrote:
>=20
> > Folks,
> >
> > Excuse me if I'm slightly out of the loop, but so far I have not seen
> > a charter proposal, if there is one please point me to it.
> >
> > It seems a bit odd to put the cart (what the wg should do) before the
> > horse (wg name). If we drill down the the charter first the wg name
> > might be easier to figure out.
> >
> > /Loa
> >
> > PS
> > OK I understand that the horse and cart analogy limps a  bit :).
> >
> >
> >
> > On 2013-09-03 17:22, AshwoodsmithPeter wrote:
> >> " If the WG charter is limited to source routing, how will we handle t=
he
> "non source routing" use cases of segment routing ? In another working
> group ? So we will go back to the WG synchronization issue that has been
> raised for this technology ..."
> >>
> >> That's why I suggested SRV2. We are revisiting source routing with new
> concepts. More generic number/action behavior.
> >>
> >> Peter
> >>
> >> -----Original Message-----
> >> From: [email-masked] [mailto:[email-masked]] On
> >> Behalf Of [email-masked]
> >> Sent: Tuesday, September 03, 2013 10:43 AM
> >> To: AshwoodsmithPeter
> >> Cc: [email-masked]
> >> Subject: Re: [Status] Summary of STATUS BOF and the next steps
> >>
> >>
> >> There was a misunderstanding in my small comment :) so I will explain
> more :
> >>
> >> In segment routing, you have more than basic source routing : segment
> routing is just associate a segment number to an action and then combine
> segment as you want, yes you can do source routing, but you also can do
> more.
> >>
> >> In the other hand, I completely agree with your statement that source
> >> routing is generic and dataplane agnostic, as segment routing is ...
> >> (segment routing is not a new dataplane ...)
> >>
> >> Now the definition of the WG naming must be inline with the charter
> >> that will be defined ... (draft today)
> >>
> >> Based on the already existing consensus (at least for MPLS dataplane)
> brought up during Berlin STATUS BOF meeting, segment routing sounds to be
> a good target candidate.
> >>
> >> So now, do we want to do more in the WG charter than just make
> progressing segment routing architecture and uses cases document and
> ensure coordination for the standardization of this technology ?
> >>
> >> Do we want to standardize other technologies in this WG ? I don't thin=
k
> so, based on Stewart's conclusion email from the BOF :"A new WG focused
> solely on SR therefore needs to be create"
> >>
> >> If the WG charter is limited to source routing, how will we handle the=
 "non
> source routing" use cases of segment routing ? In another working group ?
> So we will go back to the WG synchronization issue that has been raised f=
or
> this technology ...
> >>
> >> If the WG is focused on SR, let's use a name in relation with SR.
> >>
> >> Feedback ?
> >>
> >>
> >> Stephane
> >>
> >>
> >> -----Message d'origine-----
> >> De : AshwoodsmithPeter [mailto:[email-masked]]
> >> Envoy=E9 : mardi 3 septembre 2013 15:27 =C0 : LITKOWSKI Stephane
> DTF/DERX
> >> Cc : John E Drake; Mark Townsley; Victor Kuarsingh; Roberta Maglione
> >> (robmgl); John G. Scudder; Adrian Farrel; Alvaro Retana (aretana);
> >> [email-masked]; Stewart Bryant (stbryant) Objet : Re: [Status]
> >> Summary of STATUS BOF and the next steps
> >>
> >> The term "source routing" has been around for a very long time and is
> data path agnostic. Its also the term used in the literature etc so my
> preference is to stick with this existing well known and data path agnost=
ic
> term.
> >>
> >> Peter
> >>
> >> On Sep 3, 2013, at 9:07 AM, "[email-masked]"
> <[email-masked]> wrote:
> >>
> >>> Hi,
> >>>
> >>> "Source routing" is just a subcase of segment routing ... as it is fo=
r IP
> routing ...
> >>>
> >>> Stephane
> >>>
> >>>
> >>> -----Message d'origine-----
> >>> De : [email-masked] [mailto:[email-masked]] De la
> >>> part de John E Drake Envoy=E9 : mardi 3 septembre 2013 15:02 =C0 : Ma=
rk
> >>> Townsley; Victor Kuarsingh Cc : Roberta Maglione (robmgl); John G.
> >>> Scudder; Alvaro Retana (aretana); Adrian Farrel; [email-masked];
> >>> Stewart Bryant (stbryant) Objet : Re: [Status] Summary of STATUS BOF
> >>> and the next steps
> >>>
> >>> Hi,
> >>>
> >>> What is this 'segment routing' silliness?  The correct term is 'sourc=
e
> routing'.
> >>>
> >>> Yours Irrespectively,
> >>>
> >>> John
> >>>
> >>>> -----Original Message-----
> >>>> From: [email-masked] [mailto:[email-masked]] On
> >>>> Behalf Of Mark Townsley
> >>>> Sent: Sunday, September 01, 2013 10:08 AM
> >>>> To: Victor Kuarsingh
> >>>> Cc: Roberta Maglione (robmgl); John G. Scudder; Adrian Farrel;
> >>>> Alvaro Retana (aretana); [email-masked]; Stewart Bryant (stbryant)
> >>>> Subject: Re: [Status] Summary of STATUS BOF and the next steps
> >>>>
> >>>>
> >>>> On Sep 1, 2013, at 5:38 PM, Victor Kuarsingh wrote:
> >>>>
> >>>>> All,
> >>>>>
> >>>>> I would also favour "Segment Routing WG" as well.
> >>>>>
> >>>>> I note this since attempting to come up with an all encompassing
> >>>>> acronym will be difficult and Segment Routing is generic enough to
> >>>>> associate to multiple functions.
> >>>>
> >>>> Then we can just use "segroute" for the short name. WGs do not have
> >>>> to have acronyms, but they do need to have an 8-char limited short
> >>>> name for the various automated tools not to break.
> >>>>
> >>>> - Mark
> >>>>
> >>>>>
> >>>>> Regards,
> >>>>>
> >>>>> Victor K
> >>>>>
> >>>>>
> >>>>>
> >>>>> On 2013-08-31 6:51 PM, "Roberta Maglione (robmgl)"
> >>>>> <[email-masked]>
> >>>>> wrote:
> >>>>>
> >>>>>> +1 for Segment Routing WG
> >>>>>>
> >>>>>> Roberta
> >>>>>>
> >>>>>> Sent from my iPad
> >>>>>>
> >>>>>> On 2013-08-30, at 2:55 PM, "Alvaro Retana (aretana)"
> >>>>>> <[email-masked]>
> >>>>>> wrote:
> >>>>>>
> >>>>>>> Segment Routing WG
> >>>>>>>
> >>>>>>> Sent from my iPhone
> >>>>>>>
> >>>>>>> On Aug 30, 2013, at 1:39 PM, "Stewart Bryant (stbryant)"
> >>>>>>> <[email-masked]> wrote:
> >>>>>>>
> >>>>>>>> The second task, which hopefully should be relatively easy, is
> >>>>>>>> to find a better working name for the WG, since it has been put
> >>>>>>>> to me a number of times that STATUS is going to be confusing in
> >>>>>>>> text and a difficult search term.
> >>>>>>> _______________________________________________
> >>>>>>> status mailing list
> >>>>>>> [email-masked]
> >>>>>>> https://www.ietf.org/mailman/listinfo/status
> >>>>>> _______________________________________________
> >>>>>> status mailing list
> >>>>>> [email-masked]
> >>>>>> https://www.ietf.org/mailman/listinfo/status
> >>>>>
> >>>>>
> >>>>> _______________________________________________
> >>>>> status mailing list
> >>>>> [email-masked]
> >>>>> https://www.ietf.org/mailman/listinfo/status
> >>>>
> >>>> _______________________________________________
> >>>> status mailing list
> >>>> [email-masked]
> >>>> https://www.ietf.org/mailman/listinfo/status
> >>>
> >>>
> >>> _______________________________________________
> >>> status mailing list
> >>> [email-masked]
> >>> https://www.ietf.org/mailman/listinfo/status
> >>>
> >>>
> __________________________________________________________
> __________
> >>> __ ___________________________________________________
> >>>
> >>> Ce message et ses pieces jointes peuvent contenir des informations
> >>> confidentielles ou privilegiees et ne doivent donc pas etre
> >>> diffuses, exploites ou copies sans autorisation. Si vous avez recu
> >>> ce message par erreur, veuillez le signaler a l'expediteur et le detr=
uire
> ainsi que les pieces jointes. Les messages electroniques etant susceptibl=
es
> d'alteration, Orange decline toute responsabilite si ce message a ete alt=
ere,
> deforme ou falsifie. Merci.
> >>>
> >>> This message and its attachments may contain confidential or
> >>> privileged information that may be protected by law; they should not =
be
> distributed, used or copied without authorisation.
> >>> If you have received this email in error, please notify the sender an=
d
> delete this message and its attachments.
> >>> As emails may be altered, Orange is not liable for messages that have
> been modified, changed or falsified.
> >>> Thank you.
> >>>
> >>> _______________________________________________
> >>> status mailing list
> >>> [email-masked]
> >>> https://www.ietf.org/mailman/listinfo/status
> >>
> >>
> __________________________________________________________
> ___________
> >> ____________________________________________________
> >>
> >> Ce message et ses pieces jointes peuvent contenir des informations
> >> confidentielles ou privilegiees et ne doivent donc pas etre diffuses,
> >> exploites ou copies sans autorisation. Si vous avez recu ce message
> >> par erreur, veuillez le signaler a l'expediteur et le detruire ainsi q=
ue les
> pieces jointes. Les messages electroniques etant susceptibles d'alteratio=
n,
> Orange decline toute responsabilite si ce message a ete altere, deforme o=
u
> falsifie. Merci.
> >>
> >> This message and its attachments may contain confidential or
> >> privileged information that may be protected by law; they should not b=
e
> distributed, used or copied without authorisation.
> >> If you have received this email in error, please notify the sender and
> delete this message and its attachments.
> >> As emails may be altered, Orange is not liable for messages that have
> been modified, changed or falsified.
> >> Thank you.
> >>
> >> _______________________________________________
> >> status mailing list
> >> [email-masked]
> >> https://www.ietf.org/mailman/listinfo/status
> >> _______________________________________________
> >> status mailing list
> >> [email-masked]
> >> https://www.ietf.org/mailman/listinfo/status
> >>
> >
> > --
> >
> >
> > Loa Andersson                        email: [email-masked]
> > Senior MPLS Expert                          [email-masked]
> > Huawei Technologies (consultant)     phone: +46 739 81 21 64
> > _______________________________________________
> > status mailing list
> > [email-masked]
> > https://www.ietf.org/mailman/listinfo/status
> >
> >
>=20
>=20
> _______________________________________________
> status mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/status
>=20

To: [email-masked]
Date: Tue,  3 Sep 2013 12:54:18 -0400 (EDT)
From: [email-masked] (Noel Chiappa)
Cc: [email-masked]
Subject: Re: [Status] Summary of STATUS BOF and the next steps

    > From: Hannes Gredler <[email-masked]>

    > what about this charter proposal ?

It looks like a good start to me, but one thing:

    > Stacked Tunnels for Explicit Routing (STER)

I actually like the name "segment routing". For one, it's a new term, so it
doesn't have any existing (overloaded) meaning.

For another, I find the 'ST' part of 'STER' a bit misleading because an ERD
might not be using a tunnel (as I normally think of it, which involves 'IPvN
in IPvN encapsulation' or 'L2 in IPvN encapsulation', or something like that)
to specify a path across itself; it might be using an MPLS path, for instance
(which I don't consider a tunnel).

'Segment routing' seems to me to capture the essence of what's going on; at
certain points along the overall path, an explicit route is picked for the
next segment of the overall path; hence, my liking for it.

I have no objection to using the term 'explicit routing' along with
'segment', so combinations like 'segment routing with explicit path
sections', etc, would all be fine with me too, although I don't have a
perfect suggested name to suggest.

	Noel

From: Mark Townsley <[email-masked]>
Date: Tue, 3 Sep 2013 18:47:48 +0200
To: [email-masked]
Subject: Re: [Status] Summary of STATUS BOF and the next steps

For those who might not be aware, the homenet WG has been actively =
working on "source and destination routing" (SADR) techniques to solve =
the routing problem facing a multi-router, multi-homed, multi-prefix, =
IPv6 home network:

A few refs:

draft-troan-homenet-sadr
draft-baker-ipv6-ospf-dst-src-routing
draft-baker-ipv6-isis-dst-src-routing
draft-boutier-homenet-source-specific-routing
draft-baker-rtgwg-src-dst-routing-use-cases

We're working with the ADs on where to advance this, including the =
possibility of the rtgwg (hence baker's rtgwg document listed above). =
Whatever ends up coming out of homenet, rtgwg, and the WG that is =
forming here, we should aim to be very clear what is what.=20

- Mark

P.S. Another ref, just for kicks: =
http://www.youtube.com/watch?v=3D3Omg1lJ6EQI

On Sep 3, 2013, at 5:35 PM, Noel Chiappa wrote:

>> From: AshwoodsmithPeter <[email-masked]>
>=20
>> We are revisiting source routing with new concepts.=20
>=20
> The problem is that "source routing" seems, by the time you do the =
set-or of
> all the various meanings that people apply to it, to basically mean =
"not
> hop-by-hop routing".
>=20
> The problem, therefore, with calling something "source routing" is =
that it's
> like me calling myself "Not Peter Ashwood-Smith". The problem is that =
there
> are a lot of people whose name is "Not Peter Ashwood-Smith", so it's =
really a
> pretty useless name.
>=20
> Similarly, saying that something is "source routing" really tells you =
very
> little about it - except that it's not hop-by-hop. So let's find a =
different,
> and actually meaningful, name.
>=20
> 	Noel
> _______________________________________________
> status mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/status

From: Hannes Gredler <[email-masked]>
Date: Tue, 3 Sep 2013 18:30:56 +0200
To: Loa Andersson <[email-masked]>
Cc: [email-masked]
Subject: Re: [Status] Summary of STATUS BOF and the next steps

good point - what about this charter proposal ?

---

Stacked Tunnels for Explicit Routing (STER)=20
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

A explicit routing domain (ERD) contains a set of routers with the =
following characteristics:

- They form a connected network
- They can forward traffic through the shortest paths or paths other =
than the shortest (the latter called explicitly routed paths, or =
explicit paths)
- They share a common trust model. In this model, any router within the =
ERD can specify an explicit path between itself and any other router in =
the ERD. It can then send any packet that passes through it through any =
path that it has specified. Downstream routers within the ERD forward =
the packet as specified by the router at the head-end of the path.

The STER working group is chartered for the following ordered list of =
work items:

- The first goal of the STER WG is to identify use-cases for ERDs.=20
- Having identified use-cases, the WG will identify gaps between =
currently available technologies and use-case requirements.=20
- The WG will then define requirements for extensions to existing =
protocols or new protocols that address gaps that are identified.=20

Protocol work may be carried out in this working group or in other =
working groups responsible for the protocols, in coordination with this =
WG, and in agreement with the WG chairs and responsible ADs. However, no =
protocol work will be adopted by a working group to address the ERD =
use-cases until the requirements document motivating the protocol work =
has been sent to the IESG for publication as an RFC.

---

<flame suit on>

/hannes

On Sep 3, 2013, at 5:31 PM, Loa Andersson wrote:

> Folks,
>=20
> Excuse me if I'm slightly out of the loop, but so far I have not seen =
a
> charter proposal, if there is one please point me to it.
>=20
> It seems a bit odd to put the cart (what the wg should do) before the
> horse (wg name). If we drill down the the charter first the wg name
> might be easier to figure out.
>=20
> /Loa
>=20
> PS
> OK I understand that the horse and cart analogy limps a  bit :).
>=20
>=20
>=20
> On 2013-09-03 17:22, AshwoodsmithPeter wrote:
>> " If the WG charter is limited to source routing, how will we handle =
the "non source routing" use cases of segment routing ? In another =
working group ? So we will go back to the WG synchronization issue that =
has been raised for this technology ..."
>>=20
>> That's why I suggested SRV2. We are revisiting source routing with =
new concepts. More generic number/action behavior.
>>=20
>> Peter
>>=20
>> -----Original Message-----
>> From: [email-masked] [mailto:[email-masked]] On =
Behalf Of [email-masked]
>> Sent: Tuesday, September 03, 2013 10:43 AM
>> To: AshwoodsmithPeter
>> Cc: [email-masked]
>> Subject: Re: [Status] Summary of STATUS BOF and the next steps
>>=20
>>=20
>> There was a misunderstanding in my small comment :) so I will explain =
more :
>>=20
>> In segment routing, you have more than basic source routing : segment =
routing is just associate a segment number to an action and then combine =
segment as you want, yes you can do source routing, but you also can do =
more.
>>=20
>> In the other hand, I completely agree with your statement that source =
routing is generic and dataplane agnostic, as segment routing is ... =
(segment routing is not a new dataplane ...)
>>=20
>> Now the definition of the WG naming must be inline with the charter =
that will be defined ... (draft today)
>>=20
>> Based on the already existing consensus (at least for MPLS dataplane) =
brought up during Berlin STATUS BOF meeting, segment routing sounds to =
be a good target candidate.
>>=20
>> So now, do we want to do more in the WG charter than just make =
progressing segment routing architecture and uses cases document and =
ensure coordination for the standardization of this technology ?
>>=20
>> Do we want to standardize other technologies in this WG ? I don't =
think so, based on Stewart's conclusion email from the BOF :"A new WG =
focused solely on SR therefore needs to be create"
>>=20
>> If the WG charter is limited to source routing, how will we handle =
the "non source routing" use cases of segment routing ? In another =
working group ? So we will go back to the WG synchronization issue that =
has been raised for this technology ...
>>=20
>> If the WG is focused on SR, let's use a name in relation with SR.
>>=20
>> Feedback ?
>>=20
>>=20
>> Stephane
>>=20
>>=20
>> -----Message d'origine-----
>> De : AshwoodsmithPeter [mailto:[email-masked]]
>> Envoy=E9 : mardi 3 septembre 2013 15:27
>> =C0 : LITKOWSKI Stephane DTF/DERX
>> Cc : John E Drake; Mark Townsley; Victor Kuarsingh; Roberta Maglione =
(robmgl); John G. Scudder; Adrian Farrel; Alvaro Retana (aretana); =
[email-masked]; Stewart Bryant (stbryant) Objet : Re: [Status] Summary =
of STATUS BOF and the next steps
>>=20
>> The term "source routing" has been around for a very long time and is =
data path agnostic. Its also the term used in the literature etc so my =
preference is to stick with this existing well known and data path =
agnostic term.
>>=20
>> Peter
>>=20
>> On Sep 3, 2013, at 9:07 AM, "[email-masked]" =
<[email-masked]> wrote:
>>=20
>>> Hi,
>>>=20
>>> "Source routing" is just a subcase of segment routing ... as it is =
for IP routing ...
>>>=20
>>> Stephane
>>>=20
>>>=20
>>> -----Message d'origine-----
>>> De : [email-masked] [mailto:[email-masked]] De la
>>> part de John E Drake Envoy=E9 : mardi 3 septembre 2013 15:02 =C0 : =
Mark
>>> Townsley; Victor Kuarsingh Cc : Roberta Maglione (robmgl); John G.
>>> Scudder; Alvaro Retana (aretana); Adrian Farrel; [email-masked];
>>> Stewart Bryant (stbryant) Objet : Re: [Status] Summary of STATUS BOF
>>> and the next steps
>>>=20
>>> Hi,
>>>=20
>>> What is this 'segment routing' silliness?  The correct term is =
'source routing'.
>>>=20
>>> Yours Irrespectively,
>>>=20
>>> John
>>>=20
>>>> -----Original Message-----
>>>> From: [email-masked] [mailto:[email-masked]] On
>>>> Behalf Of Mark Townsley
>>>> Sent: Sunday, September 01, 2013 10:08 AM
>>>> To: Victor Kuarsingh
>>>> Cc: Roberta Maglione (robmgl); John G. Scudder; Adrian Farrel; =
Alvaro
>>>> Retana (aretana); [email-masked]; Stewart Bryant (stbryant)
>>>> Subject: Re: [Status] Summary of STATUS BOF and the next steps
>>>>=20
>>>>=20
>>>> On Sep 1, 2013, at 5:38 PM, Victor Kuarsingh wrote:
>>>>=20
>>>>> All,
>>>>>=20
>>>>> I would also favour "Segment Routing WG" as well.
>>>>>=20
>>>>> I note this since attempting to come up with an all encompassing
>>>>> acronym will be difficult and Segment Routing is generic enough to
>>>>> associate to multiple functions.
>>>>=20
>>>> Then we can just use "segroute" for the short name. WGs do not have
>>>> to have acronyms, but they do need to have an 8-char limited short
>>>> name for the various automated tools not to break.
>>>>=20
>>>> - Mark
>>>>=20
>>>>>=20
>>>>> Regards,
>>>>>=20
>>>>> Victor K
>>>>>=20
>>>>>=20
>>>>>=20
>>>>> On 2013-08-31 6:51 PM, "Roberta Maglione (robmgl)"
>>>>> <[email-masked]>
>>>>> wrote:
>>>>>=20
>>>>>> +1 for Segment Routing WG
>>>>>>=20
>>>>>> Roberta
>>>>>>=20
>>>>>> Sent from my iPad
>>>>>>=20
>>>>>> On 2013-08-30, at 2:55 PM, "Alvaro Retana (aretana)"
>>>>>> <[email-masked]>
>>>>>> wrote:
>>>>>>=20
>>>>>>> Segment Routing WG
>>>>>>>=20
>>>>>>> Sent from my iPhone
>>>>>>>=20
>>>>>>> On Aug 30, 2013, at 1:39 PM, "Stewart Bryant (stbryant)"
>>>>>>> <[email-masked]> wrote:
>>>>>>>=20
>>>>>>>> The second task, which hopefully should be relatively easy, is =
to
>>>>>>>> find a better working name for the WG, since it has been put to
>>>>>>>> me a number of times that STATUS is going to be confusing in =
text
>>>>>>>> and a difficult search term.
>>>>>>> _______________________________________________
>>>>>>> status mailing list
>>>>>>> [email-masked]
>>>>>>> https://www.ietf.org/mailman/listinfo/status
>>>>>> _______________________________________________
>>>>>> status mailing list
>>>>>> [email-masked]
>>>>>> https://www.ietf.org/mailman/listinfo/status
>>>>>=20
>>>>>=20
>>>>> _______________________________________________
>>>>> status mailing list
>>>>> [email-masked]
>>>>> https://www.ietf.org/mailman/listinfo/status
>>>>=20
>>>> _______________________________________________
>>>> status mailing list
>>>> [email-masked]
>>>> https://www.ietf.org/mailman/listinfo/status
>>>=20
>>>=20
>>> _______________________________________________
>>> status mailing list
>>> [email-masked]
>>> https://www.ietf.org/mailman/listinfo/status
>>>=20
>>> =
______________________________________________________________________
>>> ___________________________________________________
>>>=20
>>> Ce message et ses pieces jointes peuvent contenir des informations
>>> confidentielles ou privilegiees et ne doivent donc pas etre =
diffuses,
>>> exploites ou copies sans autorisation. Si vous avez recu ce message
>>> par erreur, veuillez le signaler a l'expediteur et le detruire ainsi =
que les pieces jointes. Les messages electroniques etant susceptibles =
d'alteration, Orange decline toute responsabilite si ce message a ete =
altere, deforme ou falsifie. Merci.
>>>=20
>>> This message and its attachments may contain confidential or
>>> privileged information that may be protected by law; they should not =
be distributed, used or copied without authorisation.
>>> If you have received this email in error, please notify the sender =
and delete this message and its attachments.
>>> As emails may be altered, Orange is not liable for messages that =
have been modified, changed or falsified.
>>> Thank you.
>>>=20
>>> _______________________________________________
>>> status mailing list
>>> [email-masked]
>>> https://www.ietf.org/mailman/listinfo/status
>>=20
>> =
__________________________________________________________________________=
_______________________________________________
>>=20
>> Ce message et ses pieces jointes peuvent contenir des informations =
confidentielles ou privilegiees et ne doivent donc
>> pas etre diffuses, exploites ou copies sans autorisation. Si vous =
avez recu ce message par erreur, veuillez le signaler
>> a l'expediteur et le detruire ainsi que les pieces jointes. Les =
messages electroniques etant susceptibles d'alteration,
>> Orange decline toute responsabilite si ce message a ete altere, =
deforme ou falsifie. Merci.
>>=20
>> This message and its attachments may contain confidential or =
privileged information that may be protected by law;
>> they should not be distributed, used or copied without authorisation.
>> If you have received this email in error, please notify the sender =
and delete this message and its attachments.
>> As emails may be altered, Orange is not liable for messages that have =
been modified, changed or falsified.
>> Thank you.
>>=20
>> _______________________________________________
>> status mailing list
>> [email-masked]
>> https://www.ietf.org/mailman/listinfo/status
>> _______________________________________________
>> status mailing list
>> [email-masked]
>> https://www.ietf.org/mailman/listinfo/status
>>=20
>=20
> --=20
>=20
>=20
> Loa Andersson                        email: [email-masked]
> Senior MPLS Expert                          [email-masked]
> Huawei Technologies (consultant)     phone: +46 739 81 21 64
> _______________________________________________
> status mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/status
>=20
>=20

From: "Alvaro Retana (aretana)" <[email-masked]>
To: "[email-masked]" <[email-masked]>
Date: Tue, 3 Sep 2013 16:11:32 +0000
Accept-Language: en-US
Subject: [Status] "Too many recipients to the message"

--_000_BBD66FD99311804F80324E8139B3C94E29068EE5xmbalnx15ciscoc_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

Hi!

We've been getting messages held by mailman because they are sent to "too m=
any recipients" (and, I guess, the system thinks they might be spam).  I th=
ink the queue has now been cleared.

The discussion on the "Summary of STATUS BOF.." thread has gathered a lot o=
f interest which is why the list of recipients has grown.  While the partic=
ipation/interest is great, please do everyone a favor and edit the list of =
recipients to the min (the person you're replying to and the list).

Thanks!

Alvaro.
Listed as one of the owners of the status list..

--_000_BBD66FD99311804F80324E8139B3C94E29068EE5xmbalnx15ciscoc_
Content-Type: text/html; charset="us-ascii"
Content-ID: <[email-masked]>
Content-Transfer-Encoding: quoted-printable

<html>
<head>
<meta http-equiv=3D"Content-Type" content=3D"text/html; charset=3Dus-ascii"=
>
</head>
<body style=3D"word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-lin=
e-break: after-white-space; color: rgb(0, 0, 0); font-size: 14px; font-fami=
ly: Calibri, sans-serif; ">
<div>Hi!</div>
<div><br>
</div>
<div>We've been getting messages held by mailman because they are sent to &=
quot;too many recipients&quot; (and, I guess, the system thinks they might =
be spam). &nbsp;I think the queue has now been cleared.</div>
<div><br>
</div>
<div>The discussion on the &quot;Summary of STATUS BOF..&quot; thread has g=
athered a lot of interest which is why the list of recipients has grown. &n=
bsp;While the participation/interest is great, please do everyone a favor a=
nd edit the list of recipients to the min (the
 person you're replying to and the list).</div>
<div><br>
</div>
<div>Thanks!</div>
<div><br>
</div>
<div>Alvaro.</div>
<div>Listed as one of the owners of the status list..</div>
</body>
</html>

--_000_BBD66FD99311804F80324E8139B3C94E29068EE5xmbalnx15ciscoc_--

To: [email-masked]
Date: Tue,  3 Sep 2013 11:35:38 -0400 (EDT)
From: [email-masked] (Noel Chiappa)
Cc: [email-masked]
Subject: Re: [Status] Summary of STATUS BOF and the next steps

    > From: AshwoodsmithPeter <[email-masked]>

    > We are revisiting source routing with new concepts. 

The problem is that "source routing" seems, by the time you do the set-or of
all the various meanings that people apply to it, to basically mean "not
hop-by-hop routing".

The problem, therefore, with calling something "source routing" is that it's
like me calling myself "Not Peter Ashwood-Smith". The problem is that there
are a lot of people whose name is "Not Peter Ashwood-Smith", so it's really a
pretty useless name.

Similarly, saying that something is "source routing" really tells you very
little about it - except that it's not hop-by-hop. So let's find a different,
and actually meaningful, name.

	Noel

From: <[email-masked]>
To: Loa Andersson <[email-masked]>, "[email-masked]" <[email-masked]>
Date: Tue, 3 Sep 2013 17:32:56 +0200
Accept-Language: fr-FR
acceptlanguage: fr-FR
Subject: Re: [Status] Summary of STATUS BOF and the next steps

+1 !
=20

-----Message d'origine-----
De : [email-masked] [mailto:[email-masked]] De la part de=
 Loa Andersson
Envoy=E9 : mardi 3 septembre 2013 17:32
=C0 : [email-masked]
Objet : Re: [Status] Summary of STATUS BOF and the next steps

Folks,

Excuse me if I'm slightly out of the loop, but so far I have not seen a cha=
rter proposal, if there is one please point me to it.

It seems a bit odd to put the cart (what the wg should do) before the horse=
 (wg name). If we drill down the the charter first the wg name might be eas=
ier to figure out.

/Loa

PS
OK I understand that the horse and cart analogy limps a  bit :).

On 2013-09-03 17:22, AshwoodsmithPeter wrote:
> " If the WG charter is limited to source routing, how will we handle the =
"non source routing" use cases of segment routing ? In another working grou=
p ? So we will go back to the WG synchronization issue that has been raised=
 for this technology ..."
>
> That's why I suggested SRV2. We are revisiting source routing with new co=
ncepts. More generic number/action behavior.
>
> Peter
>
> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On=20
> Behalf Of [email-masked]
> Sent: Tuesday, September 03, 2013 10:43 AM
> To: AshwoodsmithPeter
> Cc: [email-masked]
> Subject: Re: [Status] Summary of STATUS BOF and the next steps
>
>
> There was a misunderstanding in my small comment :) so I will explain mor=
e :
>
> In segment routing, you have more than basic source routing : segment rou=
ting is just associate a segment number to an action and then combine segme=
nt as you want, yes you can do source routing, but you also can do more.
>
> In the other hand, I completely agree with your statement that source=20
> routing is generic and dataplane agnostic, as segment routing is ...=20
> (segment routing is not a new dataplane ...)
>
> Now the definition of the WG naming must be inline with the charter=20
> that will be defined ... (draft today)
>
> Based on the already existing consensus (at least for MPLS dataplane) bro=
ught up during Berlin STATUS BOF meeting, segment routing sounds to be a go=
od target candidate.
>
> So now, do we want to do more in the WG charter than just make progressin=
g segment routing architecture and uses cases document and ensure coordinat=
ion for the standardization of this technology ?
>
> Do we want to standardize other technologies in this WG ? I don't think s=
o, based on Stewart's conclusion email from the BOF :"A new WG focused sole=
ly on SR therefore needs to be create"
>
> If the WG charter is limited to source routing, how will we handle the "n=
on source routing" use cases of segment routing ? In another working group =
? So we will go back to the WG synchronization issue that has been raised f=
or this technology ...
>
> If the WG is focused on SR, let's use a name in relation with SR.
>
> Feedback ?
>
>
> Stephane
>
>
> -----Message d'origine-----
> De : AshwoodsmithPeter [mailto:[email-masked]]
> Envoy=E9 : mardi 3 septembre 2013 15:27
> =C0 : LITKOWSKI Stephane DTF/DERX
> Cc : John E Drake; Mark Townsley; Victor Kuarsingh; Roberta Maglione=20
> (robmgl); John G. Scudder; Adrian Farrel; Alvaro Retana (aretana);=20
> [email-masked]; Stewart Bryant (stbryant) Objet : Re: [Status]=20
> Summary of STATUS BOF and the next steps
>
> The term "source routing" has been around for a very long time and is dat=
a path agnostic. Its also the term used in the literature etc so my prefere=
nce is to stick with this existing well known and data path agnostic term.
>
> Peter
>
> On Sep 3, 2013, at 9:07 AM, "[email-masked]" <stephane.lit=
[email-masked]> wrote:
>
>> Hi,
>>
>> "Source routing" is just a subcase of segment routing ... as it is for I=
P routing ...
>>
>> Stephane
>>
>>
>> -----Message d'origine-----
>> De : [email-masked] [mailto:[email-masked]] De la=20
>> part de John E Drake Envoy=E9 : mardi 3 septembre 2013 15:02 =C0 : Mark=
=20
>> Townsley; Victor Kuarsingh Cc : Roberta Maglione (robmgl); John G.
>> Scudder; Alvaro Retana (aretana); Adrian Farrel; [email-masked];=20
>> Stewart Bryant (stbryant) Objet : Re: [Status] Summary of STATUS BOF=20
>> and the next steps
>>
>> Hi,
>>
>> What is this 'segment routing' silliness?  The correct term is 'source r=
outing'.
>>
>> Yours Irrespectively,
>>
>> John
>>
>>> -----Original Message-----
>>> From: [email-masked] [mailto:[email-masked]] On=20
>>> Behalf Of Mark Townsley
>>> Sent: Sunday, September 01, 2013 10:08 AM
>>> To: Victor Kuarsingh
>>> Cc: Roberta Maglione (robmgl); John G. Scudder; Adrian Farrel;=20
>>> Alvaro Retana (aretana); [email-masked]; Stewart Bryant (stbryant)
>>> Subject: Re: [Status] Summary of STATUS BOF and the next steps
>>>
>>>
>>> On Sep 1, 2013, at 5:38 PM, Victor Kuarsingh wrote:
>>>
>>>> All,
>>>>
>>>> I would also favour "Segment Routing WG" as well.
>>>>
>>>> I note this since attempting to come up with an all encompassing=20
>>>> acronym will be difficult and Segment Routing is generic enough to=20
>>>> associate to multiple functions.
>>>
>>> Then we can just use "segroute" for the short name. WGs do not have=20
>>> to have acronyms, but they do need to have an 8-char limited short=20
>>> name for the various automated tools not to break.
>>>
>>> - Mark
>>>
>>>>
>>>> Regards,
>>>>
>>>> Victor K
>>>>
>>>>
>>>>
>>>> On 2013-08-31 6:51 PM, "Roberta Maglione (robmgl)"
>>>> <[email-masked]>
>>>> wrote:
>>>>
>>>>> +1 for Segment Routing WG
>>>>>
>>>>> Roberta
>>>>>
>>>>> Sent from my iPad
>>>>>
>>>>> On 2013-08-30, at 2:55 PM, "Alvaro Retana (aretana)"
>>>>> <[email-masked]>
>>>>> wrote:
>>>>>
>>>>>> Segment Routing WG
>>>>>>
>>>>>> Sent from my iPhone
>>>>>>
>>>>>> On Aug 30, 2013, at 1:39 PM, "Stewart Bryant (stbryant)"
>>>>>> <[email-masked]> wrote:
>>>>>>
>>>>>>> The second task, which hopefully should be relatively easy, is=20
>>>>>>> to find a better working name for the WG, since it has been put=20
>>>>>>> to me a number of times that STATUS is going to be confusing in=20
>>>>>>> text and a difficult search term.
>>>>>> _______________________________________________
>>>>>> status mailing list
>>>>>> [email-masked]
>>>>>> https://www.ietf.org/mailman/listinfo/status
>>>>> _______________________________________________
>>>>> status mailing list
>>>>> [email-masked]
>>>>> https://www.ietf.org/mailman/listinfo/status
>>>>
>>>>
>>>> _______________________________________________
>>>> status mailing list
>>>> [email-masked]
>>>> https://www.ietf.org/mailman/listinfo/status
>>>
>>> _______________________________________________
>>> status mailing list
>>> [email-masked]
>>> https://www.ietf.org/mailman/listinfo/status
>>
>>
>> _______________________________________________
>> status mailing list
>> [email-masked]
>> https://www.ietf.org/mailman/listinfo/status
>>
>> _____________________________________________________________________
>> _ ___________________________________________________
>>
>> Ce message et ses pieces jointes peuvent contenir des informations=20
>> confidentielles ou privilegiees et ne doivent donc pas etre diffuses,=20
>> exploites ou copies sans autorisation. Si vous avez recu ce message=20
>> par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que=
 les pieces jointes. Les messages electroniques etant susceptibles d'altera=
tion, Orange decline toute responsabilite si ce message a ete altere, defor=
me ou falsifie. Merci.
>>
>> This message and its attachments may contain confidential or=20
>> privileged information that may be protected by law; they should not be =
distributed, used or copied without authorisation.
>> If you have received this email in error, please notify the sender and d=
elete this message and its attachments.
>> As emails may be altered, Orange is not liable for messages that have be=
en modified, changed or falsified.
>> Thank you.
>>
>> _______________________________________________
>> status mailing list
>> [email-masked]
>> https://www.ietf.org/mailman/listinfo/status
>
> ______________________________________________________________________
> ___________________________________________________
>
> Ce message et ses pieces jointes peuvent contenir des informations=20
> confidentielles ou privilegiees et ne doivent donc pas etre diffuses,=20
> exploites ou copies sans autorisation. Si vous avez recu ce message=20
> par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que =
les pieces jointes. Les messages electroniques etant susceptibles d'alterat=
ion, Orange decline toute responsabilite si ce message a ete altere, deform=
e ou falsifie. Merci.
>
> This message and its attachments may contain confidential or=20
> privileged information that may be protected by law; they should not be d=
istributed, used or copied without authorisation.
> If you have received this email in error, please notify the sender and de=
lete this message and its attachments.
> As emails may be altered, Orange is not liable for messages that have bee=
n modified, changed or falsified.
> Thank you.
>
> _______________________________________________
> status mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/status
> _______________________________________________
> status mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/status
>

--=20

Loa Andersson                        email: [email-masked]
Senior MPLS Expert                          [email-masked]
Huawei Technologies (consultant)     phone: +46 739 81 21 64
_______________________________________________
status mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/status

___________________________________________________________________________=
______________________________________________

Ce message et ses pieces jointes peuvent contenir des informations confiden=
tielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu=
 ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages el=
ectroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou =
falsifie. Merci.

This message and its attachments may contain confidential or privileged inf=
ormation that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and dele=
te this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been =
modified, changed or falsified.
Thank you.

Date: Tue, 03 Sep 2013 17:31:44 +0200
From: Loa Andersson <[email-masked]>
To: [email-masked]
Subject: Re: [Status] Summary of STATUS BOF and the next steps

Folks,

Excuse me if I'm slightly out of the loop, but so far I have not seen a
charter proposal, if there is one please point me to it.

It seems a bit odd to put the cart (what the wg should do) before the
horse (wg name). If we drill down the the charter first the wg name
might be easier to figure out.

/Loa

PS
OK I understand that the horse and cart analogy limps a  bit :).

On 2013-09-03 17:22, AshwoodsmithPeter wrote:
> " If the WG charter is limited to source routing, how will we handle the "non source routing" use cases of segment routing ? In another working group ? So we will go back to the WG synchronization issue that has been raised for this technology ..."
>
> That's why I suggested SRV2. We are revisiting source routing with new concepts. More generic number/action behavior.
>
> Peter
>
> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of [email-masked]
> Sent: Tuesday, September 03, 2013 10:43 AM
> To: AshwoodsmithPeter
> Cc: [email-masked]
> Subject: Re: [Status] Summary of STATUS BOF and the next steps
>
>
> There was a misunderstanding in my small comment :) so I will explain more :
>
> In segment routing, you have more than basic source routing : segment routing is just associate a segment number to an action and then combine segment as you want, yes you can do source routing, but you also can do more.
>
> In the other hand, I completely agree with your statement that source routing is generic and dataplane agnostic, as segment routing is ... (segment routing is not a new dataplane ...)
>
> Now the definition of the WG naming must be inline with the charter that will be defined ... (draft today)
>
> Based on the already existing consensus (at least for MPLS dataplane) brought up during Berlin STATUS BOF meeting, segment routing sounds to be a good target candidate.
>
> So now, do we want to do more in the WG charter than just make progressing segment routing architecture and uses cases document and ensure coordination for the standardization of this technology ?
>
> Do we want to standardize other technologies in this WG ? I don't think so, based on Stewart's conclusion email from the BOF :"A new WG focused solely on SR therefore needs to be create"
>
> If the WG charter is limited to source routing, how will we handle the "non source routing" use cases of segment routing ? In another working group ? So we will go back to the WG synchronization issue that has been raised for this technology ...
>
> If the WG is focused on SR, let's use a name in relation with SR.
>
> Feedback ?
>
>
> Stephane
>
>
> -----Message d'origine-----
> De : AshwoodsmithPeter [mailto:[email-masked]]
> Envoyé : mardi 3 septembre 2013 15:27
> À : LITKOWSKI Stephane DTF/DERX
> Cc : John E Drake; Mark Townsley; Victor Kuarsingh; Roberta Maglione (robmgl); John G. Scudder; Adrian Farrel; Alvaro Retana (aretana); [email-masked]; Stewart Bryant (stbryant) Objet : Re: [Status] Summary of STATUS BOF and the next steps
>
> The term "source routing" has been around for a very long time and is data path agnostic. Its also the term used in the literature etc so my preference is to stick with this existing well known and data path agnostic term.
>
> Peter
>
> On Sep 3, 2013, at 9:07 AM, "[email-masked]" <[email-masked]> wrote:
>
>> Hi,
>>
>> "Source routing" is just a subcase of segment routing ... as it is for IP routing ...
>>
>> Stephane
>>
>>
>> -----Message d'origine-----
>> De : [email-masked] [mailto:[email-masked]] De la
>> part de John E Drake Envoyé : mardi 3 septembre 2013 15:02 À : Mark
>> Townsley; Victor Kuarsingh Cc : Roberta Maglione (robmgl); John G.
>> Scudder; Alvaro Retana (aretana); Adrian Farrel; [email-masked];
>> Stewart Bryant (stbryant) Objet : Re: [Status] Summary of STATUS BOF
>> and the next steps
>>
>> Hi,
>>
>> What is this 'segment routing' silliness?  The correct term is 'source routing'.
>>
>> Yours Irrespectively,
>>
>> John
>>
>>> -----Original Message-----
>>> From: [email-masked] [mailto:[email-masked]] On
>>> Behalf Of Mark Townsley
>>> Sent: Sunday, September 01, 2013 10:08 AM
>>> To: Victor Kuarsingh
>>> Cc: Roberta Maglione (robmgl); John G. Scudder; Adrian Farrel; Alvaro
>>> Retana (aretana); [email-masked]; Stewart Bryant (stbryant)
>>> Subject: Re: [Status] Summary of STATUS BOF and the next steps
>>>
>>>
>>> On Sep 1, 2013, at 5:38 PM, Victor Kuarsingh wrote:
>>>
>>>> All,
>>>>
>>>> I would also favour "Segment Routing WG" as well.
>>>>
>>>> I note this since attempting to come up with an all encompassing
>>>> acronym will be difficult and Segment Routing is generic enough to
>>>> associate to multiple functions.
>>>
>>> Then we can just use "segroute" for the short name. WGs do not have
>>> to have acronyms, but they do need to have an 8-char limited short
>>> name for the various automated tools not to break.
>>>
>>> - Mark
>>>
>>>>
>>>> Regards,
>>>>
>>>> Victor K
>>>>
>>>>
>>>>
>>>> On 2013-08-31 6:51 PM, "Roberta Maglione (robmgl)"
>>>> <[email-masked]>
>>>> wrote:
>>>>
>>>>> +1 for Segment Routing WG
>>>>>
>>>>> Roberta
>>>>>
>>>>> Sent from my iPad
>>>>>
>>>>> On 2013-08-30, at 2:55 PM, "Alvaro Retana (aretana)"
>>>>> <[email-masked]>
>>>>> wrote:
>>>>>
>>>>>> Segment Routing WG
>>>>>>
>>>>>> Sent from my iPhone
>>>>>>
>>>>>> On Aug 30, 2013, at 1:39 PM, "Stewart Bryant (stbryant)"
>>>>>> <[email-masked]> wrote:
>>>>>>
>>>>>>> The second task, which hopefully should be relatively easy, is to
>>>>>>> find a better working name for the WG, since it has been put to
>>>>>>> me a number of times that STATUS is going to be confusing in text
>>>>>>> and a difficult search term.
>>>>>> _______________________________________________
>>>>>> status mailing list
>>>>>> [email-masked]
>>>>>> https://www.ietf.org/mailman/listinfo/status
>>>>> _______________________________________________
>>>>> status mailing list
>>>>> [email-masked]
>>>>> https://www.ietf.org/mailman/listinfo/status
>>>>
>>>>
>>>> _______________________________________________
>>>> status mailing list
>>>> [email-masked]
>>>> https://www.ietf.org/mailman/listinfo/status
>>>
>>> _______________________________________________
>>> status mailing list
>>> [email-masked]
>>> https://www.ietf.org/mailman/listinfo/status
>>
>>
>> _______________________________________________
>> status mailing list
>> [email-masked]
>> https://www.ietf.org/mailman/listinfo/status
>>
>> ______________________________________________________________________
>> ___________________________________________________
>>
>> Ce message et ses pieces jointes peuvent contenir des informations
>> confidentielles ou privilegiees et ne doivent donc pas etre diffuses,
>> exploites ou copies sans autorisation. Si vous avez recu ce message
>> par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration, Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.
>>
>> This message and its attachments may contain confidential or
>> privileged information that may be protected by law; they should not be distributed, used or copied without authorisation.
>> If you have received this email in error, please notify the sender and delete this message and its attachments.
>> As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.
>> Thank you.
>>
>> _______________________________________________
>> status mailing list
>> [email-masked]
>> https://www.ietf.org/mailman/listinfo/status
>
> _________________________________________________________________________________________________________________________
>
> Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc
> pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler
> a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,
> Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.
>
> This message and its attachments may contain confidential or privileged information that may be protected by law;
> they should not be distributed, used or copied without authorisation.
> If you have received this email in error, please notify the sender and delete this message and its attachments.
> As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.
> Thank you.
>
> _______________________________________________
> status mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/status
> _______________________________________________
> status mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/status
>

-- 

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

From: AshwoodsmithPeter <[email-masked]>
To: "[email-masked]" <[email-masked]>
Date: Tue, 3 Sep 2013 15:22:17 +0000
Accept-Language: en-US, zh-CN
Cc: "[email-masked]" <[email-masked]>
Subject: Re: [Status] Summary of STATUS BOF and the next steps

" If the WG charter is limited to source routing, how will we handle the "n=
on source routing" use cases of segment routing ? In another working group =
? So we will go back to the WG synchronization issue that has been raised f=
or this technology ..."

That's why I suggested SRV2. We are revisiting source routing with new conc=
epts. More generic number/action behavior.=20

Peter

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of=
 [email-masked]
Sent: Tuesday, September 03, 2013 10:43 AM
To: AshwoodsmithPeter
Cc: [email-masked]
Subject: Re: [Status] Summary of STATUS BOF and the next steps

=20
There was a misunderstanding in my small comment :) so I will explain more =
:

In segment routing, you have more than basic source routing : segment routi=
ng is just associate a segment number to an action and then combine segment=
 as you want, yes you can do source routing, but you also can do more.

In the other hand, I completely agree with your statement that source routi=
ng is generic and dataplane agnostic, as segment routing is ... (segment ro=
uting is not a new dataplane ...)

Now the definition of the WG naming must be inline with the charter that wi=
ll be defined ... (draft today)
=20
Based on the already existing consensus (at least for MPLS dataplane) broug=
ht up during Berlin STATUS BOF meeting, segment routing sounds to be a good=
 target candidate.

So now, do we want to do more in the WG charter than just make progressing =
segment routing architecture and uses cases document and ensure coordinatio=
n for the standardization of this technology ?
=20
Do we want to standardize other technologies in this WG ? I don't think so,=
 based on Stewart's conclusion email from the BOF :"A new WG focused solely=
 on SR therefore needs to be create"

If the WG charter is limited to source routing, how will we handle the "non=
 source routing" use cases of segment routing ? In another working group ? =
So we will go back to the WG synchronization issue that has been raised for=
 this technology ...

If the WG is focused on SR, let's use a name in relation with SR.

Feedback ?

Stephane

-----Message d'origine-----
De : AshwoodsmithPeter [mailto:[email-masked]]
Envoy=E9 : mardi 3 septembre 2013 15:27
=C0 : LITKOWSKI Stephane DTF/DERX
Cc : John E Drake; Mark Townsley; Victor Kuarsingh; Roberta Maglione (robmg=
l); John G. Scudder; Adrian Farrel; Alvaro Retana (aretana); [email-masked]=
g; Stewart Bryant (stbryant) Objet : Re: [Status] Summary of STATUS BOF and=
 the next steps

The term "source routing" has been around for a very long time and is data =
path agnostic. Its also the term used in the literature etc so my preferenc=
e is to stick with this existing well known and data path agnostic term.

Peter

On Sep 3, 2013, at 9:07 AM, "[email-masked]" <stephane.litko=
[email-masked]> wrote:

> Hi,
>=20
> "Source routing" is just a subcase of segment routing ... as it is for IP=
 routing ...
>=20
> Stephane
>=20
>=20
> -----Message d'origine-----
> De : [email-masked] [mailto:[email-masked]] De la=20
> part de John E Drake Envoy=E9 : mardi 3 septembre 2013 15:02 =C0 : Mark=20
> Townsley; Victor Kuarsingh Cc : Roberta Maglione (robmgl); John G.
> Scudder; Alvaro Retana (aretana); Adrian Farrel; [email-masked];=20
> Stewart Bryant (stbryant) Objet : Re: [Status] Summary of STATUS BOF=20
> and the next steps
>=20
> Hi,
>=20
> What is this 'segment routing' silliness?  The correct term is 'source ro=
uting'.=20
>=20
> Yours Irrespectively,
>=20
> John
>=20
>> -----Original Message-----
>> From: [email-masked] [mailto:[email-masked]] On=20
>> Behalf Of Mark Townsley
>> Sent: Sunday, September 01, 2013 10:08 AM
>> To: Victor Kuarsingh
>> Cc: Roberta Maglione (robmgl); John G. Scudder; Adrian Farrel; Alvaro=20
>> Retana (aretana); [email-masked]; Stewart Bryant (stbryant)
>> Subject: Re: [Status] Summary of STATUS BOF and the next steps
>>=20
>>=20
>> On Sep 1, 2013, at 5:38 PM, Victor Kuarsingh wrote:
>>=20
>>> All,
>>>=20
>>> I would also favour "Segment Routing WG" as well.
>>>=20
>>> I note this since attempting to come up with an all encompassing=20
>>> acronym will be difficult and Segment Routing is generic enough to=20
>>> associate to multiple functions.
>>=20
>> Then we can just use "segroute" for the short name. WGs do not have=20
>> to have acronyms, but they do need to have an 8-char limited short=20
>> name for the various automated tools not to break.
>>=20
>> - Mark
>>=20
>>>=20
>>> Regards,
>>>=20
>>> Victor K
>>>=20
>>>=20
>>>=20
>>> On 2013-08-31 6:51 PM, "Roberta Maglione (robmgl)"=20
>>> <[email-masked]>
>>> wrote:
>>>=20
>>>> +1 for Segment Routing WG
>>>>=20
>>>> Roberta
>>>>=20
>>>> Sent from my iPad
>>>>=20
>>>> On 2013-08-30, at 2:55 PM, "Alvaro Retana (aretana)"
>>>> <[email-masked]>
>>>> wrote:
>>>>=20
>>>>> Segment Routing WG
>>>>>=20
>>>>> Sent from my iPhone
>>>>>=20
>>>>> On Aug 30, 2013, at 1:39 PM, "Stewart Bryant (stbryant)"
>>>>> <[email-masked]> wrote:
>>>>>=20
>>>>>> The second task, which hopefully should be relatively easy, is to=20
>>>>>> find a better working name for the WG, since it has been put to=20
>>>>>> me a number of times that STATUS is going to be confusing in text=20
>>>>>> and a difficult search term.
>>>>> _______________________________________________
>>>>> status mailing list
>>>>> [email-masked]
>>>>> https://www.ietf.org/mailman/listinfo/status
>>>> _______________________________________________
>>>> status mailing list
>>>> [email-masked]
>>>> https://www.ietf.org/mailman/listinfo/status
>>>=20
>>>=20
>>> _______________________________________________
>>> status mailing list
>>> [email-masked]
>>> https://www.ietf.org/mailman/listinfo/status
>>=20
>> _______________________________________________
>> status mailing list
>> [email-masked]
>> https://www.ietf.org/mailman/listinfo/status
>=20
>=20
> _______________________________________________
> status mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/status
>=20
> ______________________________________________________________________
> ___________________________________________________
>=20
> Ce message et ses pieces jointes peuvent contenir des informations=20
> confidentielles ou privilegiees et ne doivent donc pas etre diffuses,=20
> exploites ou copies sans autorisation. Si vous avez recu ce message=20
> par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que =
les pieces jointes. Les messages electroniques etant susceptibles d'alterat=
ion, Orange decline toute responsabilite si ce message a ete altere, deform=
e ou falsifie. Merci.
>=20
> This message and its attachments may contain confidential or=20
> privileged information that may be protected by law; they should not be d=
istributed, used or copied without authorisation.
> If you have received this email in error, please notify the sender and de=
lete this message and its attachments.
> As emails may be altered, Orange is not liable for messages that have bee=
n modified, changed or falsified.
> Thank you.
>=20
> _______________________________________________
> status mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/status

___________________________________________________________________________=
______________________________________________

Ce message et ses pieces jointes peuvent contenir des informations confiden=
tielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu=
 ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages el=
ectroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou =
falsifie. Merci.

This message and its attachments may contain confidential or privileged inf=
ormation that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and dele=
te this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been =
modified, changed or falsified.
Thank you.

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

From: AshwoodsmithPeter <[email-masked]>
To: "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>
Date: Tue, 3 Sep 2013 15:14:02 +0000
Accept-Language: en-US, zh-CN
Subject: Re: [Status] Summary of STATUS BOF and the next steps

Roughly speaking we have three well known transit behaviors for packet forw=
arding which can be added recursively at various boundaries.

Hop-by-hop            =3D> out interface =3D F(packet.destination)
Label-substitution    =3D> out interface =3D F(incoming port, packet.label)
Source routing        =3D> out interface =3D packet.hop[packet.nexthop++]

These terms have all been used independently of the underlying data planes,=
 eg IP, Ethernet, ATM, MPLS, etc. for nearly 20 years.

Segment routing is the use of recursive label-substitution to implement sou=
rce routing like behavior because there is no packet.nexthop++ operation in=
 existing MPLS hardware, so it does not seem agnostic of MPLS which was one=
 of the stated goals of the charter.

Not to say it's not a great thing to do and very useful, but terminology wi=
se I don't think it meets the stated agnostic requirement.=20

Peter

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of=
 [email-masked]
Sent: Tuesday, September 03, 2013 10:30 AM
To: [email-masked]; [email-masked]
Subject: Re: [Status] Summary of STATUS BOF and the next steps

+1

Regarding the MPLS dataplane, it's mostly about using the IGP as the (intra=
 AS) label distribution protocol for both SPT and 1 hop LSP. Then this allo=
ws for easier stacking of LSP/segments as any LSR knows all the LSP/segment=
s of the AS, which can then be used for different use cases as presented du=
ring the BOF. This is not source routing from the source of the IP packet.

Regards,
Bruno

>From: [email-masked]
>
>Stewart,
>
>to name a WG "Source Routing WG" just because it allows a more organised w=
ay
>of exploiting features of an MPLS network, and that limited to paths and
>routers where an operator desires to utlise these features doesn't seem to
>be a good idea.
>
>Segment Routing describes what the company I work for will be using it. We
>don't intend to operate a source routed network. It's an enhancement as
>compared to LDP based MPLS.
>
>Regards,
>
>Ruediger
>
>-----Original Message-----
>From: [email-masked] [mailto:[email-masked]] On Behalf O=
f
>Stewart Bryant
>Sent: Tuesday, September 03, 2013 3:33 PM
>To: [email-masked]
>Cc: John E Drake; Mark Townsley; Victor Kuarsingh; Roberta Maglione
>(robmgl); John G. Scudder; Adrian Farrel; Alvaro Retana (aretana);
>[email-masked]
>Subject: Re: [Status] Summary of STATUS BOF and the next steps
>
>Stephane
>
>That is not correct. A long time ago there was source routed transparent
>which was a token ring technology.
>
>Stewart
>
>On 03/09/2013 14:06, [email-masked] wrote:
>> Hi,
>>
>> "Source routing" is just a subcase of segment routing ... as it is for I=
P
>routing ...
>>
>> Stephane
>>
>>
>> -----Message d'origine-----
>> De : [email-masked] [mailto:[email-masked]] De la part
>de John E Drake
>> Envoy=E9 : mardi 3 septembre 2013 15:02
>> =C0 : Mark Townsley; Victor Kuarsingh
>> Cc : Roberta Maglione (robmgl); John G. Scudder; Alvaro Retana (aretana)=
;
>Adrian Farrel; [email-masked]; Stewart Bryant (stbryant)
>> Objet : Re: [Status] Summary of STATUS BOF and the next steps
>>
>> Hi,
>>
>> What is this 'segment routing' silliness?  The correct term is 'source
>routing'.
>>
>> Yours Irrespectively,
>>
>> John
>>
>>> -----Original Message-----
>>> From: [email-masked] [mailto:[email-masked]] On
>>> Behalf Of Mark Townsley
>>> Sent: Sunday, September 01, 2013 10:08 AM
>>> To: Victor Kuarsingh
>>> Cc: Roberta Maglione (robmgl); John G. Scudder; Adrian Farrel; Alvaro
>>> Retana (aretana); [email-masked]; Stewart Bryant (stbryant)
>>> Subject: Re: [Status] Summary of STATUS BOF and the next steps
>>>
>>>
>>> On Sep 1, 2013, at 5:38 PM, Victor Kuarsingh wrote:
>>>
>>>> All,
>>>>
>>>> I would also favour "Segment Routing WG" as well.
>>>>
>>>> I note this since attempting to come up with an all encompassing
>>>> acronym will be difficult and Segment Routing is generic enough to
>>>> associate to multiple functions.
>>> Then we can just use "segroute" for the short name. WGs do not have to
>>> have acronyms, but they do need to have an 8-char limited short name
>>> for the various automated tools not to break.
>>>
>>> - Mark
>>>
>>>> Regards,
>>>>
>>>> Victor K
>>>>
>>>>
>>>>
>>>> On 2013-08-31 6:51 PM, "Roberta Maglione (robmgl)"
>>>> <[email-masked]>
>>>> wrote:
>>>>
>>>>> +1 for Segment Routing WG
>>>>>
>>>>> Roberta
>>>>>
>>>>> Sent from my iPad
>>>>>
>>>>> On 2013-08-30, at 2:55 PM, "Alvaro Retana (aretana)"
>>>>> <[email-masked]>
>>>>> wrote:
>>>>>
>>>>>> Segment Routing WG
>>>>>>
>>>>>> Sent from my iPhone
>>>>>>
>>>>>> On Aug 30, 2013, at 1:39 PM, "Stewart Bryant (stbryant)"
>>>>>> <[email-masked]> wrote:
>>>>>>
>>>>>>> The second task, which hopefully should be relatively easy, is to
>>>>>>> find a better working name for the WG, since it has been put to
>>>>>>> me a number of times that STATUS is going to be confusing in text
>>>>>>> and a difficult search term.
>>>>>> _______________________________________________
>>>>>> status mailing list
>>>>>> [email-masked]
>>>>>> https://www.ietf.org/mailman/listinfo/status
>>>>> _______________________________________________
>>>>> status mailing list
>>>>> [email-masked]
>>>>> https://www.ietf.org/mailman/listinfo/status
>>>>
>>>> _______________________________________________
>>>> status mailing list
>>>> [email-masked]
>>>> https://www.ietf.org/mailman/listinfo/status
>>> _______________________________________________
>>> status mailing list
>>> [email-masked]
>>> https://www.ietf.org/mailman/listinfo/status
>>>
>>
>> _______________________________________________
>> status mailing list
>> [email-masked]
>> https://www.ietf.org/mailman/listinfo/status
>>
>>
>__________________________________________________________________________=
__
>_____________________________________________
>>
>> Ce message et ses pieces jointes peuvent contenir des informations
>confidentielles ou privilegiees et ne doivent donc
>> pas etre diffuses, exploites ou copies sans autorisation. Si vous avez
>recu ce message par erreur, veuillez le signaler
>> a l'expediteur et le detruire ainsi que les pieces jointes. Les messages
>electroniques etant susceptibles d'alteration,
>> Orange decline toute responsabilite si ce message a ete altere, deforme =
ou
>falsifie. Merci.
>>
>> This message and its attachments may contain confidential or privileged
>information that may be protected by law;
>> they should not be distributed, used or copied without authorisation.
>> If you have received this email in error, please notify the sender and
>delete this message and its attachments.
>> As emails may be altered, Orange is not liable for messages that have be=
en
>modified, changed or falsified.
>> Thank you.
>>
>> .
>>
>
>
>--
>For corporate legal information go to:
>
>http://www.cisco.com/web/about/doing_business/legal/cri/index.html
>
>_______________________________________________
>status mailing list
>[email-masked]
>https://www.ietf.org/mailman/listinfo/status
>_______________________________________________
>status mailing list
>[email-masked]
>https://www.ietf.org/mailman/listinfo/status

___________________________________________________________________________=
______________________________________________

Ce message et ses pieces jointes peuvent contenir des informations confiden=
tielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu=
 ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages el=
ectroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou =
falsifie. Merci.

This message and its attachments may contain confidential or privileged inf=
ormation that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and dele=
te this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been =
modified, changed or falsified.
Thank you.

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

From: <[email-masked]>
To: AshwoodsmithPeter <[email-masked]>
Date: Tue, 3 Sep 2013 16:43:26 +0200
Accept-Language: fr-FR
acceptlanguage: fr-FR
Cc: "[email-masked]" <[email-masked]>
Subject: Re: [Status] Summary of STATUS BOF and the next steps

=20
There was a misunderstanding in my small comment :) so I will explain more :

In segment routing, you have more than basic source routing : segment routi=
ng is just associate a segment number to an action and then combine segment=
 as you want, yes you can do source routing, but you also can do more.

In the other hand, I completely agree with your statement that source routi=
ng is generic and dataplane agnostic, as segment routing is ... (segment ro=
uting is not a new dataplane ...)

Now the definition of the WG naming must be inline with the charter that wi=
ll be defined ... (draft today)
=20
Based on the already existing consensus (at least for MPLS dataplane) broug=
ht up during Berlin STATUS BOF meeting, segment routing sounds to be a good=
 target candidate.

So now, do we want to do more in the WG charter than just make progressing =
segment routing architecture and uses cases document and ensure coordinatio=
n for the standardization of this technology ?
=20
Do we want to standardize other technologies in this WG ? I don't think so,=
 based on Stewart's conclusion email from the BOF :"A new WG focused solely=
 on SR therefore needs to be create"

If the WG charter is limited to source routing, how will we handle the "non=
 source routing" use cases of segment routing ? In another working group ? =
So we will go back to the WG synchronization issue that has been raised for=
 this technology ...

If the WG is focused on SR, let's use a name in relation with SR.

Feedback ?

Stephane

-----Message d'origine-----
De : AshwoodsmithPeter [mailto:[email-masked]]
Envoy=E9 : mardi 3 septembre 2013 15:27
=C0 : LITKOWSKI Stephane DTF/DERX
Cc : John E Drake; Mark Townsley; Victor Kuarsingh; Roberta Maglione (robmg=
l); John G. Scudder; Adrian Farrel; Alvaro Retana (aretana); [email-masked]=
g; Stewart Bryant (stbryant) Objet : Re: [Status] Summary of STATUS BOF and=
 the next steps

The term "source routing" has been around for a very long time and is data =
path agnostic. Its also the term used in the literature etc so my preferenc=
e is to stick with this existing well known and data path agnostic term.

Peter

On Sep 3, 2013, at 9:07 AM, "[email-masked]" <stephane.litko=
[email-masked]> wrote:

> Hi,
>=20
> "Source routing" is just a subcase of segment routing ... as it is for IP=
 routing ...
>=20
> Stephane
>=20
>=20
> -----Message d'origine-----
> De : [email-masked] [mailto:[email-masked]] De la=20
> part de John E Drake Envoy=E9 : mardi 3 septembre 2013 15:02 =C0 : Mark=
=20
> Townsley; Victor Kuarsingh Cc : Roberta Maglione (robmgl); John G.
> Scudder; Alvaro Retana (aretana); Adrian Farrel; [email-masked];=20
> Stewart Bryant (stbryant) Objet : Re: [Status] Summary of STATUS BOF=20
> and the next steps
>=20
> Hi,
>=20
> What is this 'segment routing' silliness?  The correct term is 'source ro=
uting'.=20
>=20
> Yours Irrespectively,
>=20
> John
>=20
>> -----Original Message-----
>> From: [email-masked] [mailto:[email-masked]] On=20
>> Behalf Of Mark Townsley
>> Sent: Sunday, September 01, 2013 10:08 AM
>> To: Victor Kuarsingh
>> Cc: Roberta Maglione (robmgl); John G. Scudder; Adrian Farrel; Alvaro=20
>> Retana (aretana); [email-masked]; Stewart Bryant (stbryant)
>> Subject: Re: [Status] Summary of STATUS BOF and the next steps
>>=20
>>=20
>> On Sep 1, 2013, at 5:38 PM, Victor Kuarsingh wrote:
>>=20
>>> All,
>>>=20
>>> I would also favour "Segment Routing WG" as well.
>>>=20
>>> I note this since attempting to come up with an all encompassing=20
>>> acronym will be difficult and Segment Routing is generic enough to=20
>>> associate to multiple functions.
>>=20
>> Then we can just use "segroute" for the short name. WGs do not have=20
>> to have acronyms, but they do need to have an 8-char limited short=20
>> name for the various automated tools not to break.
>>=20
>> - Mark
>>=20
>>>=20
>>> Regards,
>>>=20
>>> Victor K
>>>=20
>>>=20
>>>=20
>>> On 2013-08-31 6:51 PM, "Roberta Maglione (robmgl)"=20
>>> <[email-masked]>
>>> wrote:
>>>=20
>>>> +1 for Segment Routing WG
>>>>=20
>>>> Roberta
>>>>=20
>>>> Sent from my iPad
>>>>=20
>>>> On 2013-08-30, at 2:55 PM, "Alvaro Retana (aretana)"
>>>> <[email-masked]>
>>>> wrote:
>>>>=20
>>>>> Segment Routing WG
>>>>>=20
>>>>> Sent from my iPhone
>>>>>=20
>>>>> On Aug 30, 2013, at 1:39 PM, "Stewart Bryant (stbryant)"
>>>>> <[email-masked]> wrote:
>>>>>=20
>>>>>> The second task, which hopefully should be relatively easy, is to=20
>>>>>> find a better working name for the WG, since it has been put to=20
>>>>>> me a number of times that STATUS is going to be confusing in text=20
>>>>>> and a difficult search term.
>>>>> _______________________________________________
>>>>> status mailing list
>>>>> [email-masked]
>>>>> https://www.ietf.org/mailman/listinfo/status
>>>> _______________________________________________
>>>> status mailing list
>>>> [email-masked]
>>>> https://www.ietf.org/mailman/listinfo/status
>>>=20
>>>=20
>>> _______________________________________________
>>> status mailing list
>>> [email-masked]
>>> https://www.ietf.org/mailman/listinfo/status
>>=20
>> _______________________________________________
>> status mailing list
>> [email-masked]
>> https://www.ietf.org/mailman/listinfo/status
>=20
>=20
> _______________________________________________
> status mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/status
>=20
> ______________________________________________________________________
> ___________________________________________________
>=20
> Ce message et ses pieces jointes peuvent contenir des informations=20
> confidentielles ou privilegiees et ne doivent donc pas etre diffuses,=20
> exploites ou copies sans autorisation. Si vous avez recu ce message=20
> par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que =
les pieces jointes. Les messages electroniques etant susceptibles d'alterat=
ion, Orange decline toute responsabilite si ce message a ete altere, deform=
e ou falsifie. Merci.
>=20
> This message and its attachments may contain confidential or=20
> privileged information that may be protected by law; they should not be d=
istributed, used or copied without authorisation.
> If you have received this email in error, please notify the sender and de=
lete this message and its attachments.
> As emails may be altered, Orange is not liable for messages that have bee=
n modified, changed or falsified.
> Thank you.
>=20
> _______________________________________________
> status mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/status

___________________________________________________________________________=
______________________________________________

Ce message et ses pieces jointes peuvent contenir des informations confiden=
tielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu=
 ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages el=
ectroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou =
falsifie. Merci.

This message and its attachments may contain confidential or privileged inf=
ormation that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and dele=
te this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been =
modified, changed or falsified.
Thank you.

From: <[email-masked]>
To: AshwoodsmithPeter <[email-masked]>
Date: Tue, 3 Sep 2013 16:42:08 +0200
Accept-Language: fr-FR
acceptlanguage: fr-FR
Cc: John E Drake <[email-masked]>, Mark Townsley <[email-masked]>, Victor Kuarsingh <[email-masked]>, "Roberta Maglione \(robmgl\)" <[email-masked]>, "John G. Scudder" <[email-masked]>, "Alvaro Retana \(aretana\)" <[email-masked]>, Adrian Farrel <[email-masked]>, "[email-masked]" <[email-masked]>, "Stewart Bryant	\(stbryant\)" <[email-masked]>
Subject: Re: [Status] Summary of STATUS BOF and the next steps

There was a misunderstanding in my small comment :) so I will explain more :

In segment routing, you have more than basic source routing : segment routi=
ng is just associate a segment number to an action and then combine segment=
 as you want, yes you can do source routing, but you also can do more.

In the other hand, I completely agree with your statement that source routi=
ng is generic and dataplane agnostic, as segment routing is ... (segment ro=
uting is not a new dataplane ...)

Now the definition of the WG naming must be inline with the charter that wi=
ll be defined ... (draft today)
=20
Based on the already existing consensus (at least for MPLS dataplane) broug=
ht up during Berlin STATUS BOF meeting, segment routing sounds to be a good=
 target candidate.

So now, do we want to do more in the WG charter than just make progressing =
segment routing architecture and uses cases document and ensure coordinatio=
n for the standardization of this technology ?
=20
Do we want to standardize other technologies in this WG ? I don't think so,=
 based on Stewart's conclusion email from the BOF :"A new WG focused solely=
 on SR therefore needs to be create"

If the WG charter is limited to source routing, how will we handle the "non=
 source routing" use cases of segment routing ? In another working group ? =
So we will go back to the WG synchronization issue that has been raised for=
 this technology ...

If the WG is focused on SR, let's use a name in relation with SR.

Feedback ?

Stephane

-----Message d'origine-----
De : AshwoodsmithPeter [mailto:[email-masked]]=20
Envoy=E9 : mardi 3 septembre 2013 15:27
=C0 : LITKOWSKI Stephane DTF/DERX
Cc : John E Drake; Mark Townsley; Victor Kuarsingh; Roberta Maglione (robmg=
l); John G. Scudder; Adrian Farrel; Alvaro Retana (aretana); [email-masked]=
g; Stewart Bryant (stbryant)
Objet : Re: [Status] Summary of STATUS BOF and the next steps

The term "source routing" has been around for a very long time and is data =
path agnostic. Its also the term used in the literature etc so my preferenc=
e is to stick with this existing well known and data path agnostic term.

Peter

On Sep 3, 2013, at 9:07 AM, "[email-masked]" <stephane.litko=
[email-masked]> wrote:

> Hi,
>=20
> "Source routing" is just a subcase of segment routing ... as it is for IP=
 routing ...
>=20
> Stephane
>=20
>=20
> -----Message d'origine-----
> De : [email-masked] [mailto:[email-masked]] De la=20
> part de John E Drake Envoy=E9 : mardi 3 septembre 2013 15:02 =C0 : Mark=
=20
> Townsley; Victor Kuarsingh Cc : Roberta Maglione (robmgl); John G.=20
> Scudder; Alvaro Retana (aretana); Adrian Farrel; [email-masked];=20
> Stewart Bryant (stbryant) Objet : Re: [Status] Summary of STATUS BOF=20
> and the next steps
>=20
> Hi,
>=20
> What is this 'segment routing' silliness?  The correct term is 'source ro=
uting'.=20
>=20
> Yours Irrespectively,
>=20
> John
>=20
>> -----Original Message-----
>> From: [email-masked] [mailto:[email-masked]] On=20
>> Behalf Of Mark Townsley
>> Sent: Sunday, September 01, 2013 10:08 AM
>> To: Victor Kuarsingh
>> Cc: Roberta Maglione (robmgl); John G. Scudder; Adrian Farrel; Alvaro=20
>> Retana (aretana); [email-masked]; Stewart Bryant (stbryant)
>> Subject: Re: [Status] Summary of STATUS BOF and the next steps
>>=20
>>=20
>> On Sep 1, 2013, at 5:38 PM, Victor Kuarsingh wrote:
>>=20
>>> All,
>>>=20
>>> I would also favour "Segment Routing WG" as well.
>>>=20
>>> I note this since attempting to come up with an all encompassing=20
>>> acronym will be difficult and Segment Routing is generic enough to=20
>>> associate to multiple functions.
>>=20
>> Then we can just use "segroute" for the short name. WGs do not have=20
>> to have acronyms, but they do need to have an 8-char limited short=20
>> name for the various automated tools not to break.
>>=20
>> - Mark
>>=20
>>>=20
>>> Regards,
>>>=20
>>> Victor K
>>>=20
>>>=20
>>>=20
>>> On 2013-08-31 6:51 PM, "Roberta Maglione (robmgl)"=20
>>> <[email-masked]>
>>> wrote:
>>>=20
>>>> +1 for Segment Routing WG
>>>>=20
>>>> Roberta
>>>>=20
>>>> Sent from my iPad
>>>>=20
>>>> On 2013-08-30, at 2:55 PM, "Alvaro Retana (aretana)"
>>>> <[email-masked]>
>>>> wrote:
>>>>=20
>>>>> Segment Routing WG
>>>>>=20
>>>>> Sent from my iPhone
>>>>>=20
>>>>> On Aug 30, 2013, at 1:39 PM, "Stewart Bryant (stbryant)"
>>>>> <[email-masked]> wrote:
>>>>>=20
>>>>>> The second task, which hopefully should be relatively easy, is to=20
>>>>>> find a better working name for the WG, since it has been put to=20
>>>>>> me a number of times that STATUS is going to be confusing in text=20
>>>>>> and a difficult search term.
>>>>> _______________________________________________
>>>>> status mailing list
>>>>> [email-masked]
>>>>> https://www.ietf.org/mailman/listinfo/status
>>>> _______________________________________________
>>>> status mailing list
>>>> [email-masked]
>>>> https://www.ietf.org/mailman/listinfo/status
>>>=20
>>>=20
>>> _______________________________________________
>>> status mailing list
>>> [email-masked]
>>> https://www.ietf.org/mailman/listinfo/status
>>=20
>> _______________________________________________
>> status mailing list
>> [email-masked]
>> https://www.ietf.org/mailman/listinfo/status
>=20
>=20
> _______________________________________________
> status mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/status
>=20
> ______________________________________________________________________
> ___________________________________________________
>=20
> Ce message et ses pieces jointes peuvent contenir des informations=20
> confidentielles ou privilegiees et ne doivent donc pas etre diffuses,=20
> exploites ou copies sans autorisation. Si vous avez recu ce message=20
> par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que =
les pieces jointes. Les messages electroniques etant susceptibles d'alterat=
ion, Orange decline toute responsabilite si ce message a ete altere, deform=
e ou falsifie. Merci.
>=20
> This message and its attachments may contain confidential or=20
> privileged information that may be protected by law; they should not be d=
istributed, used or copied without authorisation.
> If you have received this email in error, please notify the sender and de=
lete this message and its attachments.
> As emails may be altered, Orange is not liable for messages that have bee=
n modified, changed or falsified.
> Thank you.
>=20
> _______________________________________________
> status mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/status

___________________________________________________________________________=
______________________________________________

Ce message et ses pieces jointes peuvent contenir des informations confiden=
tielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu=
 ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages el=
ectroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou =
falsifie. Merci.

This message and its attachments may contain confidential or privileged inf=
ormation that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and dele=
te this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been =
modified, changed or falsified.
Thank you.

From: <[email-masked]>
To: "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>
Date: Tue, 3 Sep 2013 14:29:35 +0000
Accept-Language: fr-FR, en-US
Subject: Re: [Status] Summary of STATUS BOF and the next steps

+1

Regarding the MPLS dataplane, it's mostly about using the IGP as the (intra=
 AS) label distribution protocol for both SPT and 1 hop LSP. Then this allo=
ws for easier stacking of LSP/segments as any LSR knows all the LSP/segment=
s of the AS, which can then be used for different use cases as presented du=
ring the BOF. This is not source routing from the source of the IP packet.

Regards,
Bruno

>From: [email-masked]
>
>Stewart,
>
>to name a WG "Source Routing WG" just because it allows a more organised w=
ay
>of exploiting features of an MPLS network, and that limited to paths and
>routers where an operator desires to utlise these features doesn't seem to
>be a good idea.
>
>Segment Routing describes what the company I work for will be using it. We
>don't intend to operate a source routed network. It's an enhancement as
>compared to LDP based MPLS.
>
>Regards,
>
>Ruediger
>
>-----Original Message-----
>From: [email-masked] [mailto:[email-masked]] On Behalf Of
>Stewart Bryant
>Sent: Tuesday, September 03, 2013 3:33 PM
>To: [email-masked]
>Cc: John E Drake; Mark Townsley; Victor Kuarsingh; Roberta Maglione
>(robmgl); John G. Scudder; Adrian Farrel; Alvaro Retana (aretana);
>[email-masked]
>Subject: Re: [Status] Summary of STATUS BOF and the next steps
>
>Stephane
>
>That is not correct. A long time ago there was source routed transparent
>which was a token ring technology.
>
>Stewart
>
>On 03/09/2013 14:06, [email-masked] wrote:
>> Hi,
>>
>> "Source routing" is just a subcase of segment routing ... as it is for IP
>routing ...
>>
>> Stephane
>>
>>
>> -----Message d'origine-----
>> De : [email-masked] [mailto:[email-masked]] De la part
>de John E Drake
>> Envoy=E9 : mardi 3 septembre 2013 15:02
>> =C0 : Mark Townsley; Victor Kuarsingh
>> Cc : Roberta Maglione (robmgl); John G. Scudder; Alvaro Retana (aretana);
>Adrian Farrel; [email-masked]; Stewart Bryant (stbryant)
>> Objet : Re: [Status] Summary of STATUS BOF and the next steps
>>
>> Hi,
>>
>> What is this 'segment routing' silliness?  The correct term is 'source
>routing'.
>>
>> Yours Irrespectively,
>>
>> John
>>
>>> -----Original Message-----
>>> From: [email-masked] [mailto:[email-masked]] On
>>> Behalf Of Mark Townsley
>>> Sent: Sunday, September 01, 2013 10:08 AM
>>> To: Victor Kuarsingh
>>> Cc: Roberta Maglione (robmgl); John G. Scudder; Adrian Farrel; Alvaro
>>> Retana (aretana); [email-masked]; Stewart Bryant (stbryant)
>>> Subject: Re: [Status] Summary of STATUS BOF and the next steps
>>>
>>>
>>> On Sep 1, 2013, at 5:38 PM, Victor Kuarsingh wrote:
>>>
>>>> All,
>>>>
>>>> I would also favour "Segment Routing WG" as well.
>>>>
>>>> I note this since attempting to come up with an all encompassing
>>>> acronym will be difficult and Segment Routing is generic enough to
>>>> associate to multiple functions.
>>> Then we can just use "segroute" for the short name. WGs do not have to
>>> have acronyms, but they do need to have an 8-char limited short name
>>> for the various automated tools not to break.
>>>
>>> - Mark
>>>
>>>> Regards,
>>>>
>>>> Victor K
>>>>
>>>>
>>>>
>>>> On 2013-08-31 6:51 PM, "Roberta Maglione (robmgl)"
>>>> <[email-masked]>
>>>> wrote:
>>>>
>>>>> +1 for Segment Routing WG
>>>>>
>>>>> Roberta
>>>>>
>>>>> Sent from my iPad
>>>>>
>>>>> On 2013-08-30, at 2:55 PM, "Alvaro Retana (aretana)"
>>>>> <[email-masked]>
>>>>> wrote:
>>>>>
>>>>>> Segment Routing WG
>>>>>>
>>>>>> Sent from my iPhone
>>>>>>
>>>>>> On Aug 30, 2013, at 1:39 PM, "Stewart Bryant (stbryant)"
>>>>>> <[email-masked]> wrote:
>>>>>>
>>>>>>> The second task, which hopefully should be relatively easy, is to
>>>>>>> find a better working name for the WG, since it has been put to
>>>>>>> me a number of times that STATUS is going to be confusing in text
>>>>>>> and a difficult search term.
>>>>>> _______________________________________________
>>>>>> status mailing list
>>>>>> [email-masked]
>>>>>> https://www.ietf.org/mailman/listinfo/status
>>>>> _______________________________________________
>>>>> status mailing list
>>>>> [email-masked]
>>>>> https://www.ietf.org/mailman/listinfo/status
>>>>
>>>> _______________________________________________
>>>> status mailing list
>>>> [email-masked]
>>>> https://www.ietf.org/mailman/listinfo/status
>>> _______________________________________________
>>> status mailing list
>>> [email-masked]
>>> https://www.ietf.org/mailman/listinfo/status
>>>
>>
>> _______________________________________________
>> status mailing list
>> [email-masked]
>> https://www.ietf.org/mailman/listinfo/status
>>
>>
>__________________________________________________________________________=
__
>_____________________________________________
>>
>> Ce message et ses pieces jointes peuvent contenir des informations
>confidentielles ou privilegiees et ne doivent donc
>> pas etre diffuses, exploites ou copies sans autorisation. Si vous avez
>recu ce message par erreur, veuillez le signaler
>> a l'expediteur et le detruire ainsi que les pieces jointes. Les messages
>electroniques etant susceptibles d'alteration,
>> Orange decline toute responsabilite si ce message a ete altere, deforme =
ou
>falsifie. Merci.
>>
>> This message and its attachments may contain confidential or privileged
>information that may be protected by law;
>> they should not be distributed, used or copied without authorisation.
>> If you have received this email in error, please notify the sender and
>delete this message and its attachments.
>> As emails may be altered, Orange is not liable for messages that have be=
en
>modified, changed or falsified.
>> Thank you.
>>
>> .
>>
>
>
>--
>For corporate legal information go to:
>
>http://www.cisco.com/web/about/doing_business/legal/cri/index.html
>
>_______________________________________________
>status mailing list
>[email-masked]
>https://www.ietf.org/mailman/listinfo/status
>_______________________________________________
>status mailing list
>[email-masked]
>https://www.ietf.org/mailman/listinfo/status

___________________________________________________________________________=
______________________________________________

Ce message et ses pieces jointes peuvent contenir des informations confiden=
tielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu=
 ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages el=
ectroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou =
falsifie. Merci.

This message and its attachments may contain confidential or privileged inf=
ormation that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and dele=
te this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been =
modified, changed or falsified.
Thank you.

To: [email-masked]
Date: Tue,  3 Sep 2013 10:19:12 -0400 (EDT)
From: [email-masked] (Noel Chiappa)
Subject: Re: [Status] Summary of STATUS BOF and the next steps

    > From: John E Drake <[email-masked]>

    > What is this 'segment routing' silliness? The correct term is 'source
    > routing'.

After a quick review of the I-D, I'm not so sure. To me, "source routing"
means... the source picks the path (specified either at a high level - 'loose
source route' - or at a low level - 'strict source route').

Which is why in Nimrod (RFC-1992) we did not use the term "source route",
because it tended to confuse people - newcomers saw that phrase "source
route" and applied their existing mental models - and went way wrong.

The I-D isn't as clear as I'd like (it seems to jumble together architectural
description and engineering detail - in the early sections, at least), but to
me, the first question to answer is 'who makes the path selection decisions'.

We have 'hop by hop' as a clearly understood term for one end of that
spectrum, and 'source routing' (classic version) for another end, but for
things in the middle (e.g. use of MPLS paths to carry datagram traffic along
an MPLS flow for _part_ of the packet's entire end-end path) we don't really
have clear terminology.

I tried, but could never come up with a good one: I tried "unitary routing"
for Nimrod's model (emphasizing that _one_ entity was in charge of selecting
the path, although perhaps in terms of high-level entities, with the path
selection process then recursing down to actual hardware, all using the same
basic model), but I was never happy with that. I later started using
"explicit routing", but I'm not sure that was any better.

"Segment routing" might in fact be a pretty good term to describe what this
design does (at least, as best I understand it).

But I'd suggest to the I-D writers that they focus on 'who makes the path
selection decision(s)' first, and only later talk about 'how that decisision
is carried out' (be it by a sequence of flow labels, or whatever - those are
secondary questions).

    > From: AshwoodsmithPeter <[email-masked]>

    > The term "source routing" has been around for a very long time .. Its
    > also the term used in the literature etc

Which means that it already has a meaning in people's minds - and, worse yet,
since it has been used to cover a lot of ground, those meanings may be
_different_ for different people.

(We really need better taxonomy of how paths are selected - as Saltzer
memorably said in RFC-1498, "trying to discuss the issues with too few
well-defined [terms] at hand" leads to confusion. There are a lot more
options for how paths are selected than just 'hop-by-hop' and 'classic source
route' - e.g. the existing MPLS stuff I alluded to above.)

Anyway, if the concept in this I-D is in some ways significantly different
from 'classic' source routing, use of that term will be confusing, so we
should not re-use that term.

	Noel

From: Gregory Mirsky <[email-masked]>
To: Loa Andersson <[email-masked]>, AshwoodsmithPeter <[email-masked]>
Date: Tue, 3 Sep 2013 14:04:52 +0000
Accept-Language: en-US
Cc: "[email-masked]" <[email-masked]>, John E Drake <[email-masked]>, Mark Townsley <[email-masked]>, Victor Kuarsingh <[email-masked]>, "Roberta Maglione \(robmgl\)" <[email-masked]>, "John G. Scudder" <[email-masked]>, "Alvaro Retana \(aretana\)" <[email-masked]>, Adrian Farrel <[email-masked]>, "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>
Subject: Re: [Status] Summary of STATUS BOF and the next steps

Unified Segment Source Routing (USSR)? ;)

	Regards,
		Greg

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of=
 Loa Andersson
Sent: Tuesday, September 03, 2013 6:58 AM
To: AshwoodsmithPeter
Cc: [email-masked]; John E Drake; Mark Townsley; Victor Kuar=
singh; Roberta Maglione (robmgl); John G. Scudder; Adrian Farrel; Alvaro Re=
tana (aretana); [email-masked]; [email-masked]
Subject: Re: [Status] Summary of STATUS BOF and the next steps

All,

I wonder - if this is true:

In segment routing the source to a (partial) source routing defining which =
segments (for any value of segment) that should be in the path.
Each segment may or may not be establish by source routing or any other rou=
ting technology.

If this is true - then a discussion on what is and what is not a sub-set of=
 the other will turn out to be extremely non-productive.

Also there is both "segment routing" and "source routing" - I could imagine=
 a case where which segment to use is not determined by the source but by a=
ny standard routing algorithm. If doing this has any value or not is for th=
e future.

/Loa

On 2013-09-03 15:41, AshwoodsmithPeter wrote:
> There was a lot of work on source routing mechanisms independent of IP. O=
ne rather cool example was a mechanism for routing through a constellation =
of polar orbit satellites. Geodesic I think it was called. There were also =
a number of other non IP proprietary source routing protocols deployed too.=
 Anyway I agree that the term is generic and not tied to IP any more than h=
op-by-hop routing is tied to IP.
>
> Peter
>
>
> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On=20
> Behalf Of Stewart Bryant
> Sent: Tuesday, September 03, 2013 9:33 AM
> To: [email-masked]
> Cc: John E Drake; Mark Townsley; Victor Kuarsingh; Roberta Maglione=20
> (robmgl); John G. Scudder; Adrian Farrel; Alvaro Retana (aretana);=20
> [email-masked]
> Subject: Re: [Status] Summary of STATUS BOF and the next steps
>
> Stephane
>
> That is not correct. A long time ago there was source routed=20
> transparent which was a token ring technology.
>
> Stewart
>
> On 03/09/2013 14:06, [email-masked] wrote:
>> Hi,
>>
>> "Source routing" is just a subcase of segment routing ... as it is for I=
P routing ...
>>
>> Stephane
>>
>>
>> -----Message d'origine-----
>> De : [email-masked] [mailto:[email-masked]] De la=20
>> part de John E Drake Envoy=E9 : mardi 3 septembre 2013 15:02 =C0 : Mark=
=20
>> Townsley; Victor Kuarsingh Cc : Roberta Maglione (robmgl); John G.=20
>> Scudder; Alvaro Retana (aretana); Adrian Farrel; [email-masked];=20
>> Stewart Bryant (stbryant) Objet : Re: [Status] Summary of STATUS BOF=20
>> and the next steps
>>
>> Hi,
>>
>> What is this 'segment routing' silliness?  The correct term is 'source r=
outing'.
>>
>> Yours Irrespectively,
>>
>> John
>>
>>> -----Original Message-----
>>> From: [email-masked] [mailto:[email-masked]] On=20
>>> Behalf Of Mark Townsley
>>> Sent: Sunday, September 01, 2013 10:08 AM
>>> To: Victor Kuarsingh
>>> Cc: Roberta Maglione (robmgl); John G. Scudder; Adrian Farrel;=20
>>> Alvaro Retana (aretana); [email-masked]; Stewart Bryant (stbryant)
>>> Subject: Re: [Status] Summary of STATUS BOF and the next steps
>>>
>>>
>>> On Sep 1, 2013, at 5:38 PM, Victor Kuarsingh wrote:
>>>
>>>> All,
>>>>
>>>> I would also favour "Segment Routing WG" as well.
>>>>
>>>> I note this since attempting to come up with an all encompassing=20
>>>> acronym will be difficult and Segment Routing is generic enough to=20
>>>> associate to multiple functions.
>>> Then we can just use "segroute" for the short name. WGs do not have=20
>>> to have acronyms, but they do need to have an 8-char limited short=20
>>> name for the various automated tools not to break.
>>>
>>> - Mark
>>>
>>>> Regards,
>>>>
>>>> Victor K
>>>>
>>>>
>>>>
>>>> On 2013-08-31 6:51 PM, "Roberta Maglione (robmgl)"
>>>> <[email-masked]>
>>>> wrote:
>>>>
>>>>> +1 for Segment Routing WG
>>>>>
>>>>> Roberta
>>>>>
>>>>> Sent from my iPad
>>>>>
>>>>> On 2013-08-30, at 2:55 PM, "Alvaro Retana (aretana)"
>>>>> <[email-masked]>
>>>>> wrote:
>>>>>
>>>>>> Segment Routing WG
>>>>>>
>>>>>> Sent from my iPhone
>>>>>>
>>>>>> On Aug 30, 2013, at 1:39 PM, "Stewart Bryant (stbryant)"
>>>>>> <[email-masked]> wrote:
>>>>>>
>>>>>>> The second task, which hopefully should be relatively easy, is=20
>>>>>>> to find a better working name for the WG, since it has been put=20
>>>>>>> to me a number of times that STATUS is going to be confusing in=20
>>>>>>> text and a difficult search term.
>>>>>> _______________________________________________
>>>>>> status mailing list
>>>>>> [email-masked]
>>>>>> https://www.ietf.org/mailman/listinfo/status
>>>>> _______________________________________________
>>>>> status mailing list
>>>>> [email-masked]
>>>>> https://www.ietf.org/mailman/listinfo/status
>>>>
>>>> _______________________________________________
>>>> status mailing list
>>>> [email-masked]
>>>> https://www.ietf.org/mailman/listinfo/status
>>> _______________________________________________
>>> status mailing list
>>> [email-masked]
>>> https://www.ietf.org/mailman/listinfo/status
>>>
>>
>> _______________________________________________
>> status mailing list
>> [email-masked]
>> https://www.ietf.org/mailman/listinfo/status
>>
>> _____________________________________________________________________
>> ____________________________________________________
>>
>> Ce message et ses pieces jointes peuvent contenir des informations=20
>> confidentielles ou privilegiees et ne doivent donc pas etre diffuses,=20
>> exploites ou copies sans autorisation. Si vous avez recu ce message=20
>> par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que=
 les pieces jointes. Les messages electroniques etant susceptibles d'altera=
tion, Orange decline toute responsabilite si ce message a ete altere, defor=
me ou falsifie. Merci.
>>
>> This message and its attachments may contain confidential or=20
>> privileged information that may be protected by law; they should not be =
distributed, used or copied without authorisation.
>> If you have received this email in error, please notify the sender and d=
elete this message and its attachments.
>> As emails may be altered, Orange is not liable for messages that have be=
en modified, changed or falsified.
>> Thank you.
>>
>> .
>>
>
>

--=20

Loa Andersson                        email: [email-masked]
Senior MPLS Expert                          [email-masked]
Huawei Technologies (consultant)     phone: +46 739 81 21 64
_______________________________________________
status mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/status

Date: Tue, 03 Sep 2013 15:58:28 +0200
From: Loa Andersson <[email-masked]>
To: AshwoodsmithPeter <[email-masked]>
Cc: "[email-masked]" <[email-masked]>, John E Drake <[email-masked]>, Mark Townsley <[email-masked]>, Victor Kuarsingh <[email-masked]>, "Roberta Maglione \(robmgl\)" <[email-masked]>, "John G. Scudder" <[email-masked]>, Adrian Farrel <[email-masked]>, "Alvaro Retana \(aretana\)" <[email-masked]>, "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>
Subject: Re: [Status] Summary of STATUS BOF and the next steps

All,

I wonder - if this is true:

In segment routing the source to a (partial) source routing defining
which segments (for any value of segment) that should be in the path.
Each segment may or may not be establish by source routing or any other
routing technology.

If this is true - then a discussion on what is and what is not a sub-set
of the other will turn out to be extremely non-productive.

Also there is both "segment routing" and "source routing" - I could
imagine a case where which segment to use is not determined by the
source but by any standard routing algorithm. If doing this has any
value or not is for the future.

/Loa

On 2013-09-03 15:41, AshwoodsmithPeter wrote:
> There was a lot of work on source routing mechanisms independent of IP. One rather cool example was a mechanism for routing through a constellation of polar orbit satellites. Geodesic I think it was called. There were also a number of other non IP proprietary source routing protocols deployed too. Anyway I agree that the term is generic and not tied to IP any more than hop-by-hop routing is tied to IP.
>
> Peter
>
>
> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of Stewart Bryant
> Sent: Tuesday, September 03, 2013 9:33 AM
> To: [email-masked]
> Cc: John E Drake; Mark Townsley; Victor Kuarsingh; Roberta Maglione (robmgl); John G. Scudder; Adrian Farrel; Alvaro Retana (aretana); [email-masked]
> Subject: Re: [Status] Summary of STATUS BOF and the next steps
>
> Stephane
>
> That is not correct. A long time ago there was source routed transparent
> which was a token ring technology.
>
> Stewart
>
> On 03/09/2013 14:06, [email-masked] wrote:
>> Hi,
>>
>> "Source routing" is just a subcase of segment routing ... as it is for IP routing ...
>>
>> Stephane
>>
>>
>> -----Message d'origine-----
>> De : [email-masked] [mailto:[email-masked]] De la part de John E Drake
>> Envoyé : mardi 3 septembre 2013 15:02
>> À : Mark Townsley; Victor Kuarsingh
>> Cc : Roberta Maglione (robmgl); John G. Scudder; Alvaro Retana (aretana); Adrian Farrel; [email-masked]; Stewart Bryant (stbryant)
>> Objet : Re: [Status] Summary of STATUS BOF and the next steps
>>
>> Hi,
>>
>> What is this 'segment routing' silliness?  The correct term is 'source routing'.
>>
>> Yours Irrespectively,
>>
>> John
>>
>>> -----Original Message-----
>>> From: [email-masked] [mailto:[email-masked]] On
>>> Behalf Of Mark Townsley
>>> Sent: Sunday, September 01, 2013 10:08 AM
>>> To: Victor Kuarsingh
>>> Cc: Roberta Maglione (robmgl); John G. Scudder; Adrian Farrel; Alvaro
>>> Retana (aretana); [email-masked]; Stewart Bryant (stbryant)
>>> Subject: Re: [Status] Summary of STATUS BOF and the next steps
>>>
>>>
>>> On Sep 1, 2013, at 5:38 PM, Victor Kuarsingh wrote:
>>>
>>>> All,
>>>>
>>>> I would also favour "Segment Routing WG" as well.
>>>>
>>>> I note this since attempting to come up with an all encompassing
>>>> acronym will be difficult and Segment Routing is generic enough to
>>>> associate to multiple functions.
>>> Then we can just use "segroute" for the short name. WGs do not have to
>>> have acronyms, but they do need to have an 8-char limited short name
>>> for the various automated tools not to break.
>>>
>>> - Mark
>>>
>>>> Regards,
>>>>
>>>> Victor K
>>>>
>>>>
>>>>
>>>> On 2013-08-31 6:51 PM, "Roberta Maglione (robmgl)"
>>>> <[email-masked]>
>>>> wrote:
>>>>
>>>>> +1 for Segment Routing WG
>>>>>
>>>>> Roberta
>>>>>
>>>>> Sent from my iPad
>>>>>
>>>>> On 2013-08-30, at 2:55 PM, "Alvaro Retana (aretana)"
>>>>> <[email-masked]>
>>>>> wrote:
>>>>>
>>>>>> Segment Routing WG
>>>>>>
>>>>>> Sent from my iPhone
>>>>>>
>>>>>> On Aug 30, 2013, at 1:39 PM, "Stewart Bryant (stbryant)"
>>>>>> <[email-masked]> wrote:
>>>>>>
>>>>>>> The second task, which hopefully should be relatively easy, is to
>>>>>>> find a better working name for the WG, since it has been put to
>>>>>>> me a number of times that STATUS is going to be confusing in text
>>>>>>> and a difficult search term.
>>>>>> _______________________________________________
>>>>>> status mailing list
>>>>>> [email-masked]
>>>>>> https://www.ietf.org/mailman/listinfo/status
>>>>> _______________________________________________
>>>>> status mailing list
>>>>> [email-masked]
>>>>> https://www.ietf.org/mailman/listinfo/status
>>>>
>>>> _______________________________________________
>>>> status mailing list
>>>> [email-masked]
>>>> https://www.ietf.org/mailman/listinfo/status
>>> _______________________________________________
>>> status mailing list
>>> [email-masked]
>>> https://www.ietf.org/mailman/listinfo/status
>>>
>>
>> _______________________________________________
>> status mailing list
>> [email-masked]
>> https://www.ietf.org/mailman/listinfo/status
>>
>> _________________________________________________________________________________________________________________________
>>
>> Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc
>> pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler
>> a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,
>> Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.
>>
>> This message and its attachments may contain confidential or privileged information that may be protected by law;
>> they should not be distributed, used or copied without authorisation.
>> If you have received this email in error, please notify the sender and delete this message and its attachments.
>> As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.
>> Thank you.
>>
>> .
>>
>
>

-- 

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

From: <[email-masked]>
To: <[email-masked]>
Date: Tue, 3 Sep 2013 15:44:58 +0200
Accept-Language: en-US, de-DE
acceptlanguage: en-US, de-DE
Cc: [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked]
Subject: Re: [Status] Summary of STATUS BOF and the next steps

Stewart,

to name a WG "Source Routing WG" just because it allows a more organised wa=
y of exploiting features of an MPLS network, and that limited to paths and =
routers where an operator desires to utlise these features doesn't seem to =
be a good idea.

Segment Routing describes what the company I work for will be using it. We =
don't intend to operate a source routed network. It's an enhancement as com=
pared to LDP based MPLS.

Regards,

Ruediger

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of=
 Stewart Bryant
Sent: Tuesday, September 03, 2013 3:33 PM
To: [email-masked]
Cc: John E Drake; Mark Townsley; Victor Kuarsingh; Roberta Maglione (robmgl=
); John G. Scudder; Adrian Farrel; Alvaro Retana (aretana); [email-masked]
Subject: Re: [Status] Summary of STATUS BOF and the next steps

Stephane

That is not correct. A long time ago there was source routed transparent
which was a token ring technology.

Stewart

On 03/09/2013 14:06, [email-masked] wrote:
> Hi,
>
> "Source routing" is just a subcase of segment routing ... as it is for IP=
 routing ...
>
> Stephane
>
>
> -----Message d'origine-----
> De : [email-masked] [mailto:[email-masked]] De la part =
de John E Drake
> Envoy=E9 : mardi 3 septembre 2013 15:02
> =C0 : Mark Townsley; Victor Kuarsingh
> Cc : Roberta Maglione (robmgl); John G. Scudder; Alvaro Retana (aretana);=
 Adrian Farrel; [email-masked]; Stewart Bryant (stbryant)
> Objet : Re: [Status] Summary of STATUS BOF and the next steps
>
> Hi,
>
> What is this 'segment routing' silliness?  The correct term is 'source ro=
uting'.
>
> Yours Irrespectively,
>
> John
>
>> -----Original Message-----
>> From: [email-masked] [mailto:[email-masked]] On
>> Behalf Of Mark Townsley
>> Sent: Sunday, September 01, 2013 10:08 AM
>> To: Victor Kuarsingh
>> Cc: Roberta Maglione (robmgl); John G. Scudder; Adrian Farrel; Alvaro
>> Retana (aretana); [email-masked]; Stewart Bryant (stbryant)
>> Subject: Re: [Status] Summary of STATUS BOF and the next steps
>>
>>
>> On Sep 1, 2013, at 5:38 PM, Victor Kuarsingh wrote:
>>
>>> All,
>>>
>>> I would also favour "Segment Routing WG" as well.
>>>
>>> I note this since attempting to come up with an all encompassing
>>> acronym will be difficult and Segment Routing is generic enough to
>>> associate to multiple functions.
>> Then we can just use "segroute" for the short name. WGs do not have to
>> have acronyms, but they do need to have an 8-char limited short name
>> for the various automated tools not to break.
>>
>> - Mark
>>
>>> Regards,
>>>
>>> Victor K
>>>
>>>
>>>
>>> On 2013-08-31 6:51 PM, "Roberta Maglione (robmgl)"
>>> <[email-masked]>
>>> wrote:
>>>
>>>> +1 for Segment Routing WG
>>>>
>>>> Roberta
>>>>
>>>> Sent from my iPad
>>>>
>>>> On 2013-08-30, at 2:55 PM, "Alvaro Retana (aretana)"
>>>> <[email-masked]>
>>>> wrote:
>>>>
>>>>> Segment Routing WG
>>>>>
>>>>> Sent from my iPhone
>>>>>
>>>>> On Aug 30, 2013, at 1:39 PM, "Stewart Bryant (stbryant)"
>>>>> <[email-masked]> wrote:
>>>>>
>>>>>> The second task, which hopefully should be relatively easy, is to
>>>>>> find a better working name for the WG, since it has been put to
>>>>>> me a number of times that STATUS is going to be confusing in text
>>>>>> and a difficult search term.
>>>>> _______________________________________________
>>>>> status mailing list
>>>>> [email-masked]
>>>>> https://www.ietf.org/mailman/listinfo/status
>>>> _______________________________________________
>>>> status mailing list
>>>> [email-masked]
>>>> https://www.ietf.org/mailman/listinfo/status
>>>
>>> _______________________________________________
>>> status mailing list
>>> [email-masked]
>>> https://www.ietf.org/mailman/listinfo/status
>> _______________________________________________
>> status mailing list
>> [email-masked]
>> https://www.ietf.org/mailman/listinfo/status
>>
>
> _______________________________________________
> status mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/status
>
> _________________________________________________________________________=
________________________________________________
>
> Ce message et ses pieces jointes peuvent contenir des informations confid=
entielles ou privilegiees et ne doivent donc
> pas etre diffuses, exploites ou copies sans autorisation. Si vous avez re=
cu ce message par erreur, veuillez le signaler
> a l'expediteur et le detruire ainsi que les pieces jointes. Les messages =
electroniques etant susceptibles d'alteration,
> Orange decline toute responsabilite si ce message a ete altere, deforme o=
u falsifie. Merci.
>
> This message and its attachments may contain confidential or privileged i=
nformation that may be protected by law;
> they should not be distributed, used or copied without authorisation.
> If you have received this email in error, please notify the sender and de=
lete this message and its attachments.
> As emails may be altered, Orange is not liable for messages that have bee=
n modified, changed or falsified.
> Thank you.
>
> .
>

--
For corporate legal information go to:

http://www.cisco.com/web/about/doing_business/legal/cri/index.html

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

From: AshwoodsmithPeter <[email-masked]>
To: "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>
Date: Tue, 3 Sep 2013 13:41:22 +0000
Accept-Language: en-US, zh-CN
Cc: John E Drake <[email-masked]>, Mark Townsley <[email-masked]>, Victor Kuarsingh <[email-masked]>, "Roberta Maglione \(robmgl\)" <[email-masked]>, "John G. Scudder" <[email-masked]>, "Alvaro Retana \(aretana\)" <[email-masked]>, Adrian Farrel <[email-masked]>, "[email-masked]" <[email-masked]>
Subject: Re: [Status] Summary of STATUS BOF and the next steps

There was a lot of work on source routing mechanisms independent of IP. One=
 rather cool example was a mechanism for routing through a constellation of=
 polar orbit satellites. Geodesic I think it was called. There were also a =
number of other non IP proprietary source routing protocols deployed too. A=
nyway I agree that the term is generic and not tied to IP any more than hop=
-by-hop routing is tied to IP.

Peter

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of=
 Stewart Bryant
Sent: Tuesday, September 03, 2013 9:33 AM
To: [email-masked]
Cc: John E Drake; Mark Townsley; Victor Kuarsingh; Roberta Maglione (robmgl=
); John G. Scudder; Adrian Farrel; Alvaro Retana (aretana); [email-masked]
Subject: Re: [Status] Summary of STATUS BOF and the next steps

Stephane

That is not correct. A long time ago there was source routed transparent=20
which was a token ring technology.

Stewart

On 03/09/2013 14:06, [email-masked] wrote:
> Hi,
>
> "Source routing" is just a subcase of segment routing ... as it is for IP=
 routing ...
>
> Stephane
>  =20
>
> -----Message d'origine-----
> De : [email-masked] [mailto:[email-masked]] De la part =
de John E Drake
> Envoy=E9 : mardi 3 septembre 2013 15:02
> =C0 : Mark Townsley; Victor Kuarsingh
> Cc : Roberta Maglione (robmgl); John G. Scudder; Alvaro Retana (aretana);=
 Adrian Farrel; [email-masked]; Stewart Bryant (stbryant)
> Objet : Re: [Status] Summary of STATUS BOF and the next steps
>
> Hi,
>
> What is this 'segment routing' silliness?  The correct term is 'source ro=
uting'.
>
> Yours Irrespectively,
>
> John
>
>> -----Original Message-----
>> From: [email-masked] [mailto:[email-masked]] On
>> Behalf Of Mark Townsley
>> Sent: Sunday, September 01, 2013 10:08 AM
>> To: Victor Kuarsingh
>> Cc: Roberta Maglione (robmgl); John G. Scudder; Adrian Farrel; Alvaro
>> Retana (aretana); [email-masked]; Stewart Bryant (stbryant)
>> Subject: Re: [Status] Summary of STATUS BOF and the next steps
>>
>>
>> On Sep 1, 2013, at 5:38 PM, Victor Kuarsingh wrote:
>>
>>> All,
>>>
>>> I would also favour "Segment Routing WG" as well.
>>>
>>> I note this since attempting to come up with an all encompassing
>>> acronym will be difficult and Segment Routing is generic enough to
>>> associate to multiple functions.
>> Then we can just use "segroute" for the short name. WGs do not have to
>> have acronyms, but they do need to have an 8-char limited short name
>> for the various automated tools not to break.
>>
>> - Mark
>>
>>> Regards,
>>>
>>> Victor K
>>>
>>>
>>>
>>> On 2013-08-31 6:51 PM, "Roberta Maglione (robmgl)"
>>> <[email-masked]>
>>> wrote:
>>>
>>>> +1 for Segment Routing WG
>>>>
>>>> Roberta
>>>>
>>>> Sent from my iPad
>>>>
>>>> On 2013-08-30, at 2:55 PM, "Alvaro Retana (aretana)"
>>>> <[email-masked]>
>>>> wrote:
>>>>
>>>>> Segment Routing WG
>>>>>
>>>>> Sent from my iPhone
>>>>>
>>>>> On Aug 30, 2013, at 1:39 PM, "Stewart Bryant (stbryant)"
>>>>> <[email-masked]> wrote:
>>>>>
>>>>>> The second task, which hopefully should be relatively easy, is to
>>>>>> find a better working name for the WG, since it has been put to
>>>>>> me a number of times that STATUS is going to be confusing in text
>>>>>> and a difficult search term.
>>>>> _______________________________________________
>>>>> status mailing list
>>>>> [email-masked]
>>>>> https://www.ietf.org/mailman/listinfo/status
>>>> _______________________________________________
>>>> status mailing list
>>>> [email-masked]
>>>> https://www.ietf.org/mailman/listinfo/status
>>>
>>> _______________________________________________
>>> status mailing list
>>> [email-masked]
>>> https://www.ietf.org/mailman/listinfo/status
>> _______________________________________________
>> status mailing list
>> [email-masked]
>> https://www.ietf.org/mailman/listinfo/status
>>
>
> _______________________________________________
> status mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/status
>
> _________________________________________________________________________=
________________________________________________
>
> Ce message et ses pieces jointes peuvent contenir des informations confid=
entielles ou privilegiees et ne doivent donc
> pas etre diffuses, exploites ou copies sans autorisation. Si vous avez re=
cu ce message par erreur, veuillez le signaler
> a l'expediteur et le detruire ainsi que les pieces jointes. Les messages =
electroniques etant susceptibles d'alteration,
> Orange decline toute responsabilite si ce message a ete altere, deforme o=
u falsifie. Merci.
>
> This message and its attachments may contain confidential or privileged i=
nformation that may be protected by law;
> they should not be distributed, used or copied without authorisation.
> If you have received this email in error, please notify the sender and de=
lete this message and its attachments.
> As emails may be altered, Orange is not liable for messages that have bee=
n modified, changed or falsified.
> Thank you.
>
> .
>

--=20
For corporate legal information go to:

http://www.cisco.com/web/about/doing_business/legal/cri/index.html

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

Date: Tue, 03 Sep 2013 14:33:02 +0100
From: Stewart Bryant <[email-masked]>
To: [email-masked]
Cc: John E Drake <[email-masked]>, Mark Townsley <[email-masked]>, Victor Kuarsingh <[email-masked]>, "Roberta Maglione \(robmgl\)" <[email-masked]>, "John G. Scudder" <[email-masked]>, Adrian Farrel <[email-masked]>, "Alvaro Retana \(aretana\)" <[email-masked]>, "[email-masked]" <[email-masked]>
Subject: Re: [Status] Summary of STATUS BOF and the next steps
Reply-To: [email-masked]

Stephane

That is not correct. A long time ago there was source routed transparent 
which was a token ring technology.

Stewart

On 03/09/2013 14:06, [email-masked] wrote:
> Hi,
>
> "Source routing" is just a subcase of segment routing ... as it is for IP routing ...
>
> Stephane
>   
>
> -----Message d'origine-----
> De : [email-masked] [mailto:[email-masked]] De la part de John E Drake
> Envoyé : mardi 3 septembre 2013 15:02
> À : Mark Townsley; Victor Kuarsingh
> Cc : Roberta Maglione (robmgl); John G. Scudder; Alvaro Retana (aretana); Adrian Farrel; [email-masked]; Stewart Bryant (stbryant)
> Objet : Re: [Status] Summary of STATUS BOF and the next steps
>
> Hi,
>
> What is this 'segment routing' silliness?  The correct term is 'source routing'.
>
> Yours Irrespectively,
>
> John
>
>> -----Original Message-----
>> From: [email-masked] [mailto:[email-masked]] On
>> Behalf Of Mark Townsley
>> Sent: Sunday, September 01, 2013 10:08 AM
>> To: Victor Kuarsingh
>> Cc: Roberta Maglione (robmgl); John G. Scudder; Adrian Farrel; Alvaro
>> Retana (aretana); [email-masked]; Stewart Bryant (stbryant)
>> Subject: Re: [Status] Summary of STATUS BOF and the next steps
>>
>>
>> On Sep 1, 2013, at 5:38 PM, Victor Kuarsingh wrote:
>>
>>> All,
>>>
>>> I would also favour "Segment Routing WG" as well.
>>>
>>> I note this since attempting to come up with an all encompassing
>>> acronym will be difficult and Segment Routing is generic enough to
>>> associate to multiple functions.
>> Then we can just use "segroute" for the short name. WGs do not have to
>> have acronyms, but they do need to have an 8-char limited short name
>> for the various automated tools not to break.
>>
>> - Mark
>>
>>> Regards,
>>>
>>> Victor K
>>>
>>>
>>>
>>> On 2013-08-31 6:51 PM, "Roberta Maglione (robmgl)"
>>> <[email-masked]>
>>> wrote:
>>>
>>>> +1 for Segment Routing WG
>>>>
>>>> Roberta
>>>>
>>>> Sent from my iPad
>>>>
>>>> On 2013-08-30, at 2:55 PM, "Alvaro Retana (aretana)"
>>>> <[email-masked]>
>>>> wrote:
>>>>
>>>>> Segment Routing WG
>>>>>
>>>>> Sent from my iPhone
>>>>>
>>>>> On Aug 30, 2013, at 1:39 PM, "Stewart Bryant (stbryant)"
>>>>> <[email-masked]> wrote:
>>>>>
>>>>>> The second task, which hopefully should be relatively easy, is to
>>>>>> find a better working name for the WG, since it has been put to
>>>>>> me a number of times that STATUS is going to be confusing in text
>>>>>> and a difficult search term.
>>>>> _______________________________________________
>>>>> status mailing list
>>>>> [email-masked]
>>>>> https://www.ietf.org/mailman/listinfo/status
>>>> _______________________________________________
>>>> status mailing list
>>>> [email-masked]
>>>> https://www.ietf.org/mailman/listinfo/status
>>>
>>> _______________________________________________
>>> status mailing list
>>> [email-masked]
>>> https://www.ietf.org/mailman/listinfo/status
>> _______________________________________________
>> status mailing list
>> [email-masked]
>> https://www.ietf.org/mailman/listinfo/status
>>
>
> _______________________________________________
> status mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/status
>
> _________________________________________________________________________________________________________________________
>
> Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc
> pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler
> a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,
> Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.
>
> This message and its attachments may contain confidential or privileged information that may be protected by law;
> they should not be distributed, used or copied without authorisation.
> If you have received this email in error, please notify the sender and delete this message and its attachments.
> As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.
> Thank you.
>
> .
>

-- 
For corporate legal information go to:

http://www.cisco.com/web/about/doing_business/legal/cri/index.html

From: John E Drake <[email-masked]>
To: AshwoodsmithPeter <[email-masked]>, "[email-masked]" <[email-masked]>
Date: Tue, 3 Sep 2013 13:32:32 +0000
Accept-Language: en-US
Cc: Mark Townsley <[email-masked]>, Victor Kuarsingh <[email-masked]>, "Roberta Maglione \(robmgl\)" <[email-masked]>, "John G. Scudder" <[email-masked]>, "Alvaro Retana \(aretana\)" <[email-masked]>, Adrian Farrel <[email-masked]>, "[email-masked]" <[email-masked]>, "Stewart Bryant \(stbryant\)" <[email-masked]>
Subject: Re: [Status] Summary of STATUS BOF and the next steps

Excellent.

Yours Irrespectively,

John

> -----Original Message-----
> From: AshwoodsmithPeter [mailto:[email-masked]]
> Sent: Tuesday, September 03, 2013 6:27 AM
> To: [email-masked]
> Cc: John E Drake; Mark Townsley; Victor Kuarsingh; Roberta Maglione
> (robmgl); John G. Scudder; Adrian Farrel; Alvaro Retana (aretana);
> [email-masked]; Stewart Bryant (stbryant)
> Subject: Re: [Status] Summary of STATUS BOF and the next steps
>=20
> The term "source routing" has been around for a very long time and is dat=
a
> path agnostic. Its also the term used in the literature etc so my prefere=
nce is
> to stick with this existing well known and data path agnostic term.
>=20
> Peter
>=20
> On Sep 3, 2013, at 9:07 AM, "[email-masked]"
> <[email-masked]> wrote:
>=20
> > Hi,
> >
> > "Source routing" is just a subcase of segment routing ... as it is for =
IP routing
> ...
> >
> > Stephane
> >
> >
> > -----Message d'origine-----
> > De : [email-masked] [mailto:[email-masked]] De la
> > part de John E Drake Envoy=E9 : mardi 3 septembre 2013 15:02 =C0 : Mark
> > Townsley; Victor Kuarsingh Cc : Roberta Maglione (robmgl); John G.
> > Scudder; Alvaro Retana (aretana); Adrian Farrel; [email-masked];
> > Stewart Bryant (stbryant) Objet : Re: [Status] Summary of STATUS BOF
> > and the next steps
> >
> > Hi,
> >
> > What is this 'segment routing' silliness?  The correct term is 'source =
routing'.
> >
> > Yours Irrespectively,
> >
> > John
> >
> >> -----Original Message-----
> >> From: [email-masked] [mailto:[email-masked]] On
> >> Behalf Of Mark Townsley
> >> Sent: Sunday, September 01, 2013 10:08 AM
> >> To: Victor Kuarsingh
> >> Cc: Roberta Maglione (robmgl); John G. Scudder; Adrian Farrel; Alvaro
> >> Retana (aretana); [email-masked]; Stewart Bryant (stbryant)
> >> Subject: Re: [Status] Summary of STATUS BOF and the next steps
> >>
> >>
> >> On Sep 1, 2013, at 5:38 PM, Victor Kuarsingh wrote:
> >>
> >>> All,
> >>>
> >>> I would also favour "Segment Routing WG" as well.
> >>>
> >>> I note this since attempting to come up with an all encompassing
> >>> acronym will be difficult and Segment Routing is generic enough to
> >>> associate to multiple functions.
> >>
> >> Then we can just use "segroute" for the short name. WGs do not have
> >> to have acronyms, but they do need to have an 8-char limited short
> >> name for the various automated tools not to break.
> >>
> >> - Mark
> >>
> >>>
> >>> Regards,
> >>>
> >>> Victor K
> >>>
> >>>
> >>>
> >>> On 2013-08-31 6:51 PM, "Roberta Maglione (robmgl)"
> >>> <[email-masked]>
> >>> wrote:
> >>>
> >>>> +1 for Segment Routing WG
> >>>>
> >>>> Roberta
> >>>>
> >>>> Sent from my iPad
> >>>>
> >>>> On 2013-08-30, at 2:55 PM, "Alvaro Retana (aretana)"
> >>>> <[email-masked]>
> >>>> wrote:
> >>>>
> >>>>> Segment Routing WG
> >>>>>
> >>>>> Sent from my iPhone
> >>>>>
> >>>>> On Aug 30, 2013, at 1:39 PM, "Stewart Bryant (stbryant)"
> >>>>> <[email-masked]> wrote:
> >>>>>
> >>>>>> The second task, which hopefully should be relatively easy, is to
> >>>>>> find a better working name for the WG, since it has been put to
> >>>>>> me a number of times that STATUS is going to be confusing in text
> >>>>>> and a difficult search term.
> >>>>> _______________________________________________
> >>>>> status mailing list
> >>>>> [email-masked]
> >>>>> https://www.ietf.org/mailman/listinfo/status
> >>>> _______________________________________________
> >>>> status mailing list
> >>>> [email-masked]
> >>>> https://www.ietf.org/mailman/listinfo/status
> >>>
> >>>
> >>> _______________________________________________
> >>> status mailing list
> >>> [email-masked]
> >>> https://www.ietf.org/mailman/listinfo/status
> >>
> >> _______________________________________________
> >> status mailing list
> >> [email-masked]
> >> https://www.ietf.org/mailman/listinfo/status
> >
> >
> > _______________________________________________
> > status mailing list
> > [email-masked]
> > https://www.ietf.org/mailman/listinfo/status
> >
> >
> __________________________________________________________
> ____________
> > ___________________________________________________
> >
> > Ce message et ses pieces jointes peuvent contenir des informations
> > confidentielles ou privilegiees et ne doivent donc pas etre diffuses,
> > exploites ou copies sans autorisation. Si vous avez recu ce message
> > par erreur, veuillez le signaler a l'expediteur et le detruire ainsi qu=
e les
> pieces jointes. Les messages electroniques etant susceptibles d'alteratio=
n,
> Orange decline toute responsabilite si ce message a ete altere, deforme o=
u
> falsifie. Merci.
> >
> > This message and its attachments may contain confidential or
> > privileged information that may be protected by law; they should not be
> distributed, used or copied without authorisation.
> > If you have received this email in error, please notify the sender and =
delete
> this message and its attachments.
> > As emails may be altered, Orange is not liable for messages that have b=
een
> modified, changed or falsified.
> > Thank you.
> >
> > _______________________________________________
> > status mailing list
> > [email-masked]
> > https://www.ietf.org/mailman/listinfo/status
>=20

From: John E Drake <[email-masked]>
To: "[email-masked]" <[email-masked]>, Mark Townsley <[email-masked]>, Victor Kuarsingh <[email-masked]>
Date: Tue, 3 Sep 2013 13:31:41 +0000
Accept-Language: en-US
Cc: "Roberta Maglione \(robmgl\)" <[email-masked]>, "John G. Scudder" <[email-masked]>, Adrian Farrel <[email-masked]>, "Alvaro Retana \(aretana\)" <[email-masked]>, "[email-masked]" <[email-masked]>, "Stewart Bryant \(stbryant\)" <[email-masked]>
Subject: Re: [Status] Summary of STATUS BOF and the next steps

Stephane,

I don't see anything in the segment routing architecture I-D that justifies=
 your assertion.

Yours Irrespectively,

John

> -----Original Message-----
> From: [email-masked]
> [mailto:[email-masked]]
> Sent: Tuesday, September 03, 2013 6:07 AM
> To: John E Drake; Mark Townsley; Victor Kuarsingh
> Cc: Roberta Maglione (robmgl); John G. Scudder; Alvaro Retana (aretana);
> Adrian Farrel; [email-masked]; Stewart Bryant (stbryant)
> Subject: RE: [Status] Summary of STATUS BOF and the next steps
>=20
> Hi,
>=20
> "Source routing" is just a subcase of segment routing ... as it is for IP=
 routing
> ...
>=20
> Stephane
>=20
>=20
> -----Message d'origine-----
> De : [email-masked] [mailto:[email-masked]] De la part =
de
> John E Drake Envoy=E9 : mardi 3 septembre 2013 15:02 =C0 : Mark Townsley;
> Victor Kuarsingh Cc : Roberta Maglione (robmgl); John G. Scudder; Alvaro
> Retana (aretana); Adrian Farrel; [email-masked]; Stewart Bryant (stbryan=
t)
> Objet : Re: [Status] Summary of STATUS BOF and the next steps
>=20
> Hi,
>=20
> What is this 'segment routing' silliness?  The correct term is 'source ro=
uting'.
>=20
> Yours Irrespectively,
>=20
> John
>=20
> > -----Original Message-----
> > From: [email-masked] [mailto:[email-masked]] On
> > Behalf Of Mark Townsley
> > Sent: Sunday, September 01, 2013 10:08 AM
> > To: Victor Kuarsingh
> > Cc: Roberta Maglione (robmgl); John G. Scudder; Adrian Farrel; Alvaro
> > Retana (aretana); [email-masked]; Stewart Bryant (stbryant)
> > Subject: Re: [Status] Summary of STATUS BOF and the next steps
> >
> >
> > On Sep 1, 2013, at 5:38 PM, Victor Kuarsingh wrote:
> >
> > > All,
> > >
> > > I would also favour "Segment Routing WG" as well.
> > >
> > > I note this since attempting to come up with an all encompassing
> > > acronym will be difficult and Segment Routing is generic enough to
> > > associate to multiple functions.
> >
> > Then we can just use "segroute" for the short name. WGs do not have to
> > have acronyms, but they do need to have an 8-char limited short name
> > for the various automated tools not to break.
> >
> > - Mark
> >
> > >
> > > Regards,
> > >
> > > Victor K
> > >
> > >
> > >
> > > On 2013-08-31 6:51 PM, "Roberta Maglione (robmgl)"
> > > <[email-masked]>
> > > wrote:
> > >
> > >> +1 for Segment Routing WG
> > >>
> > >> Roberta
> > >>
> > >> Sent from my iPad
> > >>
> > >> On 2013-08-30, at 2:55 PM, "Alvaro Retana (aretana)"
> > >> <[email-masked]>
> > >> wrote:
> > >>
> > >>> Segment Routing WG
> > >>>
> > >>> Sent from my iPhone
> > >>>
> > >>> On Aug 30, 2013, at 1:39 PM, "Stewart Bryant (stbryant)"
> > >>> <[email-masked]> wrote:
> > >>>
> > >>>> The second task, which hopefully should be relatively easy, is to
> > >>>> find a better working name for the WG, since it has been put to
> > >>>> me a number of times that STATUS is going to be confusing in text
> > >>>> and a difficult search term.
> > >>> _______________________________________________
> > >>> status mailing list
> > >>> [email-masked]
> > >>> https://www.ietf.org/mailman/listinfo/status
> > >> _______________________________________________
> > >> status mailing list
> > >> [email-masked]
> > >> https://www.ietf.org/mailman/listinfo/status
> > >
> > >
> > > _______________________________________________
> > > status mailing list
> > > [email-masked]
> > > https://www.ietf.org/mailman/listinfo/status
> >
> > _______________________________________________
> > status mailing list
> > [email-masked]
> > https://www.ietf.org/mailman/listinfo/status
> >
>=20
>=20
> _______________________________________________
> status mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/status
>=20
> __________________________________________________________
> __________________________________________________________
> _____
>=20
> Ce message et ses pieces jointes peuvent contenir des informations
> confidentielles ou privilegiees et ne doivent donc pas etre diffuses, exp=
loites
> ou copies sans autorisation. Si vous avez recu ce message par erreur, veu=
illez
> le signaler a l'expediteur et le detruire ainsi que les pieces jointes. L=
es
> messages electroniques etant susceptibles d'alteration, Orange decline to=
ute
> responsabilite si ce message a ete altere, deforme ou falsifie. Merci.
>=20
> This message and its attachments may contain confidential or privileged
> information that may be protected by law; they should not be distributed,
> used or copied without authorisation.
> If you have received this email in error, please notify the sender and de=
lete
> this message and its attachments.
> As emails may be altered, Orange is not liable for messages that have bee=
n
> modified, changed or falsified.
> Thank you.
>=20
>=20

From: AshwoodsmithPeter <[email-masked]>
To: "[email-masked]" <[email-masked]>
Date: Tue, 3 Sep 2013 13:27:15 +0000
Accept-Language: en-US, zh-CN
Cc: John E Drake <[email-masked]>, Mark Townsley <[email-masked]>, Victor Kuarsingh <[email-masked]>, "Roberta Maglione \(robmgl\)" <[email-masked]>, "John G. Scudder" <[email-masked]>, "Alvaro Retana \(aretana\)" <[email-masked]>, Adrian Farrel <[email-masked]>, "[email-masked]" <[email-masked]>, "Stewart Bryant	\(stbryant\)" <[email-masked]>
Subject: Re: [Status] Summary of STATUS BOF and the next steps

The term "source routing" has been around for a very long time and is data =
path agnostic. Its also the term used in the literature etc so my preferenc=
e is to stick with this existing well known and data path agnostic term.

Peter

On Sep 3, 2013, at 9:07 AM, "[email-masked]" <stephane.litko=
[email-masked]> wrote:

> Hi,
>=20
> "Source routing" is just a subcase of segment routing ... as it is for IP=
 routing ...
>=20
> Stephane
>=20
>=20
> -----Message d'origine-----
> De : [email-masked] [mailto:[email-masked]] De la part =
de John E Drake
> Envoy=E9 : mardi 3 septembre 2013 15:02
> =C0 : Mark Townsley; Victor Kuarsingh
> Cc : Roberta Maglione (robmgl); John G. Scudder; Alvaro Retana (aretana);=
 Adrian Farrel; [email-masked]; Stewart Bryant (stbryant)
> Objet : Re: [Status] Summary of STATUS BOF and the next steps
>=20
> Hi,
>=20
> What is this 'segment routing' silliness?  The correct term is 'source ro=
uting'.=20
>=20
> Yours Irrespectively,
>=20
> John
>=20
>> -----Original Message-----
>> From: [email-masked] [mailto:[email-masked]] On=20
>> Behalf Of Mark Townsley
>> Sent: Sunday, September 01, 2013 10:08 AM
>> To: Victor Kuarsingh
>> Cc: Roberta Maglione (robmgl); John G. Scudder; Adrian Farrel; Alvaro=20
>> Retana (aretana); [email-masked]; Stewart Bryant (stbryant)
>> Subject: Re: [Status] Summary of STATUS BOF and the next steps
>>=20
>>=20
>> On Sep 1, 2013, at 5:38 PM, Victor Kuarsingh wrote:
>>=20
>>> All,
>>>=20
>>> I would also favour "Segment Routing WG" as well.
>>>=20
>>> I note this since attempting to come up with an all encompassing=20
>>> acronym will be difficult and Segment Routing is generic enough to=20
>>> associate to multiple functions.
>>=20
>> Then we can just use "segroute" for the short name. WGs do not have to=20
>> have acronyms, but they do need to have an 8-char limited short name=20
>> for the various automated tools not to break.
>>=20
>> - Mark
>>=20
>>>=20
>>> Regards,
>>>=20
>>> Victor K
>>>=20
>>>=20
>>>=20
>>> On 2013-08-31 6:51 PM, "Roberta Maglione (robmgl)"=20
>>> <[email-masked]>
>>> wrote:
>>>=20
>>>> +1 for Segment Routing WG
>>>>=20
>>>> Roberta
>>>>=20
>>>> Sent from my iPad
>>>>=20
>>>> On 2013-08-30, at 2:55 PM, "Alvaro Retana (aretana)"
>>>> <[email-masked]>
>>>> wrote:
>>>>=20
>>>>> Segment Routing WG
>>>>>=20
>>>>> Sent from my iPhone
>>>>>=20
>>>>> On Aug 30, 2013, at 1:39 PM, "Stewart Bryant (stbryant)"
>>>>> <[email-masked]> wrote:
>>>>>=20
>>>>>> The second task, which hopefully should be relatively easy, is to=20
>>>>>> find a better working name for the WG, since it has been put to=20
>>>>>> me a number of times that STATUS is going to be confusing in text=20
>>>>>> and a difficult search term.
>>>>> _______________________________________________
>>>>> status mailing list
>>>>> [email-masked]
>>>>> https://www.ietf.org/mailman/listinfo/status
>>>> _______________________________________________
>>>> status mailing list
>>>> [email-masked]
>>>> https://www.ietf.org/mailman/listinfo/status
>>>=20
>>>=20
>>> _______________________________________________
>>> status mailing list
>>> [email-masked]
>>> https://www.ietf.org/mailman/listinfo/status
>>=20
>> _______________________________________________
>> status mailing list
>> [email-masked]
>> https://www.ietf.org/mailman/listinfo/status
>=20
>=20
> _______________________________________________
> status mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/status
>=20
> _________________________________________________________________________=
________________________________________________
>=20
> Ce message et ses pieces jointes peuvent contenir des informations confid=
entielles ou privilegiees et ne doivent donc
> pas etre diffuses, exploites ou copies sans autorisation. Si vous avez re=
cu ce message par erreur, veuillez le signaler
> a l'expediteur et le detruire ainsi que les pieces jointes. Les messages =
electroniques etant susceptibles d'alteration,
> Orange decline toute responsabilite si ce message a ete altere, deforme o=
u falsifie. Merci.
>=20
> This message and its attachments may contain confidential or privileged i=
nformation that may be protected by law;
> they should not be distributed, used or copied without authorisation.
> If you have received this email in error, please notify the sender and de=
lete this message and its attachments.
> As emails may be altered, Orange is not liable for messages that have bee=
n modified, changed or falsified.
> Thank you.
>=20
> _______________________________________________
> status mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/status

From: <[email-masked]>
To: John E Drake <[email-masked]>, Mark Townsley <[email-masked]>, Victor Kuarsingh <[email-masked]>
Date: Tue, 3 Sep 2013 15:06:38 +0200
Accept-Language: fr-FR
acceptlanguage: fr-FR
Cc: "Roberta Maglione \(robmgl\)" <[email-masked]>, "John G. Scudder" <[email-masked]>, Adrian Farrel <[email-masked]>, "Alvaro Retana \(aretana\)" <[email-masked]>, "[email-masked]" <[email-masked]>, "Stewart Bryant \(stbryant\)" <[email-masked]>
Subject: Re: [Status] Summary of STATUS BOF and the next steps

Hi,

"Source routing" is just a subcase of segment routing ... as it is for IP r=
outing ...

Stephane
=20

-----Message d'origine-----
De : [email-masked] [mailto:[email-masked]] De la part de=
 John E Drake
Envoy=E9 : mardi 3 septembre 2013 15:02
=C0 : Mark Townsley; Victor Kuarsingh
Cc : Roberta Maglione (robmgl); John G. Scudder; Alvaro Retana (aretana); A=
drian Farrel; [email-masked]; Stewart Bryant (stbryant)
Objet : Re: [Status] Summary of STATUS BOF and the next steps

Hi,

What is this 'segment routing' silliness?  The correct term is 'source rout=
ing'.=20

Yours Irrespectively,

John

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On=20
> Behalf Of Mark Townsley
> Sent: Sunday, September 01, 2013 10:08 AM
> To: Victor Kuarsingh
> Cc: Roberta Maglione (robmgl); John G. Scudder; Adrian Farrel; Alvaro=20
> Retana (aretana); [email-masked]; Stewart Bryant (stbryant)
> Subject: Re: [Status] Summary of STATUS BOF and the next steps
>=20
>=20
> On Sep 1, 2013, at 5:38 PM, Victor Kuarsingh wrote:
>=20
> > All,
> >
> > I would also favour "Segment Routing WG" as well.
> >
> > I note this since attempting to come up with an all encompassing=20
> > acronym will be difficult and Segment Routing is generic enough to=20
> > associate to multiple functions.
>=20
> Then we can just use "segroute" for the short name. WGs do not have to=20
> have acronyms, but they do need to have an 8-char limited short name=20
> for the various automated tools not to break.
>=20
> - Mark
>=20
> >
> > Regards,
> >
> > Victor K
> >
> >
> >
> > On 2013-08-31 6:51 PM, "Roberta Maglione (robmgl)"=20
> > <[email-masked]>
> > wrote:
> >
> >> +1 for Segment Routing WG
> >>
> >> Roberta
> >>
> >> Sent from my iPad
> >>
> >> On 2013-08-30, at 2:55 PM, "Alvaro Retana (aretana)"
> >> <[email-masked]>
> >> wrote:
> >>
> >>> Segment Routing WG
> >>>
> >>> Sent from my iPhone
> >>>
> >>> On Aug 30, 2013, at 1:39 PM, "Stewart Bryant (stbryant)"
> >>> <[email-masked]> wrote:
> >>>
> >>>> The second task, which hopefully should be relatively easy, is to=20
> >>>> find a better working name for the WG, since it has been put to=20
> >>>> me a number of times that STATUS is going to be confusing in text=20
> >>>> and a difficult search term.
> >>> _______________________________________________
> >>> status mailing list
> >>> [email-masked]
> >>> https://www.ietf.org/mailman/listinfo/status
> >> _______________________________________________
> >> status mailing list
> >> [email-masked]
> >> https://www.ietf.org/mailman/listinfo/status
> >
> >
> > _______________________________________________
> > status mailing list
> > [email-masked]
> > https://www.ietf.org/mailman/listinfo/status
>=20
> _______________________________________________
> status mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/status
>=20

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

___________________________________________________________________________=
______________________________________________

Ce message et ses pieces jointes peuvent contenir des informations confiden=
tielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu=
 ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages el=
ectroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou =
falsifie. Merci.

This message and its attachments may contain confidential or privileged inf=
ormation that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and dele=
te this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been =
modified, changed or falsified.
Thank you.

From: John E Drake <[email-masked]>
To: Mark Townsley <[email-masked]>, Victor Kuarsingh <[email-masked]>
Date: Tue, 3 Sep 2013 13:02:01 +0000
Accept-Language: en-US
Cc: "Roberta Maglione \(robmgl\)" <[email-masked]>, "John G. Scudder" <[email-masked]>, "Alvaro Retana \(aretana\)" <[email-masked]>, Adrian Farrel <[email-masked]>, "[email-masked]" <[email-masked]>, "Stewart Bryant \(stbryant\)" <[email-masked]>
Subject: Re: [Status] Summary of STATUS BOF and the next steps

Hi,

What is this 'segment routing' silliness?  The correct term is 'source rout=
ing'.=20

Yours Irrespectively,

John

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf
> Of Mark Townsley
> Sent: Sunday, September 01, 2013 10:08 AM
> To: Victor Kuarsingh
> Cc: Roberta Maglione (robmgl); John G. Scudder; Adrian Farrel; Alvaro Ret=
ana
> (aretana); [email-masked]; Stewart Bryant (stbryant)
> Subject: Re: [Status] Summary of STATUS BOF and the next steps
>=20
>=20
> On Sep 1, 2013, at 5:38 PM, Victor Kuarsingh wrote:
>=20
> > All,
> >
> > I would also favour "Segment Routing WG" as well.
> >
> > I note this since attempting to come up with an all encompassing
> > acronym will be difficult and Segment Routing is generic enough to
> > associate to multiple functions.
>=20
> Then we can just use "segroute" for the short name. WGs do not have to
> have acronyms, but they do need to have an 8-char limited short name for
> the various automated tools not to break.
>=20
> - Mark
>=20
> >
> > Regards,
> >
> > Victor K
> >
> >
> >
> > On 2013-08-31 6:51 PM, "Roberta Maglione (robmgl)" <[email-masked]>
> > wrote:
> >
> >> +1 for Segment Routing WG
> >>
> >> Roberta
> >>
> >> Sent from my iPad
> >>
> >> On 2013-08-30, at 2:55 PM, "Alvaro Retana (aretana)"
> >> <[email-masked]>
> >> wrote:
> >>
> >>> Segment Routing WG
> >>>
> >>> Sent from my iPhone
> >>>
> >>> On Aug 30, 2013, at 1:39 PM, "Stewart Bryant (stbryant)"
> >>> <[email-masked]> wrote:
> >>>
> >>>> The second task, which hopefully should be relatively easy, is to
> >>>> find a better working name for the WG, since it has been put to me
> >>>> a number of times that STATUS is going to be confusing in text and
> >>>> a difficult search term.
> >>> _______________________________________________
> >>> status mailing list
> >>> [email-masked]
> >>> https://www.ietf.org/mailman/listinfo/status
> >> _______________________________________________
> >> status mailing list
> >> [email-masked]
> >> https://www.ietf.org/mailman/listinfo/status
> >
> >
> > _______________________________________________
> > status mailing list
> > [email-masked]
> > https://www.ietf.org/mailman/listinfo/status
>=20
> _______________________________________________
> status mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/status
>=20

From: Mark Townsley <[email-masked]>
Date: Sun, 1 Sep 2013 19:07:55 +0200
To: Victor Kuarsingh <[email-masked]>
Cc: "Roberta Maglione \(robmgl\)" <[email-masked]>, "John G. Scudder" <[email-masked]>, Adrian Farrel <[email-masked]>, "Alvaro Retana \(aretana\)" <[email-masked]>, "[email-masked]" <[email-masked]>, "Stewart Bryant \(stbryant\)" <[email-masked]>
Subject: Re: [Status] Summary of STATUS BOF and the next steps

On Sep 1, 2013, at 5:38 PM, Victor Kuarsingh wrote:

> All,
>=20
> I would also favour "Segment Routing WG" as well.
>=20
> I note this since attempting to come up with an all encompassing =
acronym
> will be difficult and Segment Routing is generic enough to associate =
to
> multiple functions.

Then we can just use "segroute" for the short name. WGs do not have to =
have acronyms, but they do need to have an 8-char limited short name for =
the various automated tools not to break.

- Mark

>=20
> Regards,
>=20
> Victor K
>=20
>=20
>=20
> On 2013-08-31 6:51 PM, "Roberta Maglione (robmgl)" <[email-masked]>
> wrote:
>=20
>> +1 for Segment Routing WG
>>=20
>> Roberta
>>=20
>> Sent from my iPad
>>=20
>> On 2013-08-30, at 2:55 PM, "Alvaro Retana (aretana)" =
<[email-masked]>
>> wrote:
>>=20
>>> Segment Routing WG
>>>=20
>>> Sent from my iPhone
>>>=20
>>> On Aug 30, 2013, at 1:39 PM, "Stewart Bryant (stbryant)"
>>> <[email-masked]> wrote:
>>>=20
>>>> The second task, which hopefully should be relatively easy,
>>>> is to find a better working name for the WG, since it has
>>>> been put to me a number of times that STATUS is going to
>>>> be confusing in text and a difficult search term.
>>> _______________________________________________
>>> status mailing list
>>> [email-masked]
>>> https://www.ietf.org/mailman/listinfo/status
>> _______________________________________________
>> status mailing list
>> [email-masked]
>> https://www.ietf.org/mailman/listinfo/status
>=20
>=20
> _______________________________________________
> status mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/status

Date: Sun, 01 Sep 2013 11:38:04 -0400
From: Victor Kuarsingh <[email-masked]>
To: "Roberta Maglione (robmgl)" <[email-masked]>, "Alvaro Retana (aretana)" <[email-masked]>
Cc: Adrian Farrel <[email-masked]>, "[email-masked]" <[email-masked]>, "John G. Scudder" <[email-masked]>, "Stewart Bryant \(stbryant\)" <[email-masked]>
Subject: Re: [Status] Summary of STATUS BOF and the next steps

All,

I would also favour "Segment Routing WG" as well.

I note this since attempting to come up with an all encompassing acronym
will be difficult and Segment Routing is generic enough to associate to
multiple functions.

Regards,

Victor K

On 2013-08-31 6:51 PM, "Roberta Maglione (robmgl)" <[email-masked]>
wrote:

>+1 for Segment Routing WG
>
>Roberta
>
>Sent from my iPad
>
>On 2013-08-30, at 2:55 PM, "Alvaro Retana (aretana)" <[email-masked]>
>wrote:
>
>> Segment Routing WG
>> 
>> Sent from my iPhone
>> 
>> On Aug 30, 2013, at 1:39 PM, "Stewart Bryant (stbryant)"
>><[email-masked]> wrote:
>> 
>>> The second task, which hopefully should be relatively easy,
>>> is to find a better working name for the WG, since it has
>>> been put to me a number of times that STATUS is going to
>>> be confusing in text and a difficult search term.
>> _______________________________________________
>> status mailing list
>> [email-masked]
>> https://www.ietf.org/mailman/listinfo/status
>_______________________________________________
>status mailing list
>[email-masked]
>https://www.ietf.org/mailman/listinfo/status